- From: Mark Diggory <mdiggory@MIT.EDU>
- Date: Sun, 21 Sep 2008 22:24:41 -0700
- To: SWIG <semantic-web@w3.org>
On Sep 21, 2008, at 9:22 PM, Alan Ruttenberg wrote: > 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. Touche, I certainly see your point now, yes I am casting about for responses from those that may be implementing such clients in hopes of discovering ongoing activities. > >> 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. I guess I need to give a better example. Today I have: 1.) The Sesame TupleQuery API to SPARQL Query with local and remote Sesame Stores. http://www.openrdf.org/doc/sesame2/2.1.3/apidocs/org/openrdf/query/ package-use.html#org.openrdf.query.parser 2.) The ARQ Query Engine for Querying Jena... http://www.ibm.com/developerworks/xml/library/j-sparql/#2 3.) Support for SPARQL queries on Mulgara... http://www.mulgara.org/trac/wiki/UserAPI I know we are almost talking about different subjects here. I'm not being critical of SPARQL itself, its great and refreshingly simple. My point is that, these implementations (while they may have exposed valid SPARQL endpoints available when HTTP services are functioning) do not share an underlying common API for those of us that may want to work with them regardless of the deployment situation, local in process vs remote. Again, no fault there, these are certainly new technologies. > >> 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. Again, the challenge is that we are already dependent on those vendors and their various implementations unless we are working explicitly with the RESTful SPARQL endpoint and processing the responses ourselves. > >> 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. Yes, I do realize this and see the the difference, I shouldn't have included those ATM. > >> 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. point taken. > >> 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 so I am curious if a WADL has been created for it yet. > >> 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. Yes I would agree, the point was more about IDL capabilities, not so much the literal usage of SOAP. thanks again, Mark ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology Home Page: http://purl.org/net/mdiggory/homepage
Received on Monday, 22 September 2008 05:38:37 UTC