W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: ISSUE-48: Less verbose delete syntax

From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Date: Sun, 08 Nov 2009 21:23:01 +0100
To: public-rdf-dawg@w3.org
Message-id: <200911082123.01965.kjetil@kjernsmo.net>
On Saturday 7. November 2009 20:25:47 Andy Seaborne wrote:
> What patterns are allowed?  Not all possible query patterns make
> sense.  I believe that what is going on is a mismatch between the idea
> that a pattern describes a part of the graph and the idea that a
> pattern is extracting terms from the graph.  SPARQL is the latter
> (hence DAWG is "Data Access" : getting stuff out of the RDF graph for
> onwards processing and display). This is like the "CONSTRUCT *" issue.
>  It would be nice not to repeat the pattern in the template but it
> gets complicated.

Hmmm, right. I'm sure you understand much more of this than I do.

If anything, if we can draw something from our recent discussion of traps; 
After a few DELETE FROM table <Return> snafus, if I do that kind stuff, I 
always do a SELECT * FROM table first, since it returns exactly what I am 
about to delete. Are you saying we can't do this? 

> The graph-to-graph transform languages we have are inference and
> rules.  And rules tend to be of the style, match to get variables then
> apply template.
> Examples:
> DELETE WHERE {?x :p ?o  . FILTER ( ?o < 42 ) } # Why not?
> DELETE WHERE {  ?x :p ?o OPTIONAL { ?x :q ?v } } # Seems silly to me.
> DELETE WHERE {  { ?x :p ?o } UNION { ?x :q ?v } } # Do as two
>  operations?
> These are a natural reading as identifying triples in the graph but
> that's fundamentally different from what SPARQL evaluation is doing.
> Adding "means all triples you touch for a positive answer" is not so
> clearcut.

OK, I don't think I appreciate the full implications of this.

> A simple solution is BGP's but I think FILTERS are needed.
> But it's weird if DELETE-WHERE-{} has pattern restrictions when
> DELETE-{}-WHERE-{} does not.

Yes, that is true, however, I feel that it is not necessarily evil. If we 
find that a large number of use cases can be satisfied with a simpler 
construct, so that many users will never have to related to the full 
complexity, it is a good thing, IMHO.

> > How about the UPDATE keyword I propose in there?
> I'd like to see a more detailed proposal. This is just missing the
> DELETE template?
> Isn't this the same as two operations:
> DELETE WHERE { <foo> dc:title ?o . }
> INSERT{ <foo> dc:title "Foo" . }

Yes, it is.

When I reviewed the actual use we had of SPARUL, it turned out that this 
accounted for a large majority of our actual uses. Thus, it makes a lot of 
sense (to us anyway) to have a intuitive and simple way to do just this. 

Possibly a more important argument for it, is the discussion about 
transactions we just had: Having two operations may or may not be atomic, 
UPDATE will certainly be. Now, if this is impossible to implement as atomic 
for everyone, it is of little value, but how hard can that be? :-)

> or can the additions in UPDATE take variables?

They weren't in our examples, so I would say no, if that helps :-)

Kjetil Kjernsmo
Received on Sunday, 8 November 2009 20:23:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:57 UTC