[seek-kr-sms] Color Was: Re: OBOE discussion: current version

Wed Jun 21 13:11:30 PDT 2006

Except for spectral measurements, <specification, characterization, 
measurement, naming, observing, ...> of color is something that few 
biologists (and few computer scientists) get right unless they happen to 
know a lot about human color vision or color image reproduction 
technology. Among the central issues is that color measurement, color 
matching, color appearance, and color naming have radically different 
models in color theory, none of which predict the others very well over 
the  intersections of their domains of applicability. A further problem 
is that most of these concepts have utility in science, but different 
ones have different adherents. For example, soil science has the 
practice of matching soil colors to Munsell standard colors.  AFAIK, 
entomologists have no practice corresponding to this, but are content to 
classify by color names and modifiers.

We're very interested in this (though discussion  presently deferred), 
in the TDWG standard for the Structure of Descriptive Data (cf. 
http://wiki.tdwg.org/twiki/bin/view/SDD/ColorRangeSampleData).

A particularly accessible book on color theory is "Billmeyer and 
Saltzman's Principles of Color Technology" by Roy S. Berns, 3rd edition, 
Wiley Interscience, 2000

Bob Morris
Lurker

-- 
Robert A. Morris
Professor of Computer Science
UMASS-Boston
ram at cs.umb.edu
http://www.cs.umb.edu/efg
http://www.cs.umb.edu/~ram
phone (+1)617 287 6466

==================

Ferdinando Villa wrote:
>  > 1.      Observable is either Entity or Characteristic (at the moment).
> Characteristic has only one subclass Dimension, which defines the set of
> base quantities such as length, weight, etc. , Dimension includes only
> things measured in quantities. Thus at the moment we are missing
> specification for observations of such characteristics as color, smell,
> taste or anything which is measured in qualitative scale.
>
> This is a question that has come up a lot recently and really needs to be
> confronted with some good examples.  The idea was that nominal measurements
> would just be given unit "name" and a characteristic, such as "red".  This
> would mean having these characteristics in an extension ontology such as a
> "classifiation ontology" (which would plug into OBOE's charactersitic).  
>
>
> I don't think this is right. Simply, the values of that observation come
> from a finite set of color classes (or instances). Not a measurement, if we
> define measurement as comparison with a reference unit (meter of tree) using
> an abstract unit for the dimension (meter for length). It is a measurement
> if we define measurement to encompass assigning a class to an observable in
> a context as the result of measuring it. I'd rather call it a
> "Classification", subclass of Observation and siblings of Measurement. And
> we could have "Ranking" as subclass of Classification, where classes must
> have an ordinal relationship. But stretching the definition to make it fit
> in the unit-at-all-costs framework and giving the characteristic the role of
> subsetting the value space doesn't sound right at all. This was the thought
> behind proposing an explicit value space. 
>
> Ordinal measurements may not be as easy to deal with.  It might work in the
> same way as above, but use the unit "rank".  However, the ordinal ontology
> would need to contain constructs that deal with "direction" or "magnitude".
> For example, "high" is distinct from and of greater magnitude than "low".
> This ontology would have to be able to deal with arbitrary numbers of
> levels, similar to the way we dealt with Observation in OBOE for coping with
> experimental design.  The idea was to remove these kind of things (i.e.,
> characteristics) from the core ontology because the way that people want to
> use them are so variable. 
>  
> Similar concerns, plus one: I don't think the ordinal relationship between
> classes such as {high, medium, low} has much of a chance to be captured in
> OWL. Nor I think it should be, as you don't do much with it in workflows
> unless it's a real numeric scale (whose ordinal properties are also not
> expressed in OWL, so why bother?). If really necessary, we could make such
> classification hierarchies subclasses of "Rank" and use a numeric property
> for ordering such values, but all the logic necessary to do anythingwith it
> remains outside OBOE.
>  
>  
>  2.      Continuing the same subject. If we observe say color of a lion , is
> that a measurement or just an observation? If we qualify such recording of
> color as measurement, then given the specific association of  measurement
> with units, we must have units for all qualitative scales. Having one unit
> "qualitative" will be of no use, because this would lump  together unrelated
> thing such as colors {read, orange..} , health level {exellent, good,.},
> etc. Therefore, I would vote not to call such things as recording of color
> measurement, but consider them as special kind of observation
> The color of a lion is a measurement with unit "Name" and characteristic,
> e.g., "Blue", where blue is selected from an extension ontology.  This is
> the way we have it now as far as I understand it.  The overarching point is
> that we are trying very hard to separate Observation and Measurement for
> many reasons, such as context operating only on Observations.  This gives us
> some powerful ways to deal with ecological data, such as interpreting
> experimental design.  Therefore, I think that it is better to call things
> such as color measurements; e.g., color of stick; length of stick.  I'd be
> interested to see examples of how color could be defined/described as a
> special kind of observation.
>
>
> 3.      Each specific dimension has a set of related units. Say, length may
> be measured in meters, centimeters , microns . I believe that this
> association of a specific dimension with a set of respective units is an
> important intuition that helps to make sense of calculations. Why do not we
> draw an additional property hasUnit with domain Dimension  and range  Unit
>
> Hmm.  This sounds like a good idea.  I'll think about this some more.
>
>
> 4.      O&M scheme for Observation and Measurement has additional notion of
> observation/measurement procedure. It looks as if this concept could be
> easily added to OBOE by attaching property hasProcedure either to
> observation or to Measurement or to both. If we have property has procedure
> with domain that include both Observation and Measurement, then we might
> need to think how measurement procedure is related to observation procedure.
> Does it have sense to have both observation procedure and measurement
> procedure?
>
> Yes.  This would certainly make OBOE more complete, and I agree that this
> property should operate at both the Observation and Measurement level.  For
> example, we used a telescope for observing, but a tape measure for
> measuring.  It seems that EML already captures much of the procedural stuff,
> so we need to discuss if we want to become more redundant (e.g., EML covers
> much of the unit stuff as well), or whether we just want to fill in the gaps
> that EML can't cope with.  Personally, I think that OBOE should be a
> stand-alone initiative, and therefore include the concept of observation and
> measurement procedure.
>
>
> 5.      There is property hasMeasuredCharacteristic with domain Observation
> and range Measurement. Is Measurement an event, procedure or characteristics
> of something? I think that Measurement as such is not a characteristic but
> an event. But measurement is a measurement  *of* a characteristic. Therefore
> property hasMeasuredCharacteristi should have domain Measurement and the
> range Characteristic. (but in this case it will duplicate property
> hasSubject) . In fact the choice of range Characteristic is determined by
> the name of the property hasMeasuredCharacteristic. The domain may be either
> Measurement or Observation.
>
> I totally agree and there has been some discussion about this.  I really
> like your use of the word "event", I think this makes what we are actually
> doing much clearer.  For example, we Observe a tree, each Measurement is an
> event relating to that Observation, and a Measurement is of some
> characteristic.  I second the move changing the property between Observation
> and Meaurement to something like "hasMeasurementEvent". 
>  
>  
> Our definition, if I remember correctly, was :Observation is a statement
> that an Observable has been observed. I think more than this is going to
> color OBOE with restrictions it does not need to have. By the way, we model
> the result of the observation, not the process of the observation, and the
> result is not an event. To annotate a dataset we don't need to know anything
> about the measurement except its results. 
>
> Cheers,
> Josh
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Seek-kr-sms mailing list
> Seek-kr-sms at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-kr-sms
>   