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: Tue, 08 Feb 2011 14:06:31 +0000
Message-ID: <4D514DE7.60103@epimorphics.com>
To: Chimezie Ogbuji <chimezie@gmail.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
On 07/02/11 19:32, Chimezie Ogbuji wrote:
> On Sun, Feb 6, 2011 at 5:30 PM, Andy Seaborne
> <andy.seaborne@epimorphics.com>  wrote:
>>> 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
> Yes.  I guess that suggests (if we are using the SD vocabulary for
> this purpose) we should expect the URLs of the sd:Service instance
> (when retrieved from a Dataset HTTP protocol instance) to be used.  On
> that related note, I noticed the SD vocabulary has an sd:url property
> with a domain of sd:Service and a range of a URI reference.  How is
> this different from the URI of the sd:Service instance itself? I.e.,
> this seems redundant:
> <http://example.com/dataset-service>  a sd:Service;
>       sd:uri "http://example.com/dataset-service"^^xsd:anyURI
>> ... snp ...
>> Should it be:
>> <>  a sd:Service .
> Yes, I think this seems to be the most intuitive way to describe the
> dataset protocol service. i.e., using an empty relative URI reference
>> <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.
> Ok, make sense.
>>> 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.
> In the way you think about the service and the graph store, what is
> the relationship between them? Is it one-to-one? i.e.:


identifies triples.  It is not a service on triples except in the sense 
that everything is a service on something - but that "service" has 
common semantics of GET returns a representation.

Using a container point of view,
is the container of graphs, and you might PUT/GET the container.

For indirect addressing,

it's easier to see the service viewpoint (still arguable).

(I have removed the /employees as it conflicts with the direct 
addressing example)

> sd:defaultDatasetDescription a owl:FunctionalProperty

?? It can't be functional in all cases - suppose the dataset description 
is rather minimal.

And the domain of sd:defaultDatasetDescription is sd:Service and we 
might have several services.

> I think of it as a functional relationship.  From the REST view-point,
> however, I think of it in this way (using the vocabulary from my
> earlier email on this thread and from "HTTP semantics in OWL" [1]):
> @prefix tag:<http://w3.org/2001/tag/awwsw/http#>.
> sd:manages
>    a owl:FunctionalProperty;
>    rdfs:subPropertyOf sd:defaultDatasetDescription;
>    rdfs:domain sd:RESTDatasetService;
>    rdfs:range GraphStore

Sure but this does not affect the naming issue of whether 
http://example/graphs is a service or a GraphStore.

Can we have multiple service descriptions (query, update, 
RESTDatasetService) in one description? If so, which URL gets that 


> GraphStore owl:intersectionOf ( sd:DataSet tag:Get200WildRdfSubject
> MutableWebResource )
> [1] http://www.w3.org/2001/tag/awwsw/http.owl
Received on Tuesday, 8 February 2011 14:07:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:03 UTC