There are a few reasons I am rewriting EATS as a Topic Maps application. The first impetus was wanting to have the option of treating some or all of the infrastructural data (such as authorities, entity types, and name types) as entities in the system. As it stands, there is a strict separation between the two: infrastructural data allows one to make statements about entities, but it is not possible to make statements about the infrastructural data.
The most obvious use case here is with authorities. If I am using EATS to keep track of books and publishers, and I myself am a publisher, I will want to be both an authority and an entity, and it would be silly if those two elements are not linked (if not actually the same).
Now, I could easily extend the existing EATS to link these two, and the same for the other pieces of infrastructural data, but it’s hardly an elegant solution. The EATS model is tied directly into the underlying database storage model, making this sort of extension invasive and ugly. By building the EATS model as a topic map, I’m adding in a layer that isolates the EATS view of the world from the specifics of storing the data. This frees me to be able to extend or modify the model arbitrarily.
For example, I want to be able to handle the part of Through the Looking-Glass, and What Alice Found There where the Knight talks about the name of the song being called one thing, while it’s name is another, and the song itself is some third identifier. This is easy to do if, as in a topic map, almost everything is a topic and the EATS system simply needs to be told that a particular topic is typed as an entity, and can therefore be edited and displayed as such. Marvellous!
Another reason for using Topic Maps is that it has a defined procedure for handling automatic merging of topic maps. This is very useful for a system that is all about collecting information from multiple sources. If my EATS system has a record for an entity, and your EATS system has a record for that same entity, it would be great if I could just merge in the information from your record (or all the records from your system) and sort everything out – remove duplicate information, etc. Again, I could implement this in the old EATS, but it would be an EATS-specific thing — I wouldn’t have the benefits of being able to use other people’s code, merge in non-EATS data, and the like.
Finally, in doing this rewrite, I’ve been forced to take a step back and reconsider the application as a whole. This has lead to some insights (authority records are useless, and the way they are used in old EATS is flat out wrong) and refinements (I’m not going to bother with anything other than IRIs as identifiers). In turn, that will simplify usage and hopefully make it easier to interlink EATS systems and whatever they might point to.