Archive for the ‘TMCL’ Category

Topic Map Design Patterns For Information Architecture

Monday, April 1st, 2013

Topic Map Design Patterns For Information Architecture by Kal Ahmed.


Software design patterns give programmers a high level language for discussing the design of software applications. For topic maps to achieve widespread adoption and improved interoperability, a set of topic map design patterns are needed to codify existing practices and make them available to a wider audience. Combining structured descriptions of design patterns with Published Subject Identifiers would enable not only the reuse of design approaches but also encourage the use of common sets of PSIs. This paper presents the arguments for developing and publishing topic map design patterns and a proposed notation for diagramming design patterns based on UML. Finally, by way of examples, the paper presents some design patterns for representation of traditional classification schemes such as thesauri, hierarchical and faceted classification.

Kal used UML to model the design patterns and their constraints. (TMCL, the Topic Map Constraint Language, had yet to be written. (TMCL)

For visual modeling purposes, are there any constraints in TMCL that cannot be modeled in UML?

I ask because I have not compared TMCL to UML.

Using UML to express the generic constraints in TMCL would be a first step towards answering the need for topic maps design patterns.

Apache MRUnit 0.8.1-incubating has been released!

Friday, March 16th, 2012

Apache MRUnit 0.8.1-incubating has been released!

From the post:

We (the Apache MRUnit team) have just released Apache MRUnit 0.8.1-incubating. Apache MRUnit is an Apache Incubator project. MRUnit is a Java library that helps developers unit test Apache Hadoop MapReduce jobs. Unit testing is a technique for improving project quality and reducing overall costs by writing a small amount of code that can automatically verify the software you write performs as intended. This is considered a best practice in software development since it helps identify defects early, before they’re deployed to a production system.

The MRUnit project is actively looking for contributors, even ones brand new to the world of open source software. There are many ways to contribute: documentation, bug reports, blog articles, etc. If you are interested but have no idea where to start, please email brock at cloudera dot com. If you are an experienced open source contributor, the MRUnit wiki explains How you can Contribute.

Opportunity to contribute to unit testing for MapReduce jobs.

BTW, what would unit testing for topic maps, ontologies, data models look like?

I grabbed Developing High Quality Data Models (Matthew West) off the shelf and flipped to the index. No entry for “unit testing,” “testing,” “validation,” etc.

Would the Topic Maps Constraint Language be sufficient for topic maps following the TMDM? So that you could incrementally test the design of streams of data into a topic map?

Riaknostic diagnostic tools for Riak

Thursday, December 22nd, 2011

Riaknostic diagnostic tools for Riak

From the webpage:


Sometimes, things go wrong in Riak. How can you know what’s wrong? Riaknostic is here to help.

(example omitted)

Riaknostic, which is invoked via the above command, is a small suite of diagnostic checks that can be run against your Riak node to discover common problems and recommend how to resolve them. These checks are derived from the experience of the Basho Client Services Team as well as numerous public discussions on the mailing list, IRC room, and other online media.

Two things occur to me:

One, diagnostic checks are a good idea, particularly ones that can be extended by the community. Hopefully the error messages are more helpful than cryptic but I will have to try it out to find out.

Two, what diagnostics would you write in TMCL as general diagnostics on a topic map? How would you discover what constraints to write as diagnostics in TMCL?


Thursday, April 21st, 2011


From the webpage:

Schemafit is a generic tool which extracts from an “unknown” topic map a fitting TMCL schema.

Onotoa: Simply create your Topic Maps schemas

Wednesday, January 26th, 2011

Onotoa: Simply create your Topic Maps schemas

The 1.2 version is due out fairly soon.

Onotoa assists in the construction of topic map schemas (constraint schemas).

It provides a graphic representation of types and constraints for a topic map.

You probably want to read Creating a topic map ontology with Onotoa before you try the Onotoa Handbook.

I am not sure the Onotoa Handbook, even if it were available in editable form (say ODF?), would be worth the effort to make an editorial pass at it.

Suspect splitting it into a reference manual and a users manual would be a step in the right direction. Then do an editorial pass.

Aspects of Topic Maps

Wednesday, December 8th, 2010

Writing about Bobo: Fast Faceted Search With Lucene, made me start to think about the various aspects of topic maps.

Authoring of topic maps is something that was never discussed in the original HyTime based topic map standard and despite several normative syntaxes, mostly even now it is either you have a topic map, or you don’t. Depending upon your legend.

Which is helpful given the unlimited semantics that can be addressed with topic maps but looks awfully hand-wavy to, ahem, outsiders.

Subject Identity or should I say: when two subject representatives are deemed for some purpose to represent the same subject. (That’s clearer. ;-)) This lies at the heart of topic maps and the rest of the paradigm supports or is consequences of this principle.

There is no one way to identify any subject and users should be free to use the identification that suits them best. Where subjects include the data structures that we build for users. Yes, IT doesn’t get to dictate what subjects can be identified or how. (Probably should have never been the case but that is another issue.)

Merging of subject representatives. Merging is an aspect of recognizing two or more subject representatives represent the same subject. What happens then is implementation, data model and requirement specific.

A user may wish to see separate representatives just prior to merger so merging can be audited or may wish to see only merged representatives for some subset of subjects or may have other requirements.

Interchange of topic maps. Not exclusively the domain of syntaxes/data models but an important purpose for them. It is entirely possible to have topic maps for which no interchange is intended or desirable. Rumor has it of the topic maps at the Y-12 facility at Oak Ridge for example. Interchange was not their purpose.

Navigation of the topic map. The post that provoked this one is a good example. I don’t need specialized or monolithic software to navigate a topic map. It hampers topic map development to suggest otherwise.

Querying topic maps. Topic maps have been slow to develop a query language and that effort has recently re-started. Graph query languages, that are already fairly mature, may be sufficient for querying topic maps.

Given the diversity of subject identity semantics, I don’t foresee a one size fits all topic maps query language.

Interfaces for topic maps. However one resolves/implements other aspects of topic maps, due regard has to be paid to the issue of interfaces. Efforts thus far range from web portals to “look its a topic map!” type interface.

In the defense of current efforts, human-computer interfaces are poorly understood. Not surprising since the human-codex interface isn’t completely understood and we have been working at that one considerably longer.


  1. What other aspects to topic maps would you list?
  2. Would you sub-divide any of these aspects? If so, how?
  3. What suggestions do you have for one or more of these aspects?

A Bill With No Name

Monday, August 16th, 2010

H.R. 1586 as passed by the U.S. Senate and reported by Thomas (Library of Congress, legislative information), reads:

Short Title
section 1. This Act may be cited as the “______Act of____”.

Ask yourself: How would topic maps lead to a different result? (Ok, that probably wasn’t your first thought, work with me here.)

If bills were treated as subjects, represented by topics, using TMCL, we can specify that every topic of type “House Bill” has to have one and only one name.

We can modify the example in TMCL, 7.6 Topic Name Constraint to read

houseBill isa tmcl:topic-type;
has-name(tmdm:topic-name, 1, 1).

Which says every topic of House Bill type has one and only one name. And we should get an error warning if is it missing.

If that seems like a lot of trouble fix a work flow proofing glitch, consider this:

U.S. legislation typically runs hundreds, even thousands of pages with provisions that are relevant to particular constituencies. What if all those provisions and their constituencies were treated as subjects, represented by topics?

Everyone could read those provisions of interest to them or the ones they were interested in opposing (possibly the more popular of the two). Instead of 2,000 pages you might need to read only 3 to 5 pages.

Reading maybe 3 to 5 pages sounds more like transparency to me than dumping 2,000+ pages on my desk and calling it “transparency.”

PS: My suggestion to fix the bill title: “Last Opaque Act of 2010.” Whether lobbyists, elected officials and agencies can hear it or not, transparency is coming, to the USA.

TMCL Arrives!

Sunday, March 28th, 2010

The final (hopefully) version of TMCL has arrived!

Please take a look at the latest version, before 25 April 2010.

Comments can be sent to:, or posted to the TMCL project page.

News about CTM coming tomorrow! This could be a banner year for topic map standards!