[VOTE] restructure date-time value descriptions

[Mark Schildhauer]

Hi folks,

I'm going to vote "disapprove" on classifying date-times as ordinal, 
since I think we really LOSE A LOT by categorizing these as such.

For the vast bulk of common usages (e.g., in everyday terms and 
ecological datasets), date-time values clearly have richer implied 
semantics than simply ordinal.

minute, hour, month, year, decade, century : I'm pretty confident not 
only about how to order these, but also about the relative differences 
in their durations.  Not exactly, but approximately.  Think about how 
you'd place these durations on a number line intended to represent their 
relative magnitude.. You would probably vary the size of the intervals 
among them.

regarding chronologies-- e.g., for years 1992, 1993, 2002, 2003: I'm 
pretty confident about how to order these, and I'm pretty confident 
about the approximate relative differences among intervals (durations) 
between these.  Again, the number line placement would indicate this. 
 More information here than simply ordinal methinks.

The irregularity of the measurement scales for time are indeed 
problematic.  For sure the terms for expressing date-time are often 
ambiguous or imprecise.  Thus, I suggest we consider pursuing what 
others here have suggested earlier--make date-time a *special case* 
aside from nominal/ordinal/interval/ratio.  Thus, some custom treatment 
is called for. Don't ask me for details about how this is best 
accomplished-- there has already been some debate about this and I 
accede to schema mavens to optimize the solution.  But I think 
classifying time as "ordinal" is misleading and overly information lossy 
for most situations.

Cheers,
Mark S./NCEAS


Matt Jones wrote:

> After our long discussions about date-time values, and Tim's excellent 
> treatises on that subject and units, I think we are coalescing on the 
> idea that date-time values are most appropriately modeled as ordinal 
> values (the deeper underlying issues with measurementScale 
> notwithstanding).  Date-time values are ordered, but we seem to agree 
> that one cannot do arithmetic calculations on them without parsing 
> them and converting them to an interval scale such as "seconds since 
> 1970".
>
> I have modified the eml-attribute.xsd file (yes, again!) to reflect 
> this emerging concensus.  You can see it in cvs at:
>
> http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/eml/eml-attribute.xsd?rev=1.93&content-type=text/plain 
>
>
> Using this new schema, a date-time attribute is described in eml like 
> this (taken from the eml-sample.xml file):
>
>       <attribute id="att.2">
>         <attributeName>year</attributeName>
>         <attributeLabel>year</attributeLabel>
>         <attributeDefinition>The year the data was collected
>         </attributeDefinition>
>         <storageType>gYear</storageType>
>         <measurementScale>
>           <ordinal>
>             <dateTimeDomain id="dd.2">
>               <formatString>YYYY</formatString>
>               <minimum>1944</minimum>
>             </dateTimeDomain>
>           </ordinal>
>         </measurementScale>
>       </attribute>
>
> I would like to ask for a vote to determine this issue once and for 
> all so we can release EML, especially as we were scheduled to release 
> the final version of EML tomorrow!  So, here it is:
>
> VOTE: The final release of EML should include the changes to 
> representation of date-time values that were made in revision 1.93 of 
> the eml-attribute.xsd file.  This includes moving date-time value 
> descriptions to the ordinal measurementScale, and moving the format 
> string into the DateTimeDomain description.
>
> You should vote one of the following before the end of business 
> Wednesday:
>    Approve: I understand and agree with the date-time change proposal
>    Neutral: I am neutral, or don't have a solution to propose
> Disapprove: I block this from occurring, and have a solution to propose
>
> If you vote Neutral or Disapprove, it would be great to get comments 
> from you as to why (e.g., if you vote neutral just because you haven't 
> been following the discussion, it would be good to know that), and 
> proposed alternatives.
>
> Project member      Vote
> ---------------     ---------
> Tim Bergsma
> Chad Berkley
> David Blankman
> Matthew Brooke
> James Brunt
> Scott Chapal
> Corinna Gries
> Daniel Higgins
> Matthew Jones       approve
> Chris Jones
> Peter McCartney
> Ken Ramsey
> Mark Schildhauer
>
> Thanks,
> Matt
>


-- 
Mark P. Schildhauer, Ph.D. --  Director of Computing 
NCEAS --  National Center for Ecological Analysis and Synthesis
735 State St., Suite 300       Santa Barbara, CA   93101-3351	
Email: schild at nceas.ucsb.edu   WEB: http://www.nceas.ucsb.edu
Phone: 805-892-2509            FAX: 805-892-2510