I had a flare of inspiration last night to write about the philosophy of trust, based on a book that I'm currently doing technical review for; how easy it is for us to give and take trust. Ever heard someone say "SuchAndSuch.com is crap! It was down all last night, and I couldn't buy the wife some hockey-boots!" All the time. And we, as perceptive beings, we take this one tiny fragment of someones experience with a company, in their tiny, tiny fragment of existance, and paint "ureliable" all over its timeline and hard-working staff with big brushes. Silly, ain't it? Yet, this is how we work. Trust.

Peter Van Dijck has a blurb on the difficulties in learning Topic maps. Now, I trust Peter and a lot of others do too. He's a figure in various domains, has written an apparent excelent book about Information Architecture, devised the XFML format for faceted info and sharing, and set up and initiated EasyTopicMaps.com the Topic Maps common Wiki. His word and expertise is good. And James Robertson of Column Two agrees with him. I trust James too. James is an expert, and knows his stuff. If he says jump, I'll probably do it. Same for Peter. Goodie.

Are they right, though? The thing is that I've had similar (or probably exact; memory is a bugger) conclusions about Topic maps in the past; the XTM format is too verbose, the spec too diverse, the datamodel too much, the psychological impact too distressing, and so forth. But they - and the old me - are not right.

The general issue raised is that the Topic maps examples and tools are too far away from practical real-world stuff developers do that people simply give up; it becomes too much to get going with it. First, let me give you my bias in this; this is why I created xSiteable (a real-world site generator, used to create a number of sites on the net, including this my own) and helped Thomas Passin set up TM4Jscript, a TM engine and editor (and soon a bookmarks application) for JavaScript (meaning, super-easy to get going with as every major browser has got JS in there). I'm not saying Peter and James got it wrong because I've done these things, but let's think about it;

There are a number of smaller and big applications using Topic maps around, some fancy smoke-and-mirrors, others down to the core and solving problems. There are a number of sites that are smokey demonstrations, and others that solve real issues with it. Fine, we can point to these, and say "Aha!"

Let's talk about the real world, and the need to reflect it in terms of Topic maps; the reality lies in what Topic maps should and should not be applied to. If you want a relational database, then use a relational database. It is the most real-world application out there. If you want a Topic Maps database, use a Topic Maps database. I feel a bit silly for stating the bleeding obvious, but some of the real-world problems people often want to solve can be handled with traditional methods just fine. There is no reason to enforce the wonderfulness of Topic Maps on them ... unless they want to take some steps further, and it is knowing about these steps which is the paradigm shift promised by Topic Maps, nothing else.

Peter points this out quite rightly. We call the cross-over to Topic maps for "a paradigm shift", no small statement.

"Huh? I can do this database just as well as Topic Maps using plain vanilla SQL databases! What's the fuzz?"

That's right; what's the fuzz? The thing is that if you can do the same, then don't do it, and most Topic Mappers know this. Their applications are outside of the scope of the traditional way of doing things, hence so few examples of them. We are hard-working people who write specialised and clever applications, and so we don't really have the time to write "how to sort your CD collection with Topic Maps." If a relational real-world thing that has been solved a million times over is what you want, then Topic Maps will be a pain in the hindsight, and you'll say "Topic Maps are hard to learn! I was fiddling all last night, and I didn't have time to buy the wife some hockey-boots!"

Get smart; that is why you'll dig into Topic Maps, and people who knows about those extra steps, who knows the value of semantic-rich metadata instead of the crap we mostly put out these days, will prevail with Topic Maps. It is not about showing someone a real-world problem, because they are mostly solved by proven method already. It is about showing people better ways. It is why we call it a paradigm shift, and not simply "another way of doing it"; it will tilt your mind, and push you further. That is why Topic maps can be hard to learn. Paradigm shift. Repeat it a few times until you understand it. It is 20% ideas, 70% philosophy, and 10% application.

Peter raised a few questions on a few mailing-lists and asked if anyone knew about easy applications or frameworks for Topic maps that could help us in evangelising our lamb. He states;

There are no hackable applications that I know of you can use to learn topicmaps. This means that there are no beginners tutorials that let you hack a useful application together based on topicmaps. All the tutorials I've seen teach you topicmap concepts and how to create a topicmap. They don't help you create an application to organize your CD's.

So, in Peter we trust, and even though I've seen most of the responses (I added some myself) he still says there are no hackable applications that you could use for easily learning about Topic maps. How does he come to that conclusion? I surely don't agree, but it is hard to fight this one back as I don't have the readership he's got. In fact, both Peter and James agree on this, and it is - in my opinion - far more harming to the ways of Topic Mapping than anything, as people trust what they say, and so it must be true.

To state the reality; There are lots of applications, some half-done, some bigger, some complex, some easy, some small, some big, some free, some commercial, some ugly, some pretty, and so on and on. If we are to take at face value that there are no hackable applications, please let us know the formular you're using. Hmmm, he puts a qualifier on it;

All the tutorials I've seen teach you topicmap concepts and how to create a topicmap. They don't help you create an application to organize your CD's.

Maybe he's right, but I have seen tutorials and / or documents that tell you how to use XSLT to create a website (there is also the excelent chapter 9 of the that is an extention of this; source available.), how to harvest a Topic Map using XSLT and how to create a Topic Maps engine in a relational database. Just a few off the top of my head, very real-world stuff. Of course there are overwhelming "concepts" tutorials out there; the concepts are new, and often don't solve "how to sort your CD collection" at all.

What is the purpose of Peters blurb? That Topic Maps can be hard for some? Anything that doesn't apply to? That there are no hackable application? Hogwash. No real-world tutorials? not true. That RDF with FOAF is suceeding? Politics. That we need more of whatever? Help us out. What we need is not 'this is hard', but 'this is clever.'

Permalink (Thu, 1 Apr 2004 13:00:00 GMT)| Comments (4) | Topic maps