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 <[email protected]> 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> >
