The success and wide-spread adoption of EODEM however obviously still depends on a number of factors. On the one hand, developers and software vendors need to implement EODEM import and export functionality in their collection management systems. On the other hand, this implementation needs to be accessible and simple to use.

musdb, again, has had the first condition covered for some months now. Accessibility – especially for smaller museums with less tech-savvy staff – was lacking however. Over the last months, it has improved a lot. It is thus now possible to both export and import EODEM data without having to use specialized software beyond one’s file manager and browser.

Exporting EODEM data

The exporting of EODEM data for loans has been described before and remains as simple as ever. Simply link the objects with the outgoing loan and use the respective export option on the loan editing page of the outgoing loan.

The Problem of Flexible Imports

museum-digital’s import tool offers a rather wide range of selectable “parsers” (essentially the format of data to import) and settings for many of these. It may be used for importing five objects at a time without any linked image files – or 50000 with remote image files to fetch. While the former import will be finished in seconds, the latter may take hours depending on the speed of the remote image server.

To prevent timeouts and allow users to control the importer to its full flexibility, and to allow for an easy automation, the upload workflow works via a WebDAV mount. Here, the import is configured using a plain text configuration file and the import data can be uploaded into respective folders for metadata and media files. Finally, a script checks every four hours, if there are import data in the respective directory for a museum and imports them in the background. This process works wonderfully for large imports and migrations. It is however anything but accessible for small scale imports.

Since EODEM imports follow a pre-defined standard and have a rather narrow use case, we chose to add a direct upload form for EODEM import data on the loan editing page in musdb. The sidebar of that page now features a new box “Import EODEM data”. By clicking on it, an overlay opens, prompting the user to upload their EODEM XML files. The XML files are then uploaded into the usual import directory for the museum and the configuration is automatically written with the common settings for EODEM imports.

The upload box in the sidebar is now updated and presents a message detailing the remaining workflow: Wait for some time until the import data has been processed. After the import has been finished, the user receives a mail to the mail address entered for their musdb account.

Looking at the imported object data, one may see a small new feature. The importer automatically determines whether it should update or add new objects by way of the inventory number. If two museums then use the same inventory number schema, this may lead to the loan object information overwriting the data of another object in the museum. To prevent such cases – rare as they may be – the ID of the loan is automatically prepended to the loan object’s inventory number.

EODEM imports can thus now be done directly from the web interface and with minimal worry about data loss. The only caveat may be, that EODEM imports done this way don’t support the import of object images, as this would have required an additional setting to determine if the images were sent together with the import metadata, are located on a web-accessible server, or if they are simply missing.

A Glimpse into the Future

musdb now covers both conditions – EODEM imports and exports are not only implemented and usable anymore, but they are hopefully very easy to use now as well. The EODEM working group remains close to a release of the final standard, and other implementations are announced for the upcoming versions of some other collection management systems.

It is likely that testing the EODEM import with real-world data from other systems will require some further adjustments despite all standardization. We’re looking forward to such cases and more users for the EODEM standard both in terms of vendors supporting it and actual museums profiting from it.

On the other hand, it’s a very clearly defined situation, that is repeated again and again in a very similar pattern. Which is to say, it is a perfect subject for automation.

Now, some years ago, a working group came together in the context of CIDOC to do exactly that. Since not all museums use the same collection management system, the necessary first step towards automating the exchange of object information was obviously to develop an open standard for the same, that could be implemented in the different collection management applications.

The standard thus developed – EODEM, short for Exhibition Object Digital Exchange Model – is now mature enough to have gone into a public beta release phase. We’re very, very late to the party, but it was time to try our hands on implementing an import and export for EODEM. The import had already been done by November, but by the time of the larger update and re-design of January, we also managed to release an EODEM export.

This blog post will continue explaining how to import and export EODEM data before closing on a general perspective on the usefulness of EODEM at this point in time and in the foreseeable future.

How to Use EODEM in musdb?

As with loans in general, there are two situations in which one might want to use EODEM. The receiving museum can save a lot of time by importing EODEM data, while the sending museum can help out colleagues by exporting it.

Importing EODEM data

In the (German language) handbook, one can read a lengthy explanation of how to import object data into musdb (a less extensive description can be found in the blog as well, this time in English). In short: One first needs to generate a password to access the import folder using a WebDAV client. After mounting the folder, one can proceed to upload the data. Finally, a configuration file needs to be written to enable the import tool to identify the format of the import data, a mail address which is to be notified when the import is done etc. As the server checks all museums’ import directories for available import data every four hours, the object information will then be automatically imported after some time.

EODEM was developed as an application profile for LIDO 1.1, meaning that it builds upon and extends the LIDO standard for exchanging object information. As such, we could simply integrate EODEM into our regular LIDO import. Hence, users who want to import EODEM data need to set the “parser” setting to “Lido” in the configuration file.

Depending on the way a museum forms its inventory numbers, EODEM however may present a problem regular LIDO imports do not. If an inventory number in the sending museum (say, in the import data) equals an inventory number of one of the receiving museum’s own objects, the importer would interpret the duplicate inventory number so as to update the existing record of the inventory number rather than adding a new one. In response to this problem, we added a new setting available in the LIDO parser: prefix_inventory_numbers . By entering a value (e.g. the reference number of the loan) to this setting, the given value will be prefixed to the imported inventory number so as to prevent collisions and allow importing objects safely.

Exporting EODEM data

EODEM data can be exported from musdb the same way any other XML export can be run. It is now listed as an additional export format in the regular export form. The export form is accessible either through the navigation for exporting the whole collection – which obviously makes little sense in the case of EODEM – or on the search results page once at least one search parameter is set. One can thus filter the collection for all objects of a given loan, click the export button in the sidebar, possibly adjust the list of exported fields (e.g. to exclude a field one does not actually want to export, but which is usually covered by the EODEM export). Finally, one will receive a ZIP file containing the EODEM-encoded object information. This ZIP can then be sent to the receiving museum.

To both promote and simplify the exchange of loan object information using EODEM, a shortcut has been added in the sidebar of loan editing pages. Clicking on “Objects (EODEM)” in the export section of the sidebar directly takes one to the EODEM export settings page for all objects of the given loan.

In musdb and Beyond

As stated above, we were very late to the party. EODEM has been in development for some years, but we only started seriously looking into it in late 2022 (all credit for developing EODEM thus goes to others; the working group deserves a lot of thanks!).

On the other hand, it turns out that musdb is the first collection management system to actually feature an EODEM import and export in production. For the time being, exchanging EODEM information thus mainly helps in the case of loans between two museums that both use musdb for collection management.

The working group’s page however provides a list of software vendors who plan to implement EODEM imports and / or exports. Many of the big names are already listed there, meaning that a timely implementation of the standard in many of the major collection management systems is almost given.

On the other hand, there are many, many more collection management systems than those ten listed at the time. While EODEM is based on LIDO and thus very simple to implement if a collection management system already features a LIDO import / export, it remains to be seen how many will eventually adopt the it. Hopefully it is many, so that we can improve interoperability and soon enough all save some time when working with loan objects.

Image credit: “Relief zweier sich die Hände reichenden Männer, Seebronn (?)“, CC BY-SA @ Landesmuseum Württemberg

This content is licensed under a Creative Commons Attribution 4.0 International license.

The main visible new addition to the page is a button for exporting all available columns of the page to a spreadsheet. It can be found in the top menu, just to the right of the usual button for exporting all currently selected columns to a spreadsheet.

While implementing the button, we ran into two roadblocks. First, we realized, that thus far it had only been possible to export tables with up to 26 columns (since PHPSpreadsheet, like Excel, names columns as A-Z, and begins at AA after). We fixed this bug and soon ran into a performance problem. While most of musdb had been optimized strongly for an improved performance in 2018, the “list results” function had not. Large selections of objects to list thus came to the limits of resources we allow the script to use. Through optimizations of the run database queries, we fixed this problem as well and made the tool much more performant overall. A nice side effect of these reworked database queries is that the list can now also be properly sorted by actors and places.

Next, we worked on improving the user interface a bit. On the one hand, the selection menus for changing which columns are to be displayed are now shown as table headings in their respective column. On the other, tables with more than 10 columns are now horizontally scrollable.

Finally, we added keywords to the list of object information that can be listed using the “list results” tool.

This content is licensed under a Creative Commons Attribution 4.0 International license.