Hi! CatBert here.

Gosh. Robert is soooo easy to play: I only had to show him how a web application can be expressed with my TM based language TempleScript. As expected, he first appeared to be all negative about it, but I just know him too well. Now he is hooked and off doing the conceptual footwork for me.

Which allows me to sleep more and dream up more ambitious things:

A Topic Maps based mashup infrastructure.

Obviously I managed to send CatBert back into deep depression (he saw that coming, trust me).
While he sleeps in his favourite armchair, I can steal back my ideas and tuck them safely away into an academic paper. So maybe another RDFascist can entertain me with a negative review. As if a man with a vision would care.

Locator Patterns

Among the things I want to add to TempleScript are subject locator patterns. Here is the use case:

Life is full of coincidences: First I followed with interest the Ontopia web dev tutorial, then I had my more-or-less regular "TM brain storming pizza lunch appointment" with Robert (Cerny), keeping my head spinning with ideas for days. And just earlier I was passing by CatBert's office.

He was lazily typing on his CatBook:

Look what I have done with my language TempleScript!

Actually TempleScript was our idea, but CatBert had started to take ownership.

Eating Your Own CatFood

His screen showed:

This is a complete web application written in TempleScript!

Today I have deinstalled my old TM server

It has served me well as private bookmark server, especially while I ran the ESW course.

[Beware: Topic Maps ahead.]

Once you reach a certain age, you seriously ask yourself whether this has been be all: wealth, fame and many beautiful women.

It is the time when you look for a more integrated meaning in the universe. A meaning which transcends all levels of abstraction. And a processing model which gets rid of the silly separation between programming language and semantic data store with its static knowledge.

(continued from Part II)

One thing Formula 3 (F3) was designed to help with is the quantitative transformation of time series. If you had to compute the mean values over an 1-hour interval of, say, the ticket sales then the following TSP operator takes care of it:

(continued from Part I)

Last time I implicitly proposed to think some parts of a (geosemantic) application in terms of time series. This is not so farfetched, consider for instance a semantically enabled tourism application for, say, Vienna.

Sure, there are a number of very static things you would store into the semantic network:

• the sites, churches, cathedral, churches, and even more churches,

• the museums, galleries, museums and even more museums,

• the tourism ontology, containing buildings, museums, and yes, the churches.

But even if this is Vienna, not everything is static: There are (insane) traffic conditions, (predominantly italian and spanish) tourists roaming through the city, concert tickets sold at the weirdest places. All these are perfect candidates to be packed into time series.

When people design semantic systems, then a typical architecture looks something like this:

• An RDF tuple (or Topic Maps) store for the odd and irregular data, and

• some relational DB, either imported into the semantic store, or wrapped, or linked via a message bus (MQ, events, ...).

• Some more or less sophisticated integration, and

• the user interface on top of it.

Now this is all well and good for your middle-of-the-road semantic portal, but the class of applications I have in mind have one thing in common:

Data dynamics, with temporal and geospatial aspects. And that with physical units.

CatBert was in a very aggressive mood. He had interviewed me all day on subject identification and how it worked for the Topic Maps and the RDF stack.

But the longer he investigated, the more poignant his remarks became. This evening he even meant:

Robert, I am getting tired of the lack of imagination in the semantic web community.

Recently the Perl TM package has started to experience some problems with smoke testing together with some Perl releases.

As I do not have the time to track this down properly, I simply take this opportunity to remove the complete TMQL support, just to factor this into my private implementation.

Version 1.46 is on its way into CPAN.

This weekend I have commenced work on RDF::SKOS.

As most of you know, many have observed this before and larsbot has blogged about it in the past, SKOS is strikingly similar to Topic Maps, although in detail its semantics is much more limited. Interesting from a standards-political point of view.

There is yet no Perl coverage on CPAN. That has to change.

Ever since I met Jan Schreiber in Oslo a while back I had this itch that someone should write a C library for TMRM. Not only to host maps in proxy form, but more importantly to have a fast evaluation mechanism for myTMQL path expressions.

I was waiting for an opportunity to pack this into one of the paid projects, but that opportunity never arose.

(continued from Part III)

Last time I left off with showing you how individual documents would be blended into a landscape which is computed from a topic map.

So far I have ignored the topological structure of the topic map itself and computed the landscape only from the terms within the documents. But my ultimate goal is/was to visualize whole topic maps, not just the text corpus.

(continued from Part II)

The landscape we looked at last time only consisted of mountain ranges and valleys made up by the intensity and extensity of certain words (or word groups) within a set of documents. Documents which are all captured with a topic map.

(continued from Part I)

The last time we looked at a map which only contained two topics and where the documents attached to the two topics are completely disjunct:

Infinity

One additional observation we can make is that the landscape has a rather peculiar structure: If you follow the JJJ mountain southwards towards the HHH ridge, you will see that that continues at the top.

The same holds for the east-west horizon: If you follow the EEE