Re: Draft response to: Re: major technical: blank nodes

>This is a response to Pat Hayes's email in the archive
>dated 26 Jan 2006 16:50:59 -0600.  Thank you for your
>detailed comments.  They have been very helpful to me personally
>in understanding the draft.
>The reason for my reply is that I believe we can do a better job
>in our treatment of blank nodes in SPARQL.

I honestly don't think we can, given the many constraints we need to 
satisfy. What we can do a better job of, however, is *explaining* the 
treatment.

>   I first came to an
>earlier draft after reading the RDF Recommendations.  I found
>the SPARQL draft very confusing and frustrating.  My essential
>complaint was that SPARQL uses one term for two concepts:
>
>a) RDF blank nodes, which are nodes in a graph with no label, and
>
>b) SPARQL blank nodes, which are lexical tokens in a SPARQL query.
>
>Pat Hayes's email rejects this interpretation.

Well, it wasn't the one I had in mind when we were writing the spec, 
put it that way, and it wasn't my intention. Unfortunately I can't 
speak for what was in anyone else's mind.

BTW, my experience on SPARQL has led me to think that we didn't do a 
good enough job of explaining the idea of blank nodes in the RDF 
spec. You seem to have grokked it thoroughly.

>However, let me give the reasons that I held it, based on my
>reading of RDF and SPARQL both:
>
>a) According to the "RDF Concepts and abstract syntax" Recommendation,
>section 6.6 "Blank nodes", the set of RDF blank nodes is distinct
>from the set of IRIs and "Otherwise, this set of blank nodes
>is arbitrary.  RDF makes no reference to any internal structure
>of blank nodes".  That is, RDF blank nodes have no label.

They have no label *in an RDF graph*. Other document conventions 
might 'label' them in ways determined by the specs for those 
documents.

>b) The RDF Primer section 2.3 "Structured property values and blank
>nodes" Figure 6 "Using a blank node" shows a blank node as having
>no label.  It goes on to describe "blank node identifiers" of which
>it says "...blank node identifiers are not considered to be actual
>parts of the RDF graph."
>c) In our own working draft Section 2.5.3 "Example of basic graph
>pattern matching" second sentence under the first box, it says
>"The label information is not in the graph."
>
>d) Section 2.8.3 "Blank nodes" says "Blank nodes have labels
>which are scoped to the query".  However, RDF blank nodes have
>no notion of scope (they simply exist, just as IRIs and literals
>exist, with no notion of scope)

Exactly. But look at that sentence that you quote: the LABEL is 
scoped to the query, not the blank node. Scoping, as you say, is a 
lexical matter.

>.  Scope is a lexical concept
>(the portion of a query text in which an identifier has a single
>referent).
>
>My summary is that the consistent stance of the RDF Recommendations
>is that blank node identifiers are an artefact of serialization.

Exactly. We assumed it would be permissible to be allowed a slight 
abuse of terminology, in using the serialization token to refer to 
the blank node it is a token of (in the context of the document under 
discussion: in the above case, the query document): after all, that 
is what these tokens are FOR, to refer to blank nodes. This kind of 
abuse of terminology is widely used and familiar, and it avoids what 
would otherwise be rather tedious circumlocutions like "the blank 
node whose token is", which is like saying "the person whose name is 
Fred" rather than just saying "Fred".

But given your confusion after what is clearly an extremely careful 
reading, we should perhaps have been more pedantic, indeed.

>Now if a reader comes to the SPARQL draft with that model, he
>finds it very confusing (certainly I did).

Apologies. SPARQL is indeed based on that model, and so a reader 
making your voyage should find it more transparent.

>  For example, section
>2.4 talks about how to extend a pattern solution S to graph
>patterns.  It says "If v is not in the domain of S, then S(v)
>is defined to be v."  Applied to SPARQL blank nodes such as
>_:a, this says S(_:a) is _:a.  Fine; it is still a lexical
>token; there has been no mention of creating a blank node
>corresponding to the label _:a.

Oh, but come come, surely now you are being a little TOO pedantic. If 
a document claims to be using (near) RDF conventions and uses an RDF 
blank node identifier syntax, surely it is not unreasonable to 
presume that this is intended to indicate a blank node in an RDF 
graph(-like) structure of which the document is a lexicalization. We 
have earlier defined SPARQL patterns as RDF-graph-like things. 
containing genuine blank nodes. True, we do not formally distinguish 
patterns from their lexicalizations, but it seems clear that the 
intention here is to continue and slightly extend the RDF model to 
similar structures containing variables. No?

>  As a result, the mapping of
>a triple pattern, such as
>
>  ?x :v _:a
>
>is
>
>  (S(?x), :v, _:a)
>
>and there still is no RDF blank node.

What else would _:a be considered to be a lexicalization of?

>Consequently, the result
>of the mapping is not an RDF triple.  Then we come to
>setion 2.5.1 "General framework" and the definition of "basic
>graph pattern E-matching".  This definition posits a basic
>graph pattern BGP' and a scoping graph G' such that "G' and
>BGP' do not share any blank node labels".

Whoops. That shouldn't say 'label', indeed.

>  But how can they?
>BGP' is a triple pattern and might contain SPARQL blank nodes;
>G' is an RDF graph and as such does not contain anything that
>can be called a blank node label at all (though serializations of G'
>might).
>
>After studying Pat Hayes's email, my conclusion is that the
>text is using blank node identifiers as proxies or surrogates
>for the blank nodes themselves.

Yes, a fair diagnosis. That is exactly the 'abuse of notation' I 
mentioned above.

>To clarify our text, my proposed resolution is as follows:
>
>a) We should adopt the term "blank node identifier" for what I have
>been calling SPARQL blank nodes.  This would harmonize with RDF
>Recommendations, which use this term when talking about
>character strings associated with blank nodes for identification
>purposes.  For example, section 2.1.4 would be renamed "Syntax
>for blank node identifiers".  We should scan the document for
>other occurrences of "blank node", and, as appropriate, change to
>"blank node identifier".

Good idea.

>
>b) We state explicitly that for each distinct blank node identifier,
>a distinct blank node is created for the purposes of processing
>the query, different from any blank node in the graphs in the
>query's dataset.

Er...be careful. I don't think we should phrase this in terms of 
*creation* of blank nodes; that's a bit like saying that when you 
write a numeral, you create a number. Documents written using RDF 
lexicalization conventions indicate RDF abstract graph structures 
which might contain blank nodes: OK so far. The only questions that 
we have to determine about blank nodes (the only question that can be 
asked about them, in fact) has to do with their identity. If a single 
document scope uses several occurrences of a bnode identifier, then 
they identify the same bnode in whatever structure is indicated by 
the document. Otherwise, all that SPARQL has to say is when two 
bnodes are NOT the same, which is what the 'scoping graph' 
definitions are all about.

>We can also say that the reader may wish to
>think of the blank node identifiers as proxies or surrogates for
>these created blank nodes.

Why do we need to say this? This is just part of the RDF graph 
syntax/lexicalization model. At most, I think we might say explicitly 
that SPARQL syntax is an extension of RDF syntax, and inherits the 
RDF distinction between lexical scope of bnodeIDs, and the actual 
occurrence of a bnode in an RDF graph.

>  Perhaps this might go in Section 2.1.4.
>
>c) In section 2.1.8 "Result descriptions used in this document"
>in the definition of RDF term, the created blank nodes  should be
>explicitly listed as part of RDF-B.  (Note that even if one
>believed that blank node identifiers were blank nodes all along,
>this did not put them in RDF-B because they were not part of
>any graph.)

I agree we should be more explicit about the bnode/id distinction here.

>
>d) In section 2.4 "Pattern solutions", definition of "pattern
>solution", we say that the domain of S is extended to include
>blank node identifiers by mapping each blank node identifier to
>the blank node that was created for it in item b) above.

Both the above are supposed to be handled by the 'scoping graph' 
idea. The scoping graph's sole purpose is to be the source of bnodes 
substituted for pattern variables in the answer document, to allow 
this source to be something different from (but isomorphic to) the 
source graph, and to be unique for each query. So rather than 
'creating' bnodes, SPARQL technically 'creates' a scoping graph and 
then simply *uses* the bnodes in it. I guess it comes to the same 
thing, but this way of talking about it makes sure that the bnodes in 
the scoping graph fit into an isomorphic structure as the target 
graph, so that the answer document is obliged to treat these "bnodes 
from the (current bnode-substituted version of the) target graph" in 
a way that makes sense across several answers. It is hard to express 
this as a condition on bnodeIDs.

>e) Somewhere we make the observation that the result of
>applying a pattern solution S to a triple pattern is an RDf triple.
>Thus if BGP is a basic graph pattern, then S(BGP)
>is an RDF graph.
>
>f) delete the definition of "basic graph pattern equivalence"
>(changes proposed below make it dispensable).
>
>g) delete the definition of "scoping graph", also unneeded.

I think it (or something like it) is needed, see above.

>h) Reword the definition of basic graph pattern matching
>to use the notion of graph merge found in the RDF Recommendations.
>The revised definition is something like this: "Given an
>entailment regime E, a basic graph pattern BGP, an RDF graph
>G and a pattern solution S whose range is a subset of B, then
>BGP E-matches with pattern solution S on graph G with
>respect to scoping set B if G E-entails the graph merge of G
>and S(BGP)."  Actually, with the statement that the created
>blank nodes are distinct from all blank nodes in the dataset,
>a simple set union will suffice, though we may wish to stick
>with the RDF notion of merge for consistency with RDF.

It's not that simple, unfortunately. We went through a huge 
discussion over this, and simply using merging doesn't cut it. The 
scoping graph ideas was one result of this long discussion (which is 
in the email record, should you wish to peruse it, though Im not sure 
its a good idea :-)

>i) If we want to keep the technique of renaming blank node
>identifiers, we move that outside the boxed definition into
>explanatory text.  For example, "The graph merge referred to
>in the preceding definition can be thought of as using
>blank node identifiers as proxies for the blank nodes.  In that
>case, care must be taken to ensure that the blank node identifiers
>of G are different from all blank node identifiers in BGP.
>Let G' and BGP' be serializations of G and BGP, respectively,
>such that all blank node identifiers in G' are different from
>all blank node identifiers in BGP'.   Then G' UNION BGP'
>is the serialization of some graph G2.  S is a solution for BGP using
>E entailment if G E-entails G2."
>
>j) In section 2.5.2 "SPARQL basic graph pattern matching" last
>paragraph, we can clarify that pattern solutions are unique,
>not just unique up to blank node renaming.  The so-called "blank
>node renaming" is an artefact of serialization.

Well, strictly yes: but there is a similar notion which we might call 
blank node substitution, and they aren't proof against that, so in 
fact they aren't *unique*, strictly speaking. The point is that blank 
nodes do have an identity, according to the RDF model, so if one 
takes an RDF graph and a set of blank nodes which do not occur in it, 
and substitutes these for the bnodes in the graph, then you do have a 
*different* graph. Isomorphic, true: but different, all the same. And 
this is not an artefact of serialization, but is inherent in the idea 
that blank nodes can be distinguished from one another, which if you 
think about it is about all that can be done with them. This is why 
RDF needed to distinguish between merging and taking a simple union 
when talking about graphs (not serializations of a graph).

>  The last sentence
>is thus "the serialization of a set of all pattern solutions
>is unique up to blank node identifiers".  We can also delete the phrase
>"...possibly with blank nodes renamed" earlier in the paragraph,
>because a pattern solution is not actually concerned with
>assigning blank node identifiers.

But I agree we should go through the text carefully and try to remove 
as many traces as possible of the token/node ambiguity. There is 
definitely a serious muddle in the current version of 2.5.1., which 
is why I voted against it.

Pat


>Fred


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 9 June 2006 16:40:12 UTC