Virtual Graphs
Today was spent coding up a new "in" option for "where" clauses. This will let us add an option in TQL to restrict the type of a node using a constraint like the following:

  $x <rdf:type> <rdfs:Literal> in <tucana:typeModel>

The original idea was to provide functionality to restrict a variable to literals, URI references, or blank nodes. However, it became quickly apparent that this was akin to sorting a phone book and finding all listed home numbers, listed business numbers, and unlisted numbers. The first two are possible, but the last one is not (unless you want to search for all unused numbers, and then try dialing each one).

When I thought about use cases for this requirement I realised that we don't have any need to find blank nodes. We only need to know how to avoid them. Since literals and URI references cover the rest of the possible node types then this is easy to do. TJ agreed with this, so my requirements dropped to only needing to find nodes which are not blank.

This was all done on the old string pool. DJ has finished with the new string pool, but it has yet to be checked in to the main branch of Kowari. This is because of continued testing and because it has not yet been optimised to be as fast as the old string pool. These changes should be checked in soon, and when they are it will be possible to restrict nodes by other criteria as well, including prefix matching, which is needed for RDFS. It won't be a quick merge however, as the API has changed, but the additional functionality will make this worthwhile.

In the meantime I finished the coding for the "virtual" type model, and have started on testing. I didn't get too far, as the main branch is in a state of flux, and a few unit tests are not passing. I tried my changes (which should not have affected any running code) and had only one unit test fail. Then I tried a clean checkout and tried the tests again, to make sure that the failures were the same. But the clean checkout had 4 failures, and they were in a different set of tests. I don't get this, as my current work could not have fixed these 4 failures, and they should not have introduced the new failure. In all cases the failures were in JRDF code, and none of my code has any influence to anything related to JRDF.

Finding the source of these problems may be interesting.