Re: Questions about SPARQL 1.1 service description

On Feb 22, 2011, at 1:56 AM, Nicholas Humfrey wrote:

> I have been starting to update my service description code in RedStore to be
> compatible with SPARQL 1.1 Service Description. It has brought up a few
> questions. My questions are based on version 1.49 of the document.
> 
> 1) There is currently very little mention of the SPARQL 1.1 RDF Dataset HTTP
> Protocol. Is this a separate sd:Service, with a separate service
> description? How is the service type indicated in the service description?

As it stands now, sd:Service represents only instances of the (normal) Protocol. There is nothing in the document that is about the Dataset HTTP protocol. This is an open issue that needs discussing. I've got an action to start a discussion about it and sort out details, so expect another email thread on this soon.

> 2) RedStore supports multiple query languages: sparql10, sparql11, laqrs and
> rdql. This is currently set using a lang= argument. Should there be one
> endpoint per query language? Should each endpoint have its own service
> description? How do you discover which endpoints are available?

The service description can indicate that both sparql query 1.0 and 1.1 are supported, and since one is a subset of the other, it shouldn't need a query parameter. There is no mechanism in the SD to indicate query arguments like you describe, as this falls outside the scope of the the protocol. You could probably address this by having a different service URI per language and describing them as different services.

> 3) What URI do I use for the description of non-RDF based result formats?
> Examples include HTML Tables, Atom, RSS, the GraphViz DOT format, CSV, TSV
> etc. Should I create my own, should they be bNodes in the service
> description or should they be in a more generic location?

For formats that don't have an existing IRI, you can mint your own or use a bnode, and use the properties defined in the Unique URIs document for describing the format (e.g. formats:media_type, formats:preferred_suffix). I can add a note in the SD document that makes this more clear.

> 4) In section 5, Conformance, it states that service descriptions MUST
> include a <service-URL> rdf:type sd:Service triple. However the example in
> Section 4 doesn't include this triple (without inferencing).

This part of the document is in flux based on the recent discussions surrounding the sd:url property. The example will be updated soon and should end up aligned with the current text of the conformance section.

> 5) There doesn't currently seem to be a way to distinguish between query
> result formats (from an ASK or SELECT) and RDF serialisations (CONSTRUCT or
> DESCRIBE). I think this would be a useful distinction, particularly if
> trying to work out which formats are supported for a GET using the SPARQL
> 1.1 RDF Dataset HTTP Protocol.

What sort of solution are you imagining? I'm hesitant to add a general way to group file formats (rdf vs. not rdf), but if this is really important, could consider it. My initial impression is that if the client supports a file format, it probably already knows whether it's a results or rdf serialization and so this information is out-of-band. Are there situations where this wouldn't be true?

> 6) For clarity, perhaps the vocabulary that is used to describe formats (for
> example http://www.w3.org/ns/formats/media_type) should be part for the
> service description vocabulary, particularly if format descriptions are
> inlined within the service description.

These are more generally applicable than just to service descriptions, and I think they belong in the file formats document. Will adding a note (as mentioned above) to suggest their use with non-standard file formats be enough?

> 7) Redland/RedStore are unlikely to support Property Paths in the near
> future, is there are way to describe this?

No, as property paths are a required part of the language.

> 8) Has anyone implemented SPARQL 1.1 service description yet? Are there any
> real world examples?

I don't know of anyone who has implemented all  of the recent changes yet. I've been holding off on implementing them until the open issues are resolved.

thanks,
.greg

Received on Tuesday, 22 February 2011 15:44:23 UTC