RE: [Sparql4j-devel] Design issue: datasource

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

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