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
implementation?

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: 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 09:45:52 UTC