At museum-digital, there are four main centrally controlled vocabularies – actors, places, times, and tags. In more traditional collection management software however, the main field to control is usually the object type (is the object a helmet or a painting?). Simple tagging of the objects can serve as a rather good replacement for a controlled set of object types if one simply repeats the object type as a tag.

As long as one only uses simple tagging, it can however do so only to some extend. If the object is a painting that displays a hammer, the object would feature the tags “painting” and “hammer”. If the object is a hammer with an engraving of a painting, it would feature the very same tags. Take the first example: If one wanted to be able to express that “painting” is the object type and “hammer” is something displayed on the object, one would either need to skip using tags again and use the dedicated fields again – or one needs to be able to categorize tags.

We doubled down on tagging by implementing a categorization mechanism for object tags while streamlining the tagging process in musdb and making it faster and easier to use overall.

The new tagging overlay

When clicking the usual link for linking (new) tags with an object in musdb, one will now be presented with an overlay that replaces the previous page of the same functionality. The layout is rather similar to the previous page – new tags and simple links to actors, places, and times are usually be entered using input fields on the left of the overlay. By typing in the relevant input field, a drop-down list appears, from which entries to be linked can be selected. A new tag, actor, place or time entry can be entered by pressing the “enter” key after typing the name. A sidebar on the right of the overlay allows the simple repetition of the last 10 tags, actors, places, or times the user linked to objects.

The differences between the old page and the new overlay play out on two levels. First, there is the simple fact of the new implementation moving a lot of the logic to the client side, i.e. your browser. If one only selects entries from the drop-down menus, this means that all communication with the server runs in the background. Page reloads are thus only necessary when one enters a new, thus far unknown, tags etc. As the overlay does not close after linking a tag, multiple pre-existing tags can be linked quickly one after the other. In effect, this amounts to a much smoother experience in tagging objects than before.

On the other hand, the overlay unites the existing tagging-related functionalities in one. To do so, the currently linked tags, actors, places, and times are displayed in the overlay as small tiles and can be deleted from there using the trash can icon. Tiles for tags feature an additional select field for categorizing the relationship between object and tag. By default, the relationship is set to the generic “tag”. Alternative categorization options are currently:

• Object type
• Material
• Technique
• Display subject

By categorizing the tags in the appropriate way, one keeps all the advantages the controlled vocabulary for tags brings – multilinguality, links to norm data repositories, and findability using hierarchichal searches, while now being specific about the relationship.

Additionally, another icon (the arrow downwards in a hexagon) offers narrowing down the tag to a more specific version. If an object has for example been tagged as a “portrait”, pressing on the icon will open a sidebar suggesting to replace that tag with “self-portrait”.

Effects on search

Of course, categorizing the links helps little without the relevant search options. Hence, we added five new search fields in the extended search menu: Tags (object type), tags (material), etc.

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

musdb

New fields

Other page

Batch updating object information

Instituion-wide settings and adding new objects

Notifications

In other news

• The calendar feature (accessible under the puzzle symbol in the main navigation) can now display tasks or make them subscribable via WebCal (thus implementing a “reminder” as had often been requested)
• PDF of all linked information is now in A4 and uses a two-column layout
• Ukrainian translation
• “Simple A5 PDF” now covers inventorization fields on rear side

md:term

• If two actors have been joined and one has an old links to the page of the actor now deleted, one is now referred onwards to the new, single actor entry. The same works with transferrals between vocabularies (an actor that was transformed into a tag, etc.).
• Ukrainian Translation

Frontend

• Ukrainian Translation
• JSON-based settings for specific institution pages have been removed
• Bulk download of object images
  • An overlay with a message from the museum can be displayed during batch downloads (see above)

CSVXML

• Almost completely rewritten
• The served page now is completely static and all checks and conversions run directly in the browser. This way, no uploads actually happen and the application is completely uncritical to the server’s security. On the other hand, this allows for installing CSVXML as a progressive web app and using it offline.
• We also added some explanatory texts did small updates to the design of the page. A footer now links to the source code and offers to refresh all cached contents of the page (this may be useful when visiting the page after a long time, as the whole application is cached in the browser for offline use).
• A new check also checks for the file encoding. A warning is provided if the data does not appear to be UTF-8-encoded.
• CSVXML is now released open source under the AGPL.

Importer

While the individual parsers for the different export formats are updated very often, the core scripts of the importer are very stable. November 2022 however came with a large update to these core sections, as more categories of data that had not before been covered by the importer (many of them new) can now be imported:

• Contact information (e.g. for object owners; loan partner institution)
• Object’s movement log
• Minimum and maximum temperature, humidity, and lux of an object
• Loans
• Events / Appointments

In terms of the parsers, we extended the LIDO parser to cover the new fields suggested by the upcoming EODEM standard for exchanging loan object information.

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.

In a similar fashion, the vocabulary control tool of museum-digital, nodac, has been able to parse and normalize time names for some times. While the canonical formulation of e.g. a single day is the German date format DD.MM.YYYY, similar times like “15. Januar 1920” (German) or “1920. január 15” (Hungarian) are entered often. These would have been transformed into 15.01.1920 upon the push of a button and then translated to many languages upon the push of another.

In line with some larger imports, we have now improved these and moved them into a dedicated module, that are now also used in the general input tool, musdb.

Recognizing Uncertainty and Normalizing Times in musdb

musdb can thus recognize uncertainty based on a given list of indicators of uncertainty. In the case of times, these are e.g. “um ” (“about” in German), “wohl um ” (“likely about”), “circa “, “ca. ” oder “ca ” in the beginning of an entered time term and “(?)” oder “?” at its end. If one of these indicators is present, the time name is freed of the indicator and the entry is saved as uncertain. The same works with links between events and actors and places.

In a similar fashion, many entered times can be automatically normalized and cleaned. Thus far, entries in German and Hungarian for single days and months (15. January 1920 and January 1920) can thus be automatically parsed and cleaned.

Together with normalizing the time term, the entries can in many cases be automatically translated. This is especially important for times before 1000 CE, where an indication of whether they are BCE or CE is often necessary for a quick understanding. This is thus far implemented for time spans before 1000 CE: “312 – 315” is automatically translated to “312-315 n. Chr” in German, “312-315 CE” in English and “西暦312年から315年” in Japanese.

Batch Publishing or Hiding by Object Selection

A small improvement on a sidenote, we have now added batch publishing and hiding of objects to the options available through the object selection tool in musdb. To use it, the objects to be manipulated can be selected by first dragging one with the mouse and then clicking on the others. Finally, the respective menu option at the top of the page (red in the screenshot can be pressed).

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