Re: Service or graph store naming.

Okay.  So, if I'm not mistaken, currently the Dataset Protocol is the
only protocol that allows a client to access the graph store and the
only kind of access currently sanctioned is POST which is used to add
a named graph to it and allow the service to allocate a graph URI for
it (ala. the Atom Pub collection usecase).

On Fri, Feb 4, 2011 at 4:23 AM, Andy Seaborne
<andy.seaborne@epimorphics.com> wrote:
> ..snip..
> This matters because GET behaves differently:
>
> GET <service> -> service description
>
> GET <graphStore> -> TriG for the store if allowed.

This behavior is not currently specified.

> Looking forward, with the new RDF WG, we do need to leave the possibility of
> the graph store having a URL and GET/PUT to that URL.

Where do you envision this method would be specified (in which specification)?

> There may be multiple services (endpoints) on one graph store.
> In Fuseki, I currently have both a service URI and a graph store URI
>
> If the graph store is: http://host/dataset
>
> The services are:
>
> # RDF Dataset HTTP Protocol
> http://host/graphstore/data
> ..snip..
> My preference is for http://host/graphstore?graph=... to mean that
> http://host/graphstore is the graph store.

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..

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)

> 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.

-- Chime

Received on Saturday, 5 February 2011 05:28:01 UTC