*DRAFT*: writeup of joseki in response to action taken at last DA WG telcon.

Andy,

Could you comment on this draft?

-bryan

This completes my action to review joseki[1] against the current DAWG
draft (v1.89) requirements[2].  As described at [3], joseki is an
abstract protocol for RDF query and update languages.  An extensible
binding is specified and implemented for HTTP.  Joseki does not
specify a query language, but provides an extensible mechanism for a
client to indicate which query language (by URI or shortname) it wants
to use for a given request.  A limited set of query languages is
bundled with the standalone distribution, including: 'fetch', 'rdql',
....  An extensible mechanism is provided for declaring various update
operations.  Joseki bundles a declaration and implementation of two
update operations: 'add' and 'remove'.

Joseki inherits its protocol characteristics from the protocol onto
which it is bound, for example the content and transport encoding
aspects of the HTTP protocol and its graph query and update
characteristics from the query language selected by the client.

I reached two conclusions from this survey with broader relevance to
DAWG: (1) We do not have enough requirements yet concerning the
protocol; and (2) Our current requirements should be seperated into
protocol requirements and query language requirements for the purpose
of making technology evaluations such this one.

For the purposes of this evaluation I have indicated if Joseki could
support the requirement under an HTTP binding.  The codes are:

	j+ : joseki supports this requirement today under a suitable
 	     protocol binding and/or query language.

	j- : the requirement appears to be explicitly outside of the
	     scope of joseki, which is not to say that it could NOT be
	     met by a suitable revision of joseki.

	j? : need more information to make the determination.

Requirements:

j+ : 3.1 RDF Graph Pattern Matching (inherited from query lang.)

j- : 3.2 Variable Binding Results (no joseki mechanism exists today.)

j? : 3.3 Extensible Value Testing (probably if the specified query
         lang. supports this.)

j+ : 3.4 Subgraph Results (this is the specific mechanism for joseki)

j+ : 3.5 Local Queries (e.g., by using http://localhost/model?query
         for the HTTP binding.)

j+ : 3.6 Optional Match (if the specified query language supports
         this.)

j? : 3.7 Limited Datatype Support (probably if the specified query
         lang. supports this.)

j+ : 3.8 Bookmarkable Queries (under the HTTP binding.)

j+ : 3.9 Bandwidth-efficient Protocol (under the HTTP binding by using
         using the Accept-Encoding header to negotiate a content
         compression algorithm, the selected algorithm is indicated to
         the client via the Content-Encoding header.)

j? : 3.10 Result Limits (joseki does not currently support this in the
         abstract protocol.  If limits are a property of the query
         language and not the protocol, then joseki would inherit
         support for limits from a query language that supported
         them.)

Design Objectives:

j? : 4.1 Human-friendly Syntax (It all depends on the selected query
         language and on whether or not you consider something mashed
         into a URI to be 'human friendly'.  It would be easy to
         create a human friendly XForm interface for a given query
         language.)

j- : 4.2 Provenance (No explicit provisions have been made for
         provenance.)

j+ : 4.3 Non-existent Triples (If the selected query language supports
         this feature.)

j? : 4.4 User-specifiable Serialization (Perhaps, but which query
         languages support this feature?)

j? : 4.6 Aggregate Query (Perhaps, but which query languages support
         this feature?)

j? : 4.6 Additional Semantic Information (Perhaps, but which query
         languages support this feature?)


[1] http://www.joseki.org
[2] http://www.w3.org/2001/sw/DataAccess/UseCases
[3] http://www.joseki.org/protocol.html

Received on Wednesday, 26 May 2004 06:37:00 UTC