Thinking of ways that topic maps are the same or different from other information technologies.
Your Data: I think all information technologies would claim to handle your data. Some focus more on structured data that others but in general, all handle “your data.”
Your Model: This is where topic maps and key/value stores depart from the Semantic Web.
You don’t get “your model” with the Semantic Web, you get a prefab logical model.
Contrast that with topic map where you can have FOL (first order logic), SOL (second order logic) or any other logic or non-logic you choose to have. It’s your model and it operates as you think it should. Could even be: “go ask Steve” for some operations.
The Semantic Web types will protest not using their model means your data won’t work with their software. Which is one of their main reasons for touting their model. It works with their software.
Personally I prefer models that fit my use cases. As opposed to models whose first requirement is to work on a particular class of software.
Guess it depends on whether you want to further the well being of Semantic Web software developers or your own.
Your Vocabulary: Another point where topic maps and key/value stores depart from the Semantic Web.
The vocabulary you choose for your model is your own.
Which is very likely to be more familiar and you can apply it more accurately.
How do topic maps differ from key/value stores?
Two things come to mind. First, topic maps have inherent machinery for the representation of relationships between subjects.
Not that you could not do that with a key/value store but in some sense a key/value store is more primitive than a topic map. You would have to build up such structures for yourself.
Second, “as is,” key/value stores (at least the ones I have seen, which isn’t all of them), don’t have a well developed notion of subject identity.
That is keys and values are both treated as primitives. If your key and my key aren’t the same, then they must be different. Or if they are the same, then they must be the same thing. Same for values.
That may not be a disadvantage in some cases where information aggregation or merging isn’t a requirement. But it is becoming harder and harder to think of use cases where aggregation/merging isn’t ever going to be an issue.
I need to cover issues like the differences between topic maps and key/value stores more fully.
Would you be interested in longer pieces that could eventually form a book on topic maps?
Perhaps even by subscription?
I’d love to read more on Topic Maps. I work in publishing and the confused obsession with RDF is driving me crazy. It’s a pity the tool support is weak.
Comment by bobber — March 27, 2013 @ 3:28 pm
What would be the top uses you see for topic maps in publishing? It would help get me away from the theory side if I knew what is important to others.
Comment by Patrick Durusau — March 28, 2013 @ 6:26 pm