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

On 12 Feb 2010, at 14:23, Andy Seaborne wrote:
>
> 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.

Agreed, I think the DATA and WHERE keywords are very important for  
clarity's sake.

>>  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) } }

Yes, I don't have much enthusiasm for CONSTRUCT * anymore, but a  
CONSTRUCT WHERE could be useful, if we could agree some suitable  
wording.

I don't think there's any reason why adding CONSTRUCT WHERE should  
affect existing SPARQL implementations, as that's a syntax error in  
the current grammar.

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

Well, some implementations return N3 currently, and as I understand it  
N3 can encode named graphs, so I'm not sure that this is a big issue  
conceptually.

...

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

There's a risk of the * here being conflated with the meaning in  
SELECT, but I don't have a huge problem with it either.

> Personally, I don't like:
>
> DELETE * { pattern }
>
> because delete can have such large effects and one char is not enough.

Agreed.

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

Yes, that's my understanding too.

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

Also OPTIONAL, I think I'd have more use for OPTIONAL than UNION.

- Steve

-- 
Steve Harris, Garlik Limited
2 Sheen Road, Richmond, TW9 1AE, UK
+44 20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Friday, 12 February 2010 17:16:10 UTC