Hi,
Just a quick note, as I am the developer of Sparqlify[1], which pretty
much is a general SQL-to-RDF mapping layer (well, or at least SPARQL-SQL
rewriter) based on Jena (it also has some dependencies to SDB).
From my experience, although I had and still have some dependencies to
SDB, but I had to e.g. duplicate the SqlExpr hierachy (e.g. [2]) because
I needed each SqlExpr to provide its datatype).
The old master branch of Sparqlify already had initial support for
rewriting spatial predicates to SQL (only ST_Intersects and ST_DWithin),
but we are currently enhancing this system to allow one to essentially
expose any (or at least most) SQL functions as a SPARQL one.
[1] https://github.com/AKSW/Sparqlify
[2]
https://github.com/AKSW/Sparqlify/tree/master/sparqlify-core/src/main/java/org/aksw/sparqlify/algebra/sql/exprs2
Cheers,
Claus
On 06/07/2013 11:54 AM, Olivier Rossel wrote:
Could SDB be useful when dealing with GeoSPARQL and your backend is
(something like) Postgresql+Postgis?
(just a question, this is not one of my needs at the moment).
On Fri, Jun 7, 2013 at 11:29 AM, Andy Seaborne <a...@apache.org> wrote:
SDB is a Jena storage module that uses SQL databases for RDF storage. See
[1] for documentation. It uses a custom database schema to store RDF; it is
not a general SQL-to-RDF mapping layer.
The supported databases are: Oracle, Microsoft SQL Server, DB2,
PostgreSQL, MySQL, Apache Derby, H2, HSQLDB. Only Derby and HSQLDB are
tested in the development build process.
Both Oracle and IBM corporations provide commercial RDF solutions using
Jena that are completely unrelated to SDB.
TDB is faster, more scalable and better supported than SDB but there can
be reasons why an SQL-backed solution is appropriate.
There is no active development or maintenance of SDB from within the
committer team; no committers use SDB and it imposes a cost to the team to
generate separate releases. We're not receiving patches contributed to
JIRA items for bugs.
We are proposing:
1/ moving it into the main build so it will be part of the main
distribution with limited testing.
2/ marking it as "under review / maintenance only".
It will not be treated as something that can block a release, nor for any
significant length of time, stop development builds.
It may be pulled from the main build, and from a release, at very short
notice.
If moved out, the source code will still be available but no binaries
(releases or development builds) will be produced.
What would change SDB's status is care and attention. There are ways to
enhance it, for example, pushing the work of filters into the SQL database,
where possible, to improve query performance.
Andy
[1]
http://jena.apache.org/**documentation/sdb/index.html<http://jena.apache.org/documentation/sdb/index.html>
--
Dipl. Inf. Claus Stadler
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org/
Workpage & WebID: http://aksw.org/ClausStadler
Phone: +49 341 97-32260
