Re: ISSUE-48: Less verbose delete syntax

>> > What about missing the template out instead:
>> >
>> > DELETE WHERE {?x :p ?o }
>>
>> If we're going to support this kind of syntax abbreviation, then this
>> looks better to me.
>
> Works for me too.
> That's close to what I proposed in
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0315.html

There are some issues still to be sorted out.

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.

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.

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.

I see a design tension that we have not resolved.  Simplicity of
language  (only a few forms) vs expressing common use cases.

May be (I'm raisng the possibility, not proposing) we need more verbs
in the language and not overload the general purpose operations.

It could also be that the ordering of templates and patterns is unhelpful.

USING { pattern }
DELETE { template }
INSERT { template }

but this goes all the way back to having SELECT-{pattern}.

i also note Ivan's point that variables may be artificially introduced
to constrain by pattern but not delete.

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

or can the additions in UPDATE take variables?

    Andy

>
> Cheers,
>
> Kjetil
> --
> Kjetil Kjernsmo
> kjetil@kjernsmo.net
> http://www.kjetil.kjernsmo.net/
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>

Received on Saturday, 7 November 2009 19:26:24 UTC