Project

General

Profile

Actions

Feature #1834

closed

Solve confusing actor relations at move event

Added by Bernhard Koschiček-Krombholz about 2 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Category:
CRM
Target version:
Start date:
2022-10-05
Estimated time:
4.00 h

Description

Question is, if we need the actor selection button and the actor tab. It is confusing to use.
Stefan will ask the CIDOC CRM people what is the right way to understand E9 movement and also why only person but not groups can be moved (when editing the move event directly).

Outcome
At yesterdays developer meeting we decided to leave implementation as is but make user interface and manual clearer.
  • Persons (and artifacts) can be added at the move event directly which will be saved in a more direct CIDOC CRM relation (was moved by). Unfortunately CIDOC CRM doesn't allow this for groups.
  • Additional it is possible to add actor relations via the actor tab which is a more "general" relation (participated at) but will be the only option to "move" groups.
  • We will adapt form labels and manual to make this clearer
Actions #1

Updated by Bernhard Koschiček-Krombholz about 2 years ago

  • Subject changed from Problem with move event to Confusion with move event and actor
Actions #2

Updated by Alexander Watzinger about 2 years ago

  • Subject changed from Confusion with move event and actor to Confusing actor relations at move event
  • Description updated (diff)
  • Category set to CRM
  • Status changed from New to Assigned
  • Assignee changed from Alexander Watzinger to Stefan Eichert

As soon we get an answers to the question to the CIDOC CRM people (thank you Stefan for taking care of this), we will decide how to proceed.

Actions #3

Updated by Alexander Watzinger almost 2 years ago

This issue is laying around for some time. To keep the question simple: is there any reason to keep the option to add actors at a move via the edit form?
Actors can already be added via the tab, can have own dates, types, ... and also it is possible to add persons and groups (instead of just persons).
In case we dropping this I can write an SQL statement to transform existing entries so that no information gets lost.

Actions #4

Updated by Alexander Watzinger over 1 year ago

  • Target version set to Wishlist
Actions #5

Updated by Alexander Watzinger about 1 year ago

  • Target version changed from Wishlist to 8.0.0

Not sure why I put this on the wishlist (4 month ago). However, I now think we solve this rather sooner than later so I put it on the roadmap.
@Stefan Eichert: are there any updates on this?

Actions #6

Updated by Stefan Eichert about 1 year ago

Regarding the CRM, Move events can only target Physical Things E19 or subclasses such as biological objects E20 (which includes actors E21) with P25 "moved / moved by".
This defines which entity was moved by the move event.
In the CRM definition groups cannot be moved, as they are no subclass of E19.

We asked George Brusecker about this and he pointed us to: https://chin-rcip.github.io/collections-model/en/target-model/current/staying-event

For now the answer is, that groups cannot be moved by a move event.

The other thing is, that any actor can participate at or carry out an event. So any actor (including groups) can be connected to the move event but not as the moved entity.

Actions #7

Updated by Alexander Watzinger about 1 year ago

Thank you Stefan for the update and additional information.
Main question would be if we could drop the Person field at insert/update of a move event to make it less confusing.
Like said, actors can be added by via the actor tab, even groups, and it is possible to add more information there (e.g. dates) anyway.
So I would suggest to drop the person field and transfer all existing connections (via the person field) to a participated at link.

Would the removal of the person field be ok for you too or have I missed anything?
Thank you for looking into this.

Actions #8

Updated by Stefan Eichert about 1 year ago

If we remove the person field, we would need to add an "moved by" option to the actor selection then instead to make sure that the Person is linked via "P25" and not only as participant "P11"

Actions #9

Updated by Alexander Watzinger about 1 year ago

Thank you for the feedback.

If we play it like that it would mean that groups can't move.
I would argue that it is implicit that participants at a move event have moved, it would also allow for "moving" groups.
Anyway, because it seems that this needs more discussion I put it on the agenda for next developer meeting.

Actions #10

Updated by Alexander Watzinger about 1 year ago

  • Subject changed from Confusing actor relations at move event to Solve confusing actor relations at move event
  • Assignee changed from Stefan Eichert to Alexander Watzinger
As discussed in yesterdays developer meeting we keep the implementation as is but try to make it more comprehensible:
  • Rename labels of artifact and person to moved artifact and moved person
  • Update the manual section accordingly
Actions #11

Updated by Alexander Watzinger about 1 year ago

  • Tracker changed from Question to Feature
Actions #12

Updated by Alexander Watzinger about 1 year ago

  • Description updated (diff)
  • Status changed from Assigned to In Progress
Actions #13

Updated by Alexander Watzinger about 1 year ago

  • Status changed from In Progress to Closed

I updated labels and manual entries (including tutorials) regarding the move event like discussed.

Actions #14

Updated by Alexander Watzinger about 1 year ago

  • Estimated time set to 4.00 h
Actions

Also available in: Atom PDF