[VOTE] restructure date-time value descriptions

[Scott Chapal]

Peter,

Peter McCartney <peter.mccartney at asu.edu> writes:

> I'm going to vote approve because 1) i dont want to block the
> process and 2) i failed to get my voter registration changed in time
> after moving so i want to be able to vote on SOMETHING today.

> Its simply opaque to me why this datetime domain is put in ordinal versus
> interval. we have users that treat this information as interval; we have
> textbooks that describe this as interval. I think we make ourselves look
> silly calling it ordinal.

Until we incorporate the full complexity of ISO8601 somehow, the
simplified description of date-time is more easily and accurately
described as 'ordinal' than it is as 'interval'.

(BTW, having just read Tim's VOTE email, creating a separate scale
treatment for dateTime *would* be the correct thing to do I think,
too: Wholesale incorporation of the concepts in ISO8601).

The textbook example you recently gave was for 'calendar Year', if I
remember....that's not date-time.  Thats a sequence of years, a trivial
subset of the date-time domain(s) which could be [incompletely]
described as interval.  Years aren't the same length.  Thats why
ISO8601 also has [year,common] and [year,leap], in addition to
[year,calendar].

> Since we've gone to the trouble of defining a specialized structure
> to handle datetime outside of stmml, then why cant it be a choice
> under interval where it makes intuitive sense?

Because date-time is not really interval.  It certainly is not more
intuitively interval than ordinal (at least to me).  Because of this
ambiguity/complexity, ISO8601 separates out several date and time
concepts and treats them independently: Calendar dates, ordinal dates,
week dates, time of day, differences between local time and UTC,
combination of date and time, time-intervals and recurring
time-intervals.

Exact multiples of Seconds are [truly] of interval scale, but not the
date and date-time combinations.  Although days, months and years are
often treated as interval for analytical purposes.

> Or, why cant it simply be a custom unit? 

Because date[time] occurs in every data set, it would be impractical
to be a custom unit.

> In this context, I do not see the feasibility of asking people to fill in
> stmml compliant xml to define custom units. Without a way to relate my
> custom units to types defined in the dictionary, how can i ever expect to
> relate these to anything else? Who's to say i dont define a redundant
> unitType and give it a different parentSI? how will i ever translate a
> custom unit to one defined in the another dictionary? 

Presumably, the SI units will provide the common reference for
exchange.  Defining redundant units is regrettable, but probably not
preventable.  (Until we invent a mechanism to point out those
redunancies).

> With respect to dateTimeDomain, i think you are mixing physical with logical
> again. if i have data stored in a dateTime container in some binary file
> structure, the string representation of that data has nothing to do with
> anything. I can request the data in any string representation you want. I
> see no gain in understanding of the data by using the formatString element.
> I DO see some advantage to indicating the precision (sorry, i cant think of
> an alternate word!) of the measurement - that is, is it to the year, the
> month, the day, the hour, etc. how do i describe the domain of a time field
> that is not using the date portion? (internally, sql server represents 4:10
> pm as 4:10 pm on jan 1 1980. or a time field that is ignoring the am/pm
> portion?

We're attempting to model the date-time data here, aren't we?  Not the
internal representation.  If SQL server uses:

4:10 pm on jan 1 1980

to mean:

16:10

That's not EML's concern, is it?  BTW, I doubt if SQL server uses that
internally anyway, that looks like yet another datetime string
representation with a missing (default) date.

As currently modelled the formatString implies the 'precision'.

YYYY
YYYYMM
YYYYMMDD
YYYYMMDDThh
YYYYMMDDThhmm
YYYYMMDDThhmmss

etc. or:

ss.s
ss.ss
ss.sss

For the domain of a time field wouldn't something like this work?

         <measurementScale>
           <ordinal>
             <dateTimeDomain id="dd.2">
               <formatString>HHSS</formatString>
               <minimum>0000</minimum>
               <maximum>2359</maximum>               
             </dateTimeDomain>
           </ordinal>
         </measurementScale>



Accommodating something you disagree with in the name of expediency
certainly won't accomplish the quality in EML I'm certain you are
looking for.  If you're convinced that date-time is interval then
stand up and be counted.  You've got better clarity of conviction than
I do, because it sure doesn't look that black-and-white from here.

I interpret this vote to mean that the 'ordinal' kludge has advantages
over the 'interval' kludge, and works sufficiently so that EML 2.0 can
see the light of day.

-Scott
-- 
Scott E. Chapal_________________________________________________
Database & Network Manager             scott.chapal at jonesctr.org
J.W. Jones Ecological Research Center          229.734.4706 x227
Rt. 2. Box. 2324. Newton, GA 31770-9651        229.734.6650 :FAX