Re: Review SPARQL Query 1.1, Section 18 (algebra)

On 2011-04-25, at 01:30, Birte Glimm wrote:
> 18.2.4.1 Grouping and Aggregation
> pseudo code for Step: Aggregates
> End in first If clause is indented, but shouldn't be.  The if clause
> has no Else although the next one has an Else.
> The  End at the end of the third for loop belongs to the If clause
> after the first For I assume since that If misses its End and The for
> loops don't seem to use End or there would be several Ends missing.

OK, I've tidied up this code, but I'm not sure it matches the intention, happy to edit it further later.

> 18.5
> Definition: Evaluation of Group
> eval(D(G), Group(exprlist, Ω)) = Group(exprlist, eval(D(G), Ω))
> Using Ω here is confusing. In fact you have an algebra expression
> there that has to be evaluated so that you can apply the Group
> operator.
> Definition: Evaluation of Group
> eval(D(G), Group(exprlist, P)) = Group(exprlist, eval(D(G), P))

OK, done.

> Definition: Evaluation of AggregateJoin
> Write A = (A1, A2, ...) where Ai = Aggregation(exprListi, funci, scalarvarsi, P)
> eval(D(G), AggregateJoin(A, P))
> should be
> eval(D(G), AggregateJoin(A)) P has been removed, is in each A_i

Right, fixed.

- Steve

> ------------------------
> 
> 
> 
> On 21 March 2011 10:50, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
>> 
>> 
>> On 15/03/11 00:34, Birte Glimm wrote:
>>> 
>>> 18.6
>>> The overall SPARQL design can be used for queries which assume a more
>>> elaborate form of entailment than simple entailment, by re-writing the
>>> matching conditions for basic graph patterns.
>>> 
>>> This is no longer true due to PPEs. I am not happy about this at all
>>> and I assumed that PPEs are optional features. If they are not, it is
>>> quite unfortunate that the so far existing extension point no longer
>>> really is one and something has to be done at least to clarify this!
>> 
>> Property paths are handled by maximising the rewrites to other SPARQL forms,
>> including BGPs, and introducing new SPARQL algebra operators only where
>> necessary.
>> 
>> Therefore, evaluation of property paths does reduce to algebra+BGPs, just
>> like any SPARQL query pattern.
>> 
>> Would it be useful for the entailment document to discuss the issue that the
>> property path syntax is compiled to SPARQL algebra forms.  It would be
>> useful to discuss the relationship of applications-defined relationships
>> (which is what property paths do - give the application writer a chance to
>> express complex relationships such as transitivity) and the ontology-defined
>> relationships that manifest via entailment. This might include limitations
>> on the patterns in the syntax although that weakens the expressivity
>> otherwise given to the application query writer.
>> 
>>        Andy
>> 
> 
> 
> 
> -- 
> Dr. Birte Glimm, Room 309
> Computing Laboratory
> Parks Road
> Oxford
> OX1 3QD
> United Kingdom
> +44 (0)1865 283520

-- 
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 Tuesday, 26 April 2011 11:18:59 UTC