Resolver SPI
After getting through lots of correspondence today I got back to reading the Resolver SPI. Since I was starting with the interfaces I thought that the Javadoc would be the place to start, but it turns out that it wasn't generating properly. Some fixes by SR, a few iterations on clean rebuilds, and they're going again.

Kowari
AN got back from WWW 2004 today. Some encouraging feedback about Kowari has come out of the conference, and part of today was spent discussing this. While AN was away I've had some other ideas on what we should be doing, and I know that he has had all sort of inspirations from the conference, so we still have a lot to discuss. In anticipation of this forthcoming conversation I spent a few hours going over his Ontology plan for Kowari.

One of the comments presented at the conference was that Kowari handles billions of triples; which it does. This is one of the reasons I'm proud of the system, given that it was DM and I who designed and built it with that kind of scalability in mind. Just forget that both of us want to reimplement it with a different structure. :-)

All the same, people have wanted to see this claim in action, but few people have that many triples lying about. I wrote a program a little while ago that builds RDF to describes the cardinal numbers to ~4 billion (i.e. 2^32). The information is reasonably simple: the textual description (in English); the roman numeral notation (up to 40000); the prime factors; the square of the number; primality; triangularity; perfection (is that the name of the property which describes that a number is "perfect"?).

An example is shown in this excerpt:

<rdf:Description>

  <owl:sameIndividualAs rdf:datatype="&xsd;integer">6</owl:sameIndividualAs>

  <rdfs:label xml:lang="en">six</rdfs:label>

  <math:roman>VI</math:roman>

  <math:square rdf:datatype="&xsd;integer">36</math:square>

  <math:primeFactorization>

    <rdf:Bag>

      <rdf:li rdf:datatype="&xsd;integer">2</rdf:li>

      <rdf:li rdf:datatype="&xsd;integer">3</rdf:li>

    </rdf:Bag>

  </math:primeFactorization>

  <rdf:type rdf:resource="&math;PerfectNumber"/>

  <rdf:type rdf:resource="&math;TriangularNumber"/>

</rdf:Description>

Today I gave AN the generation code for this to hand out to those who ask. It is certainly much smaller than the generated RDF, though it takes a long time to run. Since I was expecting to be the only person to ever view or run this code, it probably isn't very pretty, and it had no documentation. Nonetheless I wrote up a README, and packaged it all up appropriately.

I should put it up somewhere, but I don't have anywhere convenient at the moment. I'll try and organise that in the morning.

JXUnit Revisited
Annoyingly, the Cruise Control server (aka "Trillian") failed on the JXUnit test for transitive queries. The error report never says why, only that it got back a response that didn't match what it expected. Since the test passed on my machine I'm guessing that it is due to the result being ordered differently. I'll get to that in the morning.

JRDFmem
Everything is working, tested, and building Javadoc just fine. There was one little hiccough though. I was going to use XML output from JUnit, but my path was missing some XML functionality. It had Xerces, but I couldn't find what else it needed. Rather than hunt it down, I decided to save time and just went to "plain" text output. It's more legible that way anyway.

My current plan is to make the Graph serializable, and to change the JRDF interface a little, before going onto the new triplestore code. I'm going to put transactions off for the moment, until I work out how I want to merge the ideas of javax.transaction and transactions-as-graphs.

The changes I'd like to make to JRDF involve moving the reifyStatement methods from NodeFactory and into Graph. AN has already expressed that he likes it, but he was jetlagged, so I'm holding off until he gives approval whilst compos mentis.