Background

Events as shared data

The history of an object fits badly into fields. A production is an event with an actor, a role, a date, a place and a method. An exhibition concerns a hundred objects at once and should be described once, not a hundred times. An acquisition has a previous owner, a date and a type.

If you put that into fields, you run into problems. The number is unknown, because nobody knows in advance how many exhibitions an object will have. The structure repeats itself: actor, role and date, again and again. And the same facts are typed a hundred times on a hundred objects.

The event pool

That is why events are not field values but entries of their own that are linked to objects. An event has a title, a type, actors with roles, a time span, a place and a description, plus any number of linked objects.

This is the same design as for addresses, authority data and locations: a library from which you link. And as there, a change to the entry affects all links. When you edit a shared event, the interface says so explicitly: Shared event, with the note changes affect all n linked objects.

Shared or private to the object

Not every event is shared. The event type decides.

Shared events are searched for and selected, such as an exhibition Wasserwege (an invented example). This is how exhibitions, loans and campaigns work.

Object-private events belong to exactly one object and are created there, such as a production or a condition check on 3 March. They do not appear in any selection menu.

The administration decides which types exist, which of them are shared, how many are allowed per object and which input fields a type shows. Types have their own access settings. Conservation can therefore write condition checks without being able to touch the loans.

What is attached to the object is not only the fact that it belongs to the event, but also details that apply only to this object in this event: role or catalogue number, source, note, the “uncertain” flag and the order. The same exhibition can carry catalogue number 12 on object A and 13 on object B.

A link can also be project-specific. Global is the default (Global is the default: the link is visible in every project.); with This project only you can restrict it to one project.

Why this matters for standards

LIDO describes the object history in event nodes, which is exactly the structure the event pool already has. That is why events are a source of their own in the standard binding. You do not bind fields; you state that the native events are to be used, filtered to certain types if needed. Without a binding, all of them are output.

This goes further than it first seems. The loan data from EODEM (insurance value, handling instructions, climate requirements, hazardous materials) are typed measurement and note entries on the event in LIDO. No standard-specific fields are needed for this, only entries with the matching types.

What this means for your work

Create exhibitions once and link them many times. The way to do this is called Create from project: choose the project, give a title (otherwise the project name is used), Create & link. Moliri creates a shared event and links all objects of the project. Run it again and it only links the new additions.

Read the warning before editing. If you correct the title of a shared event, you correct it on all objects. Anything that should differ only on this one object belongs in the link details, not in the event.

The history knows about events. Linking, changing and removing a link, reordering, and creating and deleting all appear in the history.

Further reading