Re: side remarks on the shortcut discussion for INSERT/DELETE...

On 12/02/2010 11:10 AM, Axel Polleres wrote:
> ... I have some side questions/remarks concerning the shortcut discussion we had for INSERT/DELETE...
>
> 1) If we define shortcuts for INSERT/DELETE, I think it would seem awkward not to have a
> similar shortcut also for CONSTRUCT, i.e.

I though we had discussed this further and we had consensus that because 
INSERT WHERE pattern is a no-op, we were only going to have DELETE WHERE 
{pattern}

This is after the point about the absence of WHERE in the delete short 
form can become confusing:

DELETE DATA { triples } and DELETE [WHERE] { triples } have different 
effects.

>
>   CONSTRUCT<Pattern>   = CONSTRUCT<Pattern>  WHERE<Pattern>
>
> agreed?

This was "CONSTRUCT *" in DAWG.

It's not so simple.  The output type of the CONSTRUCT operation is a 
graph currently. What happens about:

CONSTRUCT * { GRAPH ?g { ?s ?p ?o FILTER (?o > 57) } }

Two points: (1) use of GRAPH and (2) patterns that are more than 
templates.  The pattern needs restricting (which is why it didn't happen 
at 1.0)

It is worth noting that this is an extension to the SPARQL Query 
language that has repercussions on existing implementation design and on 
protocol because CONSTRUCT returns a graph currently, not an RDF dataset.

There is no formal standard way to encode an RDF dataset so what is the 
protocol to do? NQuads, Trig, TriX and others exists but are not W3C 
recommendations.  Each has a few corner cases to pin down - nothing hard 
but they are not agreed yet.

There's application code that relies on that as well as toolkits.

Personally, I would value the uniformity of using quads. But also I 
recognize that current implementations are built around graphs and I 
don't think we should go there without a wider consensus on handling 
named graphs given our incremental charter.

> 2)  Another thing... as an alternative to definintg the shortcut by the absence of a
> WHERE clause (which, IIRC was critisised for being ambiguous) couldn't we just use
> "*" like in SELECT, i.e. for instance
>
>   INSERT * WHERE<Pattern>  = INSERT<Pattern>  WHERE<Pattern>
>   ...
>   CONSTRUCT * WHERE<Pattern>  = CONSTRUCT<Pattern>  WHERE<Pattern>

I believe the design is

DELETE WHERE { pattern }

to emphasis the WHERE is pattern.  WHERE is mandatory.

I have no problems with

DELETE * WHERE { pattern }

but it seems unnecessary.  DELETE WHERE does make restrictions on the 
pattern; DELETE * feels like a bigger promise.

Personally, I don't like:

DELETE * { pattern }

because delete can have such large effects and one char is not enough.

>
> the main question arising if we go that direction is how to handle
> complex patterns, but I think we could solve that, depending whether
> in general that sounds like a potential path to go for the rest as well?

I thought we had solved that - the pattern is a quad template only. This 
is language syntax enforced.

We did discuss quad template + filter (I was in favour) but we didn't 
reach consensus.  We observed UNION made sense as well.

---------

So our problem is that we have not documented the current working design 
yet.  Let me risk doing so: Paul - is this right?


One short form:

DELETE WHERE { quadTemplate }

where quadTemplate is a construct-like tripleTemplate or GRAPH <g> { 
tripleTemplate or a mixture.

GRAPH ?g {..} is also legal.

Triples refer to the default graph.

---------

Examples:

DELETE WHERE
{
    GRAPH <duffData> { ?x foaf:doesntKnows ?y }
}

I am not absolutely sure what the expectations are for :

DELETE WHERE
{
    ?s foaf:knows <#fred> .
    GRAPH <duffData> { ?x foaf:doesntKnows ?y }
}

Maybe it means match the whole thing and then delete all
    ?s foaf:knows <#fred> .
in the default graph and quads
    GRAPH <duffData> { ?x foaf:doesntKnows ?y }

	Andy

Received on Friday, 12 February 2010 14:23:31 UTC