I had mentioned earlier that have now reorganized my new TM server (based on Catalyst/mod_perl/Apache) along the REST paradigm. In my case this means that not only TM data, but also documents attached to it, vector spaces, and so forth are exposed RESTfullish.

At first this appeared to be more RESTfoolish as it was quite difficult to squeeze everything into a GET/PUT/POST corset. And it also was much more work than I had planned to invest, mostly because not only the original resources, but also all machine learning processes have to be exposed, and if it is only their configuration parameters. And they have plenty.

But I seem to have reaped the benefits much earlier than anticipated. Read on.

Ok, here is my new MO (method of operation):

Whenever I see an awful piece of Perl (even if only a 0.01 version and especially if it is on CPAN), then I analyze it thoroughly, write the developer an email with my findings. And wait for a response.

After 3 emails without response, I rat out the module to the Perl Police. Even if it is a 0.01 version and especially if it is on CPAN.

One of the problems I have to solve for my infrastructure is to compute semantic landscapes ("SemScapes" if you were so marketing-ish inclined) with an efficient computation model.

If, for instance, a user has added a new document to the document corpus, then new feature vectors, after that new vector spaces, new convergence models, new landscapes and new maps (as images) have to be generated.

There is a dependency graph, quite similar to one you are used with tools like make.

For a while now we own a Mac Mini in our living room, mostly for watching DVDs.

When we first bought it, the thing I noticed was that that little brat enforced the DVD region encoding. Which is pretty annoying to us, as we have acquired DVDs from Australia, the U.S., Europe, and even some in Japan. And it is not quite clear to me why moving from one continent (region) to another renders all my already paid DVDs useless.

The best of the worst:

Category Topic Maps

Every now and then you come across other people's code. Perl being Perl this means that it can range from brilliantly obscure over brilliantly clear to brilliantly hillarious.

The first kind you ignore, the second kind you nod off and the encounter of the third kind you normally mock.

But not today. Today we look at addition of numbers.

This is only a bugfix release.

I am playing with the thought to remove the experimental CTM support. I had a look at the current CTM draft and simply do not understand it. Or, to be more precise, I do not understand the consequences for my implementation. Maybe I look at it in another year or so.

Instead I would love to see JTM support.

One of the many pieces in my puzzle are surfaces of topic maps. When computed these are simply PNG files. There will be different resolutions of these surface (maps), depending on how much content is involved.

As I want to integrate this into my TM::IP landscape, the best is to follow the pattern I used with TM::IP::Documents and have another Catalyst controller doing the work.

Ideally, one would expect that this works the orthodox way using MacPorts:

The first problem here is ImageMagick itself, as it depends on xorg-libX11 and that expects xproto which I do not have.

Perl XTM, the most ancient Perl implementation of Topic Maps has now retired. Or should I say: has been forcefully retired by me as I deleted it from CPAN.

I had started it 2001 when Topic Maps were young and promising, and of course I followed the only thing which was known at that time: the XTM format. Needless to say that this was not very effective.