Well, depending on your queries and how you want to design them, you might be able to use an in-memory dataset and put all the triples for one particular subject into the named graph with that URI. That would keep things nicely partitioned.
For example you could use a DatasetGraphCollection subclass like DatasetGraphMapLink, which just uses a HashMap to keep track of graphs that are of any implementation you configure, or my (proposed) DatasetGraphGraphPerTxn, which implements graphs as persistent maps in order to afford MR+SW (multiple readers AND a single writer simultaneously) concurrency for each graph. We could maybe alter DatasetGraphMapLink to take its Map of names to graphs as a parameter. Then Claude could use a Map implementation with eviction behavior, if that is the kind of caching he wants. Maybe you could say more about the use case? Do you want something that naturally partitions data by subject because it's the size of transaction you are going to be using? Are you going to write queries that involve more than one subject? --- A. Soroka The University of Virginia Library > On Jan 22, 2017, at 1:47 PM, Claude Warren <[email protected]> wrote: > > I am wondering if we have a graph implementation that is subject based. > What I am looking for is a graph cache that is subject based. > > I want to retrieve data from a remote graph and store it in the cache, I > will retrieve all the predicates and values for the subject, so a complete > shnapshot of the data. Then as queries proceed when a new subject is > required populate the cache. > > My end goal is to be able to take a query, do some data extraction from a > big remote graph and then answer the query from the smaller in memory > graph. > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
