W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2011

Re: Dataset HTTP Protocol and Service Descriptions

From: Chimezie Ogbuji <chimezie@gmail.com>
Date: Fri, 4 Mar 2011 08:08:25 -0500
Message-ID: <AANLkTimVJ8UPKmnfNcn24UwL8J7_9wD=zFWSc+mx2C-6@mail.gmail.com>
To: Gregory Williams <greg@evilfunhouse.com>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Greg see my response inline below

On Thu, Mar 3, 2011 at 5:43 PM, Gregory Williams <greg@evilfunhouse.com> wrote:
> On Mar 1, 2011, at 9:14 PM, Chimezie Ogbuji wrote:
>> ..snip..
> I'm wary of "allowing an SD document to be served from the dataset protocol URL," if "allowing" means anything other than not specifying behavior.
> I realize this is in the dataset protocol document right now, but we never discussed this in any detail and I'm hesitant to specify this in the service description document because I worry it'll drag a ton of problems with it.

I'm not sure what you mean by 'drag a ton of problems with it.'

The SD document as it is written seems mostly agnostic about the
protocols it describes and most (certainly not all) of the description
vocabulary has to do with the dataset associated with the protocol.
If we do want SDs to be used with all the various protocols then all I
think is required is to clarify the few places where the document
seems to rule out use with anything other than the 'SPARQL protocol'.
Otherwise, we would still have issues regarding the current state of
the interaction between the RDF Dataset HTTP Protocol and Service
Descriptions as Leigh was describing.

Alternatively, this behavior as described in the dataset protocol
specification would need to be removed since it wouldn't be enough to
not specify behavior since (in the SD document) we have:

[[[
This document describes SPARQL service description, a method for
discovering, and vocabulary for describing SPARQL services made
available via the SPARQL 1.1 Protocol for RDF [...]
]]]

And a SPARQL Service is explicitly defined as "any implementation
conforming to the SPARQL 1.1 Protocol for RDF [SPROT]."

etc.

Also, I notice, for instance, that in the SD document (in the section
"3.2.14 sd:inputFormat") there is this:

[[[
Relates an instance of sd:Service to a format that is supported for
parsing RDF input (for example, [...] or an HTTP PUT as described by
SPARQL 1.1 RDF Dataset HTTP Protocol [SPARQLHTTP]).
]]]

This reference begs the same question about the interaction.

> Adding a sd:RESTService is an easy way for an existing Protocol implementation to indicate offhandedly that the default dataset is available through the dataset protocol, but trying to make the SD document also work for specifying details of a dataset protocol implementation seems to me to be beyond the scope of the SD document.

Okay, but the only way this offhand indication can be determined by a
client is via access to the SPARQL protocol.  That suggests that the
SD document would support discovery of GraphStore identifiers for
interaction via the dataset protocol but the URL of the dataset
protocol would need to be determined apriori by some other mechanism.
The only motivation for the text in the dataset protocol about the use
of SD document for this purpose was that it seemed the most
appropriate place for it in the grand scheme of things.

-- Chime
Received on Friday, 4 March 2011 13:09:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:45 GMT