Restrictions
I'm a few days overdue in writing this, but I should be reasonably accurate.

First thing in the morning, AN said that he needed to change the owl:someValuesFrom query in order to make it work. This wasn't completely surprising, as I'd spent most of my time working on the conversion, with very little testing of the actual TQL on real data. Most of the queries were trivial, so this wasn't really a big deal. However checking consistency on the more advanced restrictions required thorough testing, which is what AN was doing. Concerned that I may have originally misunderstood the problem, I sat down for some time to work through it with him.

I was initially confused about the problem, until we started looking at AN's sample data and the results he was getting. It turned out that we had differing ideas on the meaning of owl:someValuesFrom and owl:allValuesFrom. This was probably a good thing, as it made me go back to the W3C documents and confirm the exact meaning of each. I was finally able to confirm that the TQL I'd done for owl:someValuesFrom was actually correct. This was fortunate, as it validated my previous blog on the matter. :-)

Since we were looking at these queries it was natural to go straight onto looking at owl:allValuesFrom. I had made a mistake for this one, but not because of my interpretation of the operation. Instead, I hadn't quite grasped the nature of the not() operation in TQL. And it turns out that I'm not alone in this.

People perceive the not() operation to have one of several different semantics, depending on the nature of their current requirements. In many cases people are getting this wrong. I was one them. For this reason SR and AM have been arguing that we should rename the operation. AM's preferred name here would be "excludes". Hearing this helped explain for me some of the semantic of not() but I think I'll need a little more practice with it before I try and document it here.

The result of all of this was AN doing a rewrite of the owl:allValuesFrom code. It is now based on a subquery, so that each subject-predicate pair can be queried for the type on the objects, and make sure that there are none from outside of the required class.

Now I know I can probably look this up, but could someone reading this please save me the time and explain to me the difference between owl:allValuesFrom being applied as a restriction on a predicate, and rdfs:range being declared on that predicate? It seems that they perform the almost same job, but I'm guessing that there is some sort of completeness aspect that I'm missing where predicates can be of a type owl:Class in OWL Full.

Testing
Much of the day was spent testing the pseudo-model for node types. It required a little debugging, but was all working by the end of the day.

Since the problems from Wednesday could be shown to be in unrelated JRDF code, TJ was happy for me to ignore them (fine by me!). I was able to get straight into debugging and testing the new model type.

To start with I wrote a few tests looking for literals and URIs from the camera.owl file supplied with Jena. Once I had the tests and expected results lined up, I tried running it for the first time. Of course, it didn't work straight way.

For a start, I didn't realise that these pseudo-models require creation before they can be used. I had been under the mistaken impression that I could simply modify a constraint with:

  in <http://tucana.org/tucana#TypeModel>

SR was able to explain that is a model type, and that an actual model of this type must first be created. Consequently, a model creation statement must appear first:

  create <rmi://servername/server1#type> <http://tucana.org/tucana#TypeModel>;

And the modifier becomes:

  in <rmi://servername/server1#type>

This is a little disappointing, as it requires at least 2 TQL statements, while we have worked hard to keep all of the individual inference operations to a single statement. I asked TJ about this, and he agree that it might be worth creating default instances of the special pseudo-models on creation of the system model.

Once I had my syntax correct, I encountered a NullPointerException in the String Pool code. This was entirely DM's code, so I asked for him input. After an hour or so he had it working again. At that point the tests all produced exactly the output required, so I started converting them to JXUnit tests. This took me until the end of the day.

Versioning
While waiting for DM to look at the string pool, I started to look at some of the statements that AN was considering for OWL. The first one to look at was owl:backwardCompatibleWith.

I hadn't really considered versioning before this point. If anything, I expected that it was about attaching version information to the OWL data, with few consequences for the data. Looking at instructions like owl:import it quickly became apparent that these instructions perform actions of real consequence.

Considering the owl:backwardCompatibleWith statement, I realised that it needs to participate in consistency checks during inferencing. However, it is unlike most other OWL statements, in that there is no single TQL statement which can enforce it. The only way to confirm the consistency of this statement is to confirm the consistency of all the statements from the older ontology against those of the ontology containing the owl:backwardCompatibleWith statement. This means not only confirming each rule, but running a complete rules engine to confirm the consistency of the entire document.

The owl:import statement would have to operate similarly to this, only it would also need to perform the importation of the specified ontology. While the consistency checks would need a rules engine, the importation operation could be done with a single TQL statement. However, there is currently no TQL statement which will do this. While the load command does something along these lines, there is no way to select out the object from an owl:import statement and use that as the source of a load or an insert statement.

I suggested that to get around some of these restrictions we could introduce variables into the from clause. It turned out that SR has been suggesting this for a while, so he was happy with this suggestion. Perhaps with the requirements of the OWL versioning instructions, we may have the impetus to make these changes soon.