RE: ANN: Joseki, an RDF server for Jena

>I think PUT is about an operation on the whole model but a "partial PUT" to
>do replace and "partial DELETE" may be OK -- PUT and DELETE are really
about
>the whole resource at the URI i.e. the whole model.

I could envisage a PUT as a statement insertion/replace.
For this to be possible statements would have to have URIs.

something like this .../modelname/statementID.

statementID could be a digest of the triple.



One of the things I find a bit odd about the Semantic Web is the gap between
the REST model of the web and RDF systems.
I hope this initiative will bridge that gap.

regards

Nigel Hutchison

Nigel W.O Hutchison
Chief Scientist 
Software AG
Uhlandstr 12,D-64297 Darmstadt, Germany
+49 6151 92 1207




-----Original Message-----
From: Seaborne, Andy [mailto:Andy_Seaborne@hplb.hpl.hp.com]
Sent: Wednesday, March 27, 2002 2:36 PM
To: 'Mark Baker'
Cc: www-rdf-interest@w3.org
Subject: RE: ANN: Joseki, an RDF server for Jena


Mark,

Good to hear from you - especially as I know you're interested in REST style
architectures.

The operations described (update and query) are the abstraction of
operations which could be realised in various different ways (SOAP, directly
in HTTP operations (c.f. webdav), servlets).

In Joseki, I choose to use HTTP POST and servlets because it is easy to
supply a web server add-on to get the thing running.  Run the standalone
server from the command line or drop in the WAR file and go.

I'm thinking of a world where models are 1st class resources and have URIs.
There are three categories of RDF operations:

- Operations on models themselves (GET, PUT, DELETE of whole models)
- Operations on the statements in model (conditional GET)
- The meta operation of what operations/options are possible on this model.

The correct set of operations on statement in models is by no means
finished.  It has been suggested that a "replace" is needed to remove
everything about a resource and replace it with new information.  As the
operations stand, the app needs to do a query to find all the relevant
triples, then do a second operation to delete them and add the new ones.
This leave a timing hole and transfers the to-be-deleted statements twice
for no reason.  

In this style, models (collections of statements) are first class resources
so meta-data about resources is not necessarily located with the resource.
The style where metadata is stored with the resource would also be good -
sort of GET-META or PUT-META (maybe by MIME negotiation).

There is also a choice about granularity - one choice is operations on
individual triples (add statement, delete statement) which is the
fine-grained approach.  An alternative is to have operations on sets of
statements.  I choose the latter because it means the model can go from one
consistent view to another consistent view in a single operation.
"Consistent" may involve deleting several triples and adding multiple
triples.

An alternative protocol to realise the same abstraction that more directly
uses HTTP would be to be to use 

	"GET modelURI?query"
	"POST modeURI" with adds and deletes in the body

I think PUT is about an operation on the whole model but a "partial PUT" to
do replace and "partial DELETE" may be OK -- PUT and DELETE are really about
the whole resource at the URI i.e. the whole model.  This is realising the
operations in a different way where transport end point (where the operation
is performed) is also the name of the object being operated on (404's and
all that).  Joseki splits the two concepts.


I wasn't sure what the GET in your comment was acting on.  Was it a triple
(possibly taking the note about triples and URIs a bit too literally).  If
so, is the model all the URIs this server hosts? (i.e. there is no explicit
concept of a model).

In Joseki, all triples do get an identity - I reify them to transfer them (I
just use the resource for the statement - currently the resource for the
reification is a bNode.  I could have chosen to generate a URI (modulo
mutterings about overhead).

I know you like REST style architectures - while REST is about a hypermedia
system and I am thinking about manipulation of collections of RDF, the
infrastructure is common and I have picked some key features from it.  The
use of coarse-grained operations to help efficient server deployment; a
first attempt to define a fixed set of verbs, with variations in the
parameters (e.g. choice of query language and result formats).  It isn't
RPC-style in the sense that there would be a few fixed, well known
operations, not operations defined by the domain of usage (i.e. application
specific operations like "get everything known about such-and-such" - the
"everything" is application dependent) which requires a client to reflect to
see if it understands the API.

In this first prototype that realises the RDFNetAPI, I made some pragmatic
choices: not modifying  HTTP, simple deployment of packages protocol engine,
client-side API in Java for Jena.  Other implementations would be good.  I
am thinking about the abstraction of a NetAPI, not so much of the concrete
protocol.

	Andy

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: 27 March 2002 04:42
To: Andy_Seaborne@hplb.hpl.hp.com
Cc: www-rdf-interest@w3.org
Subject: Re: ANN: Joseki, an RDF server for Jena


> The RDF NetAPI has two operations:
>     + Update(modelURI, triples to delete, triple to add)
>     + Query(modelURI, query) -> results

What about using HTTP for this?  GET for queries, POST for add, PUT for
replace, DELETE for deletion.  This way you can identify your triples
with URIs too; yummy goodness.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Wednesday, 27 March 2002 08:59:28 UTC