- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 10 Nov 2009 06:44:22 +0000
- To: Andy Seaborne <andy.seaborne@talis.com>
- Cc: Kjetil Kjernsmo <kjetil@kjernsmo.net>, public-rdf-dawg@w3.org
On 9 Nov 2009, at 22:15, Andy Seaborne wrote:
> On 09/11/2009 20:27, Steve Harris wrote:ILTERs
>>
>>
>> I'm not so sure, FILTERs don't feel any less complex than OPTIONAL
>> and
>> friends.
>
> Don't understand - how can a filter over a BGP be as complicated as
> one of the binary graph patterns?
Well, it's just as disallowed in the template side, so the pattern
still needs to be transformed. Admittedly it's FILTER -> nothing, but
it's still some transformation work.
> A FILTER accepts or rejects rows of the query solution table, but
> does not change the shape of a row which is determined by the BGP.
Well, it's surely a matter of perspective whether that's more or less
complicated. I think in terms of joins, so FILTER seems more complex.
>> If we're going with simple lets just have templates (BGP + GRAPH).
>
> GRAPH is OK - same as with FILTER because the pattern is still a
> fixed shape (no irregularities).
Well, in any case we still need to allow for
DELETE {
template
}
WHERE {
pattern
OPTIONAL {
pattern2
}
}
CONSTRUCT can do that, so it's well defined.
> We ought to change CONSTRUCT to align with that.
Yup.
> We ought to formalize the query forms : CONSTRUCT can be done with
> the "substitute(pattern, μ)" operation in Q-1.1
Yup. Modulo some stuff around unbound variables.
- Steve
--
Steve Harris, CTO, Garlik Limited
2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)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 Tuesday, 10 November 2009 06:44:51 UTC