Re: Service or graph store naming.

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