Subject: Re: DEADLINE FOR ...

From: [email-masked]
Date: Fri, 10 Sep 1993 13:29:05 MST

Greetings,
I have been out of town for some weeks, so could not send the
following comments before the deadline.
(Or is this earlier enough for the November 4 deadline ?)
If it is too late, I hope these can be considered in the next version.

I feel that some of these are rather significant (e.g. P1, P2, P6), but
may easily be incorporated in the final version.
I group them into two categories, one for changing some terms
and the other for minor adjustments.

* Proposals for changing some terms:

P1:	User-defined Time (Section 3.3)
    problem:	User-defined time can easily be confused with
			the feature for the user-defined data types,
			as described in the next entry for
			"Temporal Data Type".
		It seems to suggest a new data type defined by users
			to handle time.
		This was not much of a problem before, but it will become so
			when the user-defined data types become available
			e.g. in SQL3.
		(I think I, with Rick, am partly responsible for this misnomer)
    replacing term:
	User-dependent Time
		The semantics of user-dependent time is dependent upon
			user's interpretation, and not interpreted
			by the system.
		This avoids the confusion with the user-defined data types.

P2:	Temporal Element (Section 3.15)
    problem:	This term is not intuitive, in fact counter-intuitive,
			for representing a union of time intervals.
		It sounds like an elementary item, e.g.
			a single timestamp or a chronon.
		Besides, \part{Previously Used Names} mentions
			the same term again.
    replacing term:
	"Multi-intervals" or "Interval sets" or simply "Intervals"
		I personally prefer "Multi-intervals", but anything
			would be better than "temporal element".

P3:	Beginning (Section 4.25)
    problem:	too vague when there is a better term.
    replacing term:
	Epoch
		Epoch, I think, is the perfect term for this purpose.

P4:	Time-invariant Attribute (Section 4.35)
    problem:	too long (-E2) when there is a better and shorter term.
    replacing term:
	Static

P5:	Time-variant Attribute (Section 4.36)
    problem:	too long (-E2) when there is a better and shorter term.
    replacing term:
	Dynamic

P6:	Predictive (Section 4.41)
    problem:	Term "proactive" is existing and accepted (-E7).
		"proactive" is orthogonal to "retroactive" (-E1).
		Term "predictive" is not precise (-E8).
		Tuples inserted into a predictive bitemporal relation
		    instance are not just predictions about the future,
		    because predictions are different from facts.
		Rather, such tuples represents facts that would become
			effective in the future.
		"Predictive" means that it may not be quite correct.
    replacing term:
	It is true that "proactive" is not in some dictionary, but
		the term is commonly used.
	Term "proactive" has been existing and accepted (+E7).
	Meanings of "predictive" and "proactive" are different.
	"proactive" is orthogonal to "retroactive" (+E1).

P7:	Degenerate Bitemporal Relation (Section 4.42)
    problem:	Term "Degenerate" denotes something unusual or irregular.
		Term "Degenerate relation" may mean a relation
			with no attributes (columns) defined.
    replacing term:
	Synchronous Bitemporal Relation
		If the valid and the transaction times are identical,
			they are synchronous.
		Term "synchronous" is existing and accepted (+E7), and
			precise (+E8)

P8:	new entries for Continuous Model of Time
P9:	new entries for Discrete Model of Time
	These are described under "Instant" and "Chronon", but deserve
		separate entries considering their impacts on many aspects.

P10:	Retroactive Temporal Relation (Section 4.40)
	Predictive  Temporal Relation (Section 4.41)
    problem:	Terms "retroactive" and "proactive" refers to
			characteristics of an operation, rather than
			a relation which is the result of such an operation.
    replacing term:
	Retroactive Operation
	Proactive Operation
		Define the concepts for the operation, not the relation.

* Minor adjustments:

A1: Section 3.2 Transaction Time

	~~ database fact is stored in a database at some point in time, and
	~~ after it is stored, it is current until logically deleted. The {\em
	~~ transaction time\/} of a database fact is the time when the fact is
									   ====
								>>	becomes
	~~ current in the database and may be retrieved. Transaction times are
	~~ consistent with the serialization order of the transactions.
	~~ Transaction-time values cannot be after the current time.
					     =====
				 	>>  later than

A2: Section 3.3 Temporal Data Type
	\epart{Definition}
		Temporal data type may be built-in or user-defined.
		    (Why or how does it have to be user-defined ?)

		 ~~ Terms belonging to a user-defined temporal data type
		 ~~ get the same query language support as do terms
		 ~~ belonging to built-in temporal data types such as the
		 ~~ {\tt DATE} data type

		 Is this true ?
		 Isn't this dependent on the query language ?

A3: Section 3.24 Event
	\epart{Previously Used Names}
	 Event relation, instant relation.

		"Event" and "event or instant relation" are of
			different domains, and cannot be compared.

---

From: Shashi K. Gadia <[email-masked]>
Date: Tue, 14 Sep 93 14:36:17 CDT

Hi everyone: 

I am responding to Ahn's message about 
temporal element. 

> 			would be better than "temporal element".

A temporal element in one dimension is 
a union but NOT a set of intervals.  
The terms "Multi-intervals" or "Interval sets" 
or simply "Intervals" lean towards a set and 
not union.  

The term temporal element is more generic.  
In the bitemporal model, it is union of rectangles.  
Moreover if your bitemporal space does not contain 
notion of future the bitemporal space reduces 
to triangle below the diagonal.  And a temporal 
element becomes union of triangles and rectangles.  
(See Section 6.2 on page P-26 of workshop 
proceedings.)

The term temporal element generalizes to spatial 
or spatio-temporal element.  A spatio temporal 
element can be very complex. 

Regards
Shashi