Re: Blank Nodes and SPARQL

Dan Connolly wrote:
> Ron writes...
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Jun/0045.html
> 
>>There is a difference between extending the protocol in a compatible
>>way, and extending it in a conflicting manner.
> 
> 
> yeah... I'm trying to figure out which you're asking for. I wonder
> if a test case clarifies.
> 
> I gather the relevant text is...
> 
> [[
> Blank nodes in queries are distinct from all blank nodes in the data. A
> blank node in a graph pattern does not match a blank node in the data by blank
> node label. A blank node in a query pattern may match any RDF term.
> ]]
>  -- 2.7 Blank Nodes
>  http://www.w3.org/2001/sw/DataAccess/rq23/#BlankNodes

The text in 2.7 includes:
"""
A blank node .. does not match a blank node ... by blank node label.
"""

It's the "by blank node label" that matters most.  I didn't think that labels 
were preserved (or not preserved for that matter) so for compatiblity across all 
systems, and getting the same answers, matching by label can't be done.

> 
> cwm has a mode where it makes up blank nodes based on line/column
> numbers so you can see where they came from and so they're repeatable.
> So we might have data a la...
> 
>  _:l23c14 foaf:mbox <mailto:connolly@w3.org>.
> 
> and we might make a query like...
> 
>  SELECT ?MBOX
>   WHERE { _:l23c14 foaf:mbox ?MBOX. }.
> 
> Now in fact, the bnode in the query *does* match the bnode
> in the data in that case. So it's pretty clear that
> 
>  "A blank node in a graph pattern does not match a blank node in the
>  data by blank node label."
> 
> is misleading. In fact, I think
> 
>  "A blank node in a query pattern may match any RDF term."
> 
> should just be
> 
>  "A blank node in a query pattern matches every RDF term."
> 
> but every is sorta confusing in a way... so maybe
> 
>   "In a query pattern, a blank node is parsed as a variable
>   that is distinct from all other variables in the query."
> 
> so that in the abstract form, query patterns never
> have bnodes at all. Andy, how does that strike you?


Another test here is:

SELECT ?MBOX WHERE { [] foaf:mbox ?MBOX . }

where a bnode where the label is not mentioned.   This was one of the inputs to 
the design from F2F-BOS (as was list forms like "(1 2 3)")

If there are not blank nodes in queries at all, I'm not sure how it helps Ron 
other than by making bNodes in a query pattern an extension.  The syntax can't 
speak it, so the the abstract query pattern can't be sent over the wire compatibly.


RDF/XML says:
http://www.w3.org/TR/rdf-syntax-grammar/

"""
In this case, a blank node identifier can be given to the blank node for 
identifying it in the document. Blank node identifiers in RDF/XML are scoped to 
the containing XML Information Set document information item.
"""

I would also note that the XML Results Format says:

"""
Note: The blank node label I is scoped to the result set XML document and does
not have any association to the the blank node label for that RDF Term in the
query graph.
"""

so the second area of text in 2.7:

"""
The presence of blank nodes can be indicated by labels in the serialization of 
query results. An application or client receiving the results of a query can 
tell that two solutions or two variable bindings differ in blank nodes but this 
information is only scoped to the results as defined in "SPARQL Variable Binding 
Results XML Format" or the CONSTRUCT result form.
"""

is following this pattern.  Being scoped to the XML document does not preclude a 
wider scoping (i.e. uniquer identifiers) but it can't be relied on in all 
implementations.

 Andy

> 
> 
> Meanwhile, if you really mean to use bnodes in
> some session context, I'm not sure you can do that
> in a compatible way. If you use different bnode
> identifiers, they still have to match. i.e.
> 
>  SELECT ?MBOX
>   WHERE { _:l55c33 foaf:mbox ?MBOX. }.
> 
> still has (?MBOX, <mailto:connolly@w3.org>) as a solution,
> even thought the bnode identifiers are different.
> Any piece of software that says that's not a solution
> is not implementing the semantics of SPARQL.
>

Received on Friday, 1 July 2005 16:51:56 UTC