For museums

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.

What should a museum do to implement EODEM?
This is really a question for collections management system (CMS) vendors, who will need to do the technical work. But a museum could help this by making sure that it has good data in the CMS fields which are exported to / imported from LIDO, and set up standards for their use if necessary. It’s important to remember that LIDO is a comparatively open standard, and so mapping your data to it can be complex; but EODEM has done all the hard work and provides very precise instructions for how individual data are mapped into an EODEM LIDO record, so EODEM is much easier to implement than a more generic LIDO record.

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.

Does EODEM enable a borrower to send data back to a lender, for example about a change in condition or a damage or loss?
No, but this might be worth considering in subsequent versions.

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*
• Record Language*
• Object Type Keyword
• Title Type
• Title/Name
• Title Language
• Lender Name*
• Object Identifier
• Local Record ID*
• LIDO Record Type Identifier*
• LIDO Record Type Keyword*
• Export Date/Timestamp*

and the ones with an asterisk (and quite possibly Title Type and Title Language, too) 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 a record’s base language is specified, as well as allowing for the export of the same record in multiple languages. Within a record, it only allows for the identification of different languages for titles/names.

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.

How can a LIDO record, which requires the use of Linked Data identifiers, be created if a collection does not record links to AAT, ULAN, etc.?
There are two kinds of identifier used in an EODEM record:

1. Identifiers as data. In  nearly all cases, these are optional, and need only be exported if the identifiers already exist in the museum’s data.
2. Identifiers which identify the type of data being recorded. These are all pre-defined and provided in the EODEM documentation.

Does EODEM data come with an expiry date, after which it should be removed from systems?
No. This is something to be agreed between borrower and lender. But a borrower may want to retain at least some of the data in perpetuity, as an historical record of the exhibition.

For developers

What support is available whilst I’m implementing EODEM?

1. The EODEM specifications
2. These FAQs
3. A sample EODEM document
4. An online EODEM file viewer
5. A demonstration EODEM XML-to-CSV XSL template and accompanying examples (to follow)
6. Email support: eodem-support@googlegroups.com
7. A Slack workspace: https://eodem.slack.com/

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.

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. And the work will be easiest if the database has a fairly static data structure, and no configuration is necessary for individual clients.

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 does an importer recognise data that is already in the system? More importantly, how can it differentiate between two similar records from different lenders – two institutions could share the same object number or a local record ID.
Using an Object Identifier (e.g. accession or inventory number) and / or a record ID. LIDO Record ID should comprise both a local key value and a prefix for the data creator, which should render identifiers unique. Checking both local identifiers and record IDs should also help ensure the uniqueness of records.