Materializable and Non-Materializable Topic Maps

Map resources like the files above are all representable as a whole in memory. The maps might be big, but there is no conceptual limitation to load the map into memory. It just takes time to load or save the content. A strict synchronization of the file content with what we operate on in memory is not so much an issue, usually. This is not true for all resources, especially not for the really interesting ones.

Take, for instance, a relational database which, say, holds information about employees. It is pretty straightforward to translate the information in this database into topics and associations, it may even be possible to convert the whole database into a topic map and perform some clever operations on that which would not be so simple with SQL. Most content in such databases, though, is constantly changed, any derived copy as topic map would be potentially obsolete at the end of the conversion process. So the resource is defacto not materializable as map.

Another example is the global domain name service (DNS). It holds - among other things - information about machine names and their IP addresses. By itself, there is no big problem to represent this information as topics and associations and to load any fraction of the DNS database into memory. But as the attribute 'global' insinuates, the data stored there is pretty massive. And it is highly distributed to avoid bottlenecks and improve scalability in respect to the number of clients. It may make not much sense to 'materialize' a current snapshot of the global DNS into a map.