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

Re: Service or graph store naming.

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Sun, 06 Feb 2011 22:30:46 +0000
Message-ID: <4D4F2116.4070706@epimorphics.com>
To: Chimezie Ogbuji <chimezie@gmail.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>

> Currently, http://host/graphstore is considered the Dataset HTTP
> Protocol service.  There is an assumption that the service location is
> known apriori and the graph store URI is described in its service
> description document.  So the follow-your-nose pattern of discovery
> is:
>
> GET .. dataset protocol service URL .. HTTP/1.1
> Host: ..hostname..
>
> returns
>
> @prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>  .
> @prefix sd:<http://www.w3.org/ns/sparql-service-description#>  .
>
> [] a sd:Service;
>     sd:defaultDatasetDescription<http://host/graphstore>
> <http://host/graphstore>  a sd:Dataset; ..snip..

But this says:

http://host/graphstore a sd:Dataset ;
and

[] a sd:Service;

which is odd to return from Dataset HTTP Protocol service

http://host/graphstore

If it said:

<> a sd:Service;
or
<http://host/graphstore> a sd:Service;

then it's a service and a dataset.

Should it be:

<> a sd:Service .

<http://host/graphstore/dataset a sd:Dataset .

> It is not clear to me what capabilities allowing other verbs (beyond
> POST) would provide that you wouldn't already have (albeit at a level
> of granularity no larger than a single graph)

Looking to the possibility of RDF3-WG doing named graph, or something 
around that, and the existence of N-Quads and TriG already, the HTTP 
verbs have a natural meaning on the dataset/graph store as a whole. 
While I acknowledge this is to-be-decided-elsewhere, the formats exist 
today.

Uses include dump and restore.

>> There will be other URIs for
>> services (query, update) anyway so leave this as the graph store and put the
>> service description with a service URI.
>
> It seems more intuitive to me to have that be the service since that
> already has a self-describing document format, is assumed to have a
> location that is known apriori, and there seems to be less use cases
> that motivate direct access to the graph store.

It seems to me to be just as natural in a REST view-point that the 
things is the graphstore.  If I think in service-style, then as a 
service works, but it seems just as valid to think in terms of having 
the graphstore itself named.

I'm undecided on this currently.

	Andy
Received on Sunday, 6 February 2011 22:31:23 GMT

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