On 26/04/12 17:58, Robert Vesse wrote:
Ok
Not sure I entirely understand what the proposal on BINDINGS is so please
correct me if I'm wrong. It sounds like it will be possible to the do the
following:
SELECT *
{
BINDINGS ?x { (<a> ) (<b> ) (<c> ) }
?x<property> ?value .
}
Or have I misunderstood?
No - spot on although the word may not be BINDINGS. BIND and BINDINGS -
similar but different.
It's a data table - it's logically joined to the rest of the group.
The eval order is
patterns - BIND - Inline DATA - FILTER
i.e. between BIND and FILTER.
And, ideally, I want to suggest a two syntax forms:
# One variable short form.
DATA ?var1 { 1 2 <a> <b> }
# Multi variable
DATA (?var1 ?var2) {
(1 <b>)
(3 <a>) }
because one variable is a common usage.
But we'll have to see about the details - I am just experimenting with
the design at the moment in preparation for a complete proposal to
SPARQL-WG.
Comments welcome - nothing too radical is going to be accepted though.
Andy
Rob
On 4/26/12 9:30 AM, "Andy Seaborne"<a...@apache.org> wrote:
Re: Carrying raw query strings (public API change).
On 13/04/12 17:00, Robert Vesse wrote:
The more I think about this the less I think it actually solves our
problem (it being carrying raw query strings) because we are still
left with the issue that a query may turn into multiple queries
internally and our developers wanted the query string to associate
with each of those internal queries but that isn't a 1:1
relationship
Maybe it is for the best if I just go ahead and revert those
changes?
I was removing some unfinished stuff in Query so I took the liberty of
reverting the changes in passing. Hope that's OK.
The "unfinished stuff" was the syntax part of having inline data (AKA
BINDINGS anywhere in a query). It wasn't going anywhere and there is a
better way.
Stephen's comment to SPARQL-WG is one of several:
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Apr/0010.
html
The SPARQL-WG is considering (but has not decided whether to do or not
do yet) allowing BINDINGS anywhere in a {}-block, which generalises the
subquery, or removes the need for placeholder { SELECT * WHERE { } }
just to attach the BINDINGS.
Going as far as referencing external data (the results of a previous
query) is too radical at this stage for standardisation but it's a
logical step for an ARQ extension.
Andy
