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

On Wed, Jul 10, 2013 at 4:41 PM, David Booth <david@dbooth.org> wrote:

> 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<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 ) .
>

I'd certainly find this comprehensible and following good practice.


>
> 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<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 .
>   }


Which is quite nice. It can even be shortened to:

    SELECT ?ocomp ?item {
      ?ocomp a oa:OrderedComposite;
        oa:order/rdf:rest*/rdf:first ?item .
    }

Cheers,
Niklas


>
>
> David
>
>