• On source / reference pages, linked objects are now sorted by the position within the source work on which they are referenced or which they do themselves reference
• The target URL of the regular / unspecified search bar for objects now follows the new, prettier URL schema
• Support for an OAI-PMH API for object metadata
  • Standardized endpoint for aggregators seeking to retrieve data in batch
  • Metadata formats thus far supported:
    • LIDO
    • OAI-DC (mandatory)
  • See also: Blog
• PDFs are only generated for users with a browser set to a non-default language if load on the server is low
  • The resource use caused by AI bots scraping museum-digital has been growing and growing. Generally, we see bots included in our mission to enable access to cultural heritage. On the other hand, nobody is served if the service is bogged down by bots. One functionality that is commonly used among bots and resource intensive is the generation of PDFs for object pages. The same information can be loaded from the object page itself and printed to a PDF using the browser’s print option. There are thus rather few downsides to limiting access to PDF generation to timmes, when server load is low. So that’s what we did.
• Collection-specific ISIL identifiers are now also used in the LIDO API
• Alternative numbers of an object can now be displayed on object pages
  • This includes tooltips for types of alternative numbers, that can be set by the museum on the institution-wide settings pages of musdb

musdb

• Search for objects
  • Type-ahead search for languages (of the object’s content)
  • Search by object’s revision status (open, read-ony, archived, etc.)
• Batch editing of objects’ revision status
• Parameters of the full text search index were updated to improve the search of word compounds in German

Importer

Core

• The dry-run mode now does not abort an import anymore, if an unmapped value is encountered. Unmapped entries are collected and displayed together afterwards.
  • This means, that unmapped entries can now much more easily be copied to and mapped in concordance.museum-digital.org
• Support for the import of alternative numbers (of objects)
• Support for the import of space hierarchies

Parser

• AdlibXml
  • Support for importing objects’ alternative numbers
• CsvXml
  • Support for importing objects’ alternative numbers
• CsvLocations
  • New parser for csv-based imports of space hierarchies
• ImageByInvno
  • New setting: append_chars (Adds suffixes, that exist in the inventory number, but not in file names)

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

Development

musdb

• Added a tool for the AI-aided detection of displayed subjects in images for tagging
  • Has to be explicitly turned on on a per-collection basis, as it makes sense only for certain types of objects (like paintings, drawings, photographs)
  • Usable within the tagging overlay on object editing pages
  • See also: blog post about the feature (German)
• The maximum length of contents in the data field “edition” of literature entries has been extended to 50 characters
• Uploaded PDFs may now be up to 40 MB large
• New command line option to reset all permissions of a user account to the default provided by their user role
• New event type: “Changed”

nodac

• Added AI-generated suggestions for tag definitions and translations of tag names in a sidebar
  • This is also re-used to identify duplicate tags

Dissemination

• Poster presented at CoRDI 2025 (Archived) on August 27, 2025, in Aachen: “To Educate or to Enforce – The Case for Underhanded Methods to Improve Research Data”
  • PDF
  • Abstract / Zenodo

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

To that end, there have traditionally been two primary ways for data retrieval. In musdb, one could run batch exports and receive a ZIP with some form of XML files. One per object, with the objects matching the results of any given object search.

On the other hand, there is the public API. Using URL manipulation, one can access the (primary) contents of each page in a machine-readable way. To access the JSON representation of an object’s published metadata, where the object’s ID is 7141 in the Hesse instance of museum-digital (URL: https://hessen.museum-digital.de/object/7141), one simply has to insert json to the path: https://hessen.museum-digital.de/json/object/7141.

Next to the default JSON output, additional APIs are offered wherever suitable for a given data type. For objects, the primary additional output method is a LIDO API.

Thus far, the main limitation of the public API was that it only allowed one object (or institution, collection, etc.) to be queried at a time.

Querying Object Metadata in Batches

After a significant refactoring of the code to load object data for object pages – primarily to improve caching and allow for parallelized requests to the database – we are now finally able to offer APIs for querying object metadata in batch. Thanks to grouped database queries, performance and resource usage scale nicely. Taking simply the currently most recent objects in the Germany-wide instance of museum-digital: Loading all object data of one object and presenting it in JSON takes 0.0087 seconds and loading and generating the JSON for the 100 most recent objects takes 0.197 seconds (or 0.00197 per object). Note that not all queries for all aspects of an object’s metadata are grouped yet, performance may thus get even better over time. This does also not yet account for the overhead of the many HTTPs requests one would previously need to execute to get each object’s metadata one by one – real performance improvements are thus even greater.

Now, how to access object metadata in batches?

The batch access is linked with the search API and reuses its main query parameter (“s”). Say, if one is searching for objects related to Berlin (a.k.a. the place of the ID 61), the URL of the respective search page would be https://global.museum-digital.org/objects?s=place%3A61. The corresponding API for retrieving all of the objects’ published metadata would then be https://global.museum-digital.org/export/json/place:61?limit=24&offset=0. Like the search page itself and its primary API (/json/objects), the full batch export API is paginated with a maximum of currently 100 objects per page being returned.

Currently, the batch export of full object metadata is available for JSON and LIDO (XML) representations of the object data. More can rather easily be added later, should a demand arise.

OAI

Implementing a performant way to export full object metadata in bulk was one of the two main missing components for the long-missing implementation of an OAI-PMH API.

OAI is a standard tailored towards data harvesting. Say, an external service like the German Digital Library or Worldcat wants to do something with external data from diverse sources, e.g. to also display objects or implement a search across the different collections / libraries to find which one has which object / book. To be able to do so, they need to be able to access the respective data in some way. Ideally, using a common standard that describes how to query data, helps to identify any data sets that need to be updated or added (or deleted), and finally presents a uniform way to access the data periodically. That, exactly, is OAI-PMH.

In a nutshell: OAI-PMH allows other services to copy all (published) data from another service in a maschine-readable way and can thus significantly improve reuse in aggregation. Of course this only applies to technical questions; legally, potential re-users need to comply with the metadata license applied by the initial data provider regardless of the (technical) means of access.

Since last week, museum-digital now provides a OAI-PMH API at /oai respective to a given subdomain. E.g.: https://hessen.museum-digital.de/oai. As of now, the OAI-PMH API provides access to the objects’ metadata using LIDO (XML) and the mandatory OAI-DC format.

Note that there are some caveats remaining for now: First, the LIDO representation of object metadata is not (and can by definition not be) as complete and fine-grained as the JSON API. It is also not exactly similar to the LIDO as returned by exports from musdb (one is formed natively in PHP, the other using XSLT, leading to divergent development paths). Also, the LIDO output lists different identifiers from the ones used by the OAI-PMH API and the OAI-DC representations otherwise.

Finally, the OAI-PMH API at museum-digital does not implement OAI-PMH data sets to group collections. Instead, it follows the existing search logic (essentially providing a new endpoint per query). Example searches via OAI might thus look as follows:

• All objects from the Agrargeschichte instance of museum-digital, represented in OAI-DC: https://agrargeschichte.museum-digital.de/oai?verb=ListRecords&metadataPrefix=oai_dc
• All objects linked to Berlin (place #61), in the Berlin instance of museum-digital, represented in LIDO: https://berlin.museum-digital.de/oai/place:61?verb=ListRecords&metadataPrefix=lido
• All objects of the Freies Deutsches Hochstift, Frankfurt am Main, represented in LIDO: https://hessen.museum-digital.de/oai/institution:1?verb=ListRecords&metadataPrefix=lido
• All objects from Baranya with only their identifiers: https://ba.hu.museum-digital.org/oai?verb=ListIdentifiers&metadataPrefix=lido

Credits

Credits where credit is due: the Städel Museum deserves praise for their implementation of OAI-PMH. For me personally, seeing the Städel’s API was the first time I saw a visibly stateless OAI-PMH implementation, enabled by the ingenious idea of using machine-readable, JSON-encoded resumption tokens over UIDs that have to be resolved on the server side. I spent weeks (or months?) making museum-digital’s frontend stateless. By following the Städel’s example, it can remain so even while offering an OAI-PMH API.

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

New Features

• Tabs are available in the configuration when the site is installed as a Progressive Web App (PWA) (See also)

Improvements

• Duplicate search query parameters for objects associated with times before / after are removed.
  Example: If one searches for “Objects after 1900, whose first recorded associated time is also after 2000”, this is a duplicate query. 2000 is always after 1900, so one of the two parameters can be removed.
  Searches by time begin / end are also the foundation for the timeline. As the timeline is both beloved by web crawlers and resource-intensive to generate, this change significantly reduced server load.
• Any links on timeline pages that do not reference single object pages are marked as rel=nofollow
  Which is to say that bots are told to ignore them.

musdb

New Features

• Tabs are available in the configuration when musdb is installed as a Progressive Web App (PWA) (See also)
• New search option for objects: “Can be published”
  Aggregate search for objects that have not yet been published and which comply with the minimum requirements for publication.
• Separated measurements can now be batch-edited
  Available via “assign results”
• Institution-wide setting to enforce the use of the user-defined object editing interface for all users of the institution
• Exhibitions can now be searched via the API (/exhibition/list)
• A user’s user-agent is checked whenever a page is requested. If it changed, the user will be logged out automatically.
  Protection against session hijacking.

Improvements

• Panorama images for tours through exhibitions / institutions are calculated down to 2400 px height rather than 1400 px height
• The APIs for searching for entries in controlled vocabularies are now available via the main API
  See e.g. /actor/search_linked_to_objects/{term} , /actor/search/{term} etc.

Bugfixes

• Fix: “Visiting scientists” couldn’t open the “location” tab (this erroneously required museum-wide editing permissions)
• Fix: User-defined defaults for descriptions of new objects were ignored when new objects were to be added
• Fix: Thumbnails were displayed as duplicate images linked to exhibitions (tag “images”)
• Fix: Prefixing via the batch editing was broken

Importer

New Features

• New parser for CSV exports / imports from Robotron Daphne

Improvements

• CSVXML Parser
  • New literature-related fields (ISSN, editor, etc.) are now covered
  • References to wikidata are now respected as tags are imported
• The maximum length of any single given tag/keyword is centrally set to 95 characters

Bugfixes

• Some more recently added fields from the “admininstration” tag of musdb’s object pages had been read by the importer but their transfer into the database had not been implemented thus far.

nodac

New Features

• Tabs are available in the configuration when nodac is installed as a Progressive Web App (PWA) (See also)

CSVXML

Improvements

• Added new literature fields: type, editor, edition / issue, ISSN

These are in the form of listings, and this is how it should be here too.

Frontend

Features & Improvements

• Some improvements in background scripts, especially better handling of timeouts when calculating “Similar objects” in very large instances
• Contributors, linked locations and times for an object group are now listed alphabetically by name
• Table headers for event components (who, when, where) are now only displayed in the A4 PDF if there is also content for the row
• New search option for object searches: “Is currently on display”
• Links to the Themator now use the new URL scheme of the Themator
  (https://themator.museum-digital.de/t/690 instead of https://themator.museum-digital.de/ausgabe/showthema.php?m_tid=690&tid=690)

Bugfixes

• Error when searching for controlled list terms that contained multiple spaces via the “Refine search” overlay (search for license “Public Domain Mark”)
• Exactness setting in the “refine search” overlay was not transferred to the actual search query
• Simple embedding of an object (analogous to YouTube videos, for example; accessible via the “Cite” menu of an object page) had various errors / now works again

musdb

Features & Improvements

• In the API documentation of musdb there is now a note that the frontend also has an API
  • Frontend API
    • You do not need to authenticate yourself to use the frontend API
    • The frontend API tends to be faster and easier to use
    • Is read-only
  • musdb API
    • Can do more: Can also see non-public stocks and fields / data types
    • Is much more granular (more queries for the same data, but you likely get exactly the data you are looking for instead of e.g. all data known about a given object)
    • Can be used for writing data
• Suggestion lists when searching for vocabulary terms in the side column of the object search page have been revised
  • Tooltips appear when hovering over
  • Implementation in Vanilla JS, removing jQuery
  • (this means significantly better performance of the search results list in list format, because jQuery no longer needs to be loaded)

• User page / Login
  • Log of logins now also with IP and user agents
  • Login via login persisted in the browser (“Remember me”) is logged and displayed
  • All browsers permanently logged in via cookie are forced to log in again after a password change
  • New option to invalidate all remembered logins on other devices (browser must be logged in again)

• Object
  • More restrictions for the publication of object data records.
  • An object can no longer be published if:
    • … the object name is the same as the object description
    • … the description contains the character string “lorem ipsum”
  • When object entries are unpublished / hidden, the images linked to the image are renamed (thus invalidating links to the images). When publishing the object again, this is reversed so that existing links work again.
  • Spaces in selection lists are now listed alphabetically as the actual location when linking
• Literature
  • Acquisitions can now be linked to literature
    • Previous owners etc. can thus be linked to a literature entry
  • Spaces (actual location) can be linked to literature

Bugfixes

• Overlay for setting searches for objects: Multi-word search terms were converted into multiple searches instead of being searched as a string of words (“red helmet” > “red” AND “helmet” instead of “red helmet”)
• Error when searching for controlled list terms that contained multiple spaces via the “Refine search” overlay (search for license “Public Domain Mark”)

Importer

• Link between literature and spaces (actual location) as well as acquisitions is implemented in the “core” of the import tool
• ImageByInvno parser (assignment of images to objects via inventory numbers contained in the file name) can now be used to import PDF files

files.museum-digital.org

• Added a small script to enhance PDF metadata based on an XML sidecar file. See e.g.: https://files.museum-digital.org/de/Praesentationen/2024-10-18_md-deutschland-eV-stellt-sich-vor_Usertreffen_MA.xml

Main post image generated using illustriousXL_smoothftSPO

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

This process is called reconciliation. One of the most used tools to actually connect to external services and reconcile data this way is OpenRefine. But to do so, OpenRefine needs to be able to communicate with such services. The open standard by which they communicate is the Reconciliation API specification. Depending on how completely the API has been implemented, the consuming software may offer additional features such as offering alternatives, suggesting entries or displaying previews of entries made available through the API.

Since this weekend, museum-digital offers such APIs for different types of data.

In md:term, reconciliation APIs were added for each of the available controlled vocabularies. Besides the controlled vocabularies of museum-digital (tags, actors, places, times) this means that users of OpenRefine can now reconcile their data with select other vocabularies such as the Oberbegriffsdatei or the hessische Systematik. Besides implementing exact and partial matching of requested terms, this implementation features previews.

Two additional points are noteworthy in terms of md:term’s implementation of the reconciliation API specification.

1) Similar to museum-digital’s import tool, md:term’s reconciliation service attempts to clean up entered terms before reconciling. As such times are automatically rewritten (“1912 bis 1914” [1912 through 1914] becomes “1912-1914”), question marks and other markers of uncertainty are removed, and – whereever known – autocorrections stored in the city (Frankfurt a.M. > Frankfurt am Main) are applied to the terms.
2) Multilinguality: Whereas the current version of the regular reconciliation API does not consider multilinguality, the above-mentioned auto-corrections and rewriting are language-dependent. And so are previews and names of entities in md:term for museum-digital’s vocabularies. Hence, an additional parameter for the requested language can be supplied.

Reconciliation APIs for md:term may be found on the download page linked in the sidebar. Going this way, the language parameter is automatically set to the user’s current language.

Reconciliation by Inventory Number

To identify objects available published through museum-digital, a reconciliation API now exists in the frontend as well. It can be found at /reconcile/invno/ on each instance of museum-digital (e.g. here for the Hessian instance.
It reconciles entries by their inventory number. An additional number may be added to the URL to search only within a single institution. Where https://hessen.museum-digital.de/reconcile/invno/ allows matching objects by inventory numbers across all institutions publishing their objects on the Hessian instance of museum-digital, the https://hessen.museum-digital.de/reconcile/invno/1 will thus only search within the collections of the Freies Deutsches Hochstift / Frankfurter Goethe-Museum (the institution of the ID 1).

Reconciling GLAM data using the MD:term reconciliation API: an example

As they have much more experience with OpenRefine, I asked the colleagues from digiS whether they could provide a description of how to actually use the reconciliation API from a user perspective. This section is theirs:

Using the reconciliation API in OpenRefine is straightforward (cf. the OpenRefine documentation for a general introduction). Let’s walk through a typical workflow using GLAM data and the MD:term API!

Our sample dataset (adapted from actual data provided by the Sportmuseum Berlin) features, among others, columns on material/technique, object type and places.

These elements are just strings and consequently not linked to any authority file. Strings are not guaranteed to be unequivocal, nor are they particularly suitable for retrieval, programmatic reuse or multilingual contexts. In order for the data to be as useful as possible, let’s reconcile them with an authority file, in our case the MD:term vocabularies now readily accessible also via a reconciliation API.

If you have never used the MD:term reconciliation service you first have to add it to OpenRefine. Click on the small triangle in the header of the column you want to reconcile. Select Reconcile → Start reconciling.

In the following window, add the API endpoint you want to use (cf. https://term.museum-digital.de/downloads for a list of MD:term endpoints).

Now you can select the service for reconciliation:

In the following window, the only really important decision you have to take is whether or not to automatically match “candidates with high confidence”. Auto-matching speeds up the whole process, but you have less control over what happens with your data.

Hit “Start reconciling” to trigger the reconciliation process. You can now see that the strings have become links. In fact, they have been linked to possible entries in MD:term. If you choose the auto-match option, the most probable candidates have been selected automatically. If not, you have to select the candidate you want to match manually by clicking the arrow to the left. One arrow matches the value in the selected row only, two arrow match all identical values in the entire columns automatically.

Once you’re done with the reconciliation you can, for example, write the IDs of the reconciled values into a new column. Click once again on the small triangle on the left side of the top row of the column you’re working on. Go to Reconcile and Add entity identifiers column.

Name the column that is to be added and you will have a new column that contains the MD:term IDs.

Along with this, we can gladly annouce a new, updated and much more performant search API for md:term (see the API documentation for now).

You can access the documentation here:

• md:term
• frontend (via the global portal)

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.

The next monthly meetup is scheduled for Tuesday, September 6th 2022, 5 p.m. (this post will be updated with a link to the meeting about a week before the meeting, as we are currently trying to organize a meeting room at Zoom or a similar service).

Update: The meeting will take place at https://meet.jit.si/museum-digital-meetup-202209

Recent Updates and New Features

musdb

XML Export

Creating new export formats for XML exports (beyond the main export formats md:xml and LIDO 1.0) is now possible using XSL files stored in a new git sub-repository. This git sub-repository is open source. As registration on our main Gitea instance is however restricted, please send a mail before contributing.

In line with this, we have also improved the representation of uncertainty in our default LIDO 1.0 exports. As version 1.1 of the LIDO standard has been recently released, we have also begun working on a LIDO 1.1 export.

Note: The pre-generated exports available through the “quick export” option are and will still only generated for LIDO 1.0 and md:xml.

Required coordinates when adding new museums

This update is only relevant to regional administrators. Coordinates of the institution are now required for adding new institutions.

QR Codes

QR codes can now also be exported in SVG and EPS, the two primary vector graphics format for use on the web and professional print layouting.

Another important improvement on QR codes is a new page that simply lists all QR codes leading to the object editing pages of a given search result in musdb. This page offers the option to manually set the size of the QR codes, so that suitable QR codes for internal collection and location management can be printed in bulk in a less paper-consuming way.

Calendar

A calendar view for all the events in the museum (events, start and end of an exhibition, start and end of loans) is now available. It can be reached by hovering the mouse over the puzzle symbol in the navigation. On the calendar page, single calendars can be selected or deselected and one subscribed to using one’s external calendar programm (e.g. Outlook, Thunderbird, or a mobile phone’s calendar).

The calendar, and especially the possibility to subscribe to the calendars, is also a first step towards enabling users to set reminders on object pages as this makes much more sense if the reminders can be integrated with one’s regular calendar application.

The calendar view is built using TUI calendar.

Institution-wide Settings and Adding Objects

The page for institution-wide settings has been re-designed to make it easier navigatable. The table of contents is now always visible, and the section “links to the institution elsewhere on the web” has been moved to the institution page.

There however are also some new options on the page. On the one hand, users can now enable or disable the image categorization when uploading images directly when adding new objects (the image recognition is render blocking and often hurts performance more than it actually benefits the inventorization). On the other, it is now possible to add additional fields to be directly accessible upon adding new objects and to make these required. It thus, for example, becomes possible to require a location to be provided before it can be recorded in the system altogether.

Watch list

The watch list feature has been completely re-implemented. The watch list is now generated completely in the browser using easily cache-able data retrieved from APIs. This, first of all, makes the watch list much faster to load and much less of a burden on the server side.

But the new watch list also comes with some new features:

• Users can now have multiple watch lists on the server
• Users can share their currently active watch list with other users of the same museum
• It is now possible to search objects by a watch list (or transfer the watch list into a search result). Thus, all batch editing and export functions available for object search results are now also available for watch lists. Obviously, this also allows for the watch list’s objects to be filtered by their place, collection, etc.
• Objects can now be added to the watch list in bulk.

Object search

The map view of object search results now updates the URL with positions and zoom factor when one browses the map. One can thus share a link to the exact same position one is currently viewing to one’s colleagues.

API

The API can now be used to delete objects.

Design

Error messages are now visible for four seconds as opposed to the regular 2.4 seconds other feedback messages on inputs are visible.

Frontend

Similar to the referencable maps of object search results in musdb, “objects on a map” maps in the frontend are now also referencable. We have also added a legend of event types on the same map.

museum-digital.org

museum-digital.org, the general website introducing museum-digital, has been reworked on a new technical basis. It is now statically generated once a day, reducing server costs and increasing performance. There are also many new texts, some new features (such as FAQs) and banner pictures that make the page more attractive.

The contents of the page are licensed under CC BY 4.0 International and can be edited on GitHub (See the repositories for the English version of the site and the German version).

Importer

The parser for importing images by their file names now offers a setting option to mark a certain part of a file name as an indicator to import the given image file as a hidden / non-public image.

Image: Courtesy NASA/JPL-Caltech.

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

In musdb, our inventorization and museum management tool, however, the situation is more complicated. On the one hand, musdb is simply much larger in terms of the offered functionality. Many features have no public equivalent, while the whole question of updating the database is not present in the frontend. The tab-based user interface and the unfortunately often still rather tight coupling between user interface and loading of data from the database has been hindering the development of an API for musdb. A simple API design like the one in the frontend, where you can just add &output=json (or ?output=json) to a page’s URL to retrieve the page’s information in a machine-readable format is made largely impossible by that very architecture. Just adding &output=json to a URL in musdb provides that machine-readable information in an astonishingly high number of cases, but often it is incomplete or otherwise of limited use.

Finally, it is especially musdb where a well-designed API may become interesting to have in the future. It would be great if museums could use their inventory app of choice besides musdb – and any update to public objects would automatically be mirrored in musdb and the frontend of museum-digital in the background. Currently, the same objective can almost be reached using imports, but imports are limited to updates of the same type and do not happen in real-time.

Off to a Good Start: Updating Object Information Using musdb’s API

A first step towards a dedicated API for musdb has now been taken. For the start, all fields directly relevant to the management of objects have been made available using a new public (though obviously authenticated) API for musdb. Further functionalities will be added when the need arises.

Obviously, starting over and writing a whole new API offers a chance to implement things cleanly. Adding the new API required us to refactor the code considerably – and that in turn provided a good opportunity to write unit tests for all functions relevant to the API. The API is thus ensured to stay stable for the foreseeable future (extensions notwithstanding).

In designing and documenting the new API, we took the opportunity to write the documentation using the OpenAPI standard. A desciption of the API in machine-readable JSON can be accessed at /musdb/api in each instance, e.g. at https://hessen.museum-digital.de/musdb/api.

Using OpenAPI also opens the way to all those tools that build on OpenAPI in general. Hence, a human-readable interface for reading about and testing the API could be generated using Swagger UI (thanks!) and is linked in the German-language handbook. Since each musdb API is linked to its respective regional instance, the “try out” buttons do not work in the handbook, but working Swagger UI instances describing the musdb API can be found linked in the “tools” menu of the navigation of musdb.

Next Steps

Even though object information can now be read and updated using the musdb API, there are a lot of features not yet covered. Even a simple task like listing the collections available to the API user is still missing. As this hinders the finding of IDs for linking with objects, it is a natural next step for implementation.

Working with OpenAPI on the other hand has been a pleasure. We are looking forward to eventually (hopefully sooner than later) being able to provide an OpenAPI description of the frontend API as well.

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

The probably most important part of md:term is its API, which is also – for example – used by the “graph navigation” and is available for external use as well. Since we – like anywhere else – do not require authentication for accessing the md:term API, we don’t have a full list of API consumers which we could contact about API changes. Hence, we hope that this blog post will also alert them to make necessary changes.

How then, is md:term made multilingual? And how does it express itself in md:term?

Months ago, we implemented the multilinguality in our controlled vocabularies by adding an additional translation table, which means that there is the base entry, which is entered by the museums. The “norm data editors” then enrich the data and also attempt to add translations to a separate table by fetching data from Wikidata. If translations in the user’s language are available, they replace the “base entry” when outputting the data.

In the API, the base entries are replaced as well. If they are used, it hence makes sense to explicitly state the wanted language of the entry. To fetch German language information on Berlin easily, one should thus query https://term.museum-digital.de/md-de/place/61/json?lang=de instead of https://term.museum-digital.de/md-de/place/61/json (which, before multilinguality, would have been the appropriate URL).

Alternatively, there is a new section in the JSON API: langs. All available translations can be found there listed by language.

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