On 03/02/13 12:40, Claude Warren wrote:
I have a CollectionGraph implementation that allows any
Collection<Triple> to be queried as a graph. This is handy for small
collections of triples that you want to query as a graph, but in no
way meets the performance characteristics of the in memory graph.
Does anybody have any objection? Does anybody have a suggestion as to
which package to place it in?
-- Claude
Claude,
We have some off-trunk areas for putting things while working on them or
to share during implementation.
/Experimental -- for large items that don't fit as branches.
/Scratch -- general, personal, whatever area
Or if its one class, just put in a JIRA. Whatever is easiest.
As to where it should go, that is a good question. I'd say
com.hp.hpl.jena.graph.impl
for now if it's a one class impl, and a package around there if several
classes. impl is implementations of the GraphAPI - if we split out the
Graph API as a package, we either need to put mem there or have a very
simple implementation so the API can be tested on it's own.
See also
com.hp.hpl.jena.sparql.graph.GraphMemPlain
There is GraphMemPlain which uses term equality only and for small sets
of triples (needed primarily for ARQ internals).
There too much stuff scattered in other places due to different rates of
evolution in the past.
Which reminds me ...
there is a bit of cleaning up to do now reification is not part of
GraphBase -- the GraphBase2 in ARQ has the alternative storage-centric
reification code in it and it is no longer relevant. The only extra
feature it has over GraphBase is that the creation of the prefix mapping
can be intercepted (for storage layers)
... which I shall do right now.
Andy
