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

Re: Service or graph store naming.

From: Gregory Williams <greg@evilfunhouse.com>
Date: Sun, 6 Feb 2011 12:32:49 -0500
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <16ED8E93-D05F-4A96-9A4A-9D4F3E704E80@evilfunhouse.com>
To: Chimezie Ogbuji <chimezie@gmail.com>
On Feb 6, 2011, at 12:03 PM, Chimezie Ogbuji wrote:

> On Sun, Feb 6, 2011 at 10:14 AM, Gregory Williams <greg@evilfunhouse.com> wrote:
>> Have we discussed this before?
> 
> Yes, see my My May 18th 2010 email
> (http://lists.w3.org/Archives/Public/public-rdf-dawg/2010AprJun/0202.html)
> in response to you regarding this.  Eventually, an editor's note was
> added in the last publication cycle in order to solicit feedback from
> the community as well as the WG.

Ah. I had forgotten about that email.

>> Until this thread I didn't realize anyone was expecting the service description to have any relationship with the dataset protocol. I'm a > bit uncomfortable with only having a "follow your nose" pattern of discovery for a graph store URI in the service description.  I worry
>> that it will lead to a situation where software tries to dereference any URI used in a SD dataset description, even for the (many?)
>> services that don't implement the dataset protocol.
> 
> Not *any* URI, just the URI of an instance of sd:Dataset.  This might
> be a little off topic, but I generally think of two categories of
> "follow your nose" (or 'linked data') traversal through a network of
> RDF: a) one where the client doesn't have any guidance about which URI
> should be followed and there is a general assumption that most RDF
> URIs are dereferencable and b) one where the vocabulary indicates
> which URIs are dereferenceable (such as terms like owl:imports,
> rdfs:seeAlso, etc.).  I share the same concerns you have about the
> first category, but this mechanism uses the second one.

I don't agree that this is entirely the second case. Protocol implementations that return a service description but don't implement the dataset protocol may still have URIs for the dataset. Just the use of sd:defaultDatasetDescription (or typing as sd:Dataset) isn't enough to imply that the URI acts as part of the dataset protocol. The only way as described to find out is to dereference the URI and see if you get anything back.

>> I'm not entirely opposed to aligning the SD document with the dataset protocol, but I've never developed it with that connection in
>> mind and had always assumed that at this stage it was only meant to work with the (non-dataset) protocol.
> 
> So, in the currently published dataset protocol document, the editor's
> note in that section says:
> 
> [[[
> The Service Description document provides an RDF vocabulary term
> (sd:Dataset) that can be used in statements about a SPARQL Dataset,
> however, it is not clear what URI the client can use to request such a
> service description that provides the URI of the Network-manipulable
> Graph Store (typed as an instance of sd:Dataset).
> ]]]
> 
> s/Network-manipulable/
> 
> Is this an improper use of the sd:Dataset term? Currently, the section
> in the Service Description editor's draft about this term says: "An
> instance of sd:Dataset represents a RDF Dataset comprised of a default
> graph and zero or more named graphs."

I don't think it's improper, no. But sd:Dataset is a fundamental part of the service description vocabulary that doesn't necessarily imply availability of a dataset protocol resource.

.greg
Received on Sunday, 6 February 2011 17:33:21 GMT

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