Re: Questions about SPARQL 1.1 service description

Hi Greg,

Thanks for your comments.


On 22/02/2011 15:43, "Gregory Williams" <greg@evilfunhouse.com> wrote:

> 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.

Ok, great, thanks.

>> 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.

I understand that RDQL is outside the scope of the service description
specification :) Was just hoping to have something flexible. Having one
endpoint per query language would work. But I may just use the Service
Description to describe the SPARQL 1.1 functionality (which will be the
default) and then keep the ?lang=laqrs as a propriety extension to RedStore.

>> 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.

Yes, that would help. My concern is that when scanning the document it might
not be clear how that the format:media_type predicate exists.

>> 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.

Ok.

>> 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?

The considerations I had were around user interface - selecting an output
format. It is true that this could probably be worked out by using the
OPTIONS method on the URL and then cross-referencing the media type. But it
would seem an easy feature to add. Redland supports CSV output for SELECT
queries but not for CONSTRUCT queries. It is true that I can't think of any
other use-cases but it seems like an obvious thing to want to know.

One option would be to have a different predicate:
<sd:Service>
  <sd:queryResultFormat>
    <sd:Format rdf:resource="http://www.w3.org/ns/formats/RDF_XML" />
  </sd:queryResultFormat>
</sd:Service>

Option 2 have a different format Class:
<sd:Service>
  <sd:resultFormat>
    <sd:RDFFormat rdf:resource="http://www.w3.org/ns/formats/RDF_XML" />
  </sd:resultFormat>
</sd:Service>

Option 3 have a property on the format:
<sd:Format rdf:resource="http://www.w3.org/ns/formats/RDF_XML" />
  <format:formatType>RDF</format:formatType>
</sd:Format>


>> 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?

Yes, I expect that would be fine. Given that there are only two properties
and not even a Class at the moment and that they aren't part of any other
official specification. Having everything documented in one place would make
implementation easier.


>> 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.

That is a concern to me.


>> 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.

I am making some changes to RedStore now to bring it closer to the
specification.


nick.


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Thursday, 24 February 2011 12:10:15 UTC