[Crm-sig] ISSUE 240: Start/End vs Period of Existence

Vladimir Alexiev 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;
  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.

More information about the Crm-sig mailing list