Re: federated client released

Hi Ruben,

> On June 28, 2015 at 2:52 PM Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
>
>
> 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.
 
I'd have thought that using FROM and FROM NAMED would be a more natural fit than
SERVICE and enable everything that is needed.
As TPF is by nature based on triples, there is no concept of named graphs.
Or to put it another way, one can consider a TPF interface as an RDF dataset
comprised of just the default graph.
 
When I read ยง13.2 Specifying RDF Datasets [1] of SPARQL 1.1 Query Language it
states "If a query provides such a dataset description, then it is used in place
of any dataset that the query service would use if no dataset description is
provided in a query."
Also "The RDF dataset may also be specified in a SPARQL protocol request ..."

In the case of a 'traditional' SPARQL endpoint the data would necessarily need
to be present in whatever graph store is being used, but for a TPF client the
web is the graph store and the datasets are fetched at run time (via TPF
interfaces).

As such the current method using to execute federated queries is equivalent to
using multiple FROM clauses in the query (or multiple default-graph-uri
parameters in the request), whereby the query is executed over the RDF merge of
those graphs.

I can appreciate that a TPF interface is not the same as an RDF dataset, so to
interpret as such would be non-standard, but certainly would be useful.

Alternatively one can specify a new clause specifically for TPF interfaces,
similar to how Update introduces USING and USING NAMED.
 
[1] http://www.w3.org/TR/sparql11-query/#specifyingDataset

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

John

Received on Monday, 29 June 2015 08:10:43 UTC