We're looking at simplifying the core of Jena. There are features in
the Graph layer that are not used but do potential add a complexity cost
to graph implementations (e.g. storage systems).
The RDF APIs will not change but there are some implications and we'd
like feedback.
1/ Graph level bulk update handler.
This is used by components that want to insert in bulk for some reason.
We decided that is the wrong way to do it (the batching should be done
by any receiving storage layer that cares) and it's not used.
If removed, ModelChangedListener would change, at least in effect, even
if not in signature.
At the moment there are difference event callbacks for different ways to
add a batch of statements, whether a list, an array, a model or a
iterator was used. Instead, all these would be replaced by multiple
calls of addedStatment/removedStatement.
If you use StatementListener, that's what already happens.
Does any code depend and use knowing the unit of update?
----
The Model API operations would remain:
Model.add(Model)
Model.add(Statement[])
Model.add(StmtIterator iter)
Model.add(List<Statement> statements)
Model.remove(Statement[])
Model.remove(StmtIterator iter)
Model.remove(List<Statement> statements)
will remain.
2/ Reification
Currently there are three modes : Standard, Convenient and Minimal.
The default is "Standard" and TDB and SDB only support standard.
Standard does not require any additional state management - it can be
provided with pure code that runs when reifications operations are made.
Convenient and Minimal hide partial reifications from view and require
statement management. Only the memory models support Convenient and
Minimal (RDB did - but it's gone.)
The idea is that the graph-level would not deal in reification at all,
and "Standard" reification semantics would be provided in the
model-layer implementation via code similar to that used by TDB and SDB
currently.
The code as used by SDB and TDB is in
com.hp.hpl.jena.sparql.graph.Reifiers2.
Does anyone use "convenient" or "minimal"?
3/ Graph level query.
This is not SPARQL and is unrelated to SPARQL execution.
There is a separate "query" system inside the graph layer which was
developed for RDQL. SPARQL is a bit more complicated. It's main use
now is in reification and if that is removed, and replaced then there is
no need for it in the graph layer.
Does any one use this code? If you have never heard of it, then you're
not using it except via reification.
Andy
PS If you want to know why things are the way they currently are, I
tried to write that down in:
http://mail-archives.apache.org/mod_mbox/jena-dev/201209.mbox/%3c5045b68c.4040...@apache.org%3E
