Sunday, June 24, 2007

Upgrading to Fedora Core 7

I was forced into an emergency upgrade to FC7 this weekend. I ran my periodic 'update everything with yum' exercise on FC5. Clearly FC5 is somewhat behind the curve now, but it was working for me and I didn't want to waste the time upgrading my system when I have (many) other more urgent things to do. Having done the updates, Gnome went truly weird. All of the text labels in Gnome itself, including menus, button labels, tooltips, etc, disappeared. Gone. Which doesn't, it has to be said, make for a very usable UI. Interestingly, many of the apps themselves were OK. The peculiar thing was that I had text in terminal windows (but no menus in those windows), FireFox was working, just no Gnome text. I thought about trying to roll back the changes to find out what broke, but there's no easy way to do that (afaik). Instead, I decided to upgrade to FC7 and hope that would fix the problem. Which it did, but caused pain along the way.

I expect that some of the problems I had would not be problems if I'd installed rather than upgraded. Maybe. I found Mauriat Miranda's Personal Fedora 7 Installation Guide very helpful. Thanks Mauriat! Especially useful was the tip, which I didn't discover right away, not to use Nvidia's own installer to provide the graphics acceleration. Better to use the Livna module, as Mauriat says. The difference is this: one way works and GDM starts, the other way doesn't work and GDM does not start.

As far as I can tell, there's no equivalent to kernel-smp in FC7. In FC5 (don't know about FC6, I skipped that one), to get the benefit of a hyper-threaded CPU (e.g. Pentium 4) you have to use the multiprocessor kernel, which you install as kernel-smp. There is no kernel-smp in the FC7 repository. However, the default kernel module shows me two CPU's in gkrellm, so I guess that the two kernel modules have been folded together. Cool.

Perl blew up on me. I noticed this during the installation of some packages, and when I tried to run Perl-based applications, I'd see:

/usr/bin/perl: error while loading shared libraries: 
cannot open shared object file: No such file or directory

It turns out that the upgrade process somehow loses perl-libs, so you need to yum install perl-libs and everything is peachy.

I now have a mostly-working FC7 system again, albeit on a an unplanned schedule. Mounting my NTFS partition isn't working yet, but I'm setting that aside for the time being. First impressions of FC7 are favourable so far. It's nice finally to have FireFox 2.x installed as the default.

Thursday, June 21, 2007

Kaspersky Kudos

I've just had to rebuild the Windows XP machine that the kids use for game-playing in the rec room. I backed-up the hard drive to an external USB drive using Windows Backup, zapped, re-installed, all fine. When it came time to re-install my virus checker of choice, Kaspersky AV 6.0, I couldn't find the .key file that the downloadable version of KAV wanted in order to recognise my existing license. Windows Backup is just the worst interface (why can't you resize the window for pity's sake?!) So I called Kaspersky tech support in the UK. What a surprise! No endless phone menu or 45+ minute wait on-hold (Vodafone, I'm looking at you). In fact, I was speaking to a tech support engineer within about 15 seconds of dialling, explained the problem in a matter of minutes, and he emailed me a new activation code. No fuss, no muss. Exactly how tech support should be done.

Saturday, June 02, 2007

Jena tip: dealing with reflexive class and property iterators

Under the semantics of OWL, every class is a sub-class of itself. Let's assume we have three classes: A, B and C. C is a sub-class of B, and B is a sub-class of A. According to OWL, the sub-classes of A are therefore A, B and C.

In Jena, the reasoners, both built-in and external (like Pellet, will correctly infer the expected triples:

:A rdfs:subClassOf :A .
:B rdfs:subClassOf :A .
:C rdfs:subClassOf :A .

However, oftentimes that correct conformance to the spec can be a nuisance when programming. Suppose we are generating the TreeModel for a Swing JTree directly from our Jena triple store. We really don't want each node in the tree to have itself as a child. This was a sufficiently common user request that, in the Jena ontology API - a convenience API for handling ontology terms - the OntClass Java class doesn't report itslelf as a sub-class when listing the sub-classes through listSubClasses(). The triple is still there in the model (assuming the appropriate degree of inference is turned on), but is filtered out from the return value to the listSubClasses() method.

It has recently been pointed out to me that listSubProperties() in OntProperty does not behave the same way. The theory is the same - every property is a sub-property of itself - but the method does not automatically filter out the reflexive case. This is an accident of history: until now, very few users have requested that feature in OntProperty. But I can see the argument that the two list... methods are inconsistent in their behaviour.

Fortunately, there is an easy workaround, which applies to this case and indeed any other where filtering out the reflexive case would be handy (e.g. when listing equivalent classes). The iterator returned by listAnything in the Ont API is a Jena ExtendedIterator, which has a number of features including a filter hook. Calling filterKeep or filterDrop on an extended iterator returns a new iterator will return a new iterator whose values are limited to those that match a given Filter object (or which don't match in the case of filterDrop). So to skip over the reflexive case, and not report that a property is its own sub-property we do:

/** Filter that matches any single object by equality */
public Class EqFilter implements Filter
  private Object m_x;
  public EqFilter( Object x ) { m_x = x; }
  public boolean accept( Object x ) { return m_x.equals(x); }

// in the application code:
OntModel m = ... the Jena model ... ;
OntProperty p = ... the property of interest ... ;
Filter reflex = new EqFilter( p );

ExtendedIterator subP = p.listSubProperties()
                         .filterDrop( reflex );

I don't know whether to change the default behaviour of listSubProperties. We generally like Jena to stick to the standards it is based on, in this case the OWL semantics. On the other hand, the point of the ontology API is to be a convenience layer on top of the raw RDF triples. Convenience is in the eye of the beholder. What I definitely don't want to do is add yet another Boolean flag to the method call. I'm open to suggestions!