Inferencing for OWL
This morning I had a discussion with AN about the next thing to move on to. Of course, it makes sense to fully integrate the inferencing code with the rest of the system, but AN pointed out that this should be done after the move to resolvers. I agree, as the selection of the source and destination models for the inferences will depend on how we talk to the models.

In the meantime I'm moving onto an iTQL construct that will allow us to select cardinality, which is an OWL requirement.

AN's document on Kowari/TKS inferencing describes cardinality as a "magic" predicate in the "tucana" namespace. This is similar to the <tucana:is> predicate used to constrain on equality. I can work with this, and so I went to find wherever tucana:is gets mentioned.

It's a little messy, with XADatabaseImpl and Subquery both defining the same predicate. I decided to ignore what subqueries do, as I needed the more general case. The string for this predicate was being put into a constant called KOWARI_IS, and I tracked down all instances of its use. This then led me to the getKowariIs() method, on the Database interface.

It was a simple matter to add the new cardinality predicates wherever I saw getKowariIs(). Then I needed to apply them when I found them.

I found that the application of these predicates was happening in ConstraintResolver. This class had been introduced to enable the use of the Visitor Pattern on constraint classes. This removed the need for lots of switch statements, as had been the case when everything used to be done in LocalQuery. Unfortunately, the magic predicates were still being done with if statements interrupting the normal flow of data. Any attempts to do the same with the cardinality predicates was going to get very messy.

Discussing the code with AN, we worked out that the current implementation of magic predicates is messy and unmaintainable in the query engine. This is because existing constraints have to behave differently if they see one of these predicates. By moving the code for handling magic predicates up into the language layer, then a different constraint object can be constructed altogether. This is more object oriented, and will definitely help with maintainability.

Unfortunately it won't be as quick to implement this as it would have been to put in a dodgy hack to get cardinality. It should be cleaner and easier though.