> -----Original Message-----
> From: Holger Knublauch [mailto:[email protected]] 
> Sent: Thursday, May 07, 2009 1:40 PM
> To: [email protected]
> Subject: [tbc-users] Re: ARQ2SPIN performance
> 
> 
> 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 rules on those 
> instances only. 
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 rectangles spin:rules would get run.  Even if applying the rule
recursively to new triples generated from the spin:rules, the only new
triple from the area rule would be something like:

 rectangle hasArea 30

The cube instance doesn't show up in that triple, so its rules wouldn't
get re-run.  

>The tricky part is to undo the previous 
> inferences first, e.g. to remove the old "area" triple of a 
> rectangle.  
Yes, that is always the tricky part when working with RDF!

> As you anticipated, I must leave the rest as an exercise to 
> the reader :)
> 
> Regards,
> Holger
> 
> 
> On May 7, 2009, at 11:30 AM, Schmitz, Jeffrey A wrote:
> 
> >
> > 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 do you have some other method?  Also, are 
> > you able to filter which rules/constructors, etc. to run 
> based on the 
> > resources that are added/deleted, or do you just re-run them all on 
> > any change to the model just to make sure?  Not sure how 
> much of this 
> > you're at liberty to reveal, but I figure it never hurts to ask :-)
> >
> > Jeff
> >
> > -----Original Message-----
> > From: Holger Knublauch [mailto:[email protected]]
> > Sent: Thursday, May 07, 2009 10:45 AM
> > To: [email protected]
> > Subject: [tbc-users] Re: ARQ2SPIN performance
> >
> >
> > 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 on the client without ever having to ask the 
> > same queries to the database. We do have implementations of these 
> > modules, but they are not open source.
> >
> > Holger
> >
> >
> > On May 6, 2009, at 9:01 AM, Schmitz, Jeffrey A wrote:
> >
> >>
> >> Yes, using just a mem model makes a HUGE difference.  I've never 
> >> really gotten a good handle on how and when to use all the 
> different 
> >> types of Jean Models/OntModels/graphs etc.  Is there any other 
> >> writeups or tutorials that you know of on this besides 
> what is here 
> >> (and that I plan on re-reading now)...
> >>
> >> http://jena.sourceforge.net/how-to/model-factory.html
> >>
> >> Thanks!
> >> Jeff
> >>
> >> -----Original Message-----
> >> From: Holger Knublauch [mailto:[email protected]]
> >> Sent: Wednesday, May 06, 2009 10:37 AM
> >> To: [email protected]
> >> Subject: [tbc-users] Re: ARQ2SPIN performance
> >>
> >>
> >>> Note though that the
> >>> baseModel is setup as a database backed model
> >>
> >> Here we go. You may want to set up a cache graph in between the 
> >> database and your application. SPIN will do various 
> look-ups during 
> >> query construction, e.g. to reuse variable names, check 
> for functions 
> >> etc.
> >>
> >> Holger
> >>
> >>
> >>
> >>
> >>>
> >
> >
> >
> >
> > >
> 
> 
> > 
> 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TopBraid Composer Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/topbraid-composer-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to