- From: Axel Polleres <axel.polleres@urjc.es>
- Date: Fri, 09 Feb 2007 02:06:44 +0100
- To: Graham Klyne <GK@ninebynine.org>
- CC: www-rdf-logic@w3.org
Graham Klyne wrote: > Axel Polleres wrote: > >>Hi all, >> >>I was studying the RDF semantics document once again in some detail and >>it looked to me I found a bug in an example in the end of section 3.3.1. >>Since I doubt that, I was asking myself whether somebody here can help >>me to get the knot out of my head.... >> >> >> http://www.w3.org/TR/rdf-mt/#Reif >> >> >> >>In the end of that section, it is stated that >> >>"For example, >> >>_:xxx rdf:type rdf:Statement . >>_:xxx rdf:subject <ex:subject> . >>_:xxx rdf:predicate <ex:predicate> . >>_:xxx rdf:object <ex:object> . > > >>_:yyy rdf:type rdf:Statement . >>_:yyy rdf:subject <ex:subject> . >>_:yyy rdf:predicate <ex:predicate> . >>_:yyy rdf:object <ex:object> . > > >>_:xxx <ex:property> <ex:foo> . >> >>does not entail >> >>_:yyy <ex:property> <ex:foo> ." >> >> >> This is at the very least strange for me... and I think simply wrong. > > > (From my distant recollection of working group discussion on this point...) > > This example was added to the spec to make a specific point about the nature of > the "reification" vocabulary in RDF -- it is possible to define the semantics to > work either way and reasonable people may disagree about whether this is the > right choice. > > In this case, the nodes _:xxx and _:yyy are effectively described as referring > to specific instances of statements -- it is possible for two logically > equivalent statements to be made under different circumstances. > > The motivation for this particular choice was that the more compelling > reification use cases surveyed were related to provenance applications (who said > what, and when), which required the (weaker) semantics exemplified above. > (consider that <ex:property> and <ex:foo> correspond roughly to "said by" and > "John", and that one might also want to describe a logically equivalent > statement that was "said by" "Jack", maybe made at a different time (i.e. the > example offered by Alex). Dear Graham, I think I have no problems understanding what the example *means* to tell me, but what I simply claim is that the graph G1: _:yyy <ex:property> <ex:foo> . *is* entailed by the graph G0: _:xxx rdf:type rdf:Statement . _:xxx rdf:subject <ex:subject> . _:xxx rdf:predicate <ex:predicate> . _:xxx rdf:object <ex:object> . _:yyy rdf:type rdf:Statement . _:yyy rdf:subject <ex:subject> . _:yyy rdf:predicate <ex:predicate> . _:yyy rdf:object <ex:object> . _:xxx <ex:property> <ex:foo> . but the example claims the opposite. if you'd write instead that G0 does not entail G2 _:xxx rdf:type rdf:Statement . _:xxx rdf:subject <ex:subject> . _:xxx rdf:predicate <ex:predicate> . _:xxx rdf:object <ex:object> . _:yyy rdf:type rdf:Statement . _:yyy rdf:subject <ex:subject> . _:yyy rdf:predicate <ex:predicate> . _:yyy rdf:object <ex:object> . _:xxx <ex:property> <ex:foo> . _:yyy <ex:property> <ex:foo> . then I would think it's fine, but the single triple graph G1 *is* entailed. This is more or less what I already replied to denny, who made a similar argument to yours. I mean to say that the example is at least misleading, easy to be misunderstood and should be clarified... although, I don't know whether further work is planned in the nearer future. Probably you can give more hints here? best regards, Axel > There were examples raised requiring a stronger form of semantics (i.e. that the > statement given IS entailed), but they were felt to be more marginal. But > mainly, for the sake of consistency, the working group had to make a choice, and > that was it. The wider problem of solving semantics for all these use cases was > out of scope for the working group charter (which was to clarify RDF as > originally designed). Personally, I think there are more fruitful ways than > "reification" to address these problems, such as named graphs. > > #g > -- Dr. Axel Polleres email: axel@polleres.net url: http://www.polleres.net/
Received on Friday, 9 February 2007 01:22:54 UTC