How different are Changing Time and Happening Time, really?

Anonymous

Im trying to understand if Changing Time and Static Happening Time are distinct only in implementation but not in concept.

For example:

If we were to model EducationalAttainment of a Person,

We could have an EducationalAttainment knot with various values: Highschool, Bachelor, Master, PhD.

We could then have a historized knotted attribute on the Person anchor that would change over time as the person makes academic achievements.

Alternatively, we could model a Graduation event anchor that has a DateGraduated attribute and tie it to the PersonAnchor and knot that tie with the EducationalAttainment knot and make the Graduation and Person anchor roles identifiers. Conceptually we've modeled the same thing, right?

I understand that in HappeningTime we cannot Time Travel using anchor's machinations. I also understand that in ChangingTime the valid date range cannot itself be historized.

But let's say we ignore anchor's machinations and historization of the date is not needed... Based on concepts alone, these are conceptually equivalent? Specifically ValidTime can be modeled in two different exclusive ways.

You would not, for example want to model both since data would end up repeating. And there is no way to consolidate HappeningTime and ChangingTime.

With ChangingTime the event can't/shouldn't be explicitly modeled but in fact exist implicitly since all change arises from some event.

Are my thoughts about this accurate? Am I overlooking something?

Anonymous

Need to edit this to have only the Graduation role be the identifier:

Roenbaeck

I would say you are correct in that they can be conceptually the same. I would go as far as saying that information in itself has no temporality. It aquires temporality as we model it.

Information may of course contain expressions of time. These can all be considered as happening times. As such, it is possible to model this information using only happening times, in a database that lack all temporal features. However, you will then have to have your own 'machinations' to deal with any temporal considerations you may need to respect.

As it turns out, looking at all those happening times, there are some that represent events when one thing undergoes a change. There are others that represent events when the information itself is corrected. Out of this, a theory of temporal databases was born. Basically, if you can build good 'machinations' life would become easier for the end user when dealing with this type of information.

Anchor Modeling is one theory, in which we differentiate between four types of time: happening time, changing time, positing time, and recording time.

Happening time consists of times of events that take place in the domain being modeled that are left explicit, as attributes, in the model. For example, the date of birth of a person, the date when a concert was held, the dates between which a coupon is valid.

Changing time consists of those events that represent change. Using it, we can capture the fact that things naturally transition between different states. For example, the date when I change my Internet provider, the date when my hair turned gray, the date I got married.

Positing time consists of those events that represent corrections. Using it we can capture the fact that not all information is correct and needs to be corrected. For example the date when I corrected my tax return, the date when I removed the erroneous attending at a concert, since I was at home at the time.

Recording time consists of those events that represent the storage of information in some kind of memory. In a sense, it is the happening time of metadata. For example, the date on which I stored the fact that I removed an erroneous attending at a concert.

Now, of course, changing, positing, and recording could all have been modeled as happening time, in a non-temporal database. What Anchor Modeling brings to the table is that if time is modeled according to these practices, you will get a lot of benefits through 'machinations'. You will get temporal referential and entity integrity. You will get time traveling, and so on...

Note that there are also situations where these times coincide, making it difficult to tell them apart.

As a more extensive example. Imagine a coupon with a happening time indicating how long it should be valid, say until '2014-12-18'. Let's assume that this was decided in a marketing meeting held on '2014-12-01', and that we stored the information in a system on '2014-12-02'.

We have happening time '2014-12-18', positing time '2014-12-01', and recording time '2014-12-02'.

In the next marketing meeting a week later, on '2014-12-08', it is decided that the campaign should be extended over Christmas, so the coupon should instead be valid until '2014-12-26'. It is stored the next day in the system.

We have a change to the happening time to '2014-12-26', with changing time '2014-12-08', but also positing time '2014-12-08' and recording time '2014-12-09'.

A day later it is discovered that what was actually said at the meeting was that the coupon should be valid until '2014-12-28' and not '2014-12-26'. We fix this in the system on the same day.

We have a correction of the happening time to '2014-12-28', with the same changing time '2014-12-08', and the new positing time '2014-12-10', but also recording time '2014-12-10'.

Without the proper terminology, it would be very hard to convey what these times represent.

I hope that explains our point of view with respect to times in general and temporal modeling.

Anonymous

Thank you, this is really quite helpful.

Could you help me get some context around the state of anchor modeling?

From what I can tell, "unitemporal" was the state of the art in anchor modeling in 2011 but it has been largely been made obsolete by concurrent-reliance-temproal (CRT). Or is it not actually obsolete, rather can it be positioned as a viable alternative to CRT with desirable benefits under certain situations?

Was the presentation from I think 2012 on bitemporal anchor modeling pertaining to a project that eventually evolved conceptually and became known as CRT?

Finally, it seems that the resources for CRT are largely the "back to the moment" pdf presentation and an implementation in the modeler for SQL Server. Do any scientific papers exist for it such as this one for unitemporal anchor modeling?

Roenbaeck

Most implementations are still made using "unitemporal" Anchor Modeling. The reasoning is that if you do not need to keep track of the additional information you get from "concurrent-reliance-temporal", people pick UNI for performance and usability reasons. The prices you pay for CRT are a slight hit to performance, additional storage requirements, and a few more things to remember when querying the data. We maintain both UNI and CRT and will keep doing so.

I do, however, believe that people actually need CRT more often than they think.

Yes, that presentation on bitemporal AM actually led to a now obsolete version (BI), which has evolved into the current CRT.

Unfortunately the documentation on CRT is lagging behind. We are working on a scientific paper in which it will be described much like the one you are referencing, but it will not be completed until early next year. I am also intending to make some video tutorials as soon as I can find the time to do so. There is no funding behind AM, so almost all development is done on our spare time, while working with various AM implementations during our day jobs.