Hi Tony, I think this issue should be added to frequently asked questions.
Let me a bit comment on that. Tony Gill wrote: > Folks, > > I'm a little concerned about the complexity of the temporal reasoning of > the CRM; it's getting increasingly powerful, offering all kinds of > temporal operators and sophisticated reasoning for disciplines that need > it (such as archaeology), but at the same time it's becoming increasingly > cumbersome for simple tasks, such as recording an individual's birth and > death dates. I agree, that the temporal operators proposed are relatively complex, and we can rediscuss the need for them. They are however additional to the CRM version 2, and version 3.2. Indeed , the examples you give below are all features of the intitial model, so I don't think that at the same time it's becoming increasingly cumbersome for simple tasks. The examples below had such mappings from the very beginning of the CRM. > As an example, here are some example mappings from the RLG Cultural > Materials data model (which I'm currently working on for the meeting): > > 1. Actor Start Date: Actor's birth year, if known. > E39 Actor <P92 brought into existence (was brought into existence by)> E63 > Beginning of Existence <P4 has time-span (is time-span of)> E52 Time-Span > <P82 at most within> E61 Time Primitive Actually you can be more specific here, if it is a physical person which is born. Then you could use "Person" and "Birth". If the RLG model implies groups and persons, your mapping cannot be made more specific. > 2. Actor End Date: Actor's death year, if known. > E39 Actor <P93 took out of existence (was taken out of existence by)> E64 > End of Existence <P4 has time-span (is time-span of)> E52 Time-Span <P82 > at most within> E61 Time Primitive > > 3. Actor Date String: Text version of the actor's lifespan (birth and > death) dates for display, as provided by the contributor. > There is no mapping of this element's semantics to the CRM that I can see, > since there is no shortcut from actor to timespan without going through > beginning of existence and end of existence, and this element combines the > two concepts. There is a mapping for all text strings. The "has note" property. It can be specialized by a type. Text elements are not qualified like numerical database elements for precise formal queries. So we map those to "has note" in the CRM, which is neither less nor more formal, and attach them to the node we took them from. "display strings" are very application specific. If this is an issue, I propose to devote a discussion to that in the next meeting. > I'm not arguing that the model shouldn't support the sophisticated > temporal reasoning, but it seems a little perverse to have to use it for > something as simple as a person's birth and death dates... Couldn't we > have a direct short cut such as E21 Person <P4 has time-span (is time-span > of)> E52 Time-Span? > > Cheers, > > T. May be the first thing that comes to my mind is, that the CRM is not a proposal for a metadataschema. I.e. it is not optimized for minimal storage and a minimal data entry procedures of a specific application case. Rather, it is the common form, into which we can merge all data, independent from their source. In information integration systems, the global schema is normally virtual, only for formulating queries and for data transport between heterogeneous sources. The success of the CRM is to abstract from application-specific simplifications. Without doing that, it would fail as has any attempt before to create a common schema for the cultural domain. Concrete, I do not regard a person's birth date as a simple thing. Try to merge ULAN data with your data base. ULAN does reasoning about all birth- and death related data. Try to automatically convert data, which do not have explicit birth events into a biography of the parents. Things that are simple for one application can make the next step of integration awefully complicated. If we register parents, birth date and birth place, the intermediate node "birth", which seems cumbersome for a single date, becomes a welcome subunit to bring order into the data. Moreover, the CRM does not make use of "nested structures" as many programming languages and advanced databases. The fact, that we put "verbose" links between the intermediate nodes, is not a complication for applications, but an explanation for their meaning. The textual length of a mapping path should not be taken for a measure of complexity, only the number of intermediate nodes, which could be avoided. E.g. if we take out the "Time-Span" entity, the four dates of the CIDOC Relational Model (begin of begin, end of begin, begin of end, end of end) would be flat among all other properties of Event, Period etc., a thing a C or Java Programmer wouldn't do. It would deprive us of the possibility to attach another Time-Span estimation for the same event. BTW, the ABC-Harmony model is equally or more indirect than the CRM. Actually instead of "Time-Span" and "Place", they use an intermediate node "context", which indirects to date and place, as Time-Span does with the dates. This is slightly more symmetric wrt to date and place, but introduces an intermediate between the place also. More important is, that it birth is a physical reality, and that we can have information about birth without dates. Then the simple task becomes insufficient, and we loose information in the easy schema or attach them to nodes not responsible for the information bits. The key element of the CRM is to make all events explicit. They seem to be the critical element for integration. To take out the birth and death events, really not marginal event, may be counterproductive. However, any short-cut you propose is compatible with the CRM, as long as you can define an AUTOMATIC transformation back into the CRM. As the CRM does not prescribe storage, there is nothing cumbersome about registrating a birth date. You do it as before, but the mapping implies some intermediate steps, which are extremely helpful to merge data from completely different sources, and can be created automatically. If you come however about more complex data, the CRM form allows to overcome the problem. The idea to associate a life-span with a Person is a new concept. So far, we tried to avoid "states" in favour of "events". The reason is, that the information about "events" is often more direct than about "states", i.e. more frequently associated with primary historical sources. Which single person would witness the whole life-span of another person? My understanding is, that it is simpler from a logical point of view to regard a lifespan as the conclusion of birth and death events than otherwise round, in particular if there are many opinions on each event, as in the ULAN data. Therefore we recommend to map a life-span to birth and death in a global schema. Anyhow, the issue of states, which are initialized and ended by well-defined events is on the discussion list. Summarizing Tony, I see your mappings as correct, and their complexity as unavoidable but fairly manageable by the appropriate tools, and not a concern for people entering data, given appropriate interfaces. Any revertible short-cuts are a local decision which is compatible with the CRM. I don't think we need to extend the CRM for that. Any comments from archeology? best, Martin > > ---------------------------------------------------------------------- > Tony Gill <> [email protected] > Research Libraries Group <> http://www.rlg.org/ > 1200 Villa Street, Mountain View, CA 94041 USA > Voice: +1 (650) 691-2304 <> Fax: +1 (650) 964-1461 > > martin <[email protected]> > Sent by: [email protected] > 30/01/2002 02:11 AM > > > To: [email protected] > cc: > Subject: Re: [crm-adhoc] Re: [crm-sig] Issue 4, scope notes > > Oops, > > You are probably right. Who volunteers to give it the appropriate cultural > touch? > > Martin > > Tony Gill wrote: > > > > Martin, > > > > I think maybe you are missing mathematics and physics at the moment -- > > this scope note will TERRIFY museum documentation people! > > > > Cheers, > > > > T. > > ---------------------------------------------------------------------- > > Tony Gill <> [email protected] > > Research Libraries Group <> http://www.rlg.org/ > > 1200 Villa Street, Mountain View, CA 94041 USA > > Voice: +1 (650) 691-2304 <> Fax: +1 (650) 964-1461 > > > > martin <[email protected]> > > Sent by: [email protected] > > 29/01/2002 11:45 AM > > > > > > To: [email protected] > > cc: > > Subject: [crm-sig] Issue 4, scope notes > > > > Dear All, > > > > In Paris we decided to add to the E2 Temporal Entity the well-known > > temporal relationships from > > J.F.Allen, 1983, which can be fairly regarded as a standard in Knowledge > > Representation. > > I terms of directed, bidirectional properties as we use in the CIDOC > CRM, > > they can be defined as: > > > > before (after) : E2 Temporal Entity > > meets in time (met-by in time): E2 Temporal Entity > > overlaps in time (overlapped-by in time): E2 Temporal Entity > > during (includes in time): E2 Temporal > > Entity > > starts (started-by): E2 Temporal Entity > > finishes (finished-by): E2 Temporal Entity > > equal in time: E2 Temporal Entity > > > > where the postfix "in-time" is used to disambiguate from spatial or > > spatiotemporal relationships, that appear > > lower in the IsA hierarchy of entities in the CIDOC CRM. > > > > Here my proposal for a scope note: > > > > The temporal relationships relate a Temporal Entity X, the domain, with > a > > Temporal Entity Y, the range. > > Let us denote the real outer temporal bounds for the Entity X and Y by > the > > dates X-,X+ and Y-,Y+, where > > "-" describes the lower and "+" the upper bound. These are the real > > narrowest limits, in which the > > Temporal Entity occurred, independent from our knowledge about them. The > > relationships in parenthesis, > > like (after), are the inverse ones, i.e. those which we obtain by > > interchanging X and Y in the definition. > > > > before (after) : X ended at a date before the one when Y started : X+ < > Y- > > > > meets in time (met-by in time) : X ended at the date when Y started : X+ > = > > Y- > > > > overlaps in time (overlapped-by in time): X started before Y started, > but > > ended within the duration of Y: X-<Y-, Y-<X+, X+<Y+ > > > > during (includes in time): X started and ended within the duration of > Y: > > Y-<X-, X+<Y+ > > > > starts (started-by): X started with Y but ended before it: X-=Y-, > > X+<Y+ > > > > finishes (finished-by): X started after Y but ended simultaneously: > > X-<Y-, X+=Y+ > > > > equal in time: X started with Y and ended with Y: X-=Y-, X+=Y+ > > > > ======================================================== > > > > My intuition about cultural documentation practice leaves me when to > > decide about the application of these relationships > > to spatiotemporal cases, or other dimensions of possible specializations > > of Temporal Entities. > > As we have decided not to attach these properties to the associated time > > spans, there are two possible interpretations: > > > > Given two "bubbles" in Space-Time, like Bronze-Age and Iron-Age, a term > like "overlaps in > > time" > > may mean: > > > > 1) At any given point in space, at any given settlement, Bronze-Age > > overlaps more or less Iron-Age. > > 2) We don't know if at any given point in space, Bronze Age overlaps > with > > Iron-Age, but at least when Iron-Age > > first started in settlement A, Bronze-Age still prevailed in > > settlement B, and when Bronze Age started, Iron-Age has > > not started anywhere, and before Iron-Age ended in the last > settlement, > > Bronze-Age ended in its last settlement. > > > > Both interpretations are equally valid, but I think one of those must be > > culturally more relevant, i.e. > > closer to the phenomena we regard worthwhile documenting. > > > > If interpretation 1) is the relevant one, the relationship "falls > within" > > of E52 Time-Span is NOT synonymous > > with the relationship "during" of the associated Time-Spans, which makes > > some sense. Another aspect is, > > that trivial relationships between known dates need not be expressed by > > explicit temporal relationships. > > Those are only needed for phenomena with nknown absolute dates. > > > > If interpretation 1) is the relevant one, > > "overlaps","starts","during","finishes" imply spatiotemporal overlap - > > in contrast to interpretation 2). This may be wanted. This may make the > > "pure spatiotemporal overlap" > > advocated for in one of my previous messages unnecessary. > > > > If interpretation 1) is the relevant one, "equal" becomes > spatiotemporally > > equal. This may be improbable for > > any real case, except the cultural periods of Atlantis starting end > ending > > with its emerging and drowning in the sea... > > > > A slight modification of interpretation 1) may be even more realistic: > > At any given point in space, at any given settlement, where both, > > Bronze-Age and Iron-Age occurred, Bronze-Age > > overlaps.... > > > > This leaves space for spaces, where the one or the other period did not > > occurr. This renders a "temporally equal" > > different from a "spatiotemporally equal" (or "coocurrent"). > > Alternatively, "temporally equal" may be defined only > > on the associated Time-Spans. > > > > As these operators were required by archeologists, we need a competent > > comment on this issue. > > > > Martin > > -- > > > > -- -------------------------------------------------------------- Dr. Martin Doerr | Vox:+30(810)391625 | Principle Researcher | Fax:+30(810)391609 | Project Leader SIS | Email: [email protected] | | Information Systems Laboratory | Institute of Computer Science | Foundation for Research and Technology - Hellas (FORTH) | | Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece | | Web-site: http://www.ics.forth.gr/proj/isst | --------------------------------------------------------------
