Topic maps - a new super hero is born!

The good thing about superheroes is that they’re there when you need them. They fly in, seemingly from no where, and save the day. My experience with topic maps has been something like this - when ever I think I’ve got into trouble, messed up the data schema, or need to incorporate new ideas, relationships, or data, topic maps comes to my rescue and doesn’t disappoint.

I know, it sounds a bit weird. People have looked at me and said, “isn’t Topic maps is just xml?” and “Topic maps is nothing great”. Well, lemme explain about the proverbial caped crusader that is topic maps.

I’ve been involved with topic maps projects now for about two years, first at the National Library with the guru of topic maps down-under, Alex Johannessen, and more recently with my work at SMS and a looming uuber engagement for a reporting system that will involve wikis, folksonomies, taxonomies and, importantly topic maps, at a government department.

With SMS, I’ve been working on a skunkworks project for work now for nearly a year now - the Capability Finder. It’s based on a topic maps engine that I developed for my Magia roleplaying website - an engine essentially for content management. I then tweaked and genericised so that it could be effectively used to join the dots between consultants: the work they do; the industries they’re worked in; the skills they have (and even aspire to having); and the engagements they’ve worked on.

Rather than sleep-in every day for four days during the Easter holidays, I was instead woken-up by the sound of XML in my head. The only way to stop the noise was to play with the underlying topic map framework for the Capability Finder for most of this Easter long weekend.

What are topic maps? I’ve dealt with them before in another of my blog posts, but, essentially, they’re a way of representing knowledge and information in the way that people (humans rather than machines) think about the knowledge and information inside their heads - that is, in terms of relationships, rather than a strict hierarchy (a taxonomy) or an unstructured cloud of tags (folksonomy).

So, there I was, playing with the topic map. The structure had evolved over time and there were many inconsistencies in the xml data schema (I don’t like to use the overly verbose ISO standard. I use one I adopted from Alex). Some things that I had as properties of a topic (essentially metadata elements) should have been expressed as relationships.

Here’s an example:

<topic id="matthew-hodgson" type="consultant">
<name>Matthew Hodgson</name>
…etc…
<property type=”EngagementCurrentTitle”>Big Agency Engagement</property>
<property type=”EngagementCurrentDateStart”>April 2006</property>
</topic>

This is perfectly fine, but it doesn’t represent the actual nature of the relationship between the two topics:

1. the topic Matthew the consultant
2. the topic Matthew’s current engagement

I should have represented the xml something like this:


<topic id=”matthew-hdogson” type=”consultant”>
<name>Matthew Hodgson</name>
…etc…
</topic><association id="engagement-association-big-agency-engagement" type="engagement-family">
<member role=”lead-consultant” refid=”matthew-hodgson”/>
<member role=”engagement” refid=”big-agency-engagement-203893″ />
</association><topic id="big-agency-engagement-203893" type="project-engagement">
<property type=”dc.date.start” refid=”ISO8601″>2006-04-23T00:00:00+10:00</property>
<property type=”status”>active</property>
</topic>

Part of why I don’t like databases is that if I had’ve made this error in judgement in a database I’d have to rebuild the database (probably from scratch). Fortunately, I had a superhero on my wide - topic maps as xml. Because of this, all I needed to do was to transform the existing xml into a new xml file using xsl.

<xsl:for-each select="topic">
<topic id=”{@id}” type=”{@type}” >
<name><xsl:value-of select=”name”/></name>
<xsl:for-each select=”property”>
<xsl:if test=”not(contains(@type, ‘Engagement’))”>
<property type=”{@type}” refid=”{@refid}” >
<xsl:apply-templates select=”.”/></property>
</xsl:if>
</xsl:for-each>
</xsl:for-each>

<xsl:for-each select="topic[@type='consultant' and
not(normalize-space(property[@type='EngagementCurrentTitle'])=”) and
not(normalize-space(property[@type='EngagementCurrentTitle'])=’No details available’)]”>
<xsl:variable name=”engagement-title”
select=”translate(property[@type='EngagementCurrentTitle'], ‘ ‘, ”)” />
<topic id=”engagement-{$engagement-title}” type=”engagement”>
<name><xsl:value-of select=”property[@type='EngagementCurrentTitle']“/></name>
<property type=”active” refid=”true”/>
<property type=”dc.date.end” refid=”ISO8601″>
<xsl:value-of select=”property[@type='dc.date.EngagementCurrentConcludes']“/>
</property>
<property type=”dc.date.start” refid=”ISO8601″></property>
<property type=”engagement-summary-document” refid=”#” />
</topic>

<association id=”assoc-{$engagement-title}” type=”engagement-family”>
<member refid=”{@id}” role=”project-lead-consultant” />
<member refid=”engagement-{$engagement-title}” role=”project” />
</association>
</xsl:for-each>

So, after being rescued by my superhero, I then moved to working on the xsl page that presents the information as XHTML so that this new relationship could be presented as hyperlinks. This would allow someone to arrive at a consultant, see the engagement relationship, click on it, and be taken to the engagement he was working on. On that page, you would see all the engagement information, skills used, industry it belongs to, documents attached as engagement summaries or even just engagement deliberables and reports. You could click on any of those and explore further.

These “super powers” of topic maps are probably what I like the best - that is, expressing the relationships as hyperlinks. It’s not about leaping tall data stores in a single bound - at the end of the day, it’s about navigability and findability.

So, next time you need a superhero, don’t look to rigid hierarchical databases. Send the bat-signal into the heavens and call upon topic maps to save the day.

M

Topic maps. On crack.

I recently wrote a post on topic maps. I think they’re very sexy. Finally, in the information classification world, we have a way of representing the knowledge in people’s heads in the way that they think about it - in terms of the relationships between those bits of knowledge.

One of the problems topic maps have is that not many people know about them. There aren’t many cool and sexy Web 2.0 examples that, as an Information Architect, I can point to and say “Look at this. This is topic maps!”. Maybe now, though, I have that chance.

A colleague sent me a link to a blog on Trampoline System’s SONAR software. It looks amazing!

Here we see, in simple terms, the power of representing information in terms of its relationships, rather than its hierarchical, taxonomical view or its data/metadata view.

Plug this thing into your email systems, information stores, records management systems, and let it work its magic to bring all that interlinked information to the surface through natural language analysis. There’s no need to spend heaps of time and money developing complex business taxonomies for knowledge management. If there’s a relationship to find SONAR will bring it to the surface and link it to the other bits of information and articulate its relationship.

Have a look - it’s topic maps on crack.

M

—-

End notes

The title of this blog post is shamelessly stolen and mangled from the movie “Thank you for Smoking“. The protagonist, Nick Naylor, explains to the audience, “You know that guy who can pick up any girl he wants? I’m that guy. On crack.”

Information Classification: Why I love Topic Maps

Doug Cornelius recently made a post about his trouble with folksonomies and taxonomies. Like him, I’ve had trouble with taxonomies. They’re hard work to build and when the information world they reflect changes you’ve just got to re-do the whole thing again. Folksonomies are a good alternative because they’re built by the users as the content is built. Unfortunately, this unstructured view of the world has troubles with scalability and issues with tags that mean the same thing: e.g. dog, dogs, canine, puppy, as tags all mean the same thing. Is there a way to bridge these two world? The answer is yes, and it involves something called topic maps.

Topic maps is an ISO standard for representing knowledge and often written/expressed as XML. It does this very successfully by capturing how people think about the knowledge inside their heads - that is, in terms of the relationships between bits of information - rather than just capturing information alone.

In the information classification world you can use a topic map to describe the relationship between a cluster of tags that mean the same thing and their relationship to the taxonomic view of the world.

canine equals dog, pooch, puppy, dogs, puppies

In corporate terms, a topic map can store:

• the relationships of a piece of content
• it’s position in a website structure’s hierarchical taxonomy
• all the tags used
• any metadata you can think of (date, author, time published, time changed, Dublin Core metadata if you want)
• a reference link to the records system and the business classification scheme used for appraisal and sentencing.

My Dog has type document

My Dog is about canine

canine is a function of the dog catcher department

canine has a disposal authority of next Tuesday

My Dog should be disposed of next Tuesday

You can also make relationships between pieces of content.

Rex is a canine

In people terms, topic maps also have advantages over other information systems because of the way it represents relationships. When I think of a topic like wine, I also think of Shiraz, Merlot, the Hunter Valley in NSW, my time in France, cheap French Bordeaux… I could go on and on… All of these things are about wine. As I learn more about wine, my thoughts and ideas about the topic of wine adapt, refine, expand and change. It’s hard to capture this fluidity of relationships in a database because the information model needed to support it need to change. In the land of topic maps, because it is based on XML, all you do is express new piece of information as a topic, and then add the new relationships between those topics.

Rex has a property of black colour

Rex has a property of is male

Rex has a property of fur that is fluffy

Rex likes Shiraz-flavoured dog food

Shiraz-flavoured dog food is eaten by dogs

Shiraz-flavoured dog food tastes like wine

Wine contains alcohol

Wine has type red

Wine has type white

Shiraz is a red wine

I recently had an engagement with a government agency. They had clients who, more or less, spoke a different language. They had their own terms for naming the things they did - a very different world to the government agency. In my information architecture report I basically recommended they use a topic map to articulate the relationship between these two world views. For the agency, it gave them the ability to understand and report on their own clients’ work to the Minister in the language of the agency, as well as the ability to communicate to their clients in the language of the clients.

All these things make topic maps very cool and very sexy. If you’re afraid of the folksonomic world because it lacks structure, but still want to give users the ability to tag their own content, then use a topic map to infer structure and relate the folksonomic world to your folk taxonomic or corporate taxonomic world view.

M