RE: Joseki as a Web Service?

-------- Original Message --------
> From: Wei Xing <mailto:xing@ucy.ac.cy>
> Date: 10 December 2004 09:43
> 
> Dear Andy:
> 
> Many thanks for your prompt reply and your suggestions.
> 
> For the sake of implementing fast, I would prefer to the "Gateway"
> approach as it is much easy and time-saving (Axis will do, I think).
> On the other hand, we need somehow a "stable" approach instead of
> a "temporal" one. Thus, I would like to inquery you to make sure that
> the changes in Joseki (i.e. from Joseki2 to Joseki3) will not  affect
> our 
> implementation?

The SPARQL protocol, developed by the RDF Data Access working group, is
not compatible with the protocol used by Joseki2.  So, Joseki2 =>
Joseki3 is not a matter of simple replacement at the protocol level.
The biggest difference being that SPARQL SELECT queries return result
sets (in XML or in RDF/XML).  The protocol in Joseki2 can't handle
SPARQL query language properly.

As the SPARQL protocol has not even been published in first working
draft form yet, nor has the XML result format, (both are close to being
working draft, I understand) it's a bit difficult to create abstractions
to mask changes.

Starting with Joseki3 has the advantage that you can use SPARQL (the
query language) and have the different result forms.  The disadvantage
is that the codebase is tracking a changing defintion.

> 
> BTW, I read the draft of SPARQL and like it very much. It is solid and
> much poweful.

Thanks for saying so

	Andy

> 
> Thanks again for your suggestions.
> 
> Best regard
> 
> Wei Xing
> 
> --
> ============================================================
> Wei Xing, M.Sc.
> Research Associate                    Tel: 00357-22892663
> Dept. of Computer Science             Fax: 00357-22892701
> University of Cyprus                  email: xing@ucy.ac.cy
> PO Box 20537
> CY1678, Nicosia, CYPRUS
> 
> 
> Seaborne, Andy wrote:
> 
> > Hi there,
> > 
> > Joseki does split into the core engine that handles queries and a
> > wrapper that handles the protocol specific side.  There is no reason
> > for being tied to just HTTP GET and the deployments environments you
> > point out have facilities that are needed.
> > 
> > It has always been my intention to produce a SOAP protocol adapter
for
> > it and the code is structured with the intention of making that
> > possible.  It just hasn't happened.
> > 
> > The alternative is to have a gateway which speaks SOAP outwards and
> > passes requests on Joseki over HTTP or over some other connector
> > protocol that the web server speaks.  Joseki can be deployed in any
> > web application server such as Tomcat or Jetty so the gateway
function
> > doesn't even have to be a separate machine or process.  This may be
a
> > simpler deployment option for if any overheads don't significantly
> > impact performance. 
> > 
> > Plans at the moment are to track and implement the SPARQL protocol
in
> > a new version (Joseki3) together with a Jena implementation of the
> > query language part (ARQ).  There is an early prototype of Joseki3
> > (and ARQ) and if you are start to invest in the area, you may wish
to
> > go with these, depending on your timescales and robustness needs. 
> > The SPARQL protocol and query language are sufficiently different
> > that these are not compatible with the current main releases.
> > 
> > The SPARQL protocol should have concrete bindings for both HTTP GET
> > and SOAP but my guess is that the HTTP GET one will be first.
> > 
> > If you are interested in developing a SOAP front-end now, which
would
> > be more work than a gateway, then let me know and we can discuss
what
> > can be done to make this easier for you.
> > 
> > 	Andy
> > 
> > SPARQL / query language: working draft:
> > http://www.w3.org/TR/rdf-sparql-query/
> > SPARQL / protocol: working draft:
> > To be published soon.
> > 
> > Online demo of Joseki3 and ARQ:
> > http://www.sparql.org/query.html
> > 
> > Builds of prototypes (liitle documentation - ask questions on
> > jena-dev): http://jena.hpl.hp.com/~afs/ARQ/
> > and the code is in CVS on SourceForge.

Received on Friday, 10 December 2004 10:26:02 UTC