P43_has_dimension should apply to E1_Entity, not E70_Thing
The painting "Susanna Bathing" by Rembrandt was sold in 1758 by Snijers to Fierens on auction for the amount of 157 HFL (Holland Florins).
For me the most natural way to model this is to say that the acquisition has a dimension (being the price):
Unfortunately P43 is attached to E70 Thing, so I cannot do that.
Temporal Entities (e.g. Events) cannot have dimensions in CRM (except Duration: P83,P84 of E52 Time-Span). But there are many useful examples of dimensions for events, e.g.:
- from project management: cost, effort
- from risk management: probability, impact
- from accidents and dangerous goods: number of deaths, number injured, area evacuated, number of people evacuated, quantity (and type) of good spilled, etc.
I propose to lift P43_has_dimension to E1_CRM_Entity.
In fact since P39i_was_measured_by is attached to E1 and P43 is a shortcut of it, I believe it is inconsistent for P43 to point lower than E1 (measurement@crmg):
As an added benefit, it will be possible for all E39 Actors to have dimension, e.g.: number of people in E74 Group.
Sent to CRM SIG. Until fixed, we'll use a custom super-property rso:P43_has_dimension:
I believe that this is the wrong approach to modelling sale prices. It is not the event that has the dimension but the object: It has a value measured as part of the sale event.
The number of people in a group should always be calculated at query-time otherwise we end up with monotonicity problems when we combine data sources.
I would be interested to see the actual museum recording practice for these things as they would make very interesting case studies.
In general temporal entities can only be measured in time and all the properties for locating and measuring them in time are already in the CRM.
- Vladimir: how do you explain this: "P39 measured" points to E1, "P43 has dimension" is a shortcut thereof, but P43 points lower than E1?
- Stephen: P43 represents the common shortcut observed in existing documentation systems that measure particular Things
- Vladimir: So P43 is intended for a commonly observed situation, while its longcut P39 is intended for an uncommon situation?
You can Measure anything (even events), but you cannot state the resulting Dimension directly?
I think that judging commonality is subjective business, so this is a shaky cognitive ground...
Stephen's suggestion "was measured as part of the sale event" means the sale is both E8 Acquisition and E16 Measurement (the sale measured the price of the object).
So instead of using a custom subProperty "rso:P43_has_dimension":
We say the sale "observed_dimension" instead of "has_dimension":