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

-------- Original Message --------
> From: Thompson, Bryan B. <>
> Date: 26 May 2004 11:38
> 
> Andy,
> 
> Could you comment on this draft?

Looks good.

http://www.joseki.org/query-languages.html describes the query languages in
the distribution.  "fetch" which 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
(Yes - you can do a GET on that; its not interesting.)

	Andy

Couple of thing below:

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

And Joseki only provides HTTP.

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

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

This is not the default mode of operation, that is the subgraph match, and
you have to supply an additional parameter to the request ("format=BV")

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

But note that as the results are graphs, you can't stream process the
results.  There is no guarantee as to the serialization ordering even for
the result set in RDF.

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

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

Received on Thursday, 27 May 2004 10:49:56 UTC