Joseki - publishing RDF

Joseki web site: http://www.joseki.org

This is a brief description of Joseki as of November 2003.


Joseki is an RDF server for publishing RDF.  It is the "Jena RDF Server" -
and is part of the Jena framework.  It is distributed separately so it can
have a different cycle, and to keep the Jena download small(er); because it
comes able to run out of the box, it has a web server in it (Jetty).

The design space for Joseki is publishing - letting remote applications
access RDF repositories (knowledge bases / KBs) across the web.  KBs have
URLs. Access can be by simple HTTP GET or by query, using URL query strings.
A server can configured not to allow plain GET (no query string) - for
SIMILE GETting a whole corpus is not a good idea because of its size.

The protocol design is that all query operations return a graph.  Usually
this is a subgraph of the target KB but operation-specific parameters can
change this.  The syntax encoding of the returned graph is determined by
content negotiation and can be RDF/XML (the default), N3 or N-triples.

Three main query language processors provided in the standard distribution
are:

The GET processor: A plain GET is a query and is handled by a regular query
processor.

The RDQL processor: The RDQL processor return the subgraph formed by merging
all the matched triples from all the query solutions.  This subgraph will
yield the same results for the query as when executed on the whole KB.  The
RDQL processor is also able to return an RDF encoding of the result set
according to the vocabulary [1] [2] by adding a parameter to the request.

The "fetch" processor: The fetch query is an operation to get RDF about some
resource.  The decision of what is returned is determined by the server.  If
you ask for a book, it might choose to send author information as well as
all the book details.  Fetch processors are, again, configurable but a
common use if the bNode closure one.

Query languages are modules loaded at run time.  You can write new query
processors - they don't have to query Jena models.  Chris Bizer has built a
query processor that can access SQL databases with conventional database
schema [5].

See also: TAP [3] and URIQA [4]

An expected use is to have Joseki front-end a Jena database-backed model.
All Joseki operations are transactional on the database (if there are no
transactions it uses MRSW (Multiple Reader, Single Writer) locking).
Another (Jena) application on the server can be updating the database and
the Joseki server will show what's in the changing database. Given
transaction boundaries are in sensible places, the remote clients see
consistent RDF, both in the sense of an intact graph and also no partial
additions/removals/changes of a number of RDF statements (e.g. adding a
vCard is more than a single statement).  This is just typical web
application structures.  Front publishing, with separate update processes.

There are client libraries in the distribution for Joseki in Java and Python
(using RDFLib [7]).  With the help from Kevin, there'll be a Perl one too. 

There have been other implementations of the RDF NetAPI style [6] protocol,
in SOAP and also other HTTP based servers.

	Andy


[0] Joseki web site: http://www.joseki.org

[1] Result set RDF vocabulary description
    http://www.w3.org/2003/03/rdfqr-tests/recording-query-results.html

[2] Result set RDF vocabulary
    N3:       http://jena.hpl.hp.com/2003/03/result-set.n3
    RDF/XML:  http://jena.hpl.hp.com/2003/03/result-set.rdf

[3] TAP: http://tap.stanford.edu/

[4] URIQA: http://sw.nokia.com/uriqa/URIQA.html

[5] D2R: http://www.wiwiss.fu-berlin.de/suhl/bizer/d2rmap/D2Rmap.htm

[6] RDF NetAPI: http://www.w3.org/Submission/2003/SUBM-rdf-netapi-20031002/

[7] RDFLib: http://rdflib.net/

Received on Thursday, 20 November 2003 05:27:29 UTC