On 11/29/2024 2:27 PM, BOTTINI Thomas via Crm-sig wrote:
1] The "E85/P143/P144/P144.1" pattern
An almost complete example is given by Yu Lee. "Almost", because the
type of the position ("E55 Butler") is not explicit because the
resource :butler_as_occupation is not linked to the E85 instance. This
would require a P144.1. This is the reason why P144.1 exists.
Rereading the E85 documentation, I wonder *what would prevent 144.1
from becoming a property of E85 *rather than a property of P144 ;-)
E85 would become a kind of ternary entity linking a person, an
institution and a function.
Dear Thomas,
Please look at the quantifications of P144. If an Actor joins more than
one Group in the same event, the property you propose would become
ambiguous.
As it stands now, even multiple Actors may join a Group (P143), but only
in the same role P144.1.
This may *deserve revision*.
Probably more realistic is one Joining event of multiple Actors in the
same Group with different roles.
Then, P144.1 should become a P143.1.
In your proposal we would need a *superevent *to connect multiple actors
joining multiple groups in one event.
Joining a government cabinet is probably a good example for the *need of
a P143.1* , rather than a P144.1.
The superevent makes things more complicated, than the property class,
because the less detailed information will need more classes.
Best,
Martin
--
------------------------------------
Dr. Martin Doerr
Honorary Head of the
Center for Cultural Informatics
Information Systems Laboratory
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)
N.Plastira 100, Vassilika Vouton,
GR70013 Heraklion,Crete,Greece
Email:[email protected]
Web-site:http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
[email protected]
http://cidoc-crm.org/crm-sig-mailing-list
