dateTime is a coordinate system
Peter McCartney
peter.mccartney at asu.edu
Mon Nov 4 10:00:27 PST 2002
Actually, the doglegs in the plss grids have nothing to do with the
projection process. plss is not a projection system and im not aware of
anyone making a regular practice of attempting to use the
townsship-range-section values as interval measurement scales. projections
(UTM, state plane, lambert, etc) simply project angular measurements to
planar ones, but there is nothing arbitrary about it other than the
practice of moving origins around to avoid negative or excessively large
values. both sets of coordinates are interval or ratio scales with units.
there is distortion, but that distortion is 100% explained in the
projection's definition, just as is the distorition between any two stmml
units. the point is that two different programs could perform the same
projetion transformation and get the same result. Lat long is no more robust
a coordinate system than any projected cordinate system; there is not loss
of accuracy (unless bad values are used in the transformation)
what's different about calendars is that unlike geographic coordinates where
every degree has 60 minutes and every minute 60 seconds, months do not
always contain the same number of days and days not always the samenumber of
hours (i think by the time we get down to hours and minutes we're back to
true units?). They are just much more difficult towork with without mapping
them to some hidden scale of elapsed seconds which is what most software
systems do. So we wind up a situation where two programs might NOT get the
same result if asked to calculate the elapsed seconds between 1/1/1990 and
2/2/1991. But i contend that this isnt because it cant be done, its just
because we have no published references to the different systems for doing
this mapping.
I would repeat my previous comment that if we all agree that there is no
implied difference in the intervals between 1/1/1990, 1/2/1990 and 1/1/2000,
then you can go ahead and call dates an ordinal scale in EML.
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: Friday, November 01, 2002 11:32 AM
> To: David Blankman
> Cc: Eml-Dev (E-mail)
> Subject: dateTime is a coordinate system
>
>
> Okay, RC3 is out, so this discussion is oriented more toward long term
> thinking rather than eml revision.
>
> It's hard to imagine saying anything original about dateTime data at
> this point. But it struck me yesterday that a Calendar is really a
> coordinate system. It is a markup (in units) of a real,
> shared entity.
> By analogy, consider the shared surface of the earth. You geospatial
> people will appreciate better than I that attempts to impose
> a cartesian
> grid (meters, miles, whatever) on a spherical object entail arbitrary
> accomodations, which is why county baseline roads occasionally have
> those bizarre doglegs. Also note that WGS84 zone 16 has an arbitrary
> maximum value for its Eastings domain (now I'm way out of my field).
>
> Calendars have all the properties of a coordinate system. There is a
> real, shared entity...the vector of time. There are attempts
> to mark up
> time using standard units. There are arbitrary adjustments
> built in to
> these attempts, due to underlying inconsistency between the
> thing itself
> and our model of it (e.g., a year is not a whole number of
> days). Best
> of all, there are "projection" algorythms for converting between
> different coordinate systems (calendars, timezones, SAS,
> etc.). Just as
> lat/long seems to be the most robust model of the earth's surface,
> "endless string of seconds" seems to be the most robust model
> of time.
> It's just terribly impractical.
>
> The point of this muse is to try to clarify the relationship between
> dateTimes and units. When you measure the length of a blade of grass,
> you report its physical extent, in comparison to the physical
> extent of
> some standard called a unit. When you measure the duration of a bird
> song, you report its temporal extent, in comparison to the temporal
> extent of some standard called a unit. But when you report a
> dateTime,
> what have you measured? Nothing. You are citing a point on the
> coordinate system. It is the coordinate system itself that
> is a markup,
> in standard units, of the shared reality called time. So there is a
> sense in which a dateTime has no units, and an indirect sense in which
> it does have units, which is why we keep hearing both answers.
>
> Viewing dateTime as a coordinate system also clarifies (?)
> assignment of
> measurement scale. Durations are obviously ratio, because they have a
> natural zero. 10 years old is twice as old as 5 years old. But
> dateTimes, using (?) the same units, hardly seem to qualify for
> interval, what with their arbitrary leaps and transitions. Again, a
> dateTime doesn't measure anything: it specifies a location on a
> coordinate system (in that sense, dateTimes are clearly ordinal).
> Useful measurements can be made, however, from comparing two
> points on a
> coordinate system. Arbitrariness is handled by projecting the points
> onto an evenly divided, "true" interval scale, such as a
> string of named
> seconds starting in 1970. So dateTime doesn't have a
> measurement scale,
> because it isn't a measurement. But the underlying entity
> (time) can be
> measured on an interval scale, so dateTimes can be used to make
> (indirect) measurements of temporal extent. Similarly, boats
> don't have
> odometers, but you can know how far you've sailed by comparing two GPS
> points. The points themselves do not measure extent, but
> extent can be
> calculated if the coordinate system is known. Since the experience of
> unique points in time cannot be repeated, it is often more
> practical to
> measure temporal extent by comparison within acoordinate system rather
> than directly using an appropriate chronometer.
>
> So, the question in EML has been whether to represent
> dateTime according
> to its true nature (ordinal) or its expected use (interval).
> I think it
> was justified to provide special handling for dateTime.
> Tim.
>
>
>
>
>
> David Blankman wrote:
> >
> > I participated in only part of the dateTime discussion. At first it
> > seemed to me that treating dates as ordinal made sense, but I think
> > that Tim has a valid point: use the guiding prinicipal of useability
> > rather than philosopohical correctness. While it is true
> that time is
> > very problematic when looked at from a deep strucure philosophical
> > perspective, it is also true that people add and subract
> dates all the
> > time..Most of ecology functions in a Newtonian world, free
> from quantum
> > mechanical and relativistic paradoxes and fluidity of time
> and space.
> >
> > Many measurements done in ecology have limited precision. A
> 1-meter plot
> > is probably 1-meter plus or minus some centimeters (2 - 3 cm maybe).
> > Coverage estimates have even less precision. Why should we
> be concerned
> > about an even smaller lack of precision in dates?
> >
> > Processing systems can be built to factor in the complex
> calendar rules.
> > EML doesn't have to do that.
> >
> > I think that Tim's suggestion of units makes great sense,
> as long as the
> > person documenting a dataset does not imply greater
> precision than is
> > appropriate.
> >
> > David
> >
> > Tim Bergsma wrote:
> >
> > >I'm not on IRC, so if you want to hash this there, call me at
> > >269-671-2337.
> > >
> > >We can't rehash forever, but this is a usability issue of the first
> > >order.
> > >
> > >There are two problems with yesterday's conference call consensus
> > >regarding datetime: 1) we provide no mechanism for
> handling durations;
> > >2) calendar dates are interval scale not ordinal scale.
> > >
> > >Regarding durations, one might argue that we provide
> xs:duration in the
> > >kludge of the ordinal measurementScale. But I looked at the
> > >representation of xs:duration
> > >(http://www.w3.org/TR/xmlschema-2/#duration), and quite
> frankly, no one
> > >has duration data in that format! EML has to handle data
> like this:
> > >
> > >Watershed YearOfClearCut YearsToReforestation
> > >W3 1887 40
> > >LittleCreek 1910 35
> > >JasperRidge 1950 52
> > >
> > >-or-
> > >
> > >EggMass DateOfLaying DaysTillHatching
> > >DuckPond 5-15-2000 30
> > >LittleCreek 4-31-2000 18
> > >GullLake 6-1-2000 16
> > >
> > >Recommendation: we should provide categories in the
> unitDictionary such
> > >as nominalYears, nominalDays, nominalMonths, nominalHours, etc. (or
> > >YearsDuration, DaysDuration, etc) and define them in
> conventional terms,
> > >explicitly acknowledging lack of precision. For instance, a
> > >nominalMinute is 60 seconds, +/- 1 second. A nominalYear is 365
> > >nominalDays, +/- 1 day. xs:gYear is fine for YearOfClearCut, but
> > >xs:duration will not be adequate for YearsToReforestation.
> > >
> > >Regarding scale: I'm convinced that ordinal scales are
> simply ranked
> > >categories. You don't do math on ranked categories, other
> than to test
> > >for order relations. But we do lots of math on
> CalendarDates, such as
> > >taking the difference between two dates, or adding a duration to a
> > >date. The objection is raised that the duration of
> sub-units of the
> > >Calendar are not constant. True, but we do the math,
> still the same, so
> > >it must be an interval scale. Actually, it is a deeply nested
> > >concatenation of interval scales of varying domain. But
> the scale is
> > >completely determined, and even naive calculations are
> valid, albeit
> > >with qualified precision, while sophisticated calculations
> are exact. I
> > >found one webpage that explicitly assigns calendar dates
> to interval
> > >scale: http://www.rattlesnake.com/notions/guttman-scales.html.
> > >
> > >So, modeling DateTime etc. under ordinal is wrong. But if
> we provide
> > >DateTime etc. under interval MeasurementScale, what are the units?
> > >DateTime does have units (year-month-day-hour-min-sec) ,
> but they are
> > >concatenated. The concatenation is a mechanism for traversing the
> > >nested tree of (arbitrary, often-non periodic) interval scales that
> > >comprise the calendar. I think, as someone suggested
> yesterday, we will
> > >have to provide a notation for indicating date format, such as
> > >CCYY-MM-DD or MM-DD-YY, etc. Applications will need the
> notation as a
> > >key for digesting date strings. We can't expect eml
> authors to change
> > >their data to conform to some format. Given the ubiquity
> of date/time
> > >data, we either have to enumerate some common formats (unit
> > >concatenations) or provide a notation for describing formats.
> > >
> > >And this just in...Campbell data loggers everywhere are
> storing dates as
> > >as a field pair: Year and DayOfYear. This just proves
> that there are
> > >alternate ways of traversing a nested interval scale.
> This is perhaps
> > >our last opportunity to trap DayOfYear and do something
> meaningful with
> > >it. It is not a duration. It has exactly the same properties as
> > >xs:gMonthDay:
> > >
> > >"[Definition:] gMonthDay is a gregorian date that
> recurs, specifically
> > >a day of the year such as the third of May. Arbitrary
> recurring dates
> > >are not supported by this datatype. The ·value space· of
> gMonthDay is
> > >the set of calendar dates, as defined in § 3 of [ISO 8601].
> > >Specifically, it is a set of one-day long, annually
> periodic instances."
> > >
> > >Solutions welcome.
> > >
> > >Tim.
> > >
> > >
> >
> > --
> > David E. Blankman
> > Database Integration Developer
> > Long Term Ecological Research (LTER) Network Office
> > University of New Mexico
> > 801 University, SE #104
> > Albuquerque, NM 87106
> > Phone 505/272-7346 fax 505/272-7080
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20021104/f153ff0e/attachment.htm
More information about the Eml-dev
mailing list