Belaboring the state of topic map tools won’t change this fact: It could use improvement.
Leaving the current state of topic map tools to one side, I have a suggestion about going forward.
What if we conceptualize topic map production as a tool chain?
A chain that can exist as separate components or with combinations of components.
Thinking like *nix tools, each one could be designed to do one task well.
The stages I see:
- Authoring
- Merging
- Conversion
- Query
- Display
The only odd looking stage is “conversion.”
By that I mean conversion from being held in a topic map data store or format to some other format for integration, query or display.
TaxMap, the oldest topic map on the WWW, is a conversion to HTML for delivery.
Converting a topic map into graph format enables the use of graph display or query mechanisms.
End-to-end solutions are possible but a tool chain perspective enables smaller projects with quicker returns.
Comments/Suggestions?
I think a tool chain is the way to go.
Having never built a topic map application before, I don’t know if I’m following the right approach but I am breaking “Authoring” into two parts: Design and Data Transformation/Import. Design is establishing the schema and maybe not so much a controlled vocabulary but a controlled set of concepts around which other topics can be added. To figure out the topics/associations I used CMap Tools (http://cmap.ihmc.us/download/) because it is fast and easy.
I then went looking for a good tool to build a topic map schema from the the diagrams in CMap Tools. I started with Onotoa from TopicMapLabs (http://onotoa.topicmapslab.de/) but that only does TMCL and it is hard to see if the schema is right unless you can see example data. So I switched to Wandora (http://www.wandora.org/www/).
Wandora has many, many ways to extract and import data so it can serve well for both my Design and Transformation/Import steps. It has dozens of built-in extractors (SKOS, Dublin Core, GATE categorizer, Wikipedia, DBPedia, etc). As an added bonus, it also has many ways to view and manipulate the data. R is embedded. Processing is embedded. It can export in many different graph file formats. So far, it makes a very good central link the the tool chain for development even if it does not support the complete Topic Map standard.
I was treating Query and Display as a single step and that is where it gets hard to find something that supports the richness of the data in topic maps. Neither the classic topic map viewer (as in Ontopia) nor the hair-ball graphs of many viewers seem to provide much insight into the data in a topic map and they don’t scale very well to large amounts of data. The former has too small a window into the data and the latter has too wide a window. You can zoom in on a graph but then you lose the context of the data. A graph view would work if I could find something that could do faceted filtering where the facets would be automatically created based on the topic types and association types but I have not been able to find anything like that yet. A continuously zoomable interfae like (http://www.onezoom.org/software.htm) could work well or self organizing maps like at (http://kill.devc.at/node/272) but they seem to be in early development still.
I’ll be interested to read what you and your readers come up with on this thread.
Comment by clemp — April 2, 2013 @ 11:05 pm
Interesting. I read your Design and Data Transformation/Import as three parts: 1) design – any convenient tool, 2) Transformation/Import – from other data sources, 3) editing content.
Could have query and display together but your experience with the typical graph presentation was one reason I separated them.
For example, if I had a topic map of an engine repair manual, a “search” should return an image of a part, situated as I will encounter it while working on an engine. A mouse-over may reveal associations and other data. Or “search” may be a textual search after conversion into another format.
BTW, thanks for the comments on facets and zooming.
Comment by Patrick Durusau — April 3, 2013 @ 6:35 pm
I see your point about query and display being separate. If I think of them as separate things, maybe it would make it easier to find the right tools for a complete tool chain.
The difference in perspectives on authoring Topic Maps is interesting. From your requirements, it appears that you see authoring a topic map as somewhat akin to writing code or writing HTML. I have never thought of it that way and maybe that is why I found it difficult to get started. My view of it didn’t match the view of the people who designed the existing tools.
I always thought of Topic Maps as a database with a standardized but extremely flexible schema. That is actually what caught my attention about Topic Maps in the first place. On the one hand, the data did not have to be as rigidly defined as in an SQL database but it still had some structure around which admin tools and core functions could be built and reused across applications. On the other hand, the structure was not as loose as RDF or a graph database where there seems to be no common structure across applications and very little would be reusable from one application to the next.
I always thought of the Topic Map formats (CTM, XTM, LTM, etc) as being designed for data interchange and not for authoring. With that in mind, I was expecting to find tools that would let me “build” rather than “write” the topic map structure. Then I could either write or import the content that filled in that structure. Maybe it’s just me because I also think of XML and HTML the same way. Iv’e never actually written any HTML beyond the “Hello World” level. There have always been tools to do that for me so all I have to worry about is the content and how I want it to look.
I’ll try going back to the text formats for Topic Maps with a different frame of mind and see if they look more usable for authoring.
As a novice, I think there is one key tool for approaching Topic Maps that way. When learning HTML, the browser provides almost immediate feedback. I think most people look at a web page and then view/change the source and then go back to view the page and see what affect the change had. Alternatively, they use a WYSIWYG editor and just generate the page at the end. For novices writing LTM, CTM, or XTM, is there a “rendering” engine for Topic Maps that you would recommend?
Comment by clemp — April 3, 2013 @ 9:20 pm
The Omnigator in Ontopia – https://code.google.com/p/ontopia/ (now at 5.2.2) will give you a default rendering of a map saved to the /install/topicmaps directory. You will need to reload it after changes.
If you go that route, check here for classpath issues, http://tm.durusau.net/?p=23845 and here for port conflicts with HBase, http://tm.durusau.net/?p=26380.
I checked the documentation for Ontopia 5.2.2 and at least install.html does not reflect either of those issues.
Appreciate your remarks about “writing” topic maps. Topic maps arose in the context of the ISO/IEC group that created SGML, etc. Thinking about it, I’m not surprised TMs are informed by a document creation bias. Not that I would have noticed it but for your comment. Broader than documents but there is a lingering tinge of documents about it.
The Omnigator will do what you ask but not as easily as the browsers that taught many of us HTML.
Comment by Patrick Durusau — April 4, 2013 @ 3:54 pm