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

From: Axel Polleres <axel.polleres@deri.org>
Subject: Re: Comments about blank nodes in Editors' draft of SPARQL update
Date: Mon, 2 May 2011 11:12:41 -0500

> 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. 

The new wording is fine here.

>> 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. 

Your operation should be a form of graph merge.  If so, I think that
there should be wording to this effect.  If not, I suspect that there is
a serious problem.

>> 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.

OK.

>> 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 these 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. 

This appears to be fine. 

>> 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. 

The current version looks better here.

> We'd appreciate if you could indicate whether this response adequately
> addresses your comment. 
> 
> Regards,
> 
> Axel (on behalf of the SPARQL WG)

peter

Received on Tuesday, 10 May 2011 13:52:33 UTC