- From: Chimezie Ogbuji <chimezie@gmail.com>
- Date: Mon, 7 Feb 2011 14:32:49 -0500
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
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.: sd:defaultDatasetDescription a owl:FunctionalProperty 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 GraphStore owl:intersectionOf ( sd:DataSet tag:Get200WildRdfSubject MutableWebResource ) [1] http://www.w3.org/2001/tag/awwsw/http.owl
Received on Monday, 7 February 2011 19:33:42 UTC