Project

General

Profile

Actions

Feature #2634

closed

Removal of creation and event class, changed acquisition

Added by Bernhard Koschiček-Krombholz 3 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Category:
Backend
Target version:
Start date:
2025-10-06
Estimated time:

Description

Currently there are 7 different classes for events which was the source of confusion and inconsistent data entry.
After some consideration we decided to remove the classes Event (E5) and Creation (E64) and simplify Acquisition (E8).
The remaining event classes are Activity (E7), Acquisition (E8), Modification (E11), Move (E9) and Production (E12).

Event

Event (E5) classes will be transformed to Activity (E7).
Initially we introduced Event (E5) to enter events without actors (e.g. a natural disaster).
But beside the difference being more superficial it was also a little awkward to use this class which is the super class of the other event classes, e.g. Events can't be chained with continued (P134) like the other ones.

Creation

Creation (E64) classes will be transformed to Production (E12).
After analyzing existing data we noticed that in most cases, the Creation event was not used in the indented way, but used for the Production of an artifact, e.g. the writing of a document (Source), which the Production event is for.
Only drawback of the transformation will be that has created (P94) will be removed. It was meant to track creators of a Document (E31) but this can also be done while adding creators to a Document (called File in OpenAtlas, e.g. a scan or a photograph) directly in the UI.
We might add Creation again when implementing a more user-friendly version of authorship (#2570).

Acquisition

The linking of donors and receivers at Acquisition (E8 via P22 and P23) was simplified: they can now be added/removed directly at the acquisition form which makes data entry much easier and more intuitive.
But a side effect of this will be that no additional link information can be added and existing ones will be removed so you might watch out for that:
  • Link dates: these doesn't make much sense anyway, e.g. a donor at an acquisition will always be the donor of that acquisition.
  • Link type: this often was used to additionally mark e.g. a donor as donor which isn't needed
  • Link description: this could have been used to add additional information

We assume that in most cases this information was left blank or isn't needed. This could be checked by e.g. looking at the database table model.link and filter for property_code P22, P23.
But in case extra information is needed, e.g. that the donor was present at the event and was the initiator, this person should also be added as an participant (via the participant tab) where additional information about the participation can be provided.

Actions

Also available in: Atom PDF