Proof Reading
Recently I decided to skip proof reading these entries. Yes, I know that is annoying (particularly when I change thought mid-sentence and fail to make any sense at all), and leaves me in the realms of the semi-literate. However, I'm usually just using this blog to organise my own thoughts, and I don't normally take the time to re-read the entries.

My main reason for being lazy like this is because the time taken to read these entries can usually be better spent in bed, which is where I really need to be tonight. :-)

At least I run the spell checker! However, I usually use English/Australian spelling, which may have some Americans wondering why I use the letter "s" so much instead of "z", in words such as "realise" and "organise".

Versions
The other day I realised that I had made the same mistake as Simon. I had checked out "kowari" from Sourceforge, instead of kowari-1.1.

I had actually seen both when I moved to using the Sourceforge CVS, after leaving CVS at Tucana. However, I reasoned that the "main" checkout would be "kowari" without modifiers. Apparently I was wrong.

The code I've worked on was not affected by any of this, so it hasn't set me back, but it's created a small hassle. The "kowari" checkout builds and runs fine on my PowerBook, but "kowari-1.1" causes a HotSpot error while unjaring a file in the build process. The exact error is here:

embedded-dist:
    [unjar] Expanding: /Users/pag/src/kowari-1.1/lib/xercesImpl.jar into /Users/pag/src/kowari-1.1/obj/xerces
    [unjar] Expanding: /Users/pag/src/kowari-1.1/lib/xmlParserAPIs.jar into /Users/pag/src/kowari-1.1/obj/xerces
    [unjar] Expanding: /Users/pag/src/kowari-1.1/lib/jsr173_07_api.jar into /Users/pag/src/kowari-1.1/obj/xerces
    [unjar] Expanding: /Users/pag/src/kowari-1.1/lib/jsr173_07_ri.jar into /Users/pag/src/kowari-1.1/obj/xerces
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://bugreport.apple.com/
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2-38 mixed mode)
#
# Fatal: java object has a bad address
#
# Error ID: /SourceCache/HotSpot14/HotSpot14-38/src/os_cpu/macosx_ppc/vm/os_macosx_ppc.cpp, 311
#
# Problematic Thread: prio=10 tid=0x00501170 nid=0x1802600 runnable 
#
./build.sh: line 125:  2683 Trace/BPT trap          ${JAVABIN} ${ARCH} -Xms64m -Xmx192m -Dant.home=${ANT_HOME} -DJAVAC=${JAVAC} -Darch.bits=${ARCH} -Ddir.base=${BASEDIR} -classpath "${CLASSPATH}" org.apache.tools.ant.Main -buildfile "${BUILDFILE}" "$@"

I've reported this to Apple, but obviously it will be a while before this gets fixed. I'd rather see Java 1.5 made available anyway.

This moved me back to running on my Linux server. I need to do this for scalability testing anyway, but it will be a problem if this is the ONLY machine I can run the Kowari tests on. It means that I will need almost permanent internet access with my notebook, which limits my portability. Maybe I should run VirtualPC. :-)

The problem here is that I'm running Java 1.5 on my Linux box. I had Kowari building and testing fine on 1.5 (and still do), but this was a CVS checkout from Tucana. Now that I have the new Sourceforge checkout I don't have all the modifications needed to build and run it with Java 1.5.

Ideally I'd use CVS to find out all the changes I'd made from the standard, and then move those changes into the latest build. However, the Tucana CVS doesn't exist anymore, so I have no idea where those changes are anymore. Fortunately, most of the work is in the Xerces classes (which I can copy over), and this blog will provide some hints, but I expect it to take a couple of hours to get it right. It's really annoying.

In the meantime I'm back to using Java 1.4 on the Linux box. Thank goodness the Kowari build script isolates the JAVA_HOME variable from the environment. Most systems can't handle a different version of binaries existing the path.

Ontology Validation
I reworked some of the rule ontology, and I'm happy with it all now. I guess I should post it somewhere for other people to look at it. :-)

I have some of the code needed to read the data that fits this ontology, but I've decided to create some example rules in RDF to test what I'm doing as I develop the code. That RDF hasn't come a long way yet.

The reason that RDF hasn't come a long way yet is because I spent quite a bit of time validating the OWL before I got to writing it. I started with the validator by Bechhofer and Volz, but it kept telling me that a " had not been closed. I cut down the XML significantly, but seemed to be getting the problem in the opening rdf:RDF tag. So I thought I'd try another online validator. This took me to the "BBN OWL Validator", but the link to this is broken (the server would not respond). I looked at some other options, but none of them were online, and I had no desire to install a new piece of software just to validate my OWL.

Finally I went back to the plain old RDF validator. This also said that the RDF was in error, but this time it said that the rdf:RDF tag needed to be closed. This gave me enough of a hint to go searching for a tag that wasn't closed properly. Sure enough, I found a couple of opening tags which each ended with a trailing "/". Once these were fixed the RDF validated, so I went back and successfully validated the OWL.

The XML was obviously wrong here, and it would have been a simple matter to find and report the error when it happened. I was disappointed that the XML parsers used be these validators would give such unhelpful messages.

This whole thing makes be think of using an XML editor. I've never used one before, but it might be worthwhile finding out how useful they are.

Meeting
I also met with Bradley Schatz today. Brad is a PhD student at QUT and is using Kowari as infrastructure for his project. Bob knows him from his time at UQ, and recommended him highly.

Brad is very keen on hearing of my progress with OWL, and has offered to help when/if I need any. That reminds me that I need to get to a point where I can offload some of the less involved work to the people who work with Greg. I'd love the boost to the project, but I don't really have anything like that available yet. Still, I'll try and remember it when I find myself in any code that is tedious. :-)

Anyway, I gave Brad a synopsis of my approach. He seemed impressed, and confessed that he thought it was quite novel. While it was inspired by Rete, he really couldn't see a lot of similarity to that algorithm. I do see how the two relate, but often they relate by how they do things differently, rather than how they are the same.

Brad had a couple of ideas, but most of the benefit came from just having to articulate what I'm doing. Putting something into words like that can often crystallise your concept of a design, and describing it several times only reinforces that. Unfortunately, very few people are familiar enough with the background material for me to explain it to them, meaning that my audience is very limited. Maybe that will improve after I've presented my confirmation. I really need to start writing that. It's been easy to put it off with so much to do lately.

Brad also presented some of what he's trying to use Kowari for. He'd like to store some of his own structures in the StringPool, but after looking at it I explained that I think that is losing many of the benefits of RDF. Still, his user-defined data types are an interesting idea, and certainly achievable (we were hoping to create an interface for exactly that), but it makes querying harder. He's going to have a look to see if moving the data structures out into RDF will help at all.

Rules
I also gave a little time to a pre-print by Guido Governatori on using defeasible logic rules on models with an open-world assumption. It cleared up an item of syntax in Description Logic for me, but my real gain was from the definitions it provided of defeasible logic. I'd seen a lot of this before, but on those occasions I had come away with only a general idea, rather than specific knowledge.

The paper raised the question of using defeasible logic with OWL, given the open world assumption of RDF, but I don't think it's applicable. In particular, OWL talks about what you can infer. There are no constructs (that I can think of) that talk about what you might or can't infer.

The real reason I have this paper is to follow his references. I've yet to get to them, but it may be worth going through them (at least superficially) before starting my confirmation report.

There are also a few grammar errors and typos which I should probably feed back to Guido. Can't hurt to help him out, since he was kind enough to show me the paper.

Swimming
The only other thing of note today was a 3km swim. I set the timer on my watch for an hour, and just kept going until the alarm sounded. I went a little over 3km, but I lost count so I don't know exactly how far I went. :-)

I've swum further than this in the past, but this was the first time I've ever swum that time or distance without pause. I'm also a little less fit than usual, after taking time off during that nasty cold. As a result, I'm shattered tonight, and really need to cut this short and get to bed early.

Location
I worked at the house today, the idea being that I'd set up my monitor to use with the notebook, since I'm starting to get neck strain from having to look down at the screen all the time. Somehow I ended up being to busy to do anything about this. This also explained the swim, as I thought it might loosen my neck (it did).

Maybe I should organise a monitor at my desk at UQ. We can always live in hope that I will be able to get some equipment allocated to me.