measurement scale typology
Tim Bergsma
tbergsma at kbs.msu.edu
Wed Nov 6 06:17:12 PST 2002
Peter,
Thanks for the clarification. I'm rather embarassed not to have noticed
the second author on the paper I was pumping. Your comment makes more
sense now.
No, I haven't tried to make custom units yet. I'm worried too. For
lack of time, custom units falls into the category of things I'm hoping
other people have tested. I'm expecting I'll have to work them out on
paper and store them as xml fragments.
Tim.
> Peter McCartney wrote:
>
> Leland Wilkinson was listed as co-author of the paper you mentioned.
> He was the primary author of the manuals for many versions of Systat
> that, to me and many others, seemed always to devote less ink to
> explaining how to do something than they did on explaining why you
> shouldnt do that in the first place. I was being a bit sarcastic for
> the benefit of those who, like me, always hated those manuals!
>
> did you see my last comment in the vote call regarding custom unit
> definitions? have you attempted to createsome custom unit definitions
> following stmml? Im still very unhappy with using stmml outside the
> context of a unified dictionary - i think the recent improvements make
> the dictionary work, but only barely.
>
> 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 3:09 PM
> > To: Peter McCartney; Eml-Dev (E-mail)
> > Subject: Re: measurement scale typology
> >
> >
> > Peter,
> >
> > I don't know what Wilkinson has to do with this, sorry. The paper I
>
> > mentioned earlier gives some examples where the
> > nominal/ordinal/interval/ratio classification just doesn't
> > apply. I was
> > speculating that maybe we have such a hard time classifying dateTime
>
> > because of the limitations of the paradigm. Regardless, we should
> > certainly stick with the paradigm for now, since it has a lot
> > of utility
> > for EML. I haven't proposed any changes to RC3. It works as
> > is. Matt
> > proposed some changes, and I don't think anyone has responded yet on
>
> > eml-dev.
> >
> > Incidentally, when people give examples of interval scales,
> > they almost
> > always use Fahrenheit and Celsius. Calendar makes three, thanks for
>
> > textbook lookup. The other examples I've run across are all ordinal
>
> > scales in psychology that are treated like interval scales,
> > e.g. Likert
> > scales and IQ tests. The paper I mentioned argues that what the
> scale
> > is depends on how you want to use the data, and warns against
> > artificially limiting your analysis options.
> >
> > Probably my choice of email title "measurement scale typology is
> > inadequate" was inflamatory and misleading. Apologies to all. It
> IS
> > adequate for our purposes. My point was, let's not beat ourselves
> to
> > hard for not knowing where to put dateTime. It might not be
> > our fault.
> >
> > I am very interested in understanding how this stuff really
> > works, apart
> > from just EML. Thank you for your comments below, and also for your
>
> > earlier clarification of spatial projections. Both were helpful.
> >
> > regards,
> >
> > Tim.
> >
> >
> >
> >
> >
> > > Peter McCartney wrote:
> > >
> > > 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
> > > >
> >
> > --
> > 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
> >
--
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
More information about the Eml-dev
mailing list