Re: rq23 def'n "Pattern Solution" wrong? (and more on BGP')

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