Re: basic federated query TODOs

> 2) (From 2 weeks ago) TODO: Put in an editor's note on allowing
> variables with SERVICE only if they are bound lexically before the
> SERVICE clause.

Observation:
tricky to define in the case of OPTIONALs:

{
    ?s a :ServiceDescription .
    ?s :name "Wanted Service" .
    OPTIONAL { ?s :service ?srv }
    SERVICE ?srv { ... }
}

The alternative is to define evaluation to be a empty (i.e same as {}).

An error is also possible.

> 4) Eric agrees with the discussion of making BINDINGS a required part of
> SPARQL 1.1 Query and leaving SERVICE as its own document. I'm not sure
> we know if the rest of the group feels the same way, so I'd love to hear
> opinions. Not sure if we'll make this change immediately, as it requires
> some coordination between Eric and Andy.

Let's leave the doc split as it is.

> If we can effect these changes this week, we'll decide as a group on
> publishing FPWD of the federated query editor's draft next Tuesday.



-----

BINDINGS is quite important for use with SERVICE.

It's use when not for a received SERVICE request bears some discussion.

It migh be better to define it's effect like parameterized prepare 
statements in SQL and a number of rows is equivalent to substituting and 
then evaluating.  In some corner cases this is different from join.

1/ Different syntax for parameter variables: e.g. ?:name or ??name

We can decide if parameter variables are full variables or not - they 
need not appear in SELECT *, for example.

2/ Evaluation is by substituting the values, then evaluating the query. 
  A query plan cached against the query can use the fact that slots are 
going to be constants, not variables.

Point 2 in:
http://lists.w3.org/Archives/Public/public-sparql-dev/2010AprJun/0006.html

3/ Can parameter variables be set in the protocol?

 Andy

Received on Friday, 14 May 2010 12:26:45 UTC