- From: Steve Harris <steve.harris@garlik.com>
- Date: Thu, 17 Feb 2011 20:21:46 +0000
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: Paul Gearon <gearon@ieee.org>, Lee Feigenbaum <lee@thefigtrees.net>, Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>, Alexandre Passant <Alexandre.Passant@deri.org>
On 2011-02-17, at 17:01, Andy Seaborne wrote:
>>
>> But that doesn't work, since the lack of bindings for ?o will prevent
>> anything from happening. I *think* that the correct equivalent would
>> be:
>>
>> DELETE{
>> ?tmp_a :p 12 .
>> ?tmp_a :q ?o .
>> }
>> WHERE {
>> ?s :r ?q OPTIONAL { ?q :s ?o }
>> ?tmp_a ?tmp_b ?tmp_c
>> OPTIONAL { ?tmp_a :q ?o }
>> }
>
> Maybe but you'll have to explain how that's going to work because I don't see the algoroithm to introduce the OPTIONAL { ?tmp_a :q ?o }. The ?o may be a much more complex combination of graph patterns - maybe you've seen something I haven't.
>
> I was looking at it as a instantiate-remove cycle:
>
> for each solution to "WHERE {}"
> instantiate template, bnodes as fresh variables.
> if there were bNodes, match template again
> for each possible set of triples
> delete concrete triples
> else # no bnodes
> delete concrete triples
>
> but that is not precise enough with named variables that are unbound.
>
> I'm being to wonder whether this was the right resolution.
I've been poking at this recently too, and it seems rather complex for the problem we're trying to solve.
The simple cases look quite tempting from a useability p.o.v., but the more with complex ones (like this) it's hard to say exactly what behaviour you would like/expect from it.
- Steve
--
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203 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 Thursday, 17 February 2011 20:22:22 UTC