If you follow me on Twitter, you may have noticed that I’ve been very quiet over the last year: I haven’t really been able to face social media since the pandemic started. But when I have tweeted, it’s usually been about conferences – and I’ve been making much of something called EODEM. This post is to explain what EODEM is, and why I think it’s important.
A framework that will enable museum databases to export objects’ data from one system at the press of a button, and import the data into another system at the press of a button.
Why is this important? Put simply, we hope that EODEM will save people time. In a normal year, museum staff manually copy the details of thousands of objects from their databases, and send them to other museums that wish to borrow those objects. The borrowing museums’ staff then manually copy those details back into their own systems. For example, where I work – the National Gallery in London – we estimate that our exhibitions team have, over the ten years from 2010 to 2019, spent between 16 and 22 days a year entering data for exhibition loans into our collection database. At a total of somewhere between 164 and 224 days, as a worst case, that’s an entire working year over the last ten years spent on data entry. And those figures ignore the work done providing information for loans out.
The fundamental problem is that there are many, many different collections management systems used in museums and, although many of them are compatible with standards like Spectrum, they all organise data in their underlying databases in different ways; and this means that they are very bad at communicating with each other. We hope that EODEM will make it much easier to move data between systems by establishing a fixed format in which the data can be transferred, which in turn means that vendors only need to create one mapping to their underlying database in order to import the data.
Transferring data using EODEM should work like this:
- We start with an object which has been requested for loan, and which has been
- Recorded in the lender’s collections management system (CMS)
- The lender opens their CMS and finds the object’s record
- They press an ‘EODEM export’ button in their system
- The system creates an EODEM file
- The lender emails the EODEM file to the borrower
- The borrower receives the email and saves the EODEM file
- They open their CMS
- They press an ‘EODEM import’ button
- The borrowed object’s data is now stored in their CMS – without having to be cut-and-pasted or (worse) typed in by hand
As I said, EODEM is one of the CIDOC DSWG‘s activities. Norbert Kanter, one of the directors at Zetcom, had been arguing for such a system for some years; I became involved through a conversation with Norbert and Jonathan Whitson Cloud, co-chair of the DSWG, at the CIDOC annual conference in 2016. Since then, we’ve gradually moved the project on, with meetings and workshops at subsequent CIDOC conferences – many of them ably facilitated by the DSWG’s other co-chair, Maija Ekosaari. It’s being managed by an informal working group of interested parties: CIDOC members, software vendors and standards bodies; my role has been to coordinate meetings and paperwork.
For the standards-minded among you, we’re implementing EODEM as a profile (a version that requires certain data values in certain fields) of the existing LIDO standard for exchanging museum object data.
If this has piqued your interest in EODEM, then I’m maintaining a temporary page of resources on this site, which contains more information, and links to the draft standard – if you have any questions that aren’t answered there, please drop me a line via the comments section below or the contact page. If it’s going to take off, then EODEM needs to be implemented by a critical mass of software vendors – so if you work in a museum and you think you or your colleagues would find it useful, please speak to the company who supplies your collections management system, and ask them to join in and implement it!
In the meantime, I’ll try and post updates on this site as the project moves on.
- It’s also been expanded as ‘Exhibition Object Data Exchange Mechanism‘, which emphasises the project’s practical nature, but we decided recently to describe it once-and-for-all as a model. [↩]