Re: GRAPH details and test cases

Lee Feigenbaum wrote:
> Hi DAWGs,
> 
> I've been working through a few cases involving the GRAPH keyword that 
> weren't immediately obvious to me from the spec. For some of them, I've 
> included test cases that demonstrate what I believe the semantics to be 
> (and, in most cases, what SPARQLer seems to do). For one, I have a 
> question on the appropriate behavior.
> 
> 
> 1/ Nested GRAPH statements
> 
> I didn't find any examples or tests that involved nested GRAPH statements, 
> but the spec made it pretty clear what should happen and SPARQLer agrees.
> 
> ng1.n3:
> 
> :s :p :o, :o1 .
> 
> ng2:n3:
> 
> :s :p :o, :o2 .
> 
> query:
> 
> SELECT ?o 
> FROM NAMED <ng1.n3>
> FROM NAMED <ng2.n3>
> {
>   GRAPH <ng1.n3> {
>     GRAPH <ng2.n3> {
>       :s :p ?o .
>     }
>   }
> }
> 
> results:
> 
> ?o/:o
> ?o/:o2
> 
> why? GRAPH takes the given named graph and places it as the default graph 
> in the RDF dataset against which the inner graph pattern is matched. So, 
> nested graphs basically act as a stack of default-graph contexts for the 
> graph patterns that they contain.

What were you expecting?  GRAPH <ng2.n3> makes ng2:n3 the target graph for the 
pattern { :s :p ?o }, which gives the results shown.  In stack terms, it is a 
stack of names, the active one being the stack front.  There's not merging of 
graphs

?o/:o
?o/:o2

match from ng2.n3

GRAPH <ng1.n3> {
   ?a ?b ?c . 		# Matches on ng1.n3
     GRAPH <ng2.n3> {
       :s :p ?o .	# Matches on ng2.n3
     }
   ?d ?e ?f . 		# Matches on ng1.n3
   }

> 
> 
> 2/ using blank nodes for graph parameter
> 
> As I would expect, blank nodes act like variables when placed as the 
> parameter to the GRAPH keyword. What I wanted to determine was which blank 
> node label scope such a blank node would be.
> 
> dg.n3:
> 
> :s :p <wrong.n3> .
> 
> ng1.n3:
> 
> :x :y :z .
> 
> query:
> 
> SELECT *
> FROM <dg.n3>
> FROM NAMED <ng1.n3>
> {
>   :s :p _:g .
>   GRAPH _:g { ?s ?p ?o }
> }
> 
> results:
> 
> (no results)
> 
> So, _:g is scoped to the graph pattern in which the GraphGraphPattern 
> occurs (according to SPARQLer's behavior). I sort of assumed this would be 
> the case, but would argue that it's not clear from the spec. which states 
> (in 2.5.4) "...the scope of the blank node label being the basic graph 
> pattern." The _:g parameter to the GRAPH clause isn't actually in any BGP, 
> so it's unclear from the spec what it's (the label's) scope should be.

Fred has suggested a syntax change that would remove blank nodes from the 
graph name slot of GRAPH.  I agree that this would be a good change.

[25] GraphGraphPattern ::= 'GRAPH' VarOrBlankNodeOrIRIref GroupGraphPattern

becomes

[25] GraphGraphPattern ::= 'GRAPH' VarOrIRIref GroupGraphPattern

and
[43] VarOrBlankNodeOrIRIref ::=  Var | BlankNode | IRIref

can be dropped.

Under no interpretation of blank nodes that has been suggested can a blank 
node match in "GRAPH _:a" because the RDF dataset is not a value to be matched.


> 
> 3/ variable as parameter to GRAPH which matches a bnode
> 
> dg.n3:
> 
> :s :p _:b .
> 
> ng1.n3:
> 
> :x :y :z:
> 
> query:
> 
> SELECT *
> FROM <dg.n3>
> FROM NAMED <ng1.n3>
> {
>   :s :p ?g .
>   GRAPH ?g { ?s ?p ?o }
> }
> 
> results:
> 
> I'd expect no results. ?g binds to a bnode and there's no entry in the 
> named grpah part of the RDF dataset whose first component is a bnode. 
> SPARQLer reacts rather strangely, giving me an empty result (not an empty 
> solution set -- no exception and no XML document or JSON structure 
> whatsoever). I think that the intended semantics are clear here, so just a 
> heads-up that SPARQLer behaves strangely in this case.

Bug - it was over zealous in the internal consistency checking aka an 
exception  :-)  Now returns an empty result set - fixed in ARQ CVS.

	Andy

> 
> Lee
> 
>

Received on Monday, 26 June 2006 09:13:39 UTC