Excellent questions. In our mapping of the Rembdandt database we "overload" classes in some cases, examples are below. Comments and critique are most welcome !!!
1. Collection as both Actor and Collection We treat them as both: - E39 Actor, so we can use E10 Transfer of Custody for the keeper and E8 Acquisition for the owner - set of physical objects (E78 Collection), so we can use E79 Part Addition for the object entering and E80 Part Removal for the object leaving rkd-collection:Mauritshuis a crm:E78_Collection, crm:E39_Actor; # not certain whether crm:E21_Person or crm:E40_Legal_Body crm:P52_has_current_owner rkd-collection:Mauritshuis; # self-link crm:P50_has_current_keeper rkd-collection:Mauritshuis; # self-link crm:P109_has_current_or_former_curator rkd-collection:Mauritshuis; # self-link crm:P1_is_identified_by [crm:P3_has_note "Koninklijk Kabinet van Schilderijen Mauritshuis"@nl, "Royal Cabinet of Paintings Mauritshuis"@en]; crm:P2_has_type rkd-collection:museum; crm:P74_has_current_or_former_residence rkd-place:TheHague; # Actor location crm:P55_has_current_location rkd-place:TheHague. # Collection location We could speak separately about Mauritshuis the organization and Mauritshuis the set of paintings, but pragmatically it's better to use just one node. I see no conflict in treating them the same: there are no "conflicting properties" and the classes are not disjoint (e.g. E21 Person is both E74 Actor, and E18 Physical Thing). 2. Object entering/leaving collection Because of 1, we can use one multi-typed event (E79, E10, E8) relating to both Actors and Collections: E.g. entry in collection: <obj/2926/collection/5/entry> a crm:E79_Part_Addition, crm:E10_Transfer_of_Custody, crm:E8_Acquisition; crm:P111_added <obj/2926>; crm:P30_transferred_custody_of <obj/2926>; crm:P24_transferred_title_of <obj/2926>; crm:P110_augmented rkd-collection:Mauritshuis; # domain E79_Part_Addition crm:P29_custody_received_by rkd-collection:Mauritshuis; # domain E10_Transfer_of_Custody crm:P22_transferred_title_to rkd-collection:Rijksmuseum; # domain E8_Acquisition crm:P4_has_time-span <obj/2926/collection/5/entry/date>. <obj/2926/collection/5/entry/date> crm:P82_at_some_time_within "1816"^^xsd:gYear. 3. Document as both conceptual thing (E31) and its physical embodiment (E84) (The db speaks about its location, size etc; so we need a physical thing) I hope it's not wrong to mix the two, they have a common parent: crm:E71_Man-Made_Thing <obj/2926/document/1> a crm:E31_Document, crm:E84_Information_Carrier; crm:P128_carries <obj/2926/document/1>; # the physical document (E84) carries its conceptual self (E31) crm:P2_has_type rkd-documentation:X-ray_film; crm:P50_has_current_keeper rkd-collection:Mauritshuis; crm:P55_has_current_location [crm:P3_has_note "conservation studio"]; crm:P43_has_dimension <obj/2926/document/1/height>; crm:P43_has_dimension <obj/2926/document/1/width>. <obj/2926/document/1/height> crm:P2_has_type rst-dimension:height; crm:P91_has_unit unit:Centimeter; crm:P90_has_value "30"^^xsd:double. <obj/2926/document/1/width> crm:P2_has_type rst-dimension:width; crm:P91_has_unit unit:Centimeter; crm:P90_has_value "40"^^xsd:double. -- > recommendations for the implementation of ... property quantifiers Do you mean "P3.1 has type" and the like?
