[VOTE] restructure date-time value descriptions
Peter McCartney
peter.mccartney at asu.edu
Wed Nov 6 12:05:11 PST 2002
i think tim has a point - instead of arguing about whether its more similar
to ordinal or to interval, we avoid the problem by moving it to another
choice within measuremntScale. This is the BEST suggestion ive seen thus far
- we're clearly getting nowwhere in the ordinal/interval debate and at least
two of us voted more to stop the debate than for the solution
Peter McCartney (peter.mccartney at asu.edu)
Center for Environmental Studies
Arizona State University
480-965-6791
> -----Original Message-----
> From: Tim Bergsma [mailto:tbergsma at kbs.msu.edu]
> Sent: Wednesday, November 06, 2002 7:55 AM
> To: Matt Jones; Eml-Dev (E-mail)
> Subject: Re: [VOTE] restructure date-time value descriptions
>
>
> I vote approve.
>
> In my heart, dateTime feels and works like interval. But I have to
> concede that the case for ordinal can be made. The deciding
> factor for
> me is that the proposed change knocks down some other
> weirdness, such as
> having the dateTime unit type available under multiple measurement
> scales.
>
> I think the underlying problem is that the current measurment scale
> typology does not adequately capture dateTime. But it's too
> late to go
> hunting for better typologies (alternatives do exist). As long as
> everyone puts dateTime in the same place, we should be able
> to find it.
>
> Peter has pointed out that numbers don't seem to fit under
> ordinal, and
> that discontinuous ranges can't be represented under numericDomain.
> Both of these things bothered me, too, but I wasn't going to say
> anything.
>
> Peter has also suggested in passing that dateTime should just be it's
> own (custom?) unit. If this were earlier in the development
> process, I
> would lobby strongly for going one step further, and making it its own
> measurement scale. It certainly deserves special handling,
> and having a
> fifth measurement scale would abstract all the messiness of dateTime
> away from the other four. Users would be free to map it back in
> wherever they wanted.
>
> Tim.
>
> 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/em
> l-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
> >
> > --
> > *******************************************************************
> > Matt Jones jones at nceas.ucsb.edu
> > http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
> > National Center for Ecological Analysis and Synthesis (NCEAS)
> >
> > Interested in ecological informatics? http://www.ecoinformatics.org
> > *******************************************************************
> >
> > _______________________________________________
> > eml-dev mailing list
> > eml-dev at ecoinformatics.org
> > http://www.ecoinformatics.org/mailman/listinfo/eml-dev
>
> --
> Tim Bergsma
> LTER Information Manager
> W.K. Kellogg Biological Station
> Michigan State University
> Hickory Corners, MI 49060
> 616/671-2337
> tbergsma at kbs.msu.edu
> http://lter.kbs.msu.edu
> _______________________________________________
> eml-dev mailing list
> eml-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/eml-dev
>
More information about the Eml-dev
mailing list