EODEM – FAQ
An EODEM file may contain sensitive information about one or more museum objects: valuations, security requirements, installation methods, etc. How can I make sure this information isn’t intercepted when I send it to a borrower?
At the moment, this information is routinely transferred between borrowers and lenders in relatively insecure formats, i.e. as unencrypted email messages or in unencrypted files attached to email messages. EODEM doesn’t mandate a transport mechanism, and has been created with the assumption that data will continue to be emailed – in other words, it would use the same level of security as is currently used by most museums. If you are concerned about the security of your data, we suggest that you wrap the EODEM files in a password-protected ZIP archive before transfer, and send the password to the borrower using a different channel from the one used to send the data.
What can I do to get ready for EODEM?
Make sure your data is good and rich (and ideally tidy – your borrowers will thank you); and start speaking to your collections management system vendor about how they will incorporate EODEM into their system. (Showing them this resources page would be a good place to start.) For the system to be useful, it needs a critical mass of vendors to offer it. We will publicise it and support vendors who want to implement it; but it needs you to demand that your software suppliers incorporate it into their systems.
How would EODEM deal with the quite complicated data that can be required when installing contemporary art?
This would go as a chunk of text in the ‘installation instructions’ unit of information.
For museums and developers
How is EODEM data transferred between lender and borrower?
EODEM data for transfer will comprise an XML file containing the actual information, and can include one or more accompanying image files. The EODEM standard does not mandate particular methods of transport (FTP, email, DropBox, etc.) Neither does it restrict the additional processing of files either before or after transfer – e.g. assembling XML and image files into a single ZIP archive prior to transfer. However, EODEM importers must be presented with a single folder containing the files listed above.
Is it a requirement that all the data within the EODEM standard can be exported from / imported into a given collections management system, or could a system export / import, say, only object ‘tombstone’ data?
We work on the principle that something is better than nothing, so our basic requirements are minimal (and in part dictated by LIDO). The only units of information we require are the following:
- LIDO Record ID*
- LIDO Application Profile*
- Object Type Keyword
- Title/Name group
- Lender Name*
- Object Identifier
- Local Record ID*
- LIDO Record Type*
- Export Date/Timestamp*
and the ones with an asterisk are likely to be system fields, or added on export. Beyond that, system vendors can implement as much or as little as they like – and their systems can manage. But the more EODEM data that a system can handle, the better it will be for their users.
How does EODEM handle different languages?
It doesn’t: it assumes that data is exported in the language in which the lender’s system holds it. However, LIDO requires that an record’s base language is specified, and allows for the identification of different languages at any point in the record, and using this would be a kindness to those receiving data.
Does EODEM data that I’ve received from a lender need to be tidied before import, for example to reconcile disparate termlists? How will these be reconciled?
No, it doesn’t. Initially, most users should assume they’ll be receiving strings of text rather than reconciled vocabulary terms, and that reconciliation will probably be a manual job post-import: that’s still better than no data at all. It will be up to individual vendors how many reconciliation tools they offer alongside EODEM – but any vendor who offers such tools will find that their clients are very grateful. Hopefully some of their current tools for reconciliation on data import, or authority deduplication, can be leveraged for this. LIDO does allow for linked data references to be provided alongside text data, so these could be used in the future as aids to deduplication.
Which is preferable: exporting structured data, or unstructured strings?
We don’t want to mandate either; but if you can export as structured data, it would be kind to also export a string for those systems which cannot import structured data.
How long does it take to implement an EODEM exporter / importer?
How long is a piece of string? It depends upon your system architecture, and particularly whether you’ve already mapped your data to LIDO for export or import. The complicated thing will be mapping each individual unit of information to its correct destination in the database. As EODEM uses LIDO for its data model, then, if you’ve already mapped your data to LIDO, it should be quite straightforward.
For MuseumPlus, which already has LIDO mappings in place, it took a few weeks, not working full time, to implement both exporter and importer – as well as updating the mappings from LIDO version 1.0 to 1.1. For other systems, we estimate one to two weeks of development time, depending on what’s already in place.
But you might want to bear in mind:
- Every user will probably need the import and export to be customised for them to some extent, because they’ve customised how they use the system.
- Where will you hold generic information – say lux levels for oil paintings on canvas, which will be the same for many records, and which you (or your users) probably won’t want to enter multiple times for every record?
- EODEM is remarkably tolerant as to what constitutes an acceptable record – you don’t need to implement everything at once.
How can I get involved in the development of EODEM?
By joining our development e-mail list and regular meetings. If you’d like to do this, please get in touch with Rupert Shepherd using the contact page on his website.