W3C home > Mailing lists > Public > semantic-web@w3.org > September 2008

Re: Survey of Java SPARQL endpoint query API

From: Mark Diggory <mdiggory@MIT.EDU>
Date: Sun, 21 Sep 2008 20:56:56 -0700
Message-Id: <B0725B1D-025F-4F1F-BCFE-3D80365F5E94@MIT.EDU>
To: SWIG <semantic-web@w3.org>

On Sep 21, 2008, at 1:48 PM, Alan Ruttenberg wrote:

> On Sun, Sep 21, 2008 at 12:15 PM, Mark Diggory <mdiggory@mit.edu>  
> wrote:
>> Hello,
>> I'm trying to get a survey of existing client side tools in Java for
>> interacting with SPARQL endpoints.  I realize that at a most basic  
>> level all
>> one needs to start with is an Http Client like Apache Commons  
>> HttpClient or
>> the Java HTTPURLConnection.  But, I'm looking more for clients that  
>> act more
>> like JDBC, allowing for the creation of prepared queries and  
>> iteration of
>> response results as "records" and possibly "paging" capabilities  
>> through
>> result-sets.
>> An important aspect I am seeking in such a library is that it be  
>> free of
>> underlying dependencies on any specific underlying triple-store
>> implementation behind that SPARQL endpoint.
> Yet your request that it be a client that act more like JDBC will do  
> just that.
> The HTTP SPARQL protocol is the only specified protocol for
> interacting with RDF stores. The results format is a very simple XML
> based format. If you want to be independent of implementation, I'd
> recommend that you stick with the basics.
> http://www.w3.org/TR/rdf-sparql-protocol/
> http://www.w3.org/TR/rdf-sparql-XMLres/
> -Alan

Alan, thank you for your response, It gives me an opportunity to  
elaborate further.  I tend to disagree. JDBC actually an example of  
how a common API allows very different vendor implementations to be  
accessed from the same interface (albeit, we won't go into the  
variance allowed in SQL that defeats this strategy). The one thing  
that all relational databases accessed via java share is being  
accessed via the common JDBC API. The one thing that would speed  
adoption of SPARQL endpoints as an important part of the Java  
community would be an API that simplifies the parsing so that there  
are not umteen local variants of such an API and/or the requirement to  
implement an entire specification every time someone needs a client  
side solution for communicating with a SPARQL ENDPOINT.  Finally, such  
an API would be considerably simpler in nature to implement than JDBC.

The point of a JAVA API for creating queries and processing them into  
record sets is to eliminate the need to be processing SPARQL/XML, RDF/ 
XML or JSON directly and thus encapsulate the parsing of such formats  
(which will possibly change over time) away from the application using  
the client code. I think it is sound to expect an API in this area.  
This is something that both REST and SOAP work to provide support for  
(via WSDL WADL) allowing for the generation of simple API for working  
with the protocol/resource backing them,

Mark Diggory
Received on Monday, 22 September 2008 03:57:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:07 UTC