Yet another follow-up of the YATO 2012-12-14 meeting.

I made a short description of what the time eco-system might look like.
Of course all comments are welcome.

The picture below is also at high resolution at http://goo.gl/KCq6c.

Time eco-system

My idea about the requested possibilities of the time eco-system might be realized as summarized in the drawing.

There can be many different ontologies (in different colors). Each ontology expresses temporal references as commonly done for the context to which the ontology applies.
We should make a difference between the structure (e.g. field list if applicable: year, month, day in a "normal" calendar, or a localized name in geology) and the instances (e.g. 2012,12,12 or Cretaceous).
Each ontology describes a different time line. Some will have a beginning and an end, some will not.

Two ontologies could be calibrated mutually but this leads to a profusion of calibrations (hard to maintain). Therefore I prefer the usage of an "universal time line" I.e. the time elapsed since some arbitrary (but clever) chosen point back in time. These calibrations are illustrated in yellow.
In order to allow calculations with a calibration there should be at least two calibration points if the units are different.

Illustrating the fact that time instances do not really make sense is done for CM1 where in the Maya calendar we have 1 day represented by 86.400 seconds on the universal time line. Fuzzy limits are illustrated by Gaussians for CG1 and CG2. We can imagine other forms of (mathematically well defined) fuzzy limits (like for the beginning of the Baroque period).

Some ontologies, not represented in the picture, like for sound tracks, are not statically calibrated but dynamically: the calibration is done the moment the music starts (if this is necessary).

Calibrations (or mappings) have a version because new knowledge might change them. There might be several calibrations for the same ontology if there is no consensus among scientists (e.g. for the Maya calendar the calibration differs up to 3 days).


On the implementation side I see things as follows.

When an instance of a temporal reference is created (i.e. it is mentioned somewhere in an analyzed source) we can immediately use the most recent calibration to calculate the corresponding period on the universal time line and associate this with that temporal reference. We do need to register the uri the specific version of the calibration.
When a calibration becomes deprecated we only have to run an update on these derived values using the previous uri to select them.

The implementation of a transformation using a specific calibration version can be done in various ways: remote service, hardcoded component, configurable component, etc.

Time-based querying on the "backend side" only consist of a straightforward numeric comparison and should be of no problem. On the user's side we will need the same transformation through a specific calibration because a user, at the moment he is querying, is in fact "creating" temporal references.

Several solutions exist for the calculations using elements with fuzzy borders or that have only topological relationships with (at some distance) calibrated neighbors (one such temporal reference in the picture is "End Biohorizon 1/Begin Biohorizon 2"). 
Calibrations should define (probably by convention) how to handle these.
Photo
Shared publiclyView activity