- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 08 Feb 2011 14:06:31 +0000
- 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.: Example: http://example.com/rdf-graphs/employees 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, http://example.com/rdf-graphs is the container of graphs, and you might PUT/GET the container. For indirect addressing, http://example.com/rdf-graphs?graph= 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 description? Andy > > 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