Steven> We also consider it axiomatic that no event is "momentary": all temporal events have duration. Martin> "momentary events" are a fiction of computer science. A basic requirement for the CRM is that it is scale-invariant. > There is no smallest granularity for events we could easily point to.
That's why I put "momentary" in quotes. My point is that Birth & Death are (several) orders of magnitude smaller than Life. All time-points of Birth must be close to the *begin* points of Life. (Birth.P82a & P81a & P82a & P82b must both be close to Life.P82a & P81a) It doesn't matter whether you'll consider Birth a momentary event, or daily, or 9-monthly: under any reasonable scale assumption (uniformly applied to Birth and Life)), this peculiar relation between Birth and Life will hold. And this is no coincidence: Birth/Death are the start/end events of Life. From some "cultural-topological" viewpoint: - Birth/Death are spatiotemporal points, if Life is a spatiotemporal curve - Birth/Death are spatiotemporal spheres, if Life is a spatiotemporal "curved cylinder" > Allen relationships have only temporal meaning, they are accidental Exactly: currently there's no good way to express the peculiar relation between Birth and Life. If the Allen property holds (<Birth> P116_starts <Life>), it does not constrain the *end* points of Birth sufficiently. <Life> P116_starts <Life> is just as true (though vacuous) as <Birth> P116_starts <Life>. Martin> life of a person is one of the candidates for a period with start/end events, but, is it a "Period" or just the spacetime volume of the person? I'm just digging through CRMgeo, so I know what you mean, and I think it is the spacetime volume. And Birth/Death are the start/end of that volume... So why in CRM we can talk about the start & end, but we can't talk about the volume as a whole? Whereas in CRMdig it's the opposite: we have crmgeo:SP8_Spacetime_Volume but we cannot talk about its start/end points. Do volumes have innate start & end? Well surely Time-Spans do. Steven> we have taken the design approach of not modelling condition states as they tend to lead to monotonicity problems > when combining different data streams... > it is always better to calculate at query time what the current state of > knowledge indicates is the period that a state existed. Martin> The problem with states, such as "period of use" is the open world semantics: What is actually observed knowledge, and what is inference? I feel like I should be able to grok what this means, but I am not able to. Could you please give an example? > See the CRM Sci extension just published on the CRM site for a definition of > states Ah, maybe I can read it during the St George's holidays :-) Dominic> The moment that we start to talk about, "there is no standard way" or it would be "more economical", alarm bells are raised. > tendency to provide a one-dimensional approach prioritising optimisation, > performance and ultimately superficially > over representing knowledge as validly as possible Well, let's see: 1. CRM has: <monarchs> P107_has_current_or_former_member <George_of_Saxony> 2. I propose eg: <George_of_Saxony/reign> a E102_Membership; P201i_is_membership_of <George_of_Saxony>; P202i_is_membership_of <monarchs>. 3. CRM has: <George_of_Saxony/ascension> a E85_Joining; P143_joined <George_of_Saxony>; P144_joined_with <monarchs>. <George_of_Saxony/death> a E86_Leaving; P145_separated <George_of_Saxony>; P146_separated_from <monarchs>; My proposal is an intermediate level of detail between what already exists in CRM. Seems to me that I'm covered on both ends ;-): neither too simple, nor too complex. In your view, are all CRM shortcuts a bad thing? Or only the ones that I'm proposing? > The CRM has been developed precisely to support the fact that you cannot make > sweeping assumptions across it What is the sweeping assumption that I am making? On the contrary, I would call your reply a sweeping generalization.
