W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2011

GET on a graph store URI / Graph Store HTTP Protocol

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 14 Dec 2011 10:00:20 +0000
Message-ID: <4EE873B4.90806@epimorphics.com>
To: sparql Working Group <public-rdf-dawg@w3.org>
(from this week's telecon - this email picks off this one point in the 
hope of "divide-and-conquer" progress)

The GET on a graph store URI is defined to return the service 
description.  We didn't understand why.

The RDF-WG is (likely to) define formats for n-quads and TriG that can 
represent an RDF datasets.

GET <uri> returns a representation of the resource at <uri>.

So returning n-quads seems natural (an implementation can 403 it if it's 
too big).

A service description describes a service and its endpoints.

It connects a service to a dataset with sd:defaultDataset.

If GET of the graph store URI is the SD then don't we have:

     <uri> sd:defaultDataset <uri> .

A graph store is a container of graphs (unnamed and named).  It is not a 
general RDF processing service.

It might be that the graph store URI is overloaded with ?query= and 
?request= functionality but it is overloading the service endpoints with 
the resource itself.  In this case alone, does returning the SD make 
complete sense to me.

I can see why returning a description of the graph store makes sense and 
the SD vocabulary has language for that but that's only a part of the 
service description.

1/ Should the return at least be a description of the graph store (using 
the sd:defaultGraph sd:NamedGraph etc vocab)?

2/ Could we allow GET on a graph store URI return quads?

Received on Wednesday, 14 December 2011 10:03:18 UTC

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