As a first cut we started looking at doing RDFS inferencing. Since this is a subset of OWL inferencing it is much smaller and simpler.

The decision has been to use iTQL to generate the inferred statements. AN started expressing concern that this was the right way to go, but he's come back around. After all, the next most appropriate place to put this would be in the query layer. The majority of the work here is in building the query constraint objects manually, but the iTQL layer gives you this already.

I worked for a while converting the RDFS inferencing rules from the Sesame inferening file entailment-rdf-mt-20030123.xml. This turned out to be quite easy, and it didn't take long to notice that each rule maps directly into an iTQL "select" statement:
- The select clause is built directly from the statement defined in the consequent section.
- The from clause is simply the model being inferred from.
- The where clause is built with triples which are defined by each premise. These are then ANDed together.

Consequently, it will be very easy to use rules built like this to create select statements automatically, allowing us to make inferences configurable, and not hard coded.

At the moment the inferences are all defined in XML files. AN is frustrated at this, and feels that it should be in RDF. I can see his point, but there are already XML files available (such as with Sesame) and it's easy to use. I'd have to consider it more carefully, but I think that Sesame's XML is reasonably terse, and the RDF configuration would probably end up longer.

The only thing missing at the moment is a "like" operator, much like the "is" operator that we currently have. This is needed for rule "XI" which searched for predicates which match the pattern "&rdf;_*". This is relatively easy to do programmatically (it can be applied as a filter to an iterator), but it can't be done in iTQL yet. Support in iTQL would also make the result smaller and faster, which may be important for scalability in future. It's also a feature that has been raised several times in the past, so it looks like this feature may become more of a priority soon.

One restriction with the rules as they stand is that they do nothing to address recursion. SubProperties and subClasses are examples of this. In some instances it would be necessary to continually re-execute a rule until no further statements are generated. This is defined by the rules, and I'm happy to do it this way, though it makes termination an issue. AN would rather reimplement the rules to deal with this efficiently, but if this were the case then we would be breaking the current rules. I think I'd rather see the rules changed if we want to adopt this approach. AN and AM are discussing this as I type, so there will probably be some kind of consensus on this by tomorrow.

Off to the ESIG (Embedded Special Interest Group) talk this evening. It's on FPGAs.