Re: Joseki as a Web Service?

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

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

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:
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:
>SPARQL / protocol: working draft:
>To be published soon.
>Online demo of Joseki3 and ARQ:
>Builds of prototypes (liitle documentation - ask questions on jena-dev):
>and the code is in CVS on SourceForge.

Received on Friday, 10 December 2004 09:45:52 UTC