On 22/11/12 19:18, Bell, Paul M. wrote:
Hi,
I have a few questions about Jena's storage and query capabilities.
1. Jena seems to support RDF stores of these types: in-memory, SQL,
native tuple store (TDB), and "custom." How are these stores
initially populated, i.e., does Jena offer some kind of "load
facility" that reads from, say, SQL and writes RDF?
The Jena APi can be used on any store so once code has got a hanle on
the store (dataset, model) everythign is the same.
Jena itself does not offer a legacy SQL to RDF path - theer are tools
such as D2RQ that offer that as a dump or as a live connection back to
the original (and live) data. Look for R2RML tools - R2RML is the W3C
standard for this.
D2RQ offers R2RML or soon will do (it's not from the Apache Jena
project, it used Jena IIRC).
There are commercial tools.
2. If there is such a load facility, can it read from a NoSQL DB,
e.g., MongoDB, and write to the RDF store?
Not in Jena per se. A key stap is mapping the data to an RDF data
model. That can be simple (close to being a RDFization of the NoSQL
store), or complex (presenting higher level modelling concepts).
3. Suppose that a SPARQL query needed to reference non-triplestore
data. Can Jena call into a custom "adapter" that reads these
non-triplestore data, receive these data from the adapter, and
incorporate them into its query resolution?
See R2RML - that would give a SPARQL interface to an existing SQL DB.
A more general question: what are some common practices concerning
RDF store consistency? I suppose that most RDF stores are initially
populated from SQL stores. Given the likely volatility of SQL stores,
doesn't this mean that the RDF store can quickly grow stale, i.e., it
might contain relationships among resources that no longer exist? How
is this consistency issue handled in the real world?
Not sure that most stores are populated from SQL.
If liveness matters, a dynamic connection such as D2RQ offers up-to-date
access.
Andy
Thanks for your help.
Cordially,
Paul
