Re: JSON-LD Telecon Minutes for 2013-07-02

On 07/09/2013 11:23 PM, Pat Hayes wrote:
>
> On Jul 9, 2013, at 4:23 AM, Markus Lanthaler wrote:
>
>> On Tuesday, July 09, 2013 6:46 AM, Pat Hayes wrote:
>>> On Jul 8, 2013, at 1:01 PM, Robert Sanderson wrote:
>>>> Something like:
>>>>
>>>> rdf:listHead  -- The object, which must be a blank node with
>>>> rdf:type
>>> rdf:List, is the first entry in a list associated with the
>>> subject resource.
>>>
>>> I guess I don't follow this. If the object is of type LIst, and
>>> it is the first item in a list, then you have a list of lists.
>>> Which is legal, but I don't see how it helps with the problem we
>>> have here. And what does "associated with" mean?
>>
>> I think was Robert meant was something like
>>
>> <> rdf:ListHead _:head . <> ... other properties of <> ... _:head
>> rdf:type rdf:List . _:head rdf:first ... _:head rdf:rest _:item2 .
>> _:item2 ...
>
> Ah, OK. But then we get back to my previous point. All this wriggling
> can't get us past the fact that if this means what it is supposed to
> mean, then the truth conditions on rdf:ListHead are going to be that
>
> <1> rdf:ListHead <2> is true just when <1> = <2>.
>
> This is still owl:sameAs with a different name (or maybe sameAs
> restricted to lists), and so it is still **logically valid** to
> substitute one side of it for the other. In other words, your graph
> above will semantically entail
>
> <>...other properties of <> .. <> rdf:type rdf:List . <> rdf:first
> ... <> rdf:rest _:item2 . etc.
>
> which David doesn't want it to. So you have gained nothing over
> simply re-using owl:sameAs, as far as David's concerns go.
>
> There is a basic point here about how semantics works. The word
> "entail" comes with a fixed meaning: A entails B means, whenever (ie
> in any interpretation in which) A is true, then B is also true. The
> semantics determines the truth conditions on expressions, and then
> entailment comes along as an, er, logical consequence of those truth
> conditions. It does not mean something like "you can make this
> inference because I like this kind of inference"; and similarly not
> being entailed does not mean "You can't do that because i don't want
> you to do that."
>
> If you can find a way to specify how
>
> <A> rdf:LIstHead <B> .
>
> can be made true without it meaning A=B, then you might be able to
> escape David's concerns. I would also be quite interested.

But AFAICT no sense of equality is needed at all, so I don't think the 
problem needs to even come up.  AFAICT they just need to use some 
property to associate -- not equate -- a list with some other data.

Here is an example, inspired by the oa:Composite example in
http://www.openannotation.org/spec/core/multiplicity.html#Composite
However I will use the term oa:OrderedComposite instead of oa:List, to 
avoid confusion with rdf:Lists .  An oa:OrderedComposite is an 
oa:Composite that additionally has an oa:order property, which is used 
to attach an rdf:List that specifies the ordering of the oa:items:

   :anno1 a oa:Annotation ;
     oa:hasBody :body1 ;
     oa:hasTarget :ocomp1 .
   :ocomp1 a oa:OrderedComposite ;
     oa:item :target1 , :target2 ;
     oa:order ( :target1 :target2 ) .

It is redundant to specify the unordered items using oa:item, but this 
is done as a convenience, as the spec suggests:
http://www.openannotation.org/spec/core/multiplicity.html#List
[[
Annotation producers SHOULD provide both oa:item and the list 
predicates. This allows consuming clients to fall back to processing the 
list in an unordered fashion without iterating through the linked list 
construction.
]]

However, I will note that it is now quite easy in SPARQL 1.1 (using 
property paths) to grab all of the items of an rdf:List in an unordered 
fashion, like this:

SELECT ?ocomp ?first
WHERE {
   ?ocomp a oa:OrderedComposite ;
     oa:order ?list .
   ?list rdf:rest* ?sublist .
   ?sublist rdf:first ?first .
   }

David

Received on Wednesday, 10 July 2013 14:42:16 UTC