Federated query with SERVICE keyword

[fadmaa]

Hi all,

On the SPARQL API Explorer, the SERVICE keyword seems to be working fine only if the endpoint used with the SERVICE is not another one on Kasabi.

example:

SELECT ?l 
WHERE{
  
  SERVICE <http://api.talis.com/stores/bbc-backstage/services/sparql> {
    <http://api.talis.com/stores/bbc-backstage/items/1262103042406#self><http://purl.org/dc/elements/1.1/title> ?l
  }
}LIMIT 10

works fine and yields result. While 

SELECT ?l 
WHERE{
  
  SERVICE <http://api.kasabi.com/dataset/business/apis/sparql> {
    <http://business.data.gov.uk/id/company><http://purl.org/dc/terms/title> ?l
  }
}LIMIT 10

parses Ok but returns no result (I am subscribed to the Business SPARQL endpoint on Kasabi).

Is this intentional, a bug or a missing feature? is it something to be added later?

I am working on a faceted browser over distributed SPARQL endpoints and was trying to test it against Kasabi.

Thanks and regards,

Fadi Maali

[Leigh Dodds]

Hi Fadi,

You've tripped over a currently undocumented feature :)

We recently upgraded all of the SPARQL endpoints so they're now fully
SPARQL 1.1 compliant. This means that they also support the SERVICE
keyword. Whether we'll continue to support all of those features
long-term will depend on how they're used and the performance impacts
we see.

The reason you can't access Kasabi SPARQL endpoints is because of the
API key authentication: the keys aren't passed over in the federated
requests.

There's an open Jena issue to support parameters, which would allow
you to pass over views manually [1]. We'll include that once its
approved.

However more generally I think SPARQL 1.1 Federation and
implementations ought to think about how authentication details are
passed on from clients as this issue will affect anyone using
authenticated endpoints.

Cheers,

L.

[1]. https://issues.apache.org/jira/browse/JENA-195

[fadi maali]

Thanks for the clarifications Leigh!

Glad to know that the endpoints on Kasabi now support SPARQL 1.1

Regards,

Fadi