Finally! The first installment in my introduction to topic maps for non-technical types arrives!
Suggestions for improving the dialogue, illustrations, etc., are most welcome!
It would be interesting if this could develop as a framework for explaining topic maps and their applicability in particular domains or to particular issues. By changing the problems confronted by George and Mary and adapting the dialogue.
This will not appeal to the “it can’t be funded unless 1) we don’t understand it, and 2) we suspect the applicant doesn’t either” crowd. Ask me if you are in that situation and we can translate a George and Mary story into complicated looking notation. With a light dusting of references to Peirce for good measure.
Something I do not get in this community, why so many people are so keen to explain Topic Maps to everybody. It’s a technology that enables you to represent and access knowledge, that’s it, nothing more. It’s simple and easy comprehensible, and that’s also part of it’s beauty.
What someone is really interested in are the applications of such a technology. The same way as people are not interested and do not need to understand how a printing press works, they still grasp and admire the implications of it -> it is easy to publish information using this technology and that’s what people want: read books, newspapers, whatever.
The application makes a technology interesting, not the technology itself. Come up with applications that make use of the technology in a way not possible before and people will love it.
Comment by Thomas Neidhart — June 23, 2010 @ 12:10 pm
You talk to Jack Park. The sanitized version is “just do it.”
There is some merit to your complaint but only some. You could just as easily say “why teach mathematics?” After all we have pocket calculators, cell phones and for anything beyond that, use MathLab or Mathematica.
The merit in your complaint is that we don’t have enough delivery of content to users, who may or may not know it is a topic map.
Authors need to know something of topic maps, even if we had better tools for them, in order to make full use of topic maps. To say nothing of developers who may be interested in building better tools.
BTW, your explanation, “enables you to represent and access knowledge” can be said about everything from pencil and paper to hypergraphs. Why choose topic maps if everything does the same thing?
Comment by Patrick Durusau — June 23, 2010 @ 1:00 pm
One additional comment:
So, where is the application you think we should be building?
Serious question. It isn’t enough that topic maps are cool or do things the way we want to see them done. What application do you see where topic maps offers a substantial advantage over other approaches? (I have an answer to that but I am interested in yours.)
Comment by Patrick Durusau — June 23, 2010 @ 6:07 pm
A Topic Map *is* a hypergraph, where some edges just have a (domain)-specific meaning. If you would step back and look at the available ways to represent knowledge, you would realize that there is not much difference between them, mainly in the way how we encode them (aka format, in mathematical terms: think of polish vs infix notation).
That does not mean that Topic Maps do not have a justification, but as you asked the question to yourself, why choose Topic Maps? For me the answer is usually: available tools, easy of usage.
@Applications:
I do not have a killer application, and I am not sure if something like this exists. A field that could have been interesting (or still is) is related to semantic wikis, look for example at http://www.freebase.com, which is pretty amazing imho. To make a bit self-advertisement, for TMRA I am preparing a paper about semantic data analysis using Topic Maps, so I believe this is also a field that could be of interest, but there are surely much more.
Comment by Thomas Neidhart — June 24, 2010 @ 2:51 am
Question: What do you see as the difference between “ways to represent knowledge” and “the way how we encode them”?
I take those two to be synonyms. Yes?
The manner in which we represent knowledge or “encode” it makes an enormous amount of difference.
Take the example that I wrote in An SQL Example for Michael. In SQL, (leaving data dictionaries aside for the moment), I can’t talk about column headers as subjects. I cannot assign them properties, I cannot say when one column header equals another.
That doesn’t sound like topic maps are equivalent to relational database representation. Does it to you?
Data dictionaries aren’t the same as representing subjects by proxies which are subject to 1) rules for subject identification and 2) rules for determining subject sameness. You could record such information there but with the same impact as writing it down on the back of a candy wrapper. No one would think to look there.
Why choose Topic Maps is a tools question but also what do those tools support that other tools do not? I think quite a bit but that requires explanation to both foster as well as to make those advantages apparent.
I don’t think there are any present killer apps but I have no doubt they are out there. Who would have thought something like Facebook would attract 400 million users? Or Twitter? Just a question of finding the pinch points where what topic maps do differently is a substantial advantage.
BTW, a hypergraph is one way to view a topic map. It is itself simply a representation. I confess to having a weakness for that sort of analysis but it falls short of pronouncing that everyone has to view topic maps that way. And it may not be the most efficient representation for some purposes.
Comment by Patrick Durusau — June 24, 2010 @ 6:57 am