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.

While there are several interpretations of what mashups actually are, I tend to stick with the following use case.

Flight Arrival Information

One application could, for instance, provide information about flight arrivals, say, for a particular airport (VIE). Let's quickly prototype that application:

As you can see, that application is hosted at http://my.airports.com/ and it offers one endpoint arrivals. That takes one PATH_INFO parameter to represent one particular airport. And that page is to be referenced as

http://my.airports.com/arrivals/vie

for the VIE airport.

Whenever the page is referenced, the SELECT query will produce a list of flight information (unsorted) for flights which are supposed to arrive at the airport within a 2 hour time horizon.

Non-Meshuppiness First

A naive (non-semantic) rendering to HTML would simply create a table, maybe something like this:

The best what we can expect is to have added automatically the data type, but that is as much as the expressions in the SELECT clause - such as $f / origin can deliver.

Meshuppiness Follows

That is certainly not enough information to allow a second application --- and that is what a mashup is all about --- to automatically hook itself into.

What we need is something more along these lines:

As you can see, while the data is still organized into a table,

• the data type information is parked in a dedicated datatypeattribute,

• what the data item is, is tucked into the class attribute,

• what property (aka occurrence type) we are talking about is held in the RDFa property attribute, and

• a wrapping DIV captures the subject we are talking about. Again instrumenting RDFa.

TempleScript Query Revisited

So how can we ask for such semantically rich information using TempleScript?

Now, when we were writing something like this

then we implicitly have asked for two things:

• First that the occurrence of type origin for the topic $f is referenced, AND

• secondly, that only the value (not scope, not type) is finally produced.

That latter process TempleScript calls (like the old TMQL) atomification.

This is not mandatory. We could step back a bit and ask for the whole occurrence, not just its value. That is done via the path expression

And now all information is available to produce the HTML snippet

from above. We might even be inclined to add not only occurrence types, but also all available supertype information into that mix.

Yes, this is why I am getting paid the big bucks.

In The Meantime, At The Browser

Where the mashup really shines is at the browser side. There actually all mashup parts will have to play together, this includes the initial bootstrap application, and then also the add-on apps.

How that works, after my nap.

CatBert out.