W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2005

Implementation Report: SPARQL/P

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 27 Jun 2005 14:43:48 +0100
Message-ID: <42C00294.1030600@hp.com>
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>

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

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: 

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:35 UTC