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 think your other examples can also be resolved without any changes to the CRM:- - from project management: cost, effort. [These are dimensions of the Thing the project produces.] - from risk management: probability, impact. [These are probably dimensions of the Thing as well. Remember that Things can be immaterial and so the probability that something will happen is a dimension of the idea of the thing happening not a dimension of an Event that has not happened (and indeed may never happen!).] - from accidents and dangerous goods: number of deaths [use death event and count], number injured [this is an activity involving the injured- then count them], area evacuated [Site], number of people evacuated [number of participants in the activity], quantity (and type[E55 Type!]) of good spilled [dimension of the Thing spilt], etc. 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. Hope this helps SdS Stephen Stead Tel +44 20 8668 3075 Mob +44 7802 755 013 E-mail [email protected] LinkedIn Profile http://uk.linkedin.com/in/steads -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Vladimir Alexiev Sent: 17 November 2011 22:36 To: 'crm-sig' Subject: [Crm-sig] ISSUE: "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): <obj/2926> crm:P24i_changed_ownership_through <obj/2926/acquisition/1>. <obj/2926/acquisition/1> crm:P2_has_type rst-event:auction; crm:P23_transferred_title_from rkd-person:P_J_Snijers; crm:P22_transferred_title_to rkd-person:Fierens. crm:P43_has_dimension <obj/2926/acquisition/1/price>. <obj/2926/acquisition/1/price>. crm:P2_has_type rst-currency:; crm:P91_has_unit rst-currency:HFL; crm:P90_has_value 157 . 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 "P39 measured" points to E1, and P43 is a shortcut, I believe it is inconsistent for P43 to point lower than E1. As an added benefit, it will be possible for all E39 Actors to have dimension, e.g.: number of people in E74 Group _______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
