Setup: background

The concept behind the standards

A museum that shares its data shares it several times over: as the Minimaldatensatz (minimum data set, MDS) with the Deutsche Digitale Bibliothek (DDB), as DDB-LIDO, as EODEM for loans, as Dublin Core with a repository. Four formats, four field lists, four mappings. And whenever a format changes, you start again from scratch.

Moliri puts a layer in between.

The concept hub

At the centre is a maintained catalogue of concepts: object title, inventory number, material, dimensions, event, media file, holding institution, more than 60 in all. A concept is neither a field list nor a format; it is a meaning.

This splits the work into two separate halves. The museum maps concepts to its fields, and does so once: our field Originaltitel is the object title, our fields for height, width and depth are the dimensions, our field Inv.-Nr. is the inventory number. The mapping of the concepts to the standards is supplied and maintained by Moliri. Every node of a standard points to a concept.

That is where the benefit lies: once you map a concept, it is mapped in every standard whose node points to it. A further format costs the museum no new mapping, as long as it uses the same concepts.

Profiles are selections, not copies

LIDO 1.1 is the base schema. What sits on top of it are profiles: a selection of nodes and their obligation levels.

ProfileRelation to the base schema
Minimaldatensatz (MDS) 1.2An explicit selection. Stays small even when the base schema grows
DDB-LIDOAll nodes of the base schema. Inscriptions, distinguishing features, related works and rights in the work are added
EODEMA selection for loans: core identification, dimensions, material, event
Dublin CoreA small schema of its own, not a LIDO profile

This separation saves maintenance. A new LIDO node extends DDB-LIDO and leaves the Minimaldatensatz alone. Without the distinction, every extension of the schema would inflate the Minimaldatensatz.

Facets

Some concepts consist of a single value, such as the inventory number. Others are structured and have facets. The object title has the title itself and its language. The dimensions have reference, type, value and unit. The event has seventeen facets, from type, person and role through dating and place to culture, period, method, material and notes.

Facets are the reason a mapping is not simply “field equals node”. A title with a language tag needs two origins, a dimension needs four.

If the repetition carries an addition (this title is in English, this dimension was measured on the frame), a single JSON field can carry the whole structure. The row’s label then takes on the role of the addition.

Separate fields or one JSON field

Where a concept has no field yet, Moliri offers to create one, in either of two forms.

Separate fields mean one field of its own per value. They can be searched, sorted and grouped.

A JSON field holds rows or sections within one field. It cannot be reached by the search, but it is equivalent for the export.

The decision is simple: if you search, sort or group by the value, use separate fields. Otherwise use the JSON field, especially if the repetition carries an addition. If you also want to read in LIDO files, you need separate fields. The import writes only to concepts that are bound to exactly one field.

The mapping determines the export

An export contains what is mapped. A concept that is not mapped is missing from the result, because Moliri invents nothing. That is why the administration always shows how many concepts are mapped and which obligation level a node has in the chosen profile. Before the export, Moliri checks the objects against the mandatory information and the finished file against the schema.

There is also a responsibility that is easily overlooked. Standard outputs are an interface, and the receiving side relies on their form. Changing a mapping means changing an interface, not just a display.

Further reading