We are all familiar with the topic maps gospel that emphasizes that subjects can have multiple identifications. And unlike other semantic technologies, we can distinguish between identifiers and locators.
There is no shortage of data integration and other IT projects that would benefit from hearing the topic maps gospel.
So, why hasn’t the gospel of topic maps spread? I suspect it is because semantic integration is only one need among many.
For example, enabling federated, global debate is ok but I need relevant documents for an IRS auditor. Who is waiting for an answer. Can we do that first?
Meeting user needs as the users understand them may explain the success of NetworkedPlanet. They have used topic maps to enhance Sharepoint, something users see a need for.
We need to preserve the semantic integration that defines topic maps but let’s express it in terms of meeting the needs others have articulated. In the context of their projects.
My first target? (First question you should ask when anyone has a call to action.) Next generation library catalog projects. I am creating a list of them now. Will lurk for a while to learn their culture but will be spreading the topic maps gospel.
The conversation will naturally develop to include the treatment of relationships (associations in our speak), roles, and in some cases, interchange of the resulting information (when interchange syntax questions arise).
That sounds like a good way to spread the good news of topic maps to me.
I suspect another reason why the Topic Maps gospel has not spread is that people have a hard time understanding how Topic Maps differ from technologies they are already familiar with, like relational databases.
Take, for example, this quote from a post at Michael Sperberg-McQueen’s Blog:
“The biggest set of open questions remains: how does modeling a collection of information with Topic Maps differ from modeling it using some other approach? Are there things we can do with Topic Maps that we can’t do, or cannot do as easily, with a SQL database? With a fact base in Prolog? With colloquial XML? It might be enlightening to see what the Italian Opera topic map might look like, if we designed a bespoke XML vocabulary for it, or if we poured it into SQL. (I have friends who tell me that SQL is really not suited for the kinds of things you can do with Topic Maps, but so far I haven’t understood what they mean; perhaps a concrete example will make it easier to compare the two.)”
from http://cmsmcq.com/mib/?p=810
“How is that any different from a database?” is probably the #1 question I get when I try to evangelize them myself, and until recently, I was not able to answer it very well. Once I started focusing on providing contextual meaning with scope, treating relationships as subjects with reification, and merging topic maps, it became much easier to highlight the differences. I think perhaps there is a bit too much focus on topics, occurrences, and associations in the introductory literature — people see the analogy with entities, attributes, and relationships and get stuck there.
This also kind of relates to understanding users’ needs — when it comes to the more technical audiences, they need to understand how Topic Maps are unique when compared to what they already know.
I think the Next Generation Catalogs community is a good target. Recently there has been some musing on the list about what the *next* next gen catalog is, which might be a good entry point for a discussion about Topic Maps. There have also been a conversation about distinguishing between entities in the real world and entities on the internet this week — I wanted to bring up Topic Maps myself in this discussion, but I couldn’t quite see how to make it fit. Also, Alexander Johannesen has been on NGC4LIB off and on over the last few years and I have seen him bring Topic Maps up there in the past. People seem interested, but not interested enough to go figure out what Topic Maps are about on their own — they might benefit from your clear explanations. I look forward to seeing your participation after you graduate from lurking. =)
You might also check out the CODE4LIB community as well as the mailing lists run by the various open-source NGC projects like VuFind and Blacklight. There’s lots of overlap between these lists and the NGC4LIB list.
Comment by Marijane White — April 15, 2010 @ 4:17 pm
Hiya. Yeah, not to be dis-encouraging anyone, but …
I’ve been in the library field toting Topic Maps (to various grades of insight) with a cursory interest shaken. The problem here isn’t the technology (in this case Topic Maps), but the library culture and how library systems are created. There is simply no reason for the libraries to adopt Topic Maps, no *matter* how well suited to their purposes it is.
So let me clarify a few things. For example, I’ve toted the brilliance of TM identity management for years. One of the proud accomplishments of the library world is the repository of authors, with aliases and alternative spellings, and it’s used in any respectable system. But it’s just a huge pile of MARC records with some special fields set, and all operations on it is the usual match and merge problem of text comparison, and hence, pretty prone to error.
The alternative, using subject locators, identifiers and indicators is just simply brilliant, with a huge distributed network of identifiers and locators that could do the job so incredibly much better. But in order to do this, lots of people need to understand the epistemological implications of such a system, and to understand the difference between an identifier and an indicator. I suspect we’ll have as much luck in this domain as we do in the RDF domain, and see how much luck we’ve gotten there in convincing people that there even is a problem which isn’t solved by 303 and massive swaths of 404.
The real problem with Topic Maps is that is is simply too clever, and it requires a paradigm shift or two for it to make sense to people. People don’t want to (or can’t) be spending that amount of time trying to figure out something they don’t understand they need.
How about, instead, a quick list of typical problems people struggle with (identity management, epistemology, knowledge management, multiple and / or variety naming conventions, object representation, relational spaghetti, and on and on; tick the boxes, and explain simply what the *alternative* to a Topic Maps solution might cost in time, resources and effort. One could use Topic Maps for identity management in a centralized tool (but can be fully distributed), or get Shiboleth and a Java stack and a few other tools up and running, compare the two systems in terms of *what you wanted to do* and what problems they solve (and not everything else around it), and I suspect things will be pretty obvious.
And even *then* you have the problem of it not being made by a big company with tons of support. Libraries are notorious for wanting big companies to support them (although a few librarians are piping up these these and complain about their current levels of actual support, but I doubt they’ll make much of a dent).
I could write (and have done) tons on these topics, and to be frank, the library world’s ‘reject’ of Topic Maps was one of the main reason I left that world; after fighting the good fight for many years I got depressed at how short-sighted one of the longest standing institutions of the world really were.
Comment by Alexander Johannesen — April 15, 2010 @ 7:07 pm
I think the same answer, albeit different aspects of it, works for both Marijane’s and Alexander’s comments.
I need to do a longer post on this but here is the short version:
What are topics, associations and occurrences? Careful, remember that as we said in the TMDM, a subject can be anything anyone wants to talk about.
Yes, those are syntactic and data model artifacts (1/4 point for the obvious answer), but those are also subjects. Yes?
And if those are subjects, that can be identified, we map representatives of the same subjects, perhaps in different representations, together?
The problem with Michael’s Prolog, SQL, XML, is that components are second class citizens, that is there is no way to identify the subjects they represent. So in any of those paradigms, you can either use my second class citizens or you can get your own. (Which is why IT keeps selling the convert to the “new syntax” approach time after time. Why people keep falling for it is a different question.)
The paradigm shift that Alexander alludes to that there are no permanent second class citizens, simply those we choose to not endow with subject identity properties.
As I said, I need to do a longer post on this issue but perhaps that helps just a little.
BTW, on the issue of major vendor support. There are any number of open source projects. But let me hasten to add that I would not object to library vendors, who really need to do better than they do, to incorporating topic map thinking in their products.
Rather than policy arguments, I think we need simple topic map facts on the ground to sell topic maps.
Comment by Patrick Durusau — April 15, 2010 @ 8:28 pm