- From: <jos.deroo@agfa.com>
- Date: Thu, 8 Sep 2005 01:26:14 +0200
- To: franconi@inf.unibz.it
- Cc: bparsia@isr.umd.edu, connolly@w3.org, public-rdf-dawg@w3.org, public-rdf-dawg-request@w3.org
[...]
> However, we spotted a case where the SPARQL document
> fails to find such redundant triples in the answer,
> if you want to take RDF-MT seriously. Consider the
> following RDF graph:
>
> <http://example.org/book/book1> dc:title "SPARQL" .
> _:b dc:title "SPARQL" .
>
> According the the RDF-MT semantics, this graph contains
> a redundant triple (the second triple with the bnode),
> since the original graph with that triple and the
> graph without that triple are equivalent, i.e., they
> RDF-entails each other. I.e., the above graph is
> RDF-equivalent according to RDF-MT to the graph:
>
> <http://example.org/book/book1> dc:title "SPARQL" .
>
> In other words, the deductive closures according to
> RDF-MT of the two graphs above *are the same*. And I
> have to get the *same answer* when I query these two
> graphs!
> So, when I query each of the above graphs as follows:
>
> SELECT ?x
> WHERE { ?x dc:title "SPARQL" }
>
> I should *not* get the bnode coming from the redundant
> triple, but simply {<http://example.org/book/book1>}.
Otoh, for
CONSTRUCT { ?x dc:title "SPARQL" }
WHERE { ?x dc:title "SPARQL" }
I actually get
<http://example.org/book/book1> dc:title "SPARQL".
_:b_0_ dc:title "SPARQL".
which I assume to be fine, no?
--
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
Received on Wednesday, 7 September 2005 23:26:39 UTC