All day debugging Jena Ontology API. Spent a lot of time documenting the route used by the code. In many places the Jena code is deliberately obtuse, with over 6 methods to a line, chained, methods, nested methods, and so on.

It seems that the Jena code is doing the selection correctly, though the complexity makes it difficult to verify this. It has broken the camera ontology into 3 parts, and the result of a "find" is returning a 3 element list, which is transparently iterated over when needed. Each element of this list translates to a part of the database that Jena has broken up.

The problem seems to be in the iteration. While I missed the start of this operation (I'll check it tomorrow) I found that the iterator is storing the next item to be returned from a "next" method. At the time that I checked this value it was set to the Camera class. This is quite surprising, as the in-memory version of the Jena database does not normally return this value, though it is supposed to. However, when next() is called the node returned is "null", which shows up the same problem as before.

I tried to find out what next was returning for me, only to discover that the data is retrieved in hasNext() which I'd already missed (This is why I missed when it found SLR). After going over the correct answers I tried tracing hasNext() for the last item (the one that returns "null"). It was here that I discovered that the level of "iterator wrapping" is extreme, with 15 levels of hasNext() being called. Similarly, numerous levels of next() were being called in the same way. When I finally got to the code that executes the actual "next" I discovered a state machine! This is enourmously complex given the task here.

Rather than try and decipher this state machine I took a step back, and realised that the reason the "next" method might not be working might be the equality method that AN mentioned all that time ago. Now that anonymous node mapping bug has been fixed it may be possible to pursue this, so I'll try it that way.

As for the fixed anonymous mapping bug, I went through the code with AN, and he pointed out some possibly poor assumptions made about types, so we went through and fixed them. Also learned that the store tests are failing, but on inspection discovered that this might just be due to a problem with toString methods, and Ant failing to recomile all of the code. These should be a quick fix tomorrow.