Why Topic Maps? (or schema version n.0)

A friend of mine forwarded one of the nay-sayer screeds bashing NoSQL implementations in favor of one of the current SQL offerings.

Why that sort of thing is popular remains a mystery to me. I freely grant that some of the NoSQL efforts may be unsuccessful but the effort overall is an interesting one.

And not unlike topic maps when you think about it.

In order to do normalization for a relational database, you have to both know all the subjects you are going to talk about in the database in advance and, more importantly, know how you are going to identify them.

(Yes, there are other, deeper semantic issues with relational databases but this post is for newbies so I won’t cover those here.)

So, what happens if you don’t know all the subjects in advance, how you are going to identify them or even what you want to say about them?

Well, with a relational database, I suppose that is what you can version 2.0 of your database schema, to which you migrate all your data.

And the same is true for relationships between subjects in your database.

Should you decide to add tables for those relationships, well, now you are at version 3.0 of your database schema.

Database versioning or “evolution” I think it is sometimes called, is an entire area of research and software in the database world. I really need to pull some of that together for a piece on how topic maps can help with the documentation aspects of that process.

I started to say that illustrates an advantage of topic maps over relational databases, that the schema does not have to be altered to add new relationships.

And from a certain point of view, it certainly is an advantage.

But, assume we do add a relationship type to a topic map, how do we then version the topic map?

Should we create topics that exist in associations with other topics to add versioning information as part of associations?

Or are there other mechanisms we should consider?

Sorry, did not mean to get side tracked into versioning but it is something that production quality topic maps should take into account.

I don’t think the choices are nearly as stark as SQL vs. NoSQL vs. Topic Maps vs. whatever.

Most information systems have needs that can be meet only with a healthy mixture of solutions.

People who advocate “myStack” solutions are selling just that “myStack” solutions.

As a user/consumer, I prefer “mySolution” stacks. Not exactly the same thing.

Comments are closed.