W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2011

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

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 28 Apr 2011 12:52:06 +0100
Message-ID: <4DB954E6.2010702@epimorphics.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
On 25/04/11 01:30, Birte Glimm wrote:
> 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

The forms should be If (Else)? End; the isea is to be cleare.  There may 
be variations.

The "If the form is" is following the style of text just above it which 
I think is clearer.


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

I have tried to clean up the algorithms - is there anywhere you thin is 
unclear?

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

Done

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

Henny Penny is saved.

I have added it back in at the start of 18.2.2

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

I'm a bit lost as to which text you are referring to. 18.2.2.4? 18.5? Other?

I've changed 18.2.2.4 to:

...
Replace EXISTS{P} by eval(D(G), exists(A))
Replace NOT EXISTS{P} by fn:not(eval(D(G), exists(A))

(with links)

Is that what you are suggesting?

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

	Thanks
	Andy
Received on Thursday, 28 April 2011 11:52:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT