Re: [Sparql4j-devel] Design issue: datasource

[Seaborne, A. <and...@hp...>]

Janne Saarela wrote:
> I would like to propose the datasource for this driver to be
> 
> jdbc:sparql4j:[http|other]://www.serveraddress.com[:port]/path/more;param1=value1

Checking, I found that the syntax is formally:

   jdbc:<subprotocol>:<subname>

and very little restrictions on the subname (it can include : and /).

We can have our own subsubprotocol so:

   jdbc:sparql4j:<subsubprotocol>

and we don't need to have a fixed remainder; it can be dependent on the 
subsubprotocol. For http, your suggestion of

   jdbc:sparql4j:http://www.serveraddress.com[:port]/path/more;param1=value1

look right.  To be clear, we have a URL for the service/model that we are 
going to query (the URL is NOT the query to go to the SPARQL server). The 
parameter is a parameter for the driver, not the SPARQL protocol.

Hmm, - actually there is a level missing.  We need something like:

   jdbc:sparql4j:sparql

(yuk - 2 sparql's) to say:

jdbc:sparql4j
   Get JDBC to route requests to our driver

jdbc:sparql4j:sparql
   our driver is going to use the SPARQL protocol

jdbc:sparql4j:sparql:http://server/path
   our driver is going to use SPARQL protocol at the named service

May be that's excessive.  An alternative is to not have sparql4j be the 
subprotocol name and directly name the connection protocol:

   jdbc:sparql

to mean our driver using the SPARQL protocol.  Our driver code using a 
different connection protocol would a different name at the JDBC protocol 
level.  This exposes the base connection technology to the application but 
that seems good and bad.

Good - it allows the app to choose
Bad - the app writer has another decision to make.

So taking the Jena/ARQ direct connect, it would have it's own name, own 
java.sql.Driver implementation (inheriting code from sparql4j).

Implementing javax.sql.DataSource is also possible but, for now, I don't see 
sufficient value over reusing the java.sql.DriverManager.


Given all that thinking aloud, I think the combination of:

   Class.forName("net.sf.sparql4j.Driver") ;

and a JDBC URL of

   jdbc:sparql:http://server/path[;param=value]*

is best.  The change from Janne's sugegstion is that the connection protocol 
isnamed, not the driver implementation and it allows other drivers to handle 
the SPARQL protocol.  We have decided the SPARQL JDBC format - a member 
submission or working group note could document it if a paragraph in the 
protocol document can't be added.  Registering "sparql" as a JDBS 
subprotocol could be done as well - later.


There isn't so much online documentation on writing the driver as choosing 
and using them (strangely that!).  The MySQL JDBC driver is GPL but the 
PostgreSQL has BSD-like license so if you're looking at the source code, 
this is safer.

http://jdbc.postgresql.org/index.html

	Andy

PS We have the option of using the org.sparql. Java package space as I have 
access to that.

> 
> This would enable addition of other protocols apart from HTTP.
> HTTP itself could express the full URI (in encoded form) with
 > additional parameters at the very end as allowed by a datasource string.


> 
> Janne
> --
> Janne Saarela <janne.saarela at profium.com>
> Profium, Lars Sonckin kaari 12, 02600 Espoo, Finland
> Internet: http://www.profium.com
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Sparql4j-devel mailing list
> Spa...@li...
> https://lists.sourceforge.net/lists/listinfo/sparql4j-devel