We have come to a conclusion during the call, where we decided to use a
free-text comment approach.
See:
https://github.com/joejimbo/HCLSDatasetDescriptions/issues/65#issuecomment-46861614
Kim
On 23 June 2014 08:45, Alan Ruttenberg wrote:
>
>
>
> On Mon, Jun 23, 2014 at 11:27 AM, Jerven B
On Mon, Jun 23, 2014 at 11:27 AM, Jerven Bolleman wrote:
> Again, I think we should encourage more specificity than the boolean
> property flag.
>
> One academic makes the following statements
>
> _:sillyAcademicsDataset a dct:Dataset ;
> prov:wasDerivedFrom realworld:commercial
Again, I think we should encourage more specificity than the boolean
property flag.
One academic makes the following statements
_:sillyAcademicsDataset a dct:Dataset ;
prov:wasDerivedFrom realworld:commercialDataset .
realworld:commercialDataset a dct:Dataset ;
Yes. And the understandability of the class is just as dependent on the
documentation as understanding the property.
-Alan
On Mon, Jun 23, 2014 at 11:22 AM, Jim McCusker wrote:
> A boolean is good enough to set a class from:
>
> Class: OpenLicenseData
> EquivalentClass: hasOpenLicense value tru
A boolean is good enough to set a class from:
Class: OpenLicenseData
EquivalentClass: hasOpenLicense value true
Class: ClosedLicenseData
EquivalentClass: hasOpenLicense value false
It makes the properties more specific, sure, but it's more than enough to
go on in many situations.
Jim
On Mon,
On Mon, Jun 23, 2014 at 11:08 AM, Joachim Baran
wrote:
>
> On 23 June 2014 06:37, Alan Ruttenberg wrote:
>
>> In the case that the license is not asserted it distinguishes the case
>> where the publisher has made an affirmative effort to determine what the
>> license is, or not.
>>
> I cannot
On 23 June 2014 06:37, Alan Ruttenberg wrote:
> In the case that the license is not asserted it distinguishes the case
> where the publisher has made an affirmative effort to determine what the
> license is, or not.
>
I cannot fathom how this could be inferred from the truth value of a bit.
On Monday, June 23, 2014, Jerven Bolleman wrote:
> Booleans, in this case, are like answers on a math exam without
> showing your work. They might be right or they might be wrong, but no
> one knows how you got there.
Mind your metaphors ;)
How does the *datatype* make a difference on this matt
On Monday, June 23, 2014, Joachim Baran wrote:
>
> On 22 June 2014 19:30, Alan Ruttenberg > wrote:
>
>> What do you have against booleans? :)
>>
> My points were:
>
>With a boolean solution -- especially when it only denotes whether
> license lookup was tried -- it is not clear what inform
Booleans, in this case, are like answers on a math exam without
showing your work. They might be right or they might be wrong, but no
one knows how you got there.
I think it is critical in the semantic web that you describe what you
know (you might still be wrong) as in a world where we try to sha
On 22 June 2014 19:30, Alan Ruttenberg wrote:
> What do you have against booleans? :)
>
My points were:
With a boolean solution -- especially when it only denotes whether
license lookup was tried -- it is not clear what information that bears.
Why would this boolean ever be set to false? Re
What do you have against booleans? :)
That seems like a sort of "too many notes" comment about Mozart's work, if
you can reach far enough to follow the analogy.
-Alan
On Fri, Jun 20, 2014 at 3:55 PM, Joachim Baran
wrote:
> I am sure we can work out the exact predicate later. The issue I rai
I am sure we can work out the exact predicate later. The issue I raised
was about not using boolean.
On 20 June 2014 12:51, Oliver Ruebenacker wrote:
>
> Hello,
>
>
> On Fri, Jun 20, 2014 at 3:44 PM, Joachim Baran
> wrote:
>
>>
>> On 20 June 2014 12:41, Oliver Ruebenacker wrote:
>>
>>>
Hello,
On Fri, Jun 20, 2014 at 3:44 PM, Joachim Baran
wrote:
>
> On 20 June 2014 12:41, Oliver Ruebenacker wrote:
>
>> Also, makes me wonder why the EBI has not already been contacted and
>> the license determined? Is that because we didn't have the resources to do
>> so or because diffe
On 20 June 2014 12:41, Oliver Ruebenacker wrote:
> Also, makes me wonder why the EBI has not already been contacted and the
> license determined? Is that because we didn't have the resources to do so
> or because different end users might end up being granted different
> licenses?
>
That is m
he
>>> > assertion remains true. If the predicate is whether we *have*
>>> determined
>>> > license then the assertion needs to be retracted when we do. When
>>> possible
>>> > we try to make statements that remain true.
>>> >
>>
On 20 June 2014 12:26, Oliver Ruebenacker wrote:
> Looks more like a piece of advice rather than a label.
>
We could use rdfs:comment instead.
at 3:06 PM, Alan Ruttenberg
>>> wrote:
>>> > The reason I labeled it tried-to-determine-license is that that way the
>>> > assertion remains true. If the predicate is whether we *have*
>>> determined
>>> > license then the assertion needs to be retrac
t way the
>> > assertion remains true. If the predicate is whether we *have* determined
>> > license then the assertion needs to be retracted when we do. When
>> possible
>> > we try to make statements that remain true.
>> >
>> > When probing for a licens
we do. When
> possible
> > we try to make statements that remain true.
> >
> > When probing for a license, first check dc:license, and if it is absent,
> > check :tried-to-determine-license.
> >
> > In user interfaces there's no reason to show both. It&#
obing for a license, first check dc:license, and if it is absent,
> check :tried-to-determine-license.
>
> In user interfaces there's no reason to show both. It's perfectly reasonable
> to use these properties to decide whether to show "License: Unknown"
>
> -Ala
e statements that remain true.
>>
>> When probing for a license, first check dc:license, and if it is absent,
>> check :tried-to-determine-license.
>>
>> In user interfaces there's no reason to show both. It's perfectly
>> reasonable to use these proper
is absent,
> check :tried-to-determine-license.
>
> In user interfaces there's no reason to show both. It's perfectly
> reasonable to use these properties to decide whether to show "License:
> Unknown"
>
> -Alan
>
>
> On Wed, Jun 18, 2014 at 8:46 AM, M
check dc:license, and if it is absent,
check :tried-to-determine-license.
In user interfaces there's no reason to show both. It's perfectly
reasonable to use these properties to decide whether to show "License:
Unknown"
-Alan
On Wed, Jun 18, 2014 at 8:46 AM, M. Scott Marsha
Just a slight tweak to Alan's suggestion (thanks Alan):
:determined-license "true"^xsd:Boolean
-Scott
On Wed, Jun 18, 2014 at 2:36 PM, Alan Ruttenberg
wrote:
> I concur. This is clear from the semantics of OWL. Understand the difference
> between integrity constraints and OWL assertions.
>
> If
I concur. This is clear from the semantics of OWL. Understand the
difference between integrity constraints and OWL assertions.
If you want to say that there was an attempt to find a license and that it
couldn't be found, say that. You could do so as an annotation on the axiom,
or as a distinct pro
Hello,
On Mon, Jun 16, 2014 at 12:10 PM, Jerven Bolleman wrote:
> Hi Alasdair,
>
> I think you are closing the world the wrong way. Both in limiting a
> dataset to have one license and secondly by having an "unknown" string
> to encode that you don't know something.
> Instead of using "unkn
:* Re: License unknown
Hi Jerven,
We are trying to ensure that a license is provided for a dataset, and that
only one license is provided. (We are closing the world in certain areas.)
Our proposed solution is written up at
https://github.com/joejimbo/HCLSDatasetDescriptions/issues/65
Hi Alasdair,
I think you are closing the world the wrong way. Both in limiting a
dataset to have one license and secondly by having an "unknown" string
to encode that you don't know something.
Instead of using "unknown" you should use a blank node.
cc:CC0 owl:sameAs "unknown"
is plain wrong and
Hi Jerven,
We are trying to ensure that a license is provided for a dataset, and that only
one license is provided. (We are closing the world in certain areas.)
Our proposed solution is written up at
https://github.com/joejimbo/HCLSDatasetDescriptions/issues/65
Alasdair
On 2 Jun 2014, at 16:47
30 matches
Mail list logo
