[Crm-sig] Implementation recommendation for disjointness

[Vladimir Alexiev]

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?