On 29th CRM – SIG meeting Ritchard Light have commented about date recording in Linked Data design pattern, especially "How should dates relevant to cultural history be recorded?". He mentioned the following:
About context
Historical dates are rarely exact, unlike the date/time values (often computer-generated and accurate to the millisecond) which are routinely used in contemporary applications. There are two aspects to this inexactness:
– The event described by the date may have a significant duration
– The precise value of the date may not be known for certain. It is common practice to record just a year, or a range of years. Entries such as "c.1850" are often encountered
Dates may be a long way in the past, so it must be possible to record e.g. "25000 BCE".
Dates may be recorded using the Gregorian, Julian or some other calendar.
About solution
Convert all values to the proleptic Gregorian calendar, and allow the year 0000 (see[1] for details).
Express each date value using W3C date syntax [2]. Use the appropriate datatype, e.g. gYear if only the year has been recorded. Do not introduce spurious accuracy. The datetime datatype should only be used where an exact time has been recorded.
These dates should be expressed as an instance of the CRM class E2_Temporal_Entity. This can be expressed directly within the RDF, or referred to via a Linked Data URL which denotes the date. (In the latter case, the structure described here will be found when the URL is dereferenced.)
Where a single date is provided, use the property P82_at_some_time_within to specify the time span.
Where a range of dates is provided, use the properties P82a_begin_of_the_begin and P82b_end_of_the_end to specify the start and end points.
Use CIDOC CRM property P4_has_time-span (or P4i_is_time-space_of) to relate this time span to an E2_Temporal_Entity.
A short description about them will be added to the beginning of the rdfs CRM file.
Posted by Vladimir on 19/4/2014
(An issue that arose at public-esw-thes@w3.org 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
You may find Vladimir's proposal about CRM-start-finish-period here.
Steve Stead wrote on 19/4
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
Posted by Martin on 19/4/2014,
Good initiative, but a lot of these things have been discussed in length in CRM-SIG, and recently we have entered a discussion about start events of periods. I'll point you to respective literature, please have a look at that.
Please do not propose too many things at a time, it makes it difficult to manage the issue.
In continuation of Stephen: Yes, it is intentional that states that can only be acquired by explicit events, such as ownership, membership etc., are described by these events. This is to ensure monotonicity under increase of incomplete, but consistent knowledge. True life-long observation is extremely rare, therefore most such states are concluded from events. If this is the case, these should be documented, and not the states. The states should be deductions, and any user of the CRM is free to introduce such deductions.
"Modeling such Periods of Existence is significantly more economical than modeling with Start/End events. "
This is no argument. Firstly, the size of all metadata together are a negligible fraction of image data we keep. Secondly, these events are the hooks for other, distinct, historically relevant information. Birth and death have quite different contexts and actors involved.
Not all periods can have start or end events. Simply, because the event itself has a duration as a fact of physics, and this creates and infinite recursion. To define properties is easy. What we need is an understanding of the semantics of "starting something". Is there an concept of cause or occasion? How does a start event behave in space-time?
See in particular:
1. Doerr, M., Kritsotaki, A., & Stead, S. (2005). Thesauri of historical periods - A proposal for standardization. In Proceedings CIDOC '05 Conference, Zagreb, Croatia, 24-27 May.
2. Doerr, M., Kritsotaki, A., & Stead, S. (2004). Which Period is it? A Methodology to Create Thesauri of Historical Periods. Computer Applications and Quantitative Methods in Archaeology Conference, CAA2004, Prato, Italy, 13-17 April.
"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.
You write:
"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"
Use of an identifier and the floruit of a person is explicitly modelled in FRBRoo v2.0.
The problem with states, such as "period of use" is the open world semantics:
What is actually observed knowledge, and what is inference? This distinction is the "soul" of the CRM. See the CRM Sci extension just publioshed on the CRM site for a definition of states. Expecting your comments.
See also Doerr, M., & Hiebel, G.H (2013). CRMgeo: Linking the CIDOC CRM to GeoSPARQL through a Spatiotemporal Refinement. here.
Finally, events and temporal knowledge is fuzzy. Allen relationships have only temporal meaning, they are accidental.
See also:
Doerr, M., Plexousakis, D., Kopaka, K., & Bekiari, Ch. (2004). Supporting Chronological Reasoning in Archaeology. In Computer Applications and Quantitative Methods in Archaeology Conference, CAA2004, (pp. 13-17).
For dealing with fuzzy boundaries.
Indeed, 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?
Posted by Dominic on 21/4/2014
From a slightly more high level perspective I have the following observation triggered by something that Martin put in his response but based on a number of emails to the list over the last couple of years. Given the increase in the use of and interest in the CRM I hope that it is useful.
Cultural Heritage data is multi-layered and highly variable. Curatorial, multiple disciplinary perspectives and research requirements contribute to these characteristics. The moment that we start to talk about, "there is no standard way" or it would be "more economical", alarm bells are raised. While efficiency can be beneficial without being detrimental the desire of technologists to standardise cultural heritage data is exactly the reason why we need the CRM.
The CRM has been developed precisely to support the fact that you cannot make sweeping assumptions across it and that representations must be based on expert domain analysis rather than what might be easier for a programmer. The historic quest for standardisation by technologists is a significant factor in explaining why many cross-organisational cultural heritage systems have been unsuccessful (finally recognised by people who worked on these systems in the 1990s and resulting in the clear need for the CRM).
Humanities scholars are often disillusioned by computer information systems because of the tendency to provide a one-dimensional approach prioritising optimisation, performance and ultimately superficially over representing knowledge as validly as possible. It is a mistake to think that cultural heritage experts want these things in preference to this integrity. In any event it is easy to implement the CRM without compromise (through collaboration) and produce highly usable and accessible systems. There is no need to artificially standardise the CRM in a way that compromises its raison d'etre.
Unless software starts to reflect the methods and understanding that underpin the work of cultural heritage researchers and academics (this means that computer system experts need to work with and collaborate with humanities experts) then it is unlikely that computer systems will contribute significantly or realise the promise that those involved in humanities computing thought that they might many decades ago.
Posted by Vladimir on 22/4/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.
Posted by Vladimir on 23/4/2014
Martin> Use of an identifier and the floruit of a person is explicitly modelled in FRBRoo v2.0.
Thanks! I see it now (F51 Floruit)
– in BM we modeled Profession and Nationality as a group.
– It's interesting that Floruit has something very general: R59 had typical subject: E1 CRM Entity
– In contrast, F52 Name Use Activity has R62 was used for membership in: E74 Group, and R61 occurred in kind of context: E55 Type
– If Floruit is modeled, surely Life merits to be modeled Then again, it's a simple case of Floruit, one with e.g. P2 has type:
Yes, it is intentional that states that can only be acquired by explicit events, such as ownership, membership etc., are described by these events. This is to ensure monotonicity under increase of incomplete, but consistent knowledge.
After reading CRMgeo and these emails a couple of times, I now grok what's "monotonicity of states".
What I called "Periods of Existence" are Spatiotemporal Volumes.
These can be discontinous, right? One can start an activity, suspend it, continue it somewhere else, etc.
The monotonic accumulation of start/end events corresponds to potentially non-monotonic update of Spatiotemporal Volumes (split into smaller volumes, remove some part).
OWLIM rules are monotonic, so I agree with the goal to uphold monotonicity.
events are the hooks for other, distinct, historically relevant information.
Birth and death have quite different contexts and actors involved.
Agree.
How about this Floruit: "Being a set and costume designer, a painter, an illustrator, and a poet in Russia and France in the first half of the 20th century [general fields of activity of Natalya Goncharova]"
Maybe it's interesting and historically relevant who helped her become a costume designer, and what caused her to stop being a costime designer?
I'm concerned that you end up with many ideosyncratic solutions, and no common pattern:
– E15 Identifier Assignment is two start/end events in one: deassignment of old identifier, and assignment of new one.
– F52 Name Use Activity is a period of use (spatiotemporal volume = period of continued use of an Appellation)
– both are subclasses of E13 Attribute Assigment
I find this confusing:
– If I say the time-span of F52 Name Use Activity is from 2000 to 2014, it means someone used that name for a period of 14 years.
– But if I say the same of E15 Identifier Assignment, it means whatever committee did this assignment, really took their sweet time and were in no hurry (14 years to decide .
And I can attest that Josh@BM got confused, he thought assigned/deassigned of E15 somehow mean start/end, but they mean new/old
Or consider modeling the military service of <Binns> a Person in <USMC> a Group:
http://en.wikipedia.org/wiki/Ricardo_C._Binns
It can be done with these statements:
<joining> a E85 Joining; P143 joined <Binns>; P144 joined with <USMC>; P4 has time-span [P82 "1963"]
<leaving> a E86 Leaving; P145 separated <Binns>; P146 separated from <USMC>; P4 has time-span [P82 "1966"]
Or this one:
<floruit> a F51 Floruit; P14 carried out by <Binns>; R59 had typical subject <USMC>; P4 has time-span [P82a "1963"; P82b "1966"]
Observations:
– Monotonicity means that the <floruit> is stronger: also means there were no intervening leaving/joining between 1963-1966.
If there were (like for this nicely moustached fella http://en.wikipedia.org/wiki/Henry_Pierson_Crowe) then we'd need to model the Floruit as a discontinuous Period (having parts).
– <joining/leaving> are stronger than <floruit>, since joining/leaving express Membership, while R59 is only some general kind of relatedness.
I'd say: John Dover Wilson's activity as a Shakespeare scholar (F51) R59 had typical subject William Shakespeare (F10) is quite different from: Ricardo Binns' activity as a USMC soldier
– R59 is not a subprop of P14 carried out by, nor P107 has current or former member.
So if you want to query both, you need branches in your query, or Fundamental Relations to do it
– Note: R59 says it's Subproperty of:
P2 has_type / P92 brought into existence (was brought into existence by): E77 Persistent Item.
P2_has_type/ P94 has created (was created by): E89 Propositional Object.P129 is about (is subject of): E1 CRM Entity
which is some confused property chain notation, but surely it can be stated explicitly too
– Most importantly, there's no way to relate these two styles
True life-long observation is extremely rare, therefore most such states are concluded from events. If this is the case, these should be documented, and not the states.
I think this is not borne out by actual documenting practice in many cases.
Maybe nobody checked if Binns was actually a soldier every month between 1963-1966, or whether Leonardo actually painted every month during his career as a painter, or whether the Maori actually used <particular Maori term> every month of <particular Maori term>, or whether Michael Dukakis has been a member-in-good-standing of the ACLU ever since he joined.
But this won't stop biographers from making floruit statements, nor did it stop George H. W. Bush from accusing Michael Dukakis during the 1988 presidential campaign of being a "card carrying member of the ACLU" http://en.wikipedia.org/wiki/ACLU#Allegations_of_bias
http://en.wikipedia.org/wiki/Michael_Dukakis#Crime_issues
"Modeling such Periods of Existence is significantly more economical than modeling with Start/End events. "
This is no argument. Firstly, the size of all metadata together are a negligible fraction of image data we keep.
I mean firstly people economy, and only secondly computer economy.
Why do biographers make catch-all floruit statements? Because it's more economical, and it's generally/approximately true. (And life's too short.)
(Sorry can't resist: THAT is no argument. Image data is processed in fundamentally different ways from triples. Or are you doing everything possible to get Cultural Heritage to classify under EC's Big Data funding lines?
Not all periods can have start or end events.
What we need is an understanding of the semantics of "starting something".
Is there an concept of cause or occasion? How does a start event behave in space-time?
It IS causative, and because of the causal-chronological coherence of time, we know how it behaves in time.
I'm not saying all periods should have start/end; nor all start/end necessarily need a period. I am saying that CRM should offer a means to connect them (when present), causatively. But, I'm not very good at topological epistemology (or whatever this should be called
I'll try to check the other references you provided (but not CRMsci within a week.
Cheers! V
PS: There is an old Italian proverb that says, "Everything has an end except salame which has two." Because no matter which direction you start, it always ends!
Look here and salivate http://blog.needsupply.com/2014/03/02/salami-friday/
The important thing to discuss is what the semantics of "starts" and "ends" are.
We adopted Allen's temporal logic, probably prematurely, thinking we could rely on a well received theory. In the meanwhile, it turns out that Allen's logic does not work properly both for fuzzy dates and for incomplete knowledge. There are temporal relations which come from observation, but can only be represented by OR combinations of Allen's relationships. That causes problems in RDF - we need superproperties of Allen's to represent an OR. The other problem is that equality in time can only come from numerical declaration of a date, but not from observation, except if the event is identical.
If we remove exact equality, we can create a set of observable relationships purely in time.
Then we can think of more causal relationships.
The meaning of "starts / finishes" in Allen's relationships appears to be that of an initial or final phase. No assumptions about orders or magnitude. We use this to say:
Early Minoan "starts" Minoan, etc. In that case, as you suggested, it implies parthood, but not a "starting" in your sense.
There are other cases, in which the start of a Period is marked by scholars by an event, which does not necessarily imply it was the reason for what follows, such as the lightning that burned the palace in Beijing in 1425(?), which was taken as sign of the heaven for China to stop exploring the oceans.
For us most relevant are wars. For instance, the taking of Antioch by the Crusaders http://en.wikipedia.org/wiki/Siege_of_Antioch ended the muslim rule in the city and started the new rule. It has a detailed history of its own. The battle cannot easily be taken as part of either period, even though we may have to regard the battle actaully as the overlap of both periods. This proceeds over time through the space of the city itself.
Must any point in the space of a period be reachable by a messenger of that time from the start event? (doves!).
If pregnancy starts life of a human, birth can be seen as the end of the start of life. We need clear semantics to decide what "starts" means. Pregnancy is an event for the mother and the embryo.
Before talking about momentary or not start events, let us consider what the needs are to increase the CRM, which is already so big that we loose most of our potential customers.
Comments/ ideas welcome!
On 22/4/2014 5:57 μμ, Vladimir Alexiev wrote:
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)
– Start/End are considered "momentary" events, thus have only 2 points (P81a=P82a, P82b=P81b)
This is a misinterpretation I fear. P81a/b may be unknown, but never equal to P82.
>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"
This is a major violation of interoperability.
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 (
>
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?
If you replace these events with the state B, and then you learn that there was another pair in between, B->A, A-> B, , hence you have to delete state B, introduce B1, A, B2, even though, no contradictory knowledge was encountered. This is "non-monotonic". This must not happen, because we cannot easily decide in a semantic network if the state was observed or inferred. This is why in the CRM we do not want to model the inferred states, but leave it to the application. For data transfer, inferred knowledge must be removed. We use shortcuts only, when there is a strong practice of representing the shortcut only, and the implied events are either too unclear or unlikely to have an essential role in the cultural-historical discourse. Shortcuts are not the states in between, they are timeless properties.
Hi Vladimir,
We are converging.
We would in any case require activities at least intentionally not to stop. In case the "floruit" splits in different phases or very different fields, it should be more than one floruit instance per person. This may need more precise definition of identity conditions.
"Life" as pure spacetime volume is pretty useless to connect events to a person. Obviously, all events a person was present at intersect with its life. So, there is no additional information in modelling "life". When do you need it really?
>On Wed, Apr 23, 2014 at 4:08 PM, martin
>We adopted Allen's temporal logic, probably prematurely, thinking we could rely on a well received theory. In the meanwhile, it turns out that Allen's logic does not work properly both for fuzzy dates and for incomplete knowledge. There are temporal relations which come from observation, but can only be represented by OR combinations of Allen's relationships. That causes problems in RDF - we need superproperties of Allen's to represent an OR.
>The other problem is that equality in time can only come from numerical declaration of a date, but not from observation, except if the event is identical.
Hayes, PJ (1996) A Catalog of Temporal Theories. Technical Report UIUC-BI-AI-96-01, University of Illinois. http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf
Some axiomatizations have been further refined by Gruninger and Ong - see e.g.http://stl.mie.utoronto.ca/publications/colore-time.pdf
See the colore ontology repository at https://code.google.com/p/colore/ e.g.
https://code.google.com/p/colore/source/browse/#svn%2Ftrunk%2Fontologies%2Fapproximate_point
In 31st joined meeting of the CIDOC CRM SIG, ISO/TC46/SC4/WG9 and the 24th FRBR - CIDOC CRM, resolving this issue we decided
(a) P81a, P81b, P82a, P82b should be added to the rdf implementation of CRM with the sense that where a range of dates is provided the “a” in the P81a and P82a will represent the upper bound of a time-span, while the “b” in P81b and P82b will represent the lower bound.
(b) CRM needs no other modelling of states. In CRMSci, there will be a refined model of states
Heraklion, Crete, October 2014