Topic Maps Semantic Meshup (Part I)
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:
which isa web:page
select $f / arrival,
$f / SSIM,
$f / origin,
$f / airline
where $f isa flight
and $f / arrival between now and now + 2 hours
and $f / destination == $airport
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
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.
A naive (non-semantic) rendering to HTML would simply create a table, maybe something like this:
<span class="string">Austrian Airlines</span>
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.
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.