- From: Steve Harris <steve.harris@garlik.com>
- Date: Fri, 12 Feb 2010 17:15:38 +0000
- To: Andy Seaborne <andy.seaborne@talis.com>
- Cc: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
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