Tests
TJ wanted to get everything as stable as possible today, so rather than implement the BlockCacheLine.reset() method I've been concentrating on documenting the iTQL needed for OWL. I did get to speak to AM on the phone tonight, so I have an idea of what I will need to do if I get to this before Monday, when AM gets back.

In the meantime, the JXUnit tests for the node type code needed to be checked in. To ensure that the created HybridTuples never gets large enough to be backed by a file, I put a step into the test which drops all the models. Unfortunately the test still failed because the HybridTuples was still too large.

I put some more steps into the test, this time counting how large the string pool was. The result was a number somewhat larger than 222,000. That was a little larger than the 4 I expected! I added a step to print out the contents of the # model, and this showed that there was a Wordnet model loaded. That would certainly explain the size of the string pool.

After looking at the step that dropped all the other models (including the Wordnet model) I realised that it must not continue to drop models once a single model fails to be dropped. Since the Wordnet model was near the end of the list, this would explain the problem. So I created a single step which dropped just the Wordnet model. This fixed the problem, and the tests all started running well.

The only problem with this "fix" for the tests, is that the Wordnet model now needs to be re-loaded by another test which needs it. This slows the whole test suite down by about 10 minutes on my machine.

iTQL
Yes, I'm back to calling it iTQL even though that's the shell and not the language. Everyone else has fallen into the habit, so it's just easier.

I'm working on documenting the iTQL required to implement OWL, restricting the entailments to those which do not require a rules engine. These require some example data, so we are using the Wine ontology as a framework for this.

I've also provided some documentation for the "having" clause, and I will need to write something which describes how to use the new "node type" models.

MPhil
I had a meeting with Bob today, and we discussed a number of technical issues based on what I've been learning recently. This was probably more out of a sense of convincing him that I'm making progress, rather than actually getting the benefit of him as a supervisor. However, I did find it useful to talk to someone who has a good technical knowledge of this stuff, as it helped to clarify a few things for me.

After talking with SR, and today with Bob, I now know that Kowari is capable of being a complete 2nd order predicate logic system. However, there may not be a lot of point to that. For instance, is there really a need to express existence of a statement which uses a particular predicate, without actually have such a statement? As such, I'm starting to understand the advantages of a 1.5 system.

One thing I mentioned, was that it has struck me that many of the DL and predicate logic equations, used to describe consistency checks and entailments for OWL, are incapable of describing the property of the predicate which defines the rule to be run. For instance, the consistency check for owl:someValuesFrom is a predicate logic expression:

 ∀X∃Y : C(Y) ← P(X,Y) ∧ D(X)

Note that nowhere in this expression does it state that the predicate P must have a restriction of [owl:someValuesFrom Y] declared on it. The mechanism which finds the predicates to apply this to is separate from the equation. I have already mentioned some of this in an earlier blog.

Describing attributes of predicates in this way is only possible in 2nd order logic. This is one of the important features that iTQL supplies for us, and one of the advantages of a 1.5 order system. However, in order to gain a better understanding of what 2nd order (or 1.5 order if I'm to look at the limited case) I will need to learn a bit more about higher order logics. And here I haven't even finished learning predicate logic!

Confirmation
The most useful part of my meeting with Bob came at the end. He pointed out that he would like to see my confirmation paper by early next year. Given that I'm enrolled part time, I thought that he might have given me longer, but I'm actually pleased to be made to think about it earlier.

My only apprehension about my confirmation is that the more I learn about this stuff, the stupider I feel. I now know that everything I have learnt in the course of Kowari is really just a re-invention of earlier work, albeit with different structures, efficiencies, etc. If I'd had any doubt of that, then Kunii's book would have laid the matter to rest. Given this, then what do I possibly have to contribute?

Fortunately, this is where only doing an MPhil has its benefits. I'm not really expected to expand the field of knowledge significantly. Instead, Bob suggested that my work to implement OWL in a database (like Kowari) could be the basis of my thesis. Implementing a system like OWL in a new way is apparently a decent enough project, so long as I accompany it with a solid theoretical foundation of the work.

This actually suits me. I have to do this OWL work at Tucana anyway. This will involve both the entailments and the consistency checks. It will also require interaction with a rules engine. While I don't strictly need a solid theoretical understanding of this process (with tight deadlines we are often engineering solutions which work, even if we don't have a complete grasp on the problem) having one will be quite valuable. More to the point, the papers I write to do this, and the final thesis, will all contribute to the body of public work about Kowari. This last one has direct benefit for DW as he spreads the word about Kowari, particularly in academic circles.

I suppose this leaves me with one significant problem in all of this. People who know what they're talking about will be reading this stuff. That means I can't fake it. That's a little scary. I'd better get it right!