Jeff,
in our implementations we hardly ever use the default Jena
configurations out of the box. Instead we arrange base Graphs in a
delegation chain, so that higher-level graphs can implement services
such as caching and buffering. In this approach, all previous SPO
queries can be cached
Thanks for the info, it's an area that we definitly need to look at for
re-work at some point. On a related design question if you don't
mind, I was wondering if you use the Jena event handling (e.g.
ModelChangedListener interface) to determine when to re-run the SPIN
inferences on changes, or
Hi Jeff,
TopBraid has its own event/change mechanism that uses Graph listeners
under the hood, but wraps them into its own data structure. The policy
to re-run incremental inferences is simply that it checks for all
subjects, predicates and objects of the change triples and re-run the
-Original Message-
From: Holger Knublauch [mailto:hol...@topquadrant.com]
Sent: Thursday, May 07, 2009 1:40 PM
To: topbraid-composer-users@googlegroups.com
Subject: [tbc-users] Re: ARQ2SPIN performance
Hi Jeff,
TopBraid has its own event/change mechanism that uses Graph
That seems dangerous to me. What if a box (of class Box) references
its
6 side rectangles (of class Rectangle) through a side property, and
has a rule to infer its surface area by adding the areas of it's side
rectangles? If the rectangles' widths/heights change, it seems like
only the
