museum-digital:musdb has supported EODEM since February. But the usefulness of a standard is determined by how widely it is adopted. Thankfully, there is now a second collection management system to implement EODEM: Zetcom’s museumPlus.

You can learn more about EODEM on the project’s website. See also the very insightful notes from the project’s co-coordinator Rupert Shepherd.

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.

To allow administrators and users to get acquainted with the updated design and new features ahead of time, a preview follows below. The update will be distributed on January 11th.

A slight redesign

Sometime in late 2020 or early 2021 – when the reworked dashboard was released – we introduced a new, different design to musdb. While the old design had sidebars with a margin to the window border, the dashboard’s sidebar goes all the way to the windows left end. Where the old design positioned all page contents (minus sidebars and navigation) directly on the background, the dashboard features clearly defined boxes for each section of a page.

Bit by bit, pages that had undergone major updates (e.g. the institution-wide settings page and the image editing page) or were newly added altogether (task management; calendar) also received the new page layout. That way, we could slowly phase in the new design and hopefully managed to warm up users to what musdb would look like in the future.

But keeping two different page layouts side by side also comes at the cost of a harder maintenance and (obviously) a less consistent user experience. With the update, the “new” page layout will hence be extended to all pages.

A few additional improvements beyond even what the dashboard suggested have been made however. Sidebars are now used for displaying additional, directly usable information gained from a given entity’s data much more frequently (e.g. a copy-pastable address block of a contact is now displayed on the contact / address book page). And sidebars of editing pages now (almost) always come with an indicator displaying where the user currently is (“collection”) and the ID of the given entity. This hopefully allows users to better reference the entities down the line – especially when integrating musdb with other applications like Nextcloud (see below).

The clearly distinguishable boxes for each section of a page are now also used on pages for adding or updating entities. Again, to allow users a quicker grasp of where they actually are, these pages also come with much more visible headlines.

In other news …

In November 2022 we introduced maps on which the location of a museum or an object’s closer, unnamed location (e.g. a finding spot of archeological objects) could be determined by a simple click on the map. The colleagues from Baden-Württemberg requested to be able to enter geo-coordinates directly into an input field that interacts with the map, as they already know the coordinates they were to select. The maps thus now come with a button on the top right that allows the user to open a dialogue, in which the location can be entered using pastable geo-coordinates.

User-Defined Reports in musdb

Thus far reports in musdb were exclusively pre-written and provided together with the rest of the software. But in the end, museums are often bound by local regulations or already have forms or reports that may be generally used for a given purpose. Users can now define templates for report formats themselves and generate reports based on a search result, an exhibition (and its objects) or a loan (and its objects) independently. This may e.g. be used for automatically generating loan contracts.

To define a report format, one needs to hold the user role “museum director” and navigate to the institution-wide settings page. At the bottom of the page, one can upload a report template with placeholders marking the spots where object information is to be filled in by the system.

To simplify the implementation and improve security on the server side, only plain-text reports may be uploaded. HTML may be the most useful format for textual information with formatting; CSV for tabular information.

Timed Generation of Reports and Exports

One feature that was often requested, but thus far hard to implement, is to enable museums to generate exports automatically and without user input. This is now possible, both for XML reports and the new custom report formats.

Timed reports and exports are configurable on the institution-wide settings page. Each timed report requires the setting of:

• a start date (when should the first report be sent?)
• an interval (weekly, monthly, annual)
• a selector; usually a search query, written in the query language for searching objects
• mail address of a recipient

Note: As musdb is used by many museums together, we had to set some limitation on this feature. If an export file size exceeds 10 MB (which is also a size that many mail servers simply would deny for attachments), the configuration for the automatic report is automatically removed and a warning mail is sent to the recipient.

Literature entries

Probably the aspect of musdb with the most requests for improvements is the handling of literature entries. Almost any request for making literature entries interoperable with other software (e.g. Zotero for bibliography management or library catalogues) essentially requires a field for defining the type of a given literature entry. The same goes for most common citation standards: Within a citation style, the way of citing for books differs from that for articles, for webpages, or for archival material.

We have now added that rather essential field and – as that is possible using the new field – display a BibTeX representation of the literature entry in the new sidebar of literature pages.

User-specific defaults for adding new Objects

Museums have specializations, and so do people. It’s not rare for people to almost always enter objects of e.g. a given object type, especially if they are working within the context of a project focusing on a given collection (“Digitize all paintings of the museum”). Similarly, all users in the museum likely use the same units for values and measurements of objects.

To speed up the data entry in the case of such fields with unchanging contents, users will now be able set default values for “direct” text fields of an object. Unfortunately, setting defaults for links [e.g. to collections or spaces] and repeatable fields is much harder to implement and not yet covered by this update. Default values for the form for adding new objects can be set in the personal settings.

Take note that defaults can only be set for fields that are displayed on the object addition page. The most basic and generally required fields aside, one can determine which fields are available on the object addition page in the institution-wide settings.

Loans

To be able to better represent the process of a loan in a museum – from the request to the discussion with insurers to the final sending of the objects – we have now added a concise but hopefully reasonably complete checklist of the steps a loan takes within a museum in the sidebar of the loans page. The checklist covers the most common steps within a loan lifecycle and allows simply marking a progress in working on the loan. The last user to update a given entry in the checklist is displayed if a field has been updated at one point to allow following the progress later on.

We were also notified of a very obvious, but thus far overlooked case: Loan requests that are denied. We added the missing field to cover this status of a loan.

Finally, it is now possible to links loans to exhibitions. All loans of an exhibition can be listed together on a tab of the respective exhibition page.

To return to the checklist for a moment: One of the more noteworthy selectable points in the loan checklist is “metadata exchanged”. Adding this point may be opinionated, but hints at the next steps. In November 2022 we added the option to import loan object information following the upcoming EODEM standard. We hope to be able to implement an EODEM export before the update is pushed to the production instances, so that at least museums using musdb can handle loans with minimal duplicate data entry.

Exhibitions

As mentioned above, loans can now be linked to exhibitions. A new tab on the exhibition page allows listing all loans that happened in the context of the given exhibition.

The list of objects of an exhibition is now also redesigned. When linking an object with an exhibition, it is now possible to enter the exhibition room in which the object will be displayed. If this information has been entered for the objects of an exhibition, the list of objects of that exhibition will be grouped by the objects’ locations.

Integration with Nextcloud

Keeping with the theme of allowing for a deeper integration of musdb into the actual everyday work of museums, we have added the option to integrate musdb with a museum’s Nextcloud instance. If the Nextcloud integration is activated, a new widget will be accessible in the sidebar of most editing pages (e.g. for loans).

This widget displays a reference ID of the entity (e.g. LOA-000000005 for the loan with the ID 5). If this ID is present in a folder or filename on Nextcloud (say, there is a folder for everything concerning the loan, which will then be named something like “2022 Loan Brisbane [LOA-000000005]”), musdb can identify the folder or file as belonging to loan and list it in the widget. If the ID is present in a folder name, the folder contents will be listed in musdb.

For this integration to work, musdb connects to Nextcloud using WebDAV (unfortunately we needed to use some properties exclusive to Nextcloud’s and likely OwnCloud’s WebDAV interfaces, which makes our integration incompatible to other storage solutions that also use WebDAV like Google Drive). And to connect via WebDAV, it needs the information to get an authorized access.

To configure the Nextcloud integration, one hence first has to set the base URL to an institution’s Nextcloud instance on the institution-wide settings page. This only has to be done once per institution and simply gives musdb the information necessary to locate the Nextcloud instance.
Once a base URL for the Nextcloud instance has been entered, the username and password for Nextcloud (ideally an app token [can be generated in Settings > Security in Nextcloud]) can be entered on the personal settings page in musdb. Once those are entered, the Nextcloud integration is activated.

Institution and contacts pages

The layout aside, institution and contacts pages have only been minimally changed. A simple but maybe useful small widget has however been added in the sidebars of these pages: An address block to quickly copy-paste the address to e.g. a letter head.

Objects

Finally: Objects. Objects have seen the addition of a lot of new fields, mainly for administrative purposes.

On the “administration” tab of object pages, one can now reserve an object. If an object is currently reserved or will be so in the next week, an indicator will appear in the sidebar.

For logging an object’s history within the museum, we added a number of logs for:

• Damages to an object (Tab: “Restoration”)
• Conservation and restoration treatments for an object (Tab: “Restoration”)
• Scheduled Checks (Tab: Administration). These checks cover e.g. condition checks, but also audits of whether the object information in musdb is complete. This section comes with a notification that can be sent if a check is upcoming.

Deaccessions can similarly now be covered in musdb.

Again reaching for the most practical applications, we have finally implemented linking an object’s actual / permanent location as a “space” rather than simply identifying it using a text field. This way, it is now possible to search for objects that are not currently in the location their expected permanent location.

We also added some simple text fields that are often present in imports and suggested by the Canadian Heritage Information Network’s software requirements checklist. Namely: sex of the object (for biological specimen), the color of the object, and form of the object.

Post image: Courtesy NASA/JPL-Caltech.