measurement scale typology is inadequate
Peter McCartney
peter.mccartney at asu.edu
Mon Nov 4 10:38:29 PST 2002
God, if we now have to make all this live up to Leland Wilkinson's twisted
sense of what's right in statistics, we can give up now!
Without professing to be an expert, it seems your test implications are
confusing the picture. i would simply offer that the rule I remebered was
that ratio scales have an absolute zero. What you should be asking is
whether the result of subtracting the two measures says anything absolute
about the magnitude of thier difference. The classic text book examples are
degrees fahrenheit (interval) and most distance measurements (ratio). its
possible to easily go into the negative numbers on the fahrenheit scale (Tim
and Matt probably appreciate this better than most of us) but it makes no
sense to say that -40 is twice as cold as -20 since zero is arbitrary. Not
so with most distance measures where there is an expectation that when
something reaches zero, it ceases to exist. so with some exact figures, i
could say with some meaning that matt was x% taller than I.
so lets go back to everest and sea level. the problem is that you can't
compare the heights of everest and an object at selevel because the latter
has no height - the measurement doesnt exist. To accomodate objects at (and
even below) sea level, youve shifted into using elevion as an interval scale
with zero just an arbitrary point on a continuum that has no true zero. The
minute you do this, it no longer makes sense to say that everest is twice as
tall as Long's peak. this would never happen in comparing tree stem
diameters for example because you would never find a stem with a diamter of
zero - it cant happen.
The stats text book i opened, incidentally, also names calendar years as an
interval scale for the same reasons - the zero point is arbtrary. you cant
say that -4000bc is twice as old as -2000 bc. contrast this with most
radiometric dating scales which report ages as elapsed time prior to a
defined "modern" level of radioactivity. these scales do have a concept of
something being twice as old as something else (although that meaning is
lost the minute you calibrate the age estimates to a calendar date).
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: Monday, November 04, 2002 8:14 AM
> To: Matt Jones; Eml-Dev (E-mail); David Blankman
> Subject: measurement scale typology is inadequate
>
>
> Matt,
>
> I retract my silly idea of preclassifying standard units by
> measurement
> scale!
>
> Consider meters. Obviously ratio, right? But elevation is
> measured in
> meters, often relative to sea level. So what is the ratio of Mt.
> Everest to sea level? You get a divide-by-zero error. What about the
> elevation of the Dead Sea, or Holland? Suddenly, meters is looking
> rather interval.
>
> Seems to me like I'm missing something important. What is the
> relationship between "elevation" and "meters"? How about
> "distance" and
> "meters"? When you subtract two elevations, you get a distance, not a
> third elevation. When you subract two dates, you get a
> duration, not a
> third date. It is meaninless to add two dates: What is 1 July 2002
> plus 1 September 2002? Similarly, it is meaningless to add two GPS
> locations, but meaningful to subtract them (but you get a
> distance, not
> a third GPS point). What about celsius? You can certainly add 20
> degrees and 30 degrees, but what does it mean? You can subtract two
> temperatures, but do you get a third temperature? No. You
> can express
> the result in the same units, but there is a big difference
> between the
> idea that something is 10 celsius degrees colder and the idea that
> something is 10 celsius degrees. One is an offset, like duration and
> distance, and the other is a reference to a coordinate system, like
> calendar and geoposition.
>
> At this point, I've done enough damage to eml to disqualify
> myself from
> commenting further on where to put dateTime. I'd like to suggest,
> however, that the problem may be the typology itself.
> Surfing the web,
> I stumbled across an article "Nominal, Ordinal, Interval, and Ratio
> Typologies are Misleading"
> http://www.spss.com/research/wilkinson/Publications/Stevens.pdf
> (attached), which should be required reading for eml application
> developers. With respect to EML 2.0, I think the ability to describe
> the format of a dateTime is absolutely critical, if for no
> other reason
> than to trap the Old World habit of using day-month rather than
> month-day. If we are specific now, we can map 2.0 dateTimes
> to a better
> location when 3.0 comes out. I'd like to hear what David thinks about
> all this.
>
> Tim.
>
> P.S. why not make dateTime it's own measurementScale? (oops!
> I said I
> wasn't gonna comment. Sorry.)
>
>
>
> Matt Jones wrote:
> >
> > Tim,
> >
> > So, are you saying that "unit" implies measurement scale? That is
> > probably true, but it would be much harder to nest
> measurement scale in
> > unit as not all measurement scales have units, and there
> are infinite
> > numbers of units. An application that digests the units
> and thereby can
> > suggest (or even automatically fill in) a measurement scale
> would make
> > the whole thing more usable. But I think that is an
> application issue
> > more than an EML one. I don't see a need for any changes
> to the schemas
> > to enable applications to guide users based on units.
> >
> > Can you outline a bit more concretely what you were proposing?
> >
> > BTW, I found that I fully agreed with your treatise on datetime as a
> > coordinate system. You said "Arbitrariness is handled by
> projecting the
> > points onto an evenly divided, "true" interval scale, such
> as a string
> > of named seconds starting in 1970." I fully fully agree
> that this is
> > the case here. Datetimes are ordinals (given any two
> datetime values,
> > they always have a pre-determined ordering). Datetimes can
> be projected
> > onto an interval scale such as seconds since 1970. The
> fact that most
> > scientists consider datetimes as interval values is more
> from pragmatism
> > than theoretical correctness. We could move the datetime
> format string
> > out of unit and into ordinal if people prefer. THis would be more
> > technically correct, would also eliminate our problem with
> the precision
> > field for datetime values, and would remove the format string from
> > UnitType so it would no longer show up under interval (and
> ratio, which
> > is good). It would introduce a need for dateTimeDomain in ordinal,
> > which would be ok too.
> >
> > Does anyone have a preference about whether this should in
> fact be in
> > ordinal or in interval?
> >
> > Matt
> >
> > Tim Bergsma wrote:
> > > Matt,
> > >
> > > We know already the measurementScale for every dictionary
> unit. But all
> > > the units are available under interval and rato (in fact,
> > > formattedDateTimeUnit also appears under ratio!). Is
> there a way to
> > > represent our prior knowledge of scale so that
> applications can provide
> > > some guidance to users?
> > >
> > > Tim.
> >
> > --
> > *******************************************************************
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20021104/2007a6b9/attachment.htm
More information about the Eml-dev
mailing list