Vladimir I am not trying to answer all your points but I have a couple of comments that may address several of them. In general we have taken the design approach of not modelling condition states as they tend to lead to monotonicity problems when combining different data streams. As far as I can remember a parallel effort by a different research group did try that approach and ran into so many problems with their model that the development effort was abandoned. However, not before we had harmonised the constructs they had with the CRM. Our contention is that it is always better to calculate at query time what the current state of knowledge indicates is the period that a state existed.
We also consider it axiomatic that no event is "momentary": all temporal events have duration. HTH Rgds 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: Crm-sig [mailto:[email protected]] On Behalf Of Vladimir Alexiev Sent: 19 April 2014 12:00 To: 'crm-sig' Subject: [Crm-sig] ISSUE 240: Start/End vs Period of Existence Hi! (An issue that arose at [email protected] under subject Re: TGN place types (broader/narrower spanning ConceptSchemes) and was discussed to some extent between me and Richard Light) There are many "dual" Events in CRM that indicate the Start/End of something: - Beginning/End of Existence - Birth/Death of a person - Identifier Assignment with props assigned/deassigned - Acquisition with props transferred from/to - Transfer of Custody with props from/to - Production/Destruction (not completely dual) - Part Addition/Removal - Formation/Dissolution of a group - agent Joining/Leaving a group There are also events that indicate Start, without a corresponding End event: - Creation (End is not appropriate, since conceptual things are forever) - Type Assignment (IMHO should also have "type deassigned", just like Identifier Assignment) HOWEVER, there is no standard way to state the "Period of use/existence/activity of something", such as: - period of use of an Identifier (Appellation, Title), Type - life of a Person - floruit of a Person - period of group membership or profession of a Person (e.g. reign) One would have to model them as Event/Activity in which the concerned entity participated, with some P2_has_type. We also need to relate the start/end events to the period of existence. P116_starts and P115_finishes almost fit the bill, though they bind only one of the endpoints. E.g. P115: "allows the ending point for a E2 Temporal Entity to be situated by reference to the ending point of another temporal entity of longer duration". P115 makes no relation between the starting points. But Death is *the* end of Life, so *both* points of Death must be strongly related to the ending point of Life. - We could introduce sub-properties: P216 really starts (really started by): "an E2 Temporal Entity (e.g. Birth) is considered to be "momentary", and is the start of a longer E2 Temporal Entity (e.g. Life)" P215 really finishes (really finished by): "an E2 Temporal Entity (e.g. Death) is considered to be "momentary", and is the finish (end) of a longer E2 Temporal Entity (e.g. Life)" - These should be subproperties not only of starts/finishes, but also of forms_part_of : P216_really_starts rdfs:subPropertyOf P116_starts, P9i_forms_part_of. P215_really_finishes rdfs:subPropertyOf P115_finishes, crm:P9i_forms_part_of. (This is optional, we could just use P116 and P115) Finally, we need some rules to relate the 4 time-points (P82a, P81a, P81b, P82b) of the Start/End events to those of the Existence period. I'm not sure what the rules should be... One approach could be that: - Start/End are considered "momentary" events, thus have only 2 points (P81a=P82a, P82b=P81b) - these points correlate to Existence as follows: Start.P82a=Existence.P82a, Start.P82b=Existence.P81a, End.P82a=Existence.P81b, End.P82b=Existence.P82b. Maybe this is a bit naïve, since: - "momentary" is a relative term. Birth could be described as a minute event, usually is described as an the "expected" inequalities P82a<=P81a<=P81b<=P82b do not always hold, see Deducing event chronology in a cultural heritage documentation system (Holmen & Ore, CAA 2009) Modeling such Periods of Existence is significantly more economical than modeling with Start/End events. So I think this is a new important shortcut pattern: one event (e.g. Life) being the shortcut expression of two events (Birth/Death). I expect the classical objection will be raised, that Life is not used often in cataloging practice. But if there's enough interest to have explicit classes for Birth/Death, how can there be not enough interest to have specific class for Life? In the attached Turtle file I've defined a couple of extension classes (Life and Membership) and given some examples. Note that Joining/Leaving are longcuts of Membership, which itself is a longcut of P107_has_current_or_former_member. So it's interesting that we've discovered an expression at intermediate level of detail between super-detailed (Joining/Leaving) and undetailed (P107) I give an example of a king whose reign finishes with his life (descension coincides with Death). It would be interesting to try to model Picasso's creative periods with this machinery, e.g. see http://en.wikipedia.org/wiki/Picasso http://en.wikipedia.org/wiki/Picasso%27s_Blue_Period Cheers! Vladimir
