The following sections outline each of the major pieces of the design and give a rationale as to the importance of each. The design has been implemented and is in the public domain.

TimeValue

The TimeValue API is implemented in the desired domain. For example, we have implemented a discrete, unbounded domain with two special values (effectively the integers plus Beginning and Ending of Time, the latter two values have special semantics). The domain is unbounded since it uses Java's built-in BigInteger class (which does not limit the size of integers).

Semantics

The general idea behind the Semantics interface is to abstract the operations on temporal entities. Such operations have a variety of meanings or interpretations. Each implementation of the Semantics interface imbues temporal operations with a different meaning.

For example, a Semantics should support an operation that determines whether one instant precedes another. For the purpose of this example, we will assume that an instant is represented as a point on an underlying discrete time-line. Several alternative semantics for this simple operation

LeftOperandSemantics which casts the second operand to the granularity of the first operand in all operations). Here is an example using the LeftOperandSemantics.

  Instant i = new Instant(...);
  Instant j = new Instant(...);
  Interval k = new Interval(...);
  // A Semantics is just a name space
  Semantics ops = new LeftOperandSemantics();
  

  // Compare two instants
  ExtendedBoolean cond = ops.precedes(i,j);
  

  // Add an interval and an instant
  Anchorable t = ops.add(i, k);
  System.out.println("add(i,k) is " + t.image());

  // Scale to the coarser operands
  Semantics ops = new CoarserOperandSemantics();

Instead of using an interface and allowing dynamic switching between semantics, one could use a package to encapsulate the semantics and call operations statically. For example, assume the LeftOperandSemantics package has the Ops class that statically defines all the available operations. Then the code given above would look like the following.

  import LeftOperandSemantics.*;
   ...
  Instant i = new Instant(...);
  Instant j = new Instant(...);
  Interval k = new Interval(...);
  // A Semantics is just a name space
  

  // Compare two instants
  ExtendedBoolean cond = Ops.precedes(i,j);
  

  // Add an interval and an instant
  Anchorable t = Ops.add(i, k);
  System.out.println("add(i,k) is " + t.image());

We didn't add the ability to use different Semantics to the previous versions of MultiCal (and it is not in the C++ OO design) because at the back of our minds we had what we wrote in the granularity paper: the SQL compiler will generate the proper code with the casts and scales done prior to the operation. There are two reasons why this won't be best in this context.

1. There won't necessarily be a compiler to generate the proper sequence of calls, we expect the operations to be called directly in other kinds of applications.
2. Casts and scales are expensive, on temporal elements they are especially expensive. In general, it is actually much better to do the cast and scale as needed by the operation. Below I give an example with a period to illustrate my point. First, we'll give the naive sequence of calls.

     ...
     Instant i = new Instant(...);  
     Period j = new Period(...);
     // We want to do a precedes on the Instant and the Period
     // So we first cast the Period to the granularity of the Instant
     Period k = j.cast(i.granularity());
     // Now we can do the precedes since the operands are at
     // the same granularity 
     ...precedes(i,k)....
   

   What may not be obvious is that we've done lots more work than necessary because we've cast both the starting *and* terminating instant in the period, when in fact all we had to do was cast the starting instant. So the better code is

     ...
     Instant i = new Instant(...);  
     Period j = new Period(...);
     // We want to do a precedes on the Instant and the Period
     // So we first fetch only the Starting Instant, then we do 
     // the cast 
     Instant starting = j.earliest();
     Instant k = starting.cast(i.granularity());
     // Now we can do the precedes since the operands are at
     // the same granularity 
     ...precedes(i,k)....
   

   Extrapolate for temporal elements.

   Sure a precise and careful implementer could write the optimised code directly whenever a precedes is done between a period and an instant in a semantics that says they should cast to the granularity of the first operand, but I believe it is much, much better for the implementor of the semantics to package all the optimisations/casting/scaling in a single operation since the same thing is done every time the operation is called, for each semantics.

  Instant i = new Instant(...);
  Instant j = new Instant(...);
  Interval k = new Interval(...);
  // A Semantics is just a name space
  IndeterminateSemantics ops = new LeftOperandIndeterminateSemantics();
  

  // Carry out the operations at a plausibility of 60
  ops.setPlausibility(60);
  

  // Compare two instants
  ExtendedBoolean cond = ops.precedes(i,j);
  

  // Add an interval and an instant
  Anchorable t = ops.add(i, k);
  System.out.println("add(i,k) is " + t.image());

I'm certain that not every new semantics can be accommodated so easily within this framework, but all the ones that I currently know about can. And it gives us some leverage for accommodating other as yet unthought of, temporal semantics.

I anticipate that TSQL2 semantics will be just another implementation of a Semantics, exactly as any other semantics, although it will perhaps support a lot more methods than are outlined in the basic Semantics Interface, but that is not a worry, as one can always add to an interface.

Anchorables and Unanchorables

But before I talk about those two classes, suppose one wanted to add an PeriodicInstant temporal entity which is a periodic instant. Basically, all they have to do is implement the Anchorable interface and then you should be able to add PeriodicInstants to TemporalElements without any problems. Anyways, that is the goal, and in theory, if I've done the design correctly, that is how it should work. Note that Semantics are defined with respect to operations on Anchorables and Unanchorables, so the Semantics should work no matter what kinds of Anchorables and Unanchorables you give it, as long as they correctly implement the Anchorable/Unanchorable interface.

As an aside, suppose you didn't want your LeftOperandSemantics to add PeriodicInstants and Intervals. My view is that you are making an arbitrary decision in your semantics (which could be perfectly OK in a different semantics) so to handle this restriction you just overload the add method in your implementation of the semantics to detect this combination and either die if the user tries it or throw the appropriate exception. So the design allows restrictions of general operations (needed for TSQL2).

The Instant, Period, and Interval, classes are special implementations and support all the operations on that are needed to implement a Semantics. To be truly orthogonal, I should define them as an Point, Segment, and a Distance interface, respectively, and then implement the interface appropriately. But I slanted the names to just a Temporal domain. For BiTemporalElements a "Region" class will be needed to support operations on regions.

ExtendedBoolean

C/C++/Java API

 package TSQL2.API;
 import TSQL2.Instant.*;
 import TSQL2.Interval.*;
  

 Instant InstantPlusInterval(Instant i, Interval s) { 
   return (Instant)tadt.standard.LeftOperandSemantics.add(i,s);
   }

 package TSQL2.API;
 import TSQL2.Instant.*;
  

 Instant newInstant(byteArray b) {
   return new Instant(b);
   }
 ...
 package TSQL2.Instant;
  

 public Instant(byteArray b) { 
   return (Instant)new tadt.standard.Instant(b);
   }

Conclusion