I am looking at the Cassandra limitations. Cassandra does not have an "or"
operator and I think that it will be most efficient building a working
graph as part of how to work with BGP.
For example:
Select * Where {
?x t:prop1 ?y
?x t:prop2 'foo'
?x t:prop3 ?z
?z t:prop4 'bar'
}
I think I want to build a temp graph in the query context that contains
?x ?p ?o where ?x t:prop2 'foo' ; ?p ?o
?z ?p ?o where ?z tprop4 'bar' : ?p ?o
for each select ?y where ?x t:prop1 ?y in themp
<y> ?p ?o where <y> ?p ?o
Later BGPs that reference earlier bindings can then query the local graph
where the subject is known.
I guess that I would say that I am pre-processing the query to pull data
from Cassandra and create a local graph that can then be used to answer the
query.
this is my first approach to this problem and it is probably fraught with
issues. It may make more sense to perform the query in stages like a
normal query but using the temp graph in the background.
Claude
On Sun, Jan 22, 2017 at 6:59 PM, A. Soroka <aj...@virginia.edu> wrote:
> 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 <cla...@xenei.com> 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
>
>
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
