Re: Survey of Java SPARQL endpoint query API

On Sun, Sep 21, 2008 at 11:56 PM, Mark Diggory <mdiggory@mit.edu> wrote:
>
>
> 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).

This would seem to be not an insignificant point. But let me be clear
as well. You asked how to avoid depending on a single implementation,
and I told you. I too agree that a standardized API for java would be
a good thing, but the key is *standard*. If you want such a thing you
need to work towards defining a standard, or influencing the variety
of implementors to support a defacto standard. Casting around for one
under the guise of looking for something portable will look as it did
to me - inconsistent.

> 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.

I think that while the case for RDBs might suggest this is the case,
I'm afraid it isn't for SPARQL, whose protocol and results format are
dead simple.

> Finally, such an API would be  considerably simpler in nature to implement than JDBC.

Again, no problem with you suggesting such a thing for
standardization, or writing one and proposing it. But don't suggest it
will help someone be independent of vendor until it will. For the
moment, if you want portability, use the published standards.

> 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

You only need to process SPARQL/XML. It is also important to realize
that the difference between RDBs and RDF is that in RDBs everything
*is* a flat record set, while in RDF, it's only the SPARQL query
results that look like that.

> directly and thus encapsulate the parsing of such formats (which will
> possibly change over time)

Anything is possible. I can't see why, in this case, there's any
reason to believe that they will.

> 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

The SPARQL protocol is RESTful.

> 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.

Well, tastes vary. I certainly wouldn't trade the simplicity of the
SPARQL results XML format for the complexity that is SOAP.

Regards,
-Alan

Received on Monday, 22 September 2008 04:23:06 UTC