Thank you for your comprehensive explanations and hints, Dave!
My view on that topic is quite clearer now. I think I'll stick with the
following plan. Let us assume, that much more weight is focussed on Requests
than on Updates. So I'll rely on pre-reasoning.
1. My Service creates from time to time (e.g. on demand) a "From Scratch"
buil of my ontology. The rules will be modified to your last suggestion:
Instead of one all-covering rule that has to compute the Cartesian product
of all Services/handling Conditions, there will be more fine-granular rules
that enable (hopefully) a better performance by minimizing the cardinality
for the Cartesian product by considering easy-to-determine, limiting
properties of the Individuals.
2. At Server start-up, my Service will read a (latest) pre-calculated
Snapshot in-memory from (1). That snapshot includes a timestamp of creation.
At this point, there will be no reasoning, since the consumed snapshot
already includes all entailments for the given timestamp. This operation is
probably quite quick.
1. My service then fetches a list of Objects from a superior service,
which were modified (added, modified, deleted) since the timestamp of the
snapshot.
2. Each modification will be added to the spanshot in-memory Model.
Each modifcation will trigger an Event (
http://openjena.org/how-to/event-handler.html) that I'll cover
manually:
- Delete: I know which properties were determined by reasoning, so in
case of delete, I'll let the rules engine search the
properties with the
Subject/Object _Deleted Object_ and delete it. Also, I'll delete the
Individual itself.
- Modify: Delete + Insert
- Insert: Depending on the object type, I'll start a small
GenericRulesEngine that does the reasoning with scope onto
the new object.
Since each reasoning process is limited on single Individuals (One
OfferedService, One Item, One OfferedhandlingCondition and so on), the
update-reasoning will probably quite quick.
Again: Thank you for your comprehensive help.
-- Martin
2011/8/29 Dave Reynolds <[email protected]>
> Hi,
>
> On Mon, 2011-08-29 at 10:26 +0200, Martin Weitzel wrote:
> > (Note: This is a crosspost from the depreciated List@
> > http://tech.groups.yahoo.com/group/jena-dev/)
>
> Answered here rather than there since we are trying to migrate to the
> Apache lists :)
>
> > My main questions are:
> > (Q1) What is the best-practice to persist InfModels without losing the
> > update-functionality and without triggering a whole new inference-process
> on
> > load? Is this possible with TDB?
>
> The short answer is that there is no provision in Jena for persisting
> reasoner state.
>
> You can compute the complete inference closure and persist that, just
> like any other bunch of triples, but if you need to later update the
> data then you have to start inference again from scratch.
>
> In your case if you really do want arbitrary update then there's no
> particular point in persisting the base data in a database, it would be
> just as quick to load that small about of data in from file.
>
> > (Q2) How to maintain the update-functionality when using mutliple layer
> of
> > reasoners?
>
> The bottom layer will work as normal. The upper layers will see your
> incremental adds/removes but won't see any entailments from the bottom
> layers as increments - typically you'll need to trigger a rebind() on
> the upper layers which losses incrementality. Layered reasoners are a
> pain.
>
> You *may* be able to achieve your goal of having separate rule groups by
> using one reasoner but using guard clauses in your rules to delay one
> group until you know the other group have finished.
>
> You *may* be able to maintain separate, not layered, reasoners and
> manually move the relevant entailment results from one InfModel to the
> next.
>
> But in general if you can avoid layering reasoners then do so.
>
> > (Q3) And first of all: Does the InfModel update-functionality work the
> way I
> > am
> > assuming? Will updateing the Ontology (adding, removing a Statement)
> > correctly
> > regarded respective related reasoning actions?
>
> Backward rules (without any table declarations) are always rerun on
> demand. There is no state and so they are always incremental in that
> sense.
>
> Forward rules are incremental on add. When you add a new triple then
> partial results from the previous matches will be reused.
>
> However, deletes are not incremental - if you remove a triple then the
> forward reasoner will be started over from scratch.
>
> > (Q4) Are there other related technologies, that I should consider for my
> > application? (owlapi, other reasoners*, Joseki/Fuseki, ...)
> >
> > I would appreciate any hints!
>
> There's a couple of approaches you could think about.
>
> If you are going to be dealing with a lot of updates, including removes,
> and if your queries between updates tend to be few and narrow, then you
> may want to switch to pure on demand reasoning - i.e. do everything as
> backward rules. That way there is no state to maintain.
> You may even be able to replace some of your reasoning by sufficiently
> complex SPARQL queries - the combination of path expressions and
> sub-queries has made SPARQL pretty powerful these days.
>
> Conversely if your typical workload involves a lot of queries and only
> occasional updates, and if those updates are usually pure adds then you
> do want to maintain reasoning state. In that case one option would be to
> separately persist both the base data and the inference closure. When
> you application starts up it can answer queries from the persisted
> inference closure straight away. It could start up a background worker
> thread which builds an in-memory InfModel from the base data ready to
> handle update processing. That way you get quick start up for query
> answering but by the time an update comes in you have a working
> in-memory InfModel ready and can switch to that for doing the update and
> for future query answering.
>
> [Note that in your case you seem to have both forward and backward rules
> so presumably you would persist only the results of forward inference.]
>
>
> By the way are the rules in http://pastebin.com/i96sM1W3 the full set of
> rules? If so then your slow performance and 20x growth suggests you
> have an lot of offer and required conditions and that the quadratic set
> of match statements between them is dominating all your data. I don't
> understand the details of what you are trying to achieve but you may be
> better off having separate phases which first pick out plausible
> candidates and then do inference over that reduced plausible set. That
> way you may be able to reduce the combinatorics, and with luck the
> candidate selection can be done as an on-demand query - that might
> reduce your need for persistence of inference state.
>
> Dave
>
>
>
