Re: ANN: Joseki, an RDF server for Jena

Hi Andy,

Yup, I'm an HTTP cop. 8-)

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

You found this easier than just implementing doGet(), doPut(), etc..?
And you recognize that you've sacrificed caching and bookmarking?

> I'm thinking of a world where models are 1st class resources and have URIs.

Me too!

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

Why conditional?  PUT would be appropriate too, to replace a statement.

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

Wouldn't that be a PUT?

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

Have you considered WebDAV LOCK?

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

Well, the model could be encapsulated within an HTTP intermediary such
that a GET on a resource proxied through that intermediary (where the
resource was referenced in that model) could return metadata on the
responding HTTP headers.

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

It's a trade-off, I suppose.  But my first impression is that this may
be a case of premature optimization.  Could be wrong though, I don't
have a lot of information to go by.

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

I would use GET for queries, as you mention above.

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

I understand, you made some calls.  If I were doing it, I'd start with
giving everything and URI and stick with HTTP and WebDAV methods.  If that
didn't perform as I wanted, then I'd consider doing what you did.  Just
IMHO, of course.

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

The protocol is the NetAPI, no? 8-)

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.

Received on Thursday, 28 March 2002 22:30:08 UTC