NULL in Topic Maps

<< 2006-07-08 19:42 >>

One point on which Topic Maps differ from most other information representations is the handling of unknown or missing information. In relational databases these are represented using the special NULL value, and the same is the case in object-oriented programming. In XML there are different ways to approach this issue, one of which is the xsi:nil attribute.

Missing information

So how would we represent this in Topic Maps? Let's start with the case of missing information. By this I mean not information that exists, but which the person building the topic map does not have; I mean information that the ontology says might apply to topics of a particular type, but which for some of the topics just does not exist. (If this isn't clear, the example below will probably clear it up.)

The Italian Opera Topic Map has two occurrence types date-of-birth and date-of-death for person topics. How would we handle the case of a person who has been born but not (yet) died? One could think of several possibilities, but the only one I've ever seen is to simply leave the date-of-death occurrence out. This corresponds neatly to the common-sense notion that the person quite simply does not have a date of death. There is thus no need for a NULL value in Topic Maps.

The same applies with associations. In the Italian Opera Topic Map you also find place-of-birth and place-of-death associations. Obviously, if the person has not died yet there is no place of death, and consequently no association of that type.

Unknown information

Unknown information is where the information exists, but the person creating the topic map does not have it. As an example, imagine a person whose date of birth we don't know. Since the person exists there must be a date on which the person was born, but we don't know what it is. This case is actually harder to handle cleanly than the other one, since in this case leaving out the occurrence suggests that there is no date of birth, but this is wrong. So in this case there might actually be a use for a kind of NULL or UNKNOWN value, but no standardized such value exists in Topic Maps today.

For associations the problem is even worse, since here we must have a topic to represent the unknown place of birth. There are several different possible ways to handle this:

1. Define a separate "Unknown" topic for each such case. This is cumbersome, but provides a way to state what is known about each unknown topic, and to distinguish which unknowns are known to be the same, and which are thought to be different.
2. Define a PSI for the unknown topic. This will always be used whenever the associated topic is unknown. The trouble with this is that it will have to be an instance of all types in order to avoid validation problems, and this is unlikely to be allowed. So for this to be workable an exception will have to be made for this particular topic from the ordinary validation rules.
3. Define one unknown topic for each topic type. This seems like an awkward compromise, especially as it may sometimes be hard to decide which types in a type hierarchy to make unknown topics for. And imagine that you only know that the person was born in a building of some type, but the building topic type is abstract, because all instances of it are actually instances of some more specific subtype. Clearly, this approach, too, leads to problems.

Another problem common to approaches 2 and 3 is that, again unless special rules are defined for these topics, they imply that everyone whose place of birth we don't know was born in the same place. So overall approach 1 seems best.

Why this difference

I find the question of why Topic Maps differ from the relational and object-oriented models on this point to be interesting, although the answer is actually kind of obvious. In the relational and object-oriented models the physical storage of data follows the schema, which means that if you define a place-of-birth column there is going to be a space set aside in each record for this information, and so you are forced to put something there, even if that something may turn out to be NULL.

In Topic Maps, as in XML, the schema is something that exists independently of how the data is stored, but against which the data may be validated at need. This means that the same problem with the predefined storage position for each data item does not exist, and so one is not forced to come up with a NULL value.

Similar posts

Comments

Add a comment