Acquisition, Transfer of Custody, Part Addition, Part Removal
Rembrandt data have the painting Susana belonging to different collections at different periods of time.
To be able to represent this it is necessary to introduce a temporal entity "CollectionBelonging" for instance.
- how would the link between the museum object and the CollectionBelonging be expressed?
- how would the link between the CollectionBelonging and the Collection, which will have location, and other properties, be expressed?
Vlado: We first have to figure out what the data means.
- data for the old (non-current) collections is clear and simpler
- data for the newest (current) collection is more complicated since it involves two museums:
<begindatum_in_collectie> date the object entered the collection 1816 <einddatum_in_collectie> date the object left the collection 2011/01/01 <catalogusnummer> catalog number 147 <collectie_afdrukken> collection print x <opm._verblijfplaats> collection remark Auction catalogue the Hague 18-05-1768 .. <inv.nr._bruikleengever> (MT) inventory number of loan giver "23 (if they want!) So this is also a test comment" <bruikleen_naam> (MT) loan name Rijksmuseum <bruikleen_plaats> (MT) loan place Amsterdam <collectienaam> collection name Mauritshuis <plaats_collectie_verblijfplaats> collection location Den Haag <soort_collectie_verblijfplaats> collection type museum
I think that means: in 1816, Rijksmuseum bought the painting (it's the Owner), but gave it to Mauritshuis for care taking (it's the Custodian). We'll ask RKD.
We should also consider what a "collection" is:
- If it's an actor (E40 Legal Body@crm), we use E10 Transfer of Custody@crm for the caretaker (object_collection@crmg) and E8 Acquisition@crm for the owner (acquisition@crmg)
- If it's a set of objects (E78 Collection@crm), then we use E79 Part Addition@crmg for the object entering and E80 Part Removal@crmg for the object leaving (collection@crmg
- In fact, I think we should consider them both
- We could speak separately about Mauritshuis the organization and Mauritshuis the set of paintings, but I saw no benefit introducing two nodes.
- I see no conflict in treating them the same: there are no "conflicting properties" and the classes are not disjoint:
E1 CRM Entity
E77 - Persistent Item
E39 - - Actor
E74 - - - Group
E40 - - - - Legal Body
E70 - - Thing
E72 - - - Legal Object
E18 - - - - Physical Thing
E24 - - - - - Physical Man-Made Thing
E78 - - - - - - Collection
- How do we know they are not disjoint? Because E21 Person is both E74 Actor, and E18 Physical Thing
The Susana record includes some data about the collections that's actually thesaurus (lookup, permanent) data.
Eg we'd be in trouble if different paintings claim Mauritshuis is in different places (so we'd ignore such claims).
The transient information (object entering a collection) is recorded as Event that is multi-typed with all relevant activity types mentioned above:
Similarly for object leaving a collection.
We also have to record the former and current situation of the object (custody->keeper, Acquisition(title)->owner, collection.location->location):