OpenAtlas

For alias we used something like this:

setattr(self.form_class, 'alias', FieldList(RemovableListField()))

Currently, we store the creator and licensor as text strings in an additional database table.

For images, we want/need to have multiple license holders and creators (either E21 Person or E74 Group), as noted in the ticket description. The "pure" CIDOC path would require creating an E65 Creation event to link the image to the creator(s). This approach, while technically correct, can clutter our database with events that are primarily for metadata rather than the actual project data. Additionally, it mixes metadata with the core data.

The current correct CIDOC CRM path for a creator would be:

• E31 Document -> P94 has created -> E65 Creation -> P14 carried out by -> E21 Person/E74 Group
• E31 Document -> P105 "right held by" -> E21 Person/E74 Group

In my opinion, there are two solutions:

Solution 1: Model Shortcut¶

The proposed solution is to introduce a new OpenAtlas system class, such as metadata or licensor and creator, and a new shortcut to simplify the data model. This keeps the metadata separate from the core data and avoids the creation of numerous E65 Creation events.

The proposed shortcut path for creation is:

• E31 Document -> OA11 "was_created_by" -> E21 Person/E74 Group (OpenAtlas class metadata)
  instead of
• E31 Document -> P94 was created by -> E65 Creation -> P14 carried out by -> E21 Person/E74 Group

• E31 Document -> P105 "right held by" -> E21 Person/E74 Group (OpenAtlas class metadata)

• It prevents cluttering the database with additional tables.
• We can stay within the CIDOC context by creating a well-documented shortcut that can be resolved in the API.
• It will allow us to easily expand the creator/license holder information with additional features like links to GND or Wikidata.
• I believe this will require minimal changes to our existing views and data-gathering processes, as most of them use the OpenAtlas classes rather than the raw CIDOC classes.

Solution 2: Separate Metadata Tables¶

An alternative solution for handling image metadata (creators and license holders) that operates in parallel to our core OpenAtlas data model is to create two new dedicated tables, for example: file_metadata_entity and file_metadata_links.

• file_metadata_entity table: This new entity table would store information about the creator or license holder. It would contain columns such as:
  • id
  • name
  • cidoc_class (to distinguish between an E21 Person and an E74 Group and therefore see if it is an organization or a natural person)
• file_metadata_links table: This link table would connect the files to their corresponding metadata. It would have the following columns:
  • id
  • file_id (linking to the file/image entity)
  • metadata_id (linking to the entry in the file_metadata table)

This setup creates a parallel system specifically for image metadata.

This solution does not interfere with or require changes to our existing CIDOC CRM-based model. It keeps the metadata completely separate from our core historical and archaeological data.
However, it requires the creation of two new tables, which could potentially clutter the database schema. It would also be more complex to expand this with features like linking the names with GND or Wikidata.

Conclusion¶

Both are valid solutions, but I would prefer option 1 for better expandability and also for easier maintenance. Let's discuss this at the next developer meeting.

Both solutions have one big issue to solve: how to enter the data. If we enter the data like in the alias field, we cannot select existing entities. If we have a MultiTreeField like the types, we would have to enter the data before, OR we could just add a "+Actor" button, with a simple input view, similar to how we handle other type fields.

I was just about to take a look with Katharina at it so thanks for the timely update.

I understand that you prefer solution 1 and there are good arguments for it. The main challenge I see with this approach is mixing of project relevant data with information needed "just" for licensing of e.g. scans or similar.
E.g. think of a project about the middle ages with locations around Constantinople. If than someone enters a person from now who did a scan with a residence in Australia this would mess up map views, social network analyses and similar.

But as you correctly noted we have a developer meeting soon and should discuss it there.

Alexander Watzinger wrote in #note-6:

I understand that you prefer solution 1 and there are good arguments for it. The main challenge I see with this approach is mixing of project relevant data with information needed "just" for licensing of e.g. scans or similar.

That is why an extra OpenAtlas system class has to be introduced, so the entered Persons and Groups doesn't show up in other views. But yeah, this is a good topic for the meeting.