W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2012

blank nodes in DELETE clause

From: Jeen Broekstra <jeen.broekstra@gmail.com>
Date: Mon, 18 Jun 2012 09:43:49 +1200
Message-ID: <4FDE4F95.2020502@gmail.com>
To: public-rdf-dawg-comments@w3.org
Dear WG,

This is a comment on http://www.w3.org/TR/sparql11-update/#deleteInsert,
specifically this bit:

"Deleting triples that are not present, or from a graph that is not
present will have no effect and will result in success. Blank nodes are
prohibited in a DELETE template, since using a new blank node in a
DELETE template would lead to nothing being deleted, as a new blank node
cannot match anything in the Graph Store. It should be noted that this
restriction is not in the EBNF for the DeleteClause itself, but made
explicit in Note 9 to the grammar."

I am completely mystified as to why this restriction is at all
necessary. It seems trivial to me to interpret blank nodes in DELETE
patterns as anonymous variables (similar to how they are interpreted
elsewhere in SPARQL queries). In fact, Sesame currently implements it
this way, and I only found out that this is apparently wrong when I
failed a conformance test in the test suite.

But it seems a useful thing to allow a shorcut like:

 DELETE {?y foaf:name [] }
 WHERE {?x ex:containsPerson ?y }

Or indeed:

DELETE {?x ex:containsPerson [ foaf:name ?n ] }
  ?x ex:containsPerson [ foaf:name ?n. ]
  FILTER(str(?n) = "Bob")

Meaning "DELETE all foaf:name properties on subject ?y, no matter what
the value".

I know this can be reformulated to:

 DELETE {?y foaf:name ?n }
 WHERE {?x ex:containsPerson ?y. ?y foaf:name ?n. }

of course, but this is a larger query to write, and I see no technical
obstacles to allowing the first form. Especially since enforcing the
restrictions means our current parser has to do post-processing on the
parsed query tree (which is expensive).

I'd appreciate it if this restriction could be taken out, or
alternatively, an explanation as to why this is necessary.


Received on Sunday, 17 June 2012 21:44:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:12 UTC