Topic Maps Semantic Meshup (Part I)

Hi! CatBert here.

http://kill.devc.at/system/files/angry-cat-small.jpg

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:

ap isa web:application = http://my.airports.com/
which consists-of
    arrivals,
       which isa web:page
       = ap:arrivals/(?<airport>\w+)
    returning
       select $f / arrival,
              $f /
SSIM,
              $f / origin,
              $f /
airline
         from http://whatever.back.end/
         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

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:

<table>
<tr>
  <td>
     <span class="daytime">19:10</span>
  </td>
  <td>
     <span class="string">TG7239</span>
  <td>
  <td>
     <span class="string">GRZ</span>
  </td>
  <td>
     <span class="string">Austrian Airlines</span>
  <td>
</tr>
...
</table>

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:

<table>
<tr>
  <td>
    <div about="flight:TG7239">
       <span property="flight:arrival"
             datatype="daytime">19:10</span>
    </div>
  </td>
  <td>
    <div about="flight:TG7239">
        <span property="flight:SSIM"
              class="flight:SSIM identifier"
              datatype="string">TG7239</span>
    </div>
  <td>
  <td>
    <div about="flight:TG7239">
        <span property="flight:origin"
              class="IATA:code identifier"
              datatype="string">GRZ</span>
    </div>
  </td>
  <td>
    <div about="flight:TG7239">
        <span property="flight:airline"
              class="flight:carrier name"
              datatype="string">Austrian Airlines</span>
    </div>
  <td>
</tr>
...
</table>

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

$f / origin

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

$f >> occurrence origin

And now all information is available to produce the HTML snippet

<div about="flight:TG7239">
        <span property="flight:origin"
              class="IATA:code identifier"
              datatype="string">GRZ</span>
    </div>

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. http://kill.devc.at/system/files/angry-cat-small.jpg

Posted In