Re: Comments about blank nodes in Editors' draft of SPARQL update

Hi Peter,

Thanks for your comments. Please, first note that the Editor's draft of SPARQL1.1 update underwent some significant changes recently, so not all of the text passages you quote are still in the current draft.

> 1/ "Blank node labels in QuadDatas are assumed to be disjoint from the
> blank nodes in the Graph Store and will be inserted as new blank nodes. "
>  Well, in some sense, the label is going to be disjoint from any blank
>  node, as these are two different sorts of things. 

We removed references to "blank node labels" or blank node "identifiers" and only uniformly speak about blank nodes now in the document.

> I suggest using the RDF graph merge operation instead of insert.

The definition of RDF graph merge from rdf-mt is not clear about whether/which blank nodes should be changed. We aim to preserve the blank nodes in GS, while only making sure that the newly inserted blank nodes are standardized apart. Thus, the definition at http://www.w3.org/TR/rdf-mt/#defmerge was not directly reusable. Note also, that the text in section 3 is meant to decribe the matters informally, whereas the significantly improved formal definitions of the operations in section 4 should make things clearer now.

> 2/ "Since blank node labels are only unique within each specific
> context, blank nodes in the QuadData will not match existing data either
> in DELETE DATA requests. The DELETE/INSERT and DELETE operations can be 
> used to remove triples containing blank nodes. "
>  Blank node labels are not "unique within each specific context".
>  The only "matching" operation available is RDF graph matching, in
>  which different blank nodes can certainly match.

This sentence has been removed.

> 3/ "Blank nodes are therefore prohibited in a delete template. It should
> be noted that this restriction is not in the grammar for DELETE. "
>  It seems to me to be very bad form to hide this condition in the "fine
>  print".  It would be much better to allow them, but make them
>  harmless, or, even better, make them *useful*.

The restrictions on blank nodes in the grammar are listed and numbered now at http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#sparqlGrammar We now directly refer to thes specific restrictions in the text.

As a side remark, note that blank nodes are only disallowed syntactically, in fact the formal definitions do not restrict them, and would - as you say - make them behave harmlessly (e.g. blank nodes in DELETE would not result in any deletions). Still, as this behavior is not necessarily intuitive for all users, and based on discussions in the group on several possible alternatives, such as more complex semantics of blank nodes in DELETE clauses (e.g blank nodes being interpreted as wild cards), the group decided to syntactically restrict the use of blank nodes in DELETE clauses.

> 4/ I think that it would be much better to define updates more in terms
> of existing machinery (merging, instance, etc.), instead of using all
> this new machinery.  A better, more useful, better specified
> specification is likely to result.Comments about blank nodes in Editors'
> draft of SPARQL update

We believe to have partially simplified and significantly streamlined the machinery for update in the current version and hope this addresses your concerns.


We'd appreciate if you could indicate whether this response adequately addresses your comment.

Regards,

Axel (on behalf of the SPARQL WG)

Received on Monday, 2 May 2011 16:13:11 UTC