- 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