Implementation Report: SPARQL/P

I have reimplemented Joseki - this is a complete restructuring.  It should now 
match the SPARQL Protocol.


== Server

The server is, as before HTTP based.  It now provides the service centric 
design.  If a service has an associated dataset, it can refuse to handle 
requests which contain FROM/FROM NAMED or use the protocol to specific the dataset.

I also included an implementation of POST using forms of
   Content-Type: application/x-www-form-urlencoded
http://www.w3.org/MarkUp/html-spec/html-spec_8.html

just to allow for long queries.  I suggest a informational section saying that 
the POST form should be done in this usual form style.


SPARQLer (http://www.sparlq.org/query.html) now runs this code.  Changes include:

No need for "lang=" - defaults to SPARQL.
Protocol names now correct: "default-graph-uri" (several allowed to align with 
the query language - I just form the RDF merge).

The services are
   <books> with a fixed dataset behind it which refuses to query anything else
   <sparql> which takes dataset descriptions from protocol or query.

Implements "stylesheet=" to inserts an XSLT processing instruction in the XML 
result form returned.

The bottom form interface has a general input box going to <sparql>.

It's not very robust yet - let me if it crashes and I'll restart it.  I found 
someone loading huge RDF graphs into the server recently and it crashed.  I 
intend to put (configuration settable) limits on the graph sizes it will read.

(Sorry Dan - this may break your previous URLs.)

== Client

This is now of ARQ and integrated with the command line results formatting with 
a new --service argument to the command line tools.  The commands parse queries 
to check for syntax errors locally before sending to a service.

When used programmatically, the client application has to indicate the query 
type by which of the operations it calls: 
execSelect()/execConstruct()/execDescribe()/execAsk()

c.f. Dan's issue about different interfaces.

Result parsing of the XML result form is done with SAX/Xerces.  I found it hard 
to parse XML results format and differentiate the type of results. As such, I 
currently don't and have different parsers for XML result sets and XML boolean 
results.  A field in the <head> area to give the type of results would help 
check for mixed XML.  Otherwise the decision is very late: it's presence of
/sparql/results/boolean or /sparql/results/result that differentiates and it's 
hard to check for a jumbled mixture.

 Andy

Received on Monday, 27 June 2005 13:44:12 UTC