Tag: LarsMariusGarshol

Ontopia gets an SDshare implementation

A prototype server implementation of the SDshare protocol was added to the sandbox today. The implementation is not yet tested, and somewhat incomplete, but good enough to be tried out. The readme file has more details, plus build instructions.

This particular implementation of SDshare allows the contents of one topic map to be replicated into another topic map, potentially on a different server. One use case is to have one hub server build a merged topic map from SDshare streams from a number of upstream servers. Another is to transfer updates from a staging server to a production server. And so on.

The implementation is being written for two reasons. One is to learn SDshare. The other is because Bouvet is likely to get a project which will be based on SDshare, in which case using Ontopia for some of the SDshare servers is one of the options we are exploring. So work on the implementation is likely to continue.

Note that the implementation is so far an SDshare server only. There is no client for the time being.

Impedance mismatch 2.0

A recurring challenge for Topic Maps-based projects is how to structure applications internally. For traditional projects based on relational storage this problem is known as the impedance mismatch problem. That is, the problem of how to handle the database in the code. Should SQL queries be just littered all over the code? Should there be some sort of structure to the database interaction? Should one perhaps use an O/R mapping tool? And so on.

The same challenge exists for Topic Maps-based projects, but it’s much less well understood, and it has not been discussed very much yet. Lars Marius Garshol did a presentation about this at an internal Bouvet conference, which describes some possible approaches to the problem. Since this is highly relevant to Ontopia users we publish the presentation here.

Triggers

While presenting tolog updates at TMRA 2009 I casually referred to the possibility of using tolog updates to create a trigger mechanism in Ontopia similar to triggers in relational databases. After the presentation the idea grew on me, and so I decided to elaborate a little further on it and present it in the open space session. The result was this little presentation, which gives a brief outline of the idea.

tolog updates

Unlike SQL tolog has so far only had support for queries, but that has now changed. Lars Marius Garshol has now extended the tolog implementation in Ontopia with support for tolog updates, which extend tolog by adding DELETE, UPDATE, INSERT, and MERGE statements, in addition to the familiar SELECT.

The update statements are described in more detail in the TMRA 2009 paper. The slides may be a bit more approachable, but have less detail, obviously. The idea for the update language is actually quite old. Here’s a blog post about an early design from 2006.

Anyway, if you want to try it, you need to get the latest source code from Subversion. In Omnigator you’ll find the “Generic Query” plugin. If you put in an update statement and click the “Update” button it will run the update statement for you. One way to try it is to navigate to the city Munich in the Italian Opera topic map in Omnigator, then click to open the generic query plugin in a new tab. In that tab, run the following query:

update value($TN, "München")
from topic-name(munich, $TN)

Now go back to the original tab, and press reload. You’ll see the name of the city change. Magic!