Re: [Sparql4j-devel] SPARQL4J : a few first thoughts

[Janne S. <jan...@pr...>]

I very much agree with your goals for this project.
The non-RDF applications will find it easy to access SPARQL enabled repos=
itories. The easiness comes via using the familiar programming concepts r=
elating to access relational databases using JDBC. In addition, the easin=
ess comes via the use of on single jdbc driver instead of having to downl=
oad a separate one for each repository.

> This, together with the scoping of JDBC
> 
> """ javadoc java.sql (1.5.0)

I would be in favor of targetting 1.4.2 JDK to start with. This is due to=
 our product which ships with 1.4.2 support as we speak with 1.5 support =
coming in the future.

I should check what changes there are in java.sql from 1.4.2 to 1.5.
Would you remember by heart?

> means I see SPARQL4J as a JDBC driver that is mainly about issuing SPAR=
QL
> SELECT queries, rather than CONSTRUCT or DESCRIBE.  A release with just=

> SPARQL SELECT, using the plain XML result format, would be very useful =
to
> application writers - one, conventional, interface to RDF published dat=
a.
> Toolkit independent.

SELECT we start with - let's see how CONSTRUCT and DESCRIBE can be tweake=
d in the long run.

> We could be merely inspired by JDBC but actually produce a new
> interface that is more SPARQL suitable.  I'd like to avoid this for now=

> and try to implement "pure" JDBC.

My goal is the very same - let's know get into extensions right away.

> I'm assuming that the connection to the database (the RDF store, the
> knowledge base) is HTTP.  Now I would like to be able to take the
> SPARQL4J codebase and plug-in an adapter, instead of HTTP, to get a JDB=
C
> driver for ARQ [0] directly for local use.  We need a plug-in layer for=
 that 
> which is a connection layer with SPARQL-centric mechanisms and then hav=
e 
> common code for the presentation of results as JDBC methods.

Ok, I see. Internally we can create a factory that gives the protocol par=
t implementation for the other parts of the driver. From the user perspec=
tive this protocol should perhaps be visible on the datasource string? Wh=
at do you think? Let's start a separate thread on the datasource.

> Update - out of scope: Until there is a standard (de facto or de jure)
> language, servers won't implement a common way to do RDF update - there=
 are
> several major decisions, like handling bNodes, to be settled first.

Agreed - out of scope for now.

> A quick review of the JDBC interfaces shows few tricky parts:
> 
> 1/ NULLs.  SQL has NULLs; SPARQL has unbound variables. That in itself
> is not important - NULL would be just a way of saying "not bound".  But=

> the getXXX methods must return a value of the given type and getInt ret=
urns 
> 0 on NULL, which isn't very distinguishing value.  But in RDF, there is=
n't 
> always a value in the result set for a given row - NULLs become more co=
mmon 
> and the "return zero" solution is a bit weak.
> 
> Solutions?: Default values that are more unusual values (e.g. MIN_VALUE=
+2)
> or ones that can be set by the app (requires an extension to JDBC).

I would be happy with a default value. Let's see what the eventual other =
users think.

> 2/ Metadata.  Each solution to a SPARQL query can have different types
> of values for the same property.  Returning anything meaningful as
> "metadata" will need design work.  Solution?: For now, return very
> little and see if applications use the metadata information much.

Let's make a, if not dummy, a very basic implementation of the resultset =
metadata and listen to use cases that would require a more elaborate impl=
ementation.

> 3/ Error conditions: The JDBC interface assumes a conventional connecti=
on to
> a local database.  SPARQL is a web protocol and many error conditions m=
atter
> - the difference between soft errors like can't contact and hard errors=
 like
> invalid query make more of a difference to a web app.

I think the different errors could be modelled as a hierarchy of Exceptio=
ns subclassed from SQLExeption. This would enable client code determine d=
ifferent flavours of errors without having to do string parsing from a SQ=
LException to see what happened.

Janne
--
Janne Saarela <janne.saarela at profium.com>
Profium, Lars Sonckin kaari 12, 02600 Espoo, Finland
Internet: http://www.profium.com