On topic types in Topic Maps

<< 2008-01-16 18:13 >>

Mountain hare tracks, Geilo, Norway

A discussion on Svein's blog regarding FreeBase and a comparison of its data model with that of Topic Maps brought up some interesting question regarding Topic Maps that I think are worth discussing.

Multiple types for topics

The first question was whether topics can have more than one type, and the answer is that they definitely can. The topic types do not have to be related by supertype-subtype associations, but can be completely independent. The best-known example of this is in the Italian Opera Topic Map where some topics are both, for example, librettist and playwright. The question of whether this is good modelling has been raised several times, but I'll leave that to one side for now, since the point is that it is definitely legal.

So why is this legal? Well, there are several reasons. One is that Topic Maps were designed from the very beginning to support automatic merging of data, and it's of course entirely possible for the same subject to be typed differently in different topic maps. The most obvious reason why this would happen is if the two topic maps are using different ontologies.

There are also different ways of using topic typing, where not all of them would necessarily have a topic wind up with a single type. The Italian opera example is one example of this, but there are other modelling approaches, too, that could lead to this kind of situation.

Then there is scoping. One could easily imagine a situation where a topic winds up with different types in different scopes, for example because there is disagreement on the correct type. My TMRA 2007 paper on scope describes one such situation.

Finally, there is no strong reason to forbid this. Yes, it may look a bit odd for people used to traditional modelling, but there is nothing inherently wrong with it.

The relationship with schemas

The Bøya glacier, Fjærland, Norway

The other question was what happens to the characteristics that topic types confer on their instances through the schema. In the TMDM itself, this is simple. There is no schema, and if you say that topic A is an instance of type B, well, then that's what you've said, and it has no further consequences (except inferencing through subtyping). Nothing more happens.

In most traditional information technologies, like object-oriented programming or relational databases, the types in the schema define slots which are physically set aside for storage of the data. This is one reason why automatic merging in a relational database is impossible. If you only have a single email column in the person table there's nowhere to put a second email address.

In Topic Maps this is not an issue, since each statement lives a life of its own, completely independent of the existence or non-existence of a schema. It is also independent of the topic(s) it applies to. An occurrence, for example, is not put into a slot on the topic which is allocated by the schema. The occurrence itself knows which topic it's about. Exactly how this is implemented will vary, of course, but the point is that everything is so schema-independent that you're not even required to have a schema.

But what about TMCL?

An interesting question is of course what happens if you do have a TMCL schema, and you say that topic A is an instance of topic types B and C. In general TMCL takes the statement that, say, A is an instance of B to mean that A must conform to all the constraints on B. This includes the implicit constraint that anything that is not explicitly allowed on B is forbidden. (This means that if you give a company a date of birth you get an error since the schema did not allow this.)

So what happens if A is an instance of both B and C? Well, basically, it means that it must conform to the constraints on both, and that anything that is not allowed for one of them is forbidden. And unless it's explicitly stated that a topic may be an instance of both you get an error. So it actually works out quite naturally.

Similar posts

Comments

Add a comment