Why rewrite EATS using Topic Maps?

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.

5 thoughts on “Why rewrite EATS using Topic Maps?

  1. Hi Jamie,

    This sounds very promising and I’m looking forward to try it out at some point 🙂 Thinking from an RMMA‘s perspective (which, for who doesn’t know, is currently based on EATS), having authorities as entities would be very helpful, because authorities can be secondary sources as well as scholars entering their own findings. Having the possibility to describe properties about them will be more expressive and will allow more filtering options.
    But what interests me the most is the possibility of merging entities. While I understand how this could work smoothly when merging two EATS systems with the same entity but different authorities, I wonder how that would work when there is a disagreement amongst authorities. Ideally RMMA will be a growing database with “screenshots” or releases from time to time. Suppose for example that a first public release happens in May 2012 with Authority A -> Entity A and Authortiy A -> Entity B (let’s assume that -> means “makes assertion”).
    Then the database keeps growing and in May 2013 we release a new public version (while keeping the other one still searchable). By the time of the new release, the data has changed: Authority B -> Entity A = Entity B.
    Merging the data of the two entities would somehow hide Authority A’s assertion that Entity A != Entity B. A solution for this in the current EATS system could be adding a relationship between the two entities called something like “same as”. Authority B could then assert that A –same as–> B. Would the topic maps allow to make this more expressive? Or would a solution like this one be necessary?

    1. An authority asserting that two entities are the same would result in a merge of those two entities iff all other authorities asserting something about that entity made the same equality assertion.

      So, a little nicer than the current situation, but I haven’t thought of a panacea to the basic issue that authorities may not agree on anything about entities, so there will be occasions when two entities must be treated as distinct for the benefit of one authority, even if another authority considers the two entities the same.

      As far as being more expressive, relationships are another piece of information that can be treated as an entity in its own right, through reification. So you could give multiple names to the relationship, etc. I’m not sure if there are many use cases for this, but it will be there.

  2. hey Jamie, interesting work, keep it up! I don’t know much about either EATS or topic maps, so I’m waiting for some detailed how-to on the django-tmapi project page to get started 🙂

    One question: when you say you’re django-ing the topic maps creation process, are you actually rewriting Django’s ORM APIs so to accommodate a topic map-ish back end? Or is it an import-export mechanism? (apologies in advance if I’ve misunderstood completely your work!)

    1. Hopefully you won’t be waiting too long for some documentation on the django-tmapi project page – but I am more concerned about EATS than making it easy to use that for other TM projects.

      I’m not rewriting Django’s ORM, I’m just implementing the Topic Maps API in Django – so there are Django models for Topic, Association, etc, and the API (implemented mostly as model methods) uses the ORM to interact with the database.

      One thing that this means for EATS is that it now has an abstracted back end, so you could keep it as a Django app but use a different TMAPI implementation instead. It would be a little work to integrate (I don’t know of another TMAPI implementation in Python), but it would be possible (particularly with Jython).

Leave a Reply

Your email address will not be published. Required fields are marked *