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

On Jul 10, 2013, at 9:41 AM, David Booth 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 thishead
>> 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.

Well, I was looking at the example given, which starts with the triple

< > rdf:ListHead _:head .

It is clear from the other triples that the blank node _:head here denotes the list described by the RDF vocabulary (In all interpretations which satisfy all the triples, etc..)  And I presume that < > is supposed to be an IRI which also denotes that same list, right? (If not, what does it denote?) And this is, again if I understand the example, true just because these two expressions do denote the same list. (If not, what *are* the truth conditions on rdf:ListHead? A relation which is true just when its arguments are equal *is* equality, even if you choose to call it "association".)

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

Here, the oa:OrderedComposite is not in fact a list, I take it, but some other kind of structure, eg one without an order. Because if it is a list, then this relationship is equality whether or not it is called equality. 

Pat


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

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 10 July 2013 17:17:45 UTC