Thanks Andy! -----Original Message----- From: Andy Seaborne [mailto:[email protected]] Sent: Tuesday, April 26, 2016 1:09 PM To: [email protected] Subject: Re: porting Jena onto new storage facility
On 26/04/16 18:04, David Jordan wrote: > Thanks. Most of these are in package org.apache.jena.graph, but not the > DatasetGraph interface. > > -----Original Message----- > From: A. Soroka [mailto:[email protected]] > Sent: Tuesday, April 26, 2016 11:56 AM > To: [email protected] > Subject: Re: porting Jena onto new storage facility > > This may require correction from a committer or more experienced dev, but I > think you are looking for the Node/Triple/Graph/DatasetGraph SPI. If you > implement that, your clients can use the public-facing > RDFNode/Statement/Model/Dataset API with your implementation underneath. > > --- > A. Soroka > The University of Virginia Library > >> On Apr 26, 2016, at 11:20 AM, David Jordan <[email protected]> wrote: >> >> I am considering porting Jena onto a new storage framework. I had looked at >> doing this a few years ago, but never did it. Now may be a better time. It >> also runs in a cloud environment that supports multi-processing, etc. But >> the first step is mapping of the data to the storage. I briefly looked at >> the latest source. I thought there were some specific interfaces I had to >> implement to plug in a new storage layer, but I have not found it yet. Any >> pointers are appreciated. >> >> > You just need the DatasetGraph interface though if there are features the query engine can take advantage of, then OpExecutor is a hook to see execution of a query. Node and Triple are fixed (by design). Graphs, when graphs in a DatasetGraph, can be done with GraphView. The code for TIM (Trasnactions In Memory) org.apache.jena.sparql.core.mem and TDB org.apache.jena.tdb.store (and OpExecutorTDB1) may help. Andy
