- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 10 Jul 2013 12:16:36 -0500
- To: David Booth <david@dbooth.org>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, 'Linked JSON' <public-linked-json@w3.org>, 'RDF WG' <public-rdf-wg@w3.org>, 'public-openannotation' <public-openannotation@w3.org>
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