[Crm-sig] ISSUE 240: Start/End vs Period of Existence
vladimir.alexiev at ontotext.com
Tue Apr 22 17:57:53 EEST 2014
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;
3. CRM has:
<George_of_Saxony/ascension> a E85_Joining;
<George_of_Saxony/death> a E86_Leaving;
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.
More information about the Crm-sig