Frontend

• Objects that are linked to a source as referencing the source or being referenced in it are now listed on the source’s page
  • Example: “Novalis Schriften. Die Werke Friedrich von Hardenbergs. Historisch-kritische Ausgabe. Erster Band: Das dichterische Werk. 3. Auflage”
• The object page now displays the new transcription fields for notes, status, and type of the transcription
• New types of classifications for the link between an object and a tag
  • Taxon
  • Topic
  • Mentioned subject (similar to the existing “display subject”)
• Dependencies
  • Updated OpenLayers to Version 10.6

musdb

• Renaming vocabulary entries to blacklisted terms is now impossible
  • Someone managed to create an actor “unknown” by adding a different actor and renaming the new actor entry to “unknown” afterwards.
• Added a sidebar to object group overview pages for additional filtering options
• New types of classifications for the link between an object and a tag
  • Taxon
  • Topic
  • Mentioned subject (similar to the existing “display subject”)
• New APIs for listing all vocabulary entries linked to the objects of a museum
• Dependencies
  • Updated OpenLayers to Version 10.6

Importer

• Core
  • Deaccessions are now covered by the import tool
  • Recipients of deaccessions are linked to the address book / contact list
• Parser
  • CSVXML: The CSVXML parser now covers deaccessions as well
  • ImageByInvno: Added an option to ignore any characters before a given starting combination of characters (if there is a consistent start of the inventory number).

CSVXML

• New fields
  • tag_related_identifier_type
  • tag_related_identifier

Dissemination

• Presentation “Von museum-digital zum eigenen Online-Katalog” for the Working Group Digitization of the State Museum Association of Rhineland-Palatine
  • Slides: PDF
  • Slides: ODP

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

Frontend

• Dates in TEI transcriptions are parsed, irrespective of whether when="" oder when='' was used
• Notes for markings are now publicly displayed
  This was missing thus far and is now implemented similar to how event notes are displayed. If a note exists, a small “[?]” appears behind the marking title line. Upon hovering over it, a tooltip appears with the relevant information.

musdb

• Names and descriptions of exhibitions and object groups can now be translated
• Version control
• Log of “current locations” of an object can be exported as a CSV file
• Uploaded object images can now be hidden or published in one batch operation
• API extended
  • (New functions)
  • Transfer object dimensions
  • List images and resources for an object
  • Image metadata
  • Publish / hide object images

January 2025

Frontend

• Objects can now be sorted by the aesthetics of the thumbnail (A dedicated blog post on this will follow soon)

musdb

• Batch transfer between between free text fields of object data
• Alignment of the maximum field length for notes on opening hours is now consistent between UI and database
• Bug fixed with switching between institutions during consistency checks fixed (relevant only to users with administrative access to multiple museums)
• Literature can now be searched by editors

Importer

• Core
  • Automatic transformation of life dates for actors
    • Year of death “01.01.2012” now becomes “2012”, instead of 01.01 as before
  • “?” and “(?)” are removed from the beginning and end of imported keywords
  • Various types of brackets in keyword names are converted to regular brackets
• Parser
  • Stricter internal implementation of settings, all imports can now implement the start_at setting
    • This is particularly useful for the repeated execution of imports that abort due to new, previously uncovered elements and other debugging.
  • New parsers:
    • MODS (mainly used in library contexts)
    • Parser for Exports from Faust for the Händel-Haus
    • Parser for XML dumps from MuseumPlus Classic (MsSQL > XML export per table > Import)
    • Bugfixes
      • Field “Verwender” in Primus parser was mapped to production events
      • Material / technology are now imported correctly in the parser for BeeCollect exports for the Industrial Museums of Saxony
• „Frontend“
  • CLI now also has options for switching off the import of individual areas
  • Help text for command line tool

nodac

• Splitting of keywords now also recognizes keywords that should be split into places, times, etc.
  • Bsp.: „Helm; Berlin“ > Schlagwort „Helm“ + Ort „Berlin“
  • Example: “helmet; Berlin” > keyword “helmet” + place “Berlin”
• When searching for keywords with ambiguous names, both keywords and generally ambiguous terms are now taken into account
• Times can now be merged with others directly from the time edit page

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.

For time names a much more extensive cleaning is done, both in the case of imports and when working directly in musdb. Time names in the sense of the controlled vocabulary of museum-digital describe clearly defined times. This may be timespans, years, or full dates. But the number of possible input values is thus already significantly limited. In fact, it is small enough, and timespans, years, etc. are uniform enough to allow the automatic parsing of time names. Where that is possible, they are automatically rewritten to their default form in the controlled vocabulary and automatically translated to some 30 languages.

In the case of place names a similar cleaning and consolidating of place names was limited to the simple stripping of leading and trailing spaces and commas and the removal of indicators for uncertainty (e.g. trailing question marks). Since the weekend, place names are more extensively rewritten to ease the work of the vocabulary editors and ensure a more immediately consistent data entry both in musdb and when importing.

General rewriting

1. Simple spelling issues

The very first step in rewriting entered place names remains the removal of superfluous characters. As such, duplicate white spaces, trailing commas, etc. are removed.

Example: , Berlin , > Berlin

2. Removal of indicators for uncertainty

Next, known indicators for uncertainty are used to update the dedicated flag describing the certainty of the link to the place and then stripped. As they indicate the relation between object and place, they are not actually part of the place name and can thus be removed safely.

Example 1: Berlin ? > Berlin
Example 2: Maybe Budapest > Budapest

3. Removal of duplicates in enumerations

Commas are used in input place names in two ways. On the one hand, they may be used to further specify a place name (Beijing, PRC), on the other, they are often used in import data to designate multiple space names at a time (Beijing, Tokyo, Nairobi; this contradicts the logic of a database altogether and needs to be cleaned up manually be the vocabulary editors).

In both cases, duplicate names in the enumeration are superfluous and can be removed.

Example 1: Berlin, Germany, Germany > Berlin, Germany

4. Language-dependent rewriting

The next steps in rewriting entries depend on the language of the entry. In musdb, the language the user set to use musdb is used to guess the language they are entering data in. In the case of imports, the default language of the given instance of museum-digital that a museum imports to is used.

4.1. Extension of common abbreviations

Where there are abbreviations, there are also unabbreviated names. And surely, both will be used. Will inevitably leads to duplicate entries. In the case of some common abbreviations, they are thus automatically rewritten to a canonical form.

Example (German): Adalberthstr. 12 (Berlin) > Adalbertstraße 12 (Berlin)
Example (Hungarian): Vaci u. 12 (Budapest) > Vaci utca 12 (Budapest)

4.2. Reordering names in commas based on indicators for more specific place names

As stated above (3.), commas may either indicate a specification of a single place, or they may indicate that the entry actually refers to more than one place. Some components of a name can be used to almost certainly determine that the former is the case – and which place of the given list is the specific one and which one is a superordinate named mainly for clarification. Common such names are “street”, “plaza”, “pier”.

If there is exactly one comma and such a name component is encountered, the entered place name can be rewritten to contain the less specific name only in brackets.

Example (German): Berlin, Adalberthstraße 12 > Adalbertstraße 12 (Berlin)
Example (Hungarian): Vaci utca 12, Budapest > Vaci utca 12 (Budapest)

If both names contain such an indicator, no rewriting is applied. Vaci utca 12, Vaci utca 13‘ is thus not rewritten.

4.3. Budapest special: Extending the names of districts

Street names in Budapest are usually referred to including the naming of the district. These districts are referred to in a number of ways. If they are referred to using roman numerals, this is automatically extended to the canonical form.
This rewrite is only applied if the language is set to Hungarian.

Example: Petőfi Sándor utca 3. Budapest, IV. > Petőfi Sándor utca 3. (Budapest, 4. kerület)

4.4. Reordering names in commas based on country names

Similar to the rewrites described in 4.2., country names can be used to indicate a hierarchical relationship between two places in a comma-separated list. If one given name is a country name and the other is not, it is likely that the non-country name is part of the given country. The comma can be replaced with brackets while the name can be reordered into the preferred specific (unspecific) form.
This check is also applied to names separated by hyphens.

Example (German): Budapest, Ungarn > Budapest (Ungarn)
Example (Hungarian): Berlin-Németország > Berlin (Németország)

There are however some common cases in which this logic does not apply – significantly cardinal directions. If one such term is found to be the non-country part, the rewrite is not applied. As such West-Deutschland remains West-Deutschland without being rewritten.

The list of names of countries and historical countries used stems from Wikidata (thanks!).

Where do these rewrites apply?

The rewrites listed above are now implemented in musdb, the import tool, and nodac.

They have also been used to consolidate existing place names, allowing us to identify some 500 duplicate place entries over the weekend (that amounts to almost 0.7 percent of the whole vocabulary). Clearly, identifying similar cases of regularly appearing, varied ways to express the same thing, and determining a canonical way of naming places in such cases holds a lot of potential for reducing the editors workload and improving data quality for everybody.

On the one hand, using shared controlled vocabularies allows for a centralized editing team. Work that’s been done for one museum is available for all. This allows for a generally higher data quality, improved search options, etc. The only downside to centralized vocabularies is rules: Without everybody following a basic set of rules for the different vocabularies the vocabularies would surely be overcome by chaos quickly.

The two most basic rules are that 1) all entries need to be clearly identifiable and 2) actor names – from actual people to companies and governments to peoples – belong to the controlled vocabularies for actors; place names – cities, countries, streets – belong to the vocabulary for places, and so on. In effect, this means that an actor entry “Gaius Iulius Caesar” (better yet, “Gaius Iulius Caesar (-100–44)”) is a good one. It is clearly identifiable. An actor name “Bosch” should not end up in the controlled vocabularies – there are many people and companies sharing that name. If one means to actually record the German tool maker, one can specify as much using brackets and / or using the full name, e.g. “Robert Bosch GmbH” or “Bosch (tool making company)”.

musdb comes with selection lists enabling a simple reuse of existing vocabulary entries. Where a term or a name has not yet been recorded in museum-digital’s controlled vocabularies, the option to import vocabulary data from Wikipedia / Wikidata and the Gemeinsame Normdatei, and alternatively the need to add a description of at least ten characters enforce some level of identifiable and minimally researched entries.

And then there are imports. During imports, there is no way to force importing users to add additional data. To the contrary, especially during data migrations museums import data from different departments and different decades, leaving one with different spellings for the same person and a very varied quality of the recording overall. Importing thus often means bringing unclean, non-uniform data into the vocabularies. Often enough manual cleanup and enrichment are required to make the data usable – and to stop the “unclean” data from disturbing other users, e.g. by appearing in selection lists and then being falsely linked to another museums entries (a classic example are place entries like “Frankfurt”. Both Frankfurt an der Oder and Frankfurt am Main are significant places – how significant they are depends on where a museum may be located. Leaving the unidentifiable place (name) in the database will easily lead to other museums linking the same entry while actually referring to the other Frankfurt).

Automation can however significantly reduce the work of the colleagues manually editing the vocabularies while also allowing their efforts to have longer-lasting internal benefits to the system. The import tool thus features a number of checks to identify the entries actually referred to. Those checks relevant to the import of references to actors will be introduced over the rest of this blog post.

Rough outline

Actors from (or for) the controlled vocabularies usually enter museum-digital by being linked to objects via events. The same usually happens in the case of imports: The import data states that an object was, e.g., created by a given person. This translates to a new event (what happened to the object? And who did it when and where?) being created. The actor of this event is then set based on the provided name, optionally taking into accounts life dates and links to norm data repositories, in so far as they are made available in the import data.

Preparation

Cleaning the name

To identify the actor name, it is first cleaned and made slightly more uniform on a simple level of spelling.

• Leading and trailing spaces, semi colons, tab stops and newlines are removed
• Duplicate white spaces are removed
• Brackets of the different types (“()”, “{}”, “[]”) are replaced with simple brackets (“()”)
• Unwanted components / specifiers of a name are removed (e.g. “mythological creature” or empty brackets)
• Language-specific name components are replaced with their preferred variants in the vocabularies (German: “d.Ä.” is extended to “(der Ältere)” [the Elder])
• Indicators for uncertainty are stripped from the name, e.g. trailing question marks. They are separately used to identify the certainty of an actor link in a dedicated fields that describes exactly that.

Thus, a name stated in the import data as “; Hans Holbein d.Ä.?” will be imported as “Hans Holbein (der Ältere)”.

Parsing life dates from the input name

If no life dates have been provided explicitly in the import data, they may still be included as part of the actor name. Some museums whose database does not feature dedicated fields for an actor’s date of birth and death will append the years in brackets. Hence, a check is done to see if there are any brackets at the end of the name – and if so, whether the bracket contains a parsable time span. In this case, the time span identified will be used for the actor’s life dates and the brackets’ content will removed from the name (it is not actually a part of the actor’s name after all).

“Hans Holbein (der Ältere) (1465-1524)” with no explicitly provided years of birth and death will thus be transformed to “Hans Holbein (der Ältere)”, born 1465 and dead since 1524.

Identifying the actor

After preparing the inputted actor data, it is checked against the database in various ways. The listed checks below take place in a chronological order. If one returns a positive result and works to identify the actor, no following checks are run.

Checking based on norm data links

If links to external norm data repositories (the Library of Congress authority files, the National Diet Library, the French National Library, etc.) are provided in the import data, the actor vocabulary at museum-digital is checked whether it contains an entry featuring the same external ID. If that is the case, this actor is doubtlessly identified.

Checking global rewrites

For many names, there are different spellings. Similarly, many people use different names over the course of their lives. But the person referred to stays the same.

As not all names are significant enough to be listed as synonyms in their own right, museum-digital features a global (though language-specific) list of “permanent rewrites”. If a museum exported a reference to a “Julius Caesar”, this will be automatically rewritten to “Gaius Iulius Caesar”, thus identifying the person of the same name.

This central list is built and extended as the vocabulary editors do their work. Whenever two actor entries are merged in nodac, editors have the option to mark the name of the actor being merged into the other as to be permanently rewritten.

Checking institution-level rewrites

Whenever a new actor entry is added through musdb or by the way of imports, this is marked down in the database. Which museum used what term, resulting in which entry. Which entry may in the future be updated to refer to another. This is most simply explained using an example from the realm of places – the above-used example of “Frankfurt”:

If a museum newly brings “Frankfurt” to the controlled vocabulary for places, an additional entry is made in the database to note that the museum was the first to add an entry named “Frankfurt”, and that that finally resulted in the creation of a new place with the ID #99999. The object data itself makes it clear that the museum actually referred to “Frankfurt am Main” (ID: #217). If the vocabulary editors thus merge “Frankfurt” (#99999) with “Frankfurt am Main” (#217), this obviously cannot be a permanent rewrite. But the museum-specific log can be updated: The museum entered “Frankfurt”, and it referred to the entry #217 (Frankfurt am Main). If the museum thus enters “Frankfurt” without any further specification in the future, the importer and musdb can automatically identify Frankfurt am Main as the place actually referred to. The same logic applies to the import of actor data.

This check is obviously based on the assumption of some level of uniformity between different workers at the same museum. If a museum in Frankfurt an der Oder has almost all of their employees referring to Frankfurt an der Oder as the canonical “Frankfurt”, except for one, this will obviously backfire. But it is to be hoped that this case is rare enough – and that such a very different colleague would recognize their own non-conformity and choose to use the full names for both places to be able to clearly document (and communicate overall) with their colleagues.

Checking by name and life dates

If all the above checks did not work, the actor’s name and life dates are checked against the controlled vocabulary for actors itself. Does anybody with the same name, who was born and died at the provided years, exist in the actor vocabulary (either going by the language-specific translation of the name or by the “base entry” of an any language).

If that is not the case, the actor likely does not exist in the database yet.

Identification failed. Should a new entry be created?

If the actor does not exist in the database yet, they need to be added. Maybe.

Some names are known to be in clear conflict with the rules of the vocabulary for actors.

Checking the blacklist

museum-digital keeps a centralized blacklist for actor names that are known to be in clear conflict to the rules of the actor vocabulary. This list mainly contains either deliberately unspecific actor names (“unknown”; “unidentified”) or very unspecific ones (“John” [a random given name without a family name], “painter” [the name of a profession, not even of the actor themselves]).

If the entered actor name is contained in this blacklist, the attempt to link any actor to the event is aborted. The free-text note about the event is instead extended to mark that an actor of the blacklisted name was noted to be related to the event.

Checking if the actor is actually a place, time, or tag

A classic problem is vocabulary entries being entered in an unsuitable vocabulary – often for simple reasons likely colleagues slipping to a wrong column when working with a table calculation program. And thus one is asked to import an actor “14th century”.

The “14th century” is obviously a time, not an actor. For this, too, there is a centralized list that can be extended using nodac. Whenever the vocabulary editors move an entry from one vocabulary to another, they have the option to mark the entry’s name as always being of the target type.

Say the 14th century was previously entered as a tag. A vocabulary editor moved the entry to the vocabulary for times and marked the string “14th century” as one always referring to a time. If one then attempts to link a new actor “14th century”, the import tool can automatically recognize that this name actually refers to a time and link a time instead of an actor to the event. The attempt to add an actor is thus redirected to a different category.

All else failed: The actor is being added

If all the above checks did neither result in identifying a pre-existing record, nor in identifying the input name as invalid in one way or another, the actor is added to the controlled vocabularies and linked to the event. The entry now needs to be cleaned and enriched manually by the vocabulary editors.

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.

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.

Either way, we have also worked on some new features: A dedicated area for markings (stamps, watermarks, etc.), one for references and reception (e.g. the publication history of an object), and entering uniform information for the field “object type” has gotten easier. Most importantly, we have added some new event types to better meet the requirements of provenance research.

Markings

Especially for art historians, a precise recording of information on different types of markings, that have been added to an object for indicating authorship and ownership are essential. Be it stamps, watermarks, signatures. Thus far, information on these could only be added using the unspecific field “Inscription” in museum-digital. The new “markings” area (to be found at the bottom of the tab “Addendum” in musdb) aims to tackle this problem. The term “markings” is deliberately chosen to be wide in meaning to also emcompass logos and other types of markings that are more relevant for e.g. technical collections.

If a user of musdb wants to add a new marking, they can scroll down to the bottom of the “Addendum” tab and find an accordion button. A click on this button toggles open the area for adding new markings. First, the tye of the marking and its position on the object need to be selected. A transcription must also be provided to safe. Additional information to add are the creator, a possible mentioned time on the marking, its size and a note.

Creators and times are drawn from the centralized controlled vocabularies for actors and times respectively. Hence, they can be entered by tiping the given term and then selecting the correct value from a drop down menu appearing as one types. If the term does not exist yet, it can be added by clicking on the “+” symbol right before the text field.

Once a marking has been entered, it is public for now, even though we consider adding an option to hide markings even when their object is public.

Reception and References

With “reception”, there is a whole new tab in musdb for linking objects with sources. These sources come from a new controlled vocabulary for sources, which is used together by all institutions and runs on a similar level as actors, times, places, and tags. Reception now describes all instances, in which an object is referenced in a source – e.g. if a painting was printed in a book, or a photo published in a newspaper. Similarly, the discussion of a custom-made car in a car magazine may be recorded here.

The counterpoint to this is the “is reference” area just below reception: This can be used, if the object itself references a publication. E.g., a painting may be drawn after a scene from a book.

Like markings, reception and references are by default public.

Object Types From a List

museum-digital traditonally treats object types as a free text field, while many – if not most – museum databases provide controlled lists of available object types. We use keywords / tags to provide the same functionality, but it surely makes sense to also have some level of uniformity in the field “object type”.

Hence, there is a new aid in adding uniform object types when adding a new object in musdb. As one types in the field, a drop-down list of similarly-phrased keywords appears. Clicking on an entry from that list enters its value into the “object type” field and (if one is adding a new object) automatically links the object with the selected tag.

JSON-LD Metadata for Image Licenses

Another minor improvement is that single image pages now feature JSON-LD markup describing the respective image license. This enables especially Google, to provide users with a more detailed view on how to attain the license to use a given image file.

Importantly, images from museum-digital now also appear in Google Images if one opts to only view Creative Commons-licensed works.

Events: New Event Types and References for Events

The probably most important change are the changes made for entering events in museum-digital. One the one hand, important missing event types have been added. These are:

• Assembled (to be used for objects, that have been assembled from parts. E.g. a car)
• Auctioned
• Bought
• Owned
• Sold
• Restorated
• Damaged
• Destroyed
• Lost
• Edited (for books and publications, that have an editor)

As can be seen from the list, most of the new event types are related to provenances (for all museums that want to use these event types: Please (!!) ensure that you have cleared the necessary rights to publish this information, as events are public). To make events at museum-digital more closely meet the requirements of provenance researchers, a missing piece were also sources for events, which can now also be added.

To do so, the addition of sources for events must first be activated on a museum-level. To do so, a museum director or user with similar permissions must first navigate to the “institution-wide settings” page in musdb, and activate the event sources there.

Once they are activated, an accordion button appears on event editing pages (accessible by clicking on the event type of an already added event). Here, sources can be linked using a drop-down menu similar to the ones used in the features described above.

Finally, with options to add event annotations and sources, there was an increased danger of cluttering the object page in the frontend of museum-digital. Hence, we redesigned the display of event annotations to now appear in a tooltip – if an event has an annotation or a source, an “i”-symbol appears next to the respective element for the event type. Hovering over that element makes sources and annotations visible.

Beitragsbild: Caravaggio: „Der ungläubige Thomas“ (CC BY-NC-SA @ Stiftung Preußische Schlösser und Gärten Berlin-Brandenburg / Murza, Gerhard)

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.