- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Thu, 2 Mar 2006 02:08:58 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On 1 Mar 2006, at 22:08, Pat Hayes wrote: >> 1) In the first part of my original message I argued that, by >> carefully >> looking at the normative semantics RDF-MT, bnodes are always >> interpreted autonomously within the RDF graph where they appear, no >> matter where bnodes come from or which (abstract) syntax identity >> they >> have. So, while this is an argument againts having BGP', this also >> shows that it is absolutely harmless to have BGP'. > > The RDF MT defines a graph simply as a set of triples, so itself > does not provide any way to determine the scope of a blank node. A > single triple, and any bnode which it contains, might occur in many > different RDF graphs. And the RDF MT refers to graphs, not to > entities such as query patterns and answer binding sets, neither of > which are RDF graphs. The SPARQL spec does not mention where the > RDF graph boundaries are intended to be maintained, so it is up to > us to make sure that the definitions draw them correctly. G' is a graph, S(BGP') is a graph, (G' union S(BGP')) is a graph, the CONSTRUCTed graph from an answer set is a graph. The abstract syntax representations of these graphs shouldn't care about the identity of the bnodes in them (since their interpretation is autonomously defined), nor should limit them in any way. >> 2) In the second part of my original message I argued that if we >> don't >> have BGP' then the abstract syntax of answer sets is limited in a >> very >> peculiar way, disallowing answer sets that contains bnodes that may >> appear in the query. > > But this is not a limitation, since given the document conventions > already in use,there is no way they could possibly share a bnode. What you are saying has nothing to do with the abstract syntax; this has to do with the concrete document syntax. The definitions in 2.5 shape the way an answer set could look like in its abstract syntax, independently on its linearisation. >> This restriction is useless, since we know (point >> 1 above) that bnodes are always interpreted autonomously within the >> graph where they appear, so having the same bnodes as in the query is >> fine anyway. This restriction is bad, since not every equivalent >> answer >> set would be legal in sparql. > > Can you elaborate on that last point? Perhaps with an example? It > seems to be a new point in this discussion. Uh? This has been my point since ever. Here we go again: For example, suppose to have two engines that, given the same data and the same query, differ only on how they represent (in abstract syntax) the final CONSTRUCTed graph. The first one chooses not to use in the final CONSTRUCTed graph any bnode appearing in the query. The second one uses in the final CONSTRUCTed graph some bnode appearing in the query. The two CONSTRUCTed graphs are graph-equivalent, but if we choose not to have BGP' then the second engine would not satisfy the conditions in 2.5, and therefore could not be called SPARQL compliant. Compare this with "2.7 Blank Nodes in Query Results" <http:// www.w3.org/2001/sw/DataAccess/rq23/#BlankNodesInResults>. There it is said that the bnode identity in the result is obviously irrelevant: "These two results have the same information: the blank nodes used to match the query are different in the two solutions. There is no relation between using _:a in the results and any blank node label in the data graph." However, without BGP' you limit the choice of bnodes in the result *not* to include some bnodes, namely the ones appearing in the query. This is bad. cheers --e.
Received on Thursday, 2 March 2006 01:09:23 UTC