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

Hi Andy, Steve, others,
I was asked to check whether the comments in my review have been
addressed. This seems mostly to be the case in particular for
aggregates I just found some minor typos or leftover from changes, but
I still have some problems outlined below. I didn't check the grammar
for PP expressions yet due to lack of time.
Birte

Can we please have unified pseudo code?
If seems to be followed by Then, but not always. If mostly has an End,
but not always. Indentation (often for End is messed up and in some
cases the End appears in the wrong place.
E.g., pseudo code 18.2.2.5 Translate Graph Patterns
If… NO Then
  …
Else
  …
NO End
The next two blocks have If, NO Else, No End
Next block has several version:
First If has no Then no End
Next If has Then on the next line, but has End
The If inside the above has no Then, lowercase else and an End.
The next Ifs are without Then, but with End
The for loop has an End, which possibly belongs to the first If.
The last If has no Then, but an End that is indented, but it shouldn't
be indented.

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.

18.2.4.3 SELECT Expressions
pseudo code for Step: Select expressions
     E := E append (variable, expr)
is not indented enough, should have same level as
       P := P  union { variable }

I can't/won't list everything, but think it would be good to decide on
a style and go once through the doc to unify everything.
-----------------------
18.2.2.3 Translate Basic Graph Patterns
After translating property paths, any adjacent triple patterns are
collectied together to form a basic graph pattern BGP(triples).
s/collectied/collected/
--------------------
There no longer is a definition of transform(.), before there was
Transform(syntax form), which was defined for most basic things
(GroupGraphPattern, GroupOrUnionGraphPattern, TriplesBlock).

Transform(.) now falls from the sky first in 18.2.2.4 Translate
Pattens in Filters.
Section 18.2.2.5 Translate Graph Patterns contains what should make up
the definition of Transform(.).
--------------------
I am still not happy with the (NOT) EXISTS filters.
Here an example: query pattern is
{ ?s :p ?o FILTER EXISTS { ?s p' ?o } }
I replace the EXISTS
{ ?s :p ?o FILTER exists(Bgp(?s p' ?o)) }
and continue
Filter(exists(Bgp(?s :p' ?o)), Bgp(?s :p ?o)) (simplified already)
then evaluate
eval(D(G), Filter(…))
= Filter(exists(…), Eval(D(G),Bgp(…)))
assume the active graph has
:a :p :c .
:a :p' :c .
:b :p :c .
we get Sigma = { {?s->:a, ?o->:c}, {?s->b, ?o->:c} } for Bgp(?s :p' ?o)
Now we have
Filter(exists(Bgp(?s :p' ?o)), Sigma)
which apparently is as follows
Filter(expire, Sigma) = { mu | mu in Sigma and expr(mu) is an
expression that has an effective boolean value of true }
For exists I rather want mu(exists(…)) or exists(mu(Bgp(…))).
Even further, I would want
exists(eval(D(g), mu(Bgp(…))))
since there might be variables in Bgp(…) or whatever we have inside
the exists(…) that are not yet bound and we actually want to work with
the graph again here.
------------------------------
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))

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



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

Received on Monday, 25 April 2011 00:30:29 UTC