Lucene Indexes
Today was a little unsatisfying, but gratifyingly short. The problem with Lucene indexes had been addressed by others in the last 2 days, so a CVS update was able to help. Unfortunately the update also brought in another file that was broken. In this case it was due to someone checking in a file when they thought that their build was fine, when a completely clean build would have shown them otherwise.
The problem file was the SubQuery class in the Resolver package. This has been making a transition from using DatabaseSession objects to using ResolverSession objects. For the moment I had to fix it by passing both objects to the constructor. That was enough to get it compiling, and I can leave the rest for AM to clean up, as this is what he's currently working on.
So I tried to run Kowari again, and once more I had issues. This time the Database object is trying to add statements to the system model. However, for some reason it has picked up a read-only phase to do this with, and of course it bombs out with an exception. This is tied up with the transaction implementation for resolvers. Again, this is code that AM is working on, and he doesn't expect it to be finished for a while.
So the remote resolver testing is blocked, with nothing that can be done until AM is finished. While I'd much rather finish what I'm doing first, it does leave me free to move onto inferencing again. At last! :-)
Inferencing
As a first cut on inferencing we want to use a brute force approach and store the inferred data in a separate model. This will be a far cry from what we can really achieve, but it gets us up and running.
To start this, TJ and AN are suggesting that we use an established engine (with a compatible licence) to do the work for us. We can then use this to generate the iTQL that will do the inferencing. I've been given a couple of suggestions, but AN likes DROOLS, so I'll look at it first.
Thursday, July 01, 2004
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment