- From: Chimezie Ogbuji <chimezie@gmail.com>
- Date: Tue, 1 Mar 2011 21:14:24 -0500
- To: Gregory Williams <greg@evilfunhouse.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Greg. On Mon, Feb 28, 2011 at 4:08 PM, Gregory Williams <greg@evilfunhouse.com> wrote: > ..snip.. > It seem to me that the easiest path forward might be adding a subclass of sd:Dataset that indicates that the dataset can be accessed via the dataset protocol. > ..snip.. > you'd have: > [] a sd:Service ; > sd:defaultDatasetDescription </dataset> . > </dataset> a sd:RESTDataset . That makes sense. > In your email you had suggested sd:RESTDatasetService, but "Service" seems odd to me as that URI identifies the dataset, right? So, the origin of the thread (as I remember it) was determining how, given a dataset protocol service URL, a client can discover the GraphStore / dataset URL. Then the discussion transitioned into whether or not there needed to be a new class of "services" representing the dataset protocol service in the SD document. However, your point above makes sense. So, if we allow an SD document to be served from the dataset protocol URL (as described in the dataset protocol specification) and the GraphStore URL is typed accordingly, then I think we would have addressed both issues. > I'm not tied to "RESTDataset", but want to make sure that whatever we end up with makes sense. I'm fine with RESTDataset. > This addition seems like the path of least resistance to me, so I'd like to hear your thoughts about it. Would it satisfy your needs for being able to describe datasets made available via the dataset protocol? Yes, I think it does. Thanks -- Chime
Received on Wednesday, 2 March 2011 02:15:16 UTC