Re: Query review, part 2 (ACTION-546)

>>> "BGP( ?s :p1 ?v1 .?s :p2 ?v2 )"
>>> The whitespace is odd in this syntax, but I'm more curious about the choice of '.' as a separator for triples in the serialization of the BGP algebra.
>>
>> Whitespace fixed.
>>
>> DOT separated triples in SPARQL syntax so I left it in to show the division of triples.
>
> Ah. I didn't realize that what shows up inside a BGP(…) is sparql syntax. I expected a list of triples, so probably comma separated.

It's not formalised, it's illustrative examples.  Comma is SPARQL syntax 
for repeated objects.  Seemed easier to use . to separate triples.

>>> "variable must not appear in VS; if it does then generate a syntax error and stop"
>>> I think this should also prevent the variable from appearing in P (the list of already projected variables).
>>
>> VS is defined as the variables in the { pattern } from above.
>
> I'm not sure that actually addresses my concern. Shouldn't this
> address the case where the same variable appears in two (expr AS
> variable) selItems? On the first one, (variable, expr) is appended to E.
> On the second one, I'd expect that the restriction preventing the
> variable from appearing in the pattern *should also* prevent the
> variable from appearing in previously handled selItems, and similarly
> generate a syntax error.

Sorry - I had read your original comment differently.

Changed to "variable must not appear in VS nor in PV"

"""
where PV is the accumulating list of projected variables.
"""

>>>
>>> The 'term path term' form is defined as:
>>> """
>>> eval(D(G), ZeroOrMore(x:term, path, y:term)) =
>>>      { { } } if (x,vy:var) in eval(D(G), ZeroOrMore(x, path, vy); card[{ }] = 1
>>> """
>>> I don't understand this formulation, as I understand eval(D(G),
>>> ZeroOrMore(...)) as returning multisets of (var, term) pairs, but this
>>> seems to be looking for a (term, var) pair. Why isn't this as simple as
>>> "{ {} } if y in ALP(x, path), card[] = 1" (the opposite of the negative
>>> case which returns the empty multiset)?
>>
>> I think "in" is clear to mean a pair in the multiset of sets but I've added {} round.  Does that help?
>
> No, the original syntax without the braces was fine. My point was
> that  the formulation seems to be looking for a (term, var) element, but
> eval() returns a set of (var, term) elements. They're reversed. But the
> solution probably isn't as simple as reversing the syntax, because then
> you'd be looking at the path backwards...

Changed to

eval(D(G), ZeroOrMore(x:term, path, y:term)) =
     { { } } if { (vy:var,y) } in eval(D(G), ZeroOrMore(x, path, vy);
               card[{ }] = 1
     { } if y not in ALP(x, path), card[] = 0

it should be looking to see of the end of the path is y.

and also

eval(D(G), OneOrMore(x:term, path, y:term)) =
     { { } } if { (vy:var, y) } in eval(D(G), OneOrMore(x, path, vy); 
card[{ }] = 1
     { } if y not in ALP(x, path), card[] = 0


 Andy

Received on Monday, 12 December 2011 13:24:05 UTC