I say tom-r-toe. You say tom-aye-toe

18 January, 2008

What is it about terminology that makes some people roar and others cringe? While the literature has a lot to say about the problems of knowledge sharing between groups when language is different [1], there are some obvious obstacles to sharing knowledge in the same language when the terms, or even the style of language to describe information, differs between groups.

In the medical field, the National E-Health Transition Authority in Australia (NEHTA) is currently developing a taxonomy of terms, and an ontology to support it, to fully articulate the relationships between the chemical composition of a drug and its medicinal use all the way down to how it is represented as a product on the shelf. This set of terms is supposed to help systems “efficiently exchange data and improve how important clinical and administrative information is communicated between healthcare professionals”.

This initiative would be a great step forward if only this dictionary of terms actually represented the way that doctors prescribe medicines, the way that pharmacists in Australia dispense medicines, and the way in which companies label and market their products. Of course there are also other taxonomies around the world that also try to do the same thing, and some of them are more successful than others. The hard thing is to apply their use outside of community that uses them.

When I was recently doing some IA work in the area of health I think I found about half a dozen or so of these so called “standards”. I also found that a number of business-teams working in the same organisation each with unique terms of their own used to describe these same things. If it were just an issue of Eskimos having a zillion words for ice it probably would have been OK, but rarely did each term carry any additional meaning. You can imagine the pain caused when it came to developing a shared business system, not to mention the problems associated with creating documentation, with each team demanding specification documents with their own terms reflected and refusing to sign-off on them until this was achieved.

How can you manage terms and definitions when there’s no agreement of a one-size-fits-all approach, especially when your goal is to achieve a one-size-fits-all approach?

Topic maps are a good way to manage this chaos. For these teams I created a wiki powered by a topic map engine, allowing the members of each team to collaborate to describe the terms they used. I then coopted bribed persuaded asked subject matter experts to create the relationships between terms and across those teams. Where one team used, for example, the term “tom-r-toe” and another “tom-aye-toe”, the topic map allowed for the existence of both terms, and their definitions as agreed by those teams, and included a relationship between them that indicated they were actually the “same term”. Other relationships, like “equal term”, “equivalent term”, “parent term”, “child term”, even collections of terms, were also captured. A module in the topic maps engine even allowed for the capture of which terms were used in what documents and included an glossary of terms as an output just to make each team happy. There was even some talk of the topic map being used provide team-preferred terms within the business systems interface.

Having “one taxonomy to rule them all” isn’t always necessary when communicating knowledge across teams. Language might be a barrier, but if you can articulate and capture the relationships between terms, then you’ve got a translation matrix that will assist with and ease the burden of knowledge transfer, and can help with challenge of creating awareness of differences and similarities in intra-office communication.

M

- - - -
[1]. Preece, J. (2004) Etiquette and trust drive online communities of
practice. Journal of Universal Computer Science, 10(3), 294-302.


Topic maps. On crack.

30 March, 2007

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

29 March, 2007

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