Re: Review of "SPARQL 1.1 Update"

Thanks Andy for clarification, right, what I had in mind with ADD was indeed what we already have with INSERT DATA ...
was just puzzled by the "assymetry" of shortcuts without having really though it through.

So, trying to summarise, the options on the table are the following:

(DELETE {P1})?
(INSERT {P2})?
WHERE {P3}

where at least one of INSERT or DELETE part needs to be present, do I understand that correct as the common understanding of the long form?

Shortcut options

OPTION1: 
 * DELETE {P} for DELETE P WHERE P, but enforcing separators ";" for avoidung ambiguity 

OPTION2:
 * new keyword REMOVE, i.e. REMOVE {P} for "DELETE P WHERE {P}"

OPTION3:
 * Make  '{P1}' optional but require 'WHERE', i.e.
  DELETE WHERE {P1} for DELETE {P} WHERE {P}

Anything I forgot?

============================================================================
More remarks:

* some potential other issue for the next round:
 "INTERT DATA {P}" could in fact be viewed as a "shortcut" for "INSERT {P} WHERE {}", yes?
This raises the question whether DELETE DATA {P} isn't actually to be viewed as a restricted version of 
the SHORTCUT we discuss above where P is ground, isn't it? That is, the question is whether DELETE DATA P 
is the same as writing "DELETE WHERE {P}".

If course this very much depends on how the semantics of DELETE DATA is to be defined, i.e. is DELETE DATA
also successful, if only a part of it matches? 

Assume: the default graph (store) has only ont triple  t1 and I call:
  DELETE {t1 t2}
Also here  there are two options for dealing with this situation:
 i) the DELETE succeeds and deletes the 1st triple, or succeeds with a warning (this behavior would indeed be different from DELETE WHERE {P} )
 ii) the DELETE fails (however, actually this behavior would make DELETE DATA 
     redundant wrt. the DELETE P WHERE P shortcut, however it looks)

So, if i) was intended, at least I haven't yet seen this aspect discussed/mentioned in the current draft,
(hope I haven't overlooked this having been discusssed already again...looking at the current Web version update).

* Whatever way we choose, we have other open issues on what such request should return, but this is then more an issue for protocol,
e.g. the number of added/deleted triples could be informative.

Axel

On 11 Jan 2010, at 14:34, Andy Seaborne wrote:
> On 11/01/2010 1:40 PM, Axel Polleres wrote:
> > Without really wanting to decide between "REMOVE" or separators ";" here yet (I am not decided on this, to be honest)...
> > what I'd find a slight bit strange is that in the first alternative DELETE needs a dedicated keyword in the shortcut
> > version, whereas INSERT doesn't. One option to avoid and make it look more consistent could be to also have a dedicted
> > keyword for the short form of INSERT, i.e.
> 
> The short form of INSERT is always a no-op (caveat bnodes) because if
> the pattern matches, then the data is already in the graph.  I thought
> we were removing it because of the no-op-ness.  At most, it can
> introduce bnodes but with the same triple shapes.
> 
> INSERT { :a :p ?B }
> 
> INSERT { [] :p ?B } will at most introduce a different bnodes (and it's
> a pun - dual use of the bnode synatx - one use is non-distinguished
> variable in a pattern, one use as a template bnode).
> 
> We do have INSERT DATA and DELETE DATA - the important feature being
> they only work on data and which maybe very long so knowing there are no
> variables and it's all ground triples is quite important.
> 
> >
> > long form:
> >
> >   DELETE {P1}
> >   INSERT {P2}
> >   WHERE  {P3}
> >
> > short forms:
> >
> >   ADD {P}
> >   REMOVE {P}
> 
> And DELETE WHERE {P} - or DELETE otherword {P} - which misses the
> template part that is the duplication - and does not use a completely
> new word.  Emphasises the {P} is still a pattern with variables (albeit
> restricted in form - but the grammar can cope with that).  This
> addresses the issue at the point of concern without cascading to the
> rest of the request.
> 
>         Andy
> 
> >
> > just my two cents,
> > Axel
>

Received on Monday, 11 January 2010 16:57:23 UTC