Re: has anyone implemented SPARQL 1.1 yet?

On Nov 30, 2011, at 10:09 PM, Sandro Hawke wrote:

> On Wed, 2011-11-30 at 20:18 -0500, Gregory Williams wrote:
>> I tend to agree, while very much hoping that CR is short. From the sound of things, though, I suspect that between ARQ, RDF::Query, rasqal, and Sesame, there's probably good coverage of at least Query, Update, and Protocol. The only document that I'm concerned about is entailment, but that could just be because I'm not as familiar with systems doing entailment.
> 
> So....   what about Service Description?    There are several elements
> of implementation here.   Ideally, I'd like to see not just multiple
> servers providing descriptions, but multiple clients consuming those
> descriptions, doing the right things with them.
>  I'm not sure what those
> things are... have we defined things clients are supposed to do based on
> Service Descriptions?   The one bit of client functionality you and I
> have talked about is with ER: for that, it would be good to see clients
> which can select among multiple endpoints based on the entailment
> regimes they provide on the same dataset.

I think requiring multiple SD-consuming clients may be difficult and not all that relevant. It's difficult for a couple of reasons:

1) There isn't any requirement for SD (server) implementations to include much in the way of relevant data for clients to consume. That's because we intentionally made the conformance for SD minimal as it's meant to be a scaffolding with with other things can be built, not the end goal. I'd expect most of the future value from service descriptions to come from data using non-SD vocabularies, but which is accessed due to being attached at the extension points built into the SD vocabulary. Vocabularies to describe a dataset are the most obvious example of this right now: voiD seems obvious, but that's outside the scope of the SD vocab.

2) Regarding "clients which can select among multiple endpoints based on the entailment regimes they provide on the same dataset," I'm not immediately sure how SD would address that since it's designed to be service-centric, not dataset-centric. When you access a SD from a service endpoint URI, you'll get back a description of that service (maybe along with a description of its dataset). I suppose you could also get back a description of other services that use that same dataset, but while that would support your use case, it's certainly not required by the spec and so I think hard to depend on seeing clients relying on that in the wild before we can progress to a recommendation.

.greg

Received on Thursday, 1 December 2011 17:30:58 UTC