Re: SPARQL Federation Extensions draft

Eric,

This is great - I think we ought to include something in SPARQL 1.1 even 
if it's just the most basic SERVICE form because of time.  It it the 
semantic *web* ....

 Andy

On 27/03/2010 3:36 AM, Eric Prud'hommeaux wrote:
> http://www.w3.org/2009/sparql/docs/fed/service
>
> take a look, help out, ...
> --
> -ericP


Specific comments:
** SERVICE

"4.1 Definition of SERVICE"
http://www.w3.org/2009/sparql/docs/fed/service#sparqlDefinition

[[
The evaluation of service uses the SPARQL algebra union operator.
]]

Elements of a group are usually join'ed together, not union'ed.

Algebra example:

  Service(?s :p2 ?v2)
==>
  Service(<srvc> BGP(?s :p2 ?v2))

"with a query Q and no default or named graphs."

I think that means no FROM or FROM NAMED - correct?


** BINDINGS

This area is less clear to me - it's very useful to have something here 
but I'm not quite sure this is the right mechanism.

It's another form of assignment.

Is it the same as (the excessively verbose):

{
SELECT ("Alice" AS ?given)
        ("Anderson" AS ?family)
        (?mbox AS <mailto:alice@example.com>)
} UNION {
SELECT ("Bob" AS ?given)
        ("Robertson" AS ?family)
        (?mbox AS <mailto:eve@example.com>)
} UION { ... }


Probably better not to allow bNodes to be passed over the network.

Suggest s/UNBOUND/_/ or something a liitle less heavy. "-"
The definition of BINDING has UNDEF


* BINDING and Update:
This seems to overlap with INSERT DATA etc
It is unrelated to federated query.

The substutute operator might help in the definition:
http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#defn_substitute

Result are then a union of substitute for each binding row.  This is 
similar to the bind-join proposed by the IBM Garlic project.  It allows 
for the bINDINGs to be streamed in parallel with results coming back.

(this way the results of sending one BINDING at a time and sending all 
BINDINGS at once are the same).

** MIME Type

Doesn't the query often go in ?query= which isn't MIME typed.

 Andy

Received on Monday, 29 March 2010 14:54:54 UTC