Re: federated client released

Hi Markus,

> Could you elaborate a bit on what exactly the client supports.

At the moment, evaluating SPARQL queries against separately and explicitly listed data sources.

> For instance,
> what parts of the SPARQL Federated Query spec [1] are supported? Also, it
> seems like FROM statements are not supported but instead you have to supply
> the datasources separately. Do you plan to change that? Would be nice if the
> queries could be made self-contained.

We're still doubting on what would be the best way,
and it's likely that we will provide a few alternatives.
TL;DR: it's a trade-off between being reusable and being self-contained,
and some parts of the SPARQL spec are implicitly tied to the "endpoint" concept.

Let's first consider a simple SPARQL query (without thinking about federation).
Such a query is normally not self-contained (i.e., no FROM / SERVICE).
Why? Because it is assumed this query would be executed against a SPARQL endpoint.
So to execute this query, you need that URI of that endpoint anyway.

With a Triple Pattern Fragments client, there is no SPARQL endpoint interface
that will accept the SPARQL query. Instead, the local client takes the query.
To support the above scenario, we supply the client with query + URI of a TPF interface.

With SPARQL endpoints, this doesn't generalize to multiple endpoints.
I.e., you cannot do federation by sending one SPARQL query to multiple SPARQL endpoints.
However, with TPF, it does generalize: give the client a query and URIs of multiple TPF interfaces.
That's what we do at the moment.

What does work for SPARQL endpoints is the SERVICE keyword,
and also the FROM keyword (which is really for graphs, not endpoints).
The query is then self-contained, which is handy for execution,
but at the same time also ties the query to a specific endpoint.

We are thinking of supporting:
a) the current approach, with a separate list of endpoints
b) SERVICE (by extending its definition to TPF interfaces)
c) FROM (by interpreting a graph as a TPF interface)
The latter two interpretations are, however, non-standard
and will probably require flags to switch on or off.
The three approaches can be combined as well.

We're still thinking about how to do things.
Once we have some clarity, we'll send some proposals to this list.

For the moment, you can executed federated SPARQL queries using the first approach.

Best,

Ruben

Received on Sunday, 28 June 2015 12:52:46 UTC