ACTION: writeup of joseki in response to action taken at last DAW G telcon.

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.

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. 

Implementation details.

I reviewed a specific implementation of joskei[1].  This Joseki
distribution supports HTTP GET and provides the following query
languages: RDQL[5], Fetch, and SPO.  [4] describes these query
languages.

     RDQL: Uses the Jena implementation of RDQL.  RDQL is an
	   implementation of the SquishQL RDF query language, which
	   itself is derived from rdfDB.  This class of query
	   languages regards RDF as triple data, without schema or
	   ontology information.

     fetch: The 'fetch' query language provides a "describe" or "tell
            me about" query.  It takes a resource as argument
            (alternatively, it takes a property/object pair to find
            the subject or subjects).  It returns some RDF depending
            on server and setup.  Typically the bNode closure from
            that resource as subject; it it were FOAF, then the
            closure might be to resources of type foaf:Person + the
            defining foaf:mbox property.  The URI for "fetch" is
            http://jena.hpl.hp.com/2003/07/query/fetch

     SPO: Also known as "Triples", SPO is an experimental minimal
          query language. An SPO query is a single triple pattern,
          with optional subject (parameter "s"), predicate (parameter
          "p"), and object (parameter "o", if a URIref, parameter "v"
          for a string literal). Absence of a parameter implies "any"
          for matching that slot of the triple pattern.

An extensible mechanism is provided for declaring various update
operations.  Joseki bundles a declaration and implementation of two
update operations: 'add' and 'remove'.

Conclusions.

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.

Survey Results.

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.

           All results from a request are RDF graphs - you can ask the
	   RDQL processor for the result set in RDF form using the
	   vocabulary:

	
http://www.w3.org/2003/03/rdfqr-tests/recording-query-results.html 

	   The default mode of operation is the subgraph match.  You
	   have to supply an additional parameter to the request
	   ("format=BV") to get a variable binding result.

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.
         However, results would be unordered unless an ordering is
         somehow specified, which means that the same request with a
         limit parameter could return differing results on each
         invocation against an unchanged triple store.)

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. 

         Andy notes: "An RDQL query to Jena using jrv:directSubClassOf
	 or jrv:directSubPropertyOf.  jrv is the Jena Reasoner
	 Vocabulary.  It's a feature of the QL, not the protocol
	 although it could be a feature of which graph you ask."


[1] http://www.joseki.org 
[2] http://www.w3.org/2001/sw/DataAccess/UseCases 
[3] http://www.joseki.org/protocol.html 
[4] http://www.joseki.org/query-languages.html
[5] http://jena.sourceforge.net/tutorial/RDQL/index.html

Received on Tuesday, 1 June 2004 08:45:05 UTC