RE: [Sparql4j-devel] Design issue: datasource
Status: Pre-Alpha
Brought to you by:
jsaarela
|
From: Seaborne, A. <and...@hp...> - 2005-01-25 12:08:12
|
-------- Original Message -------- > From: Janne Saarela <> > Date: 20 January 2005 09:05 >=20 > > > I would like to propose the datasource for this driver to be > > >=20 > > > jdbc:sparql4j:[http|other]://www.serveraddress.com[:port]/path/more;para m1=3Dvalue1 > > >=20 > >=20 > >=20 > > Checking, I found that the syntax is formally: > >=20 > > jdbc:<subprotocol>:<subname> > >=20 > > and very little restrictions on the subname (it can include : and /). > >=20 > > We can have our own subsubprotocol so: > >=20 > > jdbc:sparql4j:<subsubprotocol> > >=20 > > and we don't need to have a fixed remainder; it can be dependent on > > the subsubprotocol. For http, your suggestion of > >=20 > > =20 > > jdbc:sparql4j:http://www.serveraddress.com[:port]/path/more;param1=3Dvalu= e 1 > >=20 > > 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.=20 > >=20 > > Hmm, - actually there is a level missing. We need something like: > >=20 > > jdbc:sparql4j:sparql > >=20 > > (yuk - 2 sparql's) to say: > >=20 > > jdbc:sparql4j > > Get JDBC to route requests to our driver > >=20 > > jdbc:sparql4j:sparql > > our driver is going to use the SPARQL protocol > >=20 > > jdbc:sparql4j:sparql:http://server/path > > our driver is going to use SPARQL protocol at the named service > >=20 > > May be that's excessive. An alternative is to not have sparql4j be > > the subprotocol name and directly name the connection protocol: >=20 > I'm wondering what happens if the sparql protocol enables short names in > the 'lang' attribute value, will the datasource effectively have to be > something like >=20 > jdbc:sparql:http://server/queryprocessor?lang=3Dsparql There is a different between the URL for the JDBC connection and the URL for the service request. The ":sparql:", and any service description, should be enough to tell the driver how to build the servcie request. The terminology caught be out for a while but in JDBC, the jdbc: URL names a connection, and a connection can have many request with different query strings. Hacking up a driver made it clearer for me :-) Andy >=20 > This would mean any service description part of the protocol would need > to be available before an application is built. >=20 > A datasource such as >=20 > jdbc:sparql:http://server/queryprocessor >=20 > would effectively have to fetch a service description before launching > the first query in order to determine the 'lang' value. Luckily that > value should be cacheable not having to fetch it before every single > query.=20 >=20 > Janne > -- > Janne Saarela <janne.saarela at profium.com> > Profium, Lars Sonckin kaari 12, 02600 Espoo, Finland > Internet: http://www.profium.com >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Sparql4j-devel mailing list > Spa...@li... > https://lists.sourceforge.net/lists/listinfo/sparql4j-devel |