Trond Pettersen’s posts on Web Application Development with Ontopia are a welcome relief from the initial presentation of topic maps that most of us have experienced.
While reading those posts it occurred to me that for public/static topic maps that a topic map engine might be overkill. If I am sent a fully merged topic map and all I want to do is display it, shouldn’t I be able to store it in an SQL backend, export it to XML and then use Cocoon as a framework for delivery?
I think creating, manipulating and navigating information represented in topic maps should be viewed as separate components in a work flow for topic maps. For example, postings in a blog (to shamelessly steal Trond’s example case), could result in XTM fragments with no topic map “processing” other than production of the fragments.
Another component, dare we say a “topic map engine,” might obtain those fragments from a feed and integrate those into a topic map that is periodically exported to yet another component (and possibly other destinations) for display or other uses.
All of those activities could be centralized in one piece of software, as it is with Ontopia or apparently with DC-X, to name an open source and commercial product.
But there are dangers in consolidated approaches.
One danger is being locked into a particular framework and its limitations.
Another is the potential damage to one’s imagination when every task revolves around one view of the data. Different operations are being performed to produce or upon the data. How it arrives at a common model should be left to the imaginations of developers.
A lot of very clever people are concerned with authoring, merging and delivery of topic maps. Viewing those as separate tasks may lead them to different places than when all roads start in one place.
You can of course export static topic maps to XTM and then do your output based on the XTM representation, but if you do you are essentially not using Topic Maps any more, but rather XML. The result is that you lose a lot of what is convenient and nice about Topic Maps, and instead have to reimplement Topic Maps in XML.
Usually, the result is fairly unpleasant for whoever has to do this. It doesn’t help that XTM is not very XSLT-friendly. For example, to traverse the created-by(work, creator) association, this is the XPath you’d have to write, if you assume you are operating on already-merged normalized XTM 1.0:
//xtm:association
[xtm:member[xtm:roleSpec / xtm:topicRef / @xlink:href = ‘#work’]
[xtm:topicRef / @xlink:href = concat(‘#’, $work)]]
[xtm:instanceOf / xtm:topicRef / @xlink:href = ‘#created-by’]
/ xtm:member[xtm:roleSpec / xtm:topicRef / @xlink:href = ‘#creator]
/ xtm:topicRef / @xlink:href
If you use tolog you could do this as follows:
created-by(%work% : work, $AUTHOR : creator)?
It’s true that if you use Ontopia you will find yourself tied to that framework. But then, if you use Cocoon you will find yourself tied to that. And so on, for any framework you care to mention.
So overall I’d prefer to use a Topic Maps framework for working with Topic Maps data.
Comment by Lars Marius Garshol — March 28, 2010 @ 2:24 am
Apologies for not being clear. Two separate but related issues:
(1) Having a modular approach that allows processing of topic maps similar to pipes in Unix or even XML.
I would not export topic map data from an SQL backend to XTM for display processing. I don’t see anything particularly topic mappish about display processing.
Nor, as I noted, is there anything that necessarily requires a topic map processor to author topic maps. Those could even originate from wholly automated log events.
As far as Cocoon, I haven’t done a scientific survey but I suspect there are more Cocoon frameworks than Ontopia ones. The extent to which one could provide a topic map feed (post-merging) into a Cocoon framework, I would count that as a win.
(2) The topic map feed suggestion brings up the related issue: Does topic maps include only topic map processing or does it include the results of topic map processing?
Important question because one way to promote topic maps is to provide “merged” information feeds that are unlike the ones created with other technologies. The buyer/user of such feeds may be blissfully unaware that topic maps are responsible. But they will notice a difference in topic map based data feeds and those created using other technologies.
I think the more markets we can create for topic maps and topic maps based information the better.
Comment by Patrick Durusau — March 28, 2010 @ 8:39 am