GarryJolleyRogers - Wed Nov 25 2009 - Version 1.7
Parent topic: SchemaDiscussion

MeasurementUnitDocumentation

The Documentation on the MeasurementUnit element in SDD says that "Refers to ... definition in Terminology/General... "
I am assuming this documentation comes from the old schema? , since the ref attribute points to
ExternalDataInterface/MeasurementUnits/MeasurementUnit from UBIF.xsd -- Main.JacobAsiedu - 12 Sep 2004

• Thanks, your are guessing correctly; I will improve the annotation! These small corrections are very important to me! -- Main.GregorHagedorn - 13 Sep 2004

The definition in UBIF.xsd has an InternationalAbbreviation element as a child node. However, the reference to MeasurementUnit in SDD also has an InternationalAbbreviation child node. Is this an error? If it is not,then does it make sense to define one or more InternationalAbbreviation for the same MeasurementUnit ? -- Main.JacobAsiedu - 12 Sep 2004

• This is a more general question, and I welcome a general thought. Currently, for Agents and Units tentatively the concept of MicroMeasurementUnit and MicroAgent types have been proposed. These allow a local definition as an alternative to a reference to a ExternalDataInterface proxy object. This makes it more convenient for people who are scared about all the relations in the model, if they use only a single string to define it locally.
• I am not sure this is worth it - I put it in to keep the discussion/idea alive. We have strongly opposing critique here, and many claim with the relations it is too complicated.
• Would in general the MeasurementUnit be a place where to do this, or should we rather enforce the use by ref? Please comment - we need something like an opinion poll on this!
• A confusing problem is that xml schema to my knowledge does not allow to specify the two cases as an alternative - which is the design intention. That is, you cannot validate that either the local InternationalAbbreviation must be present and ref missing, or the ref present, and InternationalAbbreviation missing. The alternative would be possible if ref would be an element, but it seems impossible when it is an attribute. Any insight on this?
• -- Main.GregorHagedorn - 13 Sep 2004

* I noticed that MeasurementUnit is on the Character reference. I think it should also be on PMeasure and Measure elements that way
when one has a QuantitativeCharacter with its states(PMeasure and Measure) having polymorphic units(say mm and cm) then one can easily associate each state with the right unit within one single QuantitativeCharacter element.
Currently, in SDD one has to create a QuantitativeCharacter for each each state with a different unit of measure.
An example, borrowed from Main.BryanHeidorn prairie plants data is:

QuantitativeCharacter : "plant_height_when_mature"
State1 : 6 dm
State2 : 3 ft

With the current SDD we coded it as follows:

   <Quantitative ref="2758" debugref="plant height when mature">
                  <Measure type="..." value="6.0"/>
                  <MeasurementUnit>
                     <InternationalAbbreviation>dm</InternationalAbbreviation>
                  </MeasurementUnit>
               </Quantitative>
               <Quantitative ref="2758" debugref="plant height when mature">
                  <Measure type="..." value="3.0"/>
                  <MeasurementUnit>
                     <InternationalAbbreviation>ft</InternationalAbbreviation>
                  </MeasurementUnit>
               </Quantitative>

                                      <Quantitative ref="2758" debugref="plant height when mature">
                  <Measure type="..." value="6.0">
                      <MeasurementUnit>
                     <InternationalAbbreviation>dm</InternationalAbbreviation>
                      </MeasurementUnit>
                                              </Measure>
                                               <Measure type="..." value="3.0">
                      <MeasurementUnit>
                     <InternationalAbbreviation>ft</InternationalAbbreviation>
                  </MeasurementUnit>
                                           </MeasurementUnit>
               </Quantitative>

-- Main.JacobAsiedu - 08 Jul 2005

Final note: At the root of this problem lies that some quantitative characters may span several orders of magnitude, depending on taxonomic scope of a dataset. For example plant hight may be 450 µm, 8 mm, 6 cm, 1.7 m, or 85 m. it is not desirable to express this as, e. g., 0.4500 mm, 8 mm, 60 mm, 1700 mm, and 85000 mm. Furthermore in data integration projects some data may be expressed in non-scientific local units like inch or feet.

In SDD up to St. Petersburg meeting in 2005 it was possible to define measurement units both as a default at the character definition, and as "override" at character data in individual descriptions. Measurement Units where defined as first-class objects and they could, in both cases be used by reference. Measurement Units further contained a relation mechanism that provided for defining conversion factors between units. However, in an attempt to lower the usuage hurdle for SDD, both at character definition and character data level it was possible NOT to use the ref-to-MeasurementUnit object method, but instead provide a simple string for unit.

At TDWG St. Petersburg both Jacob and Kevin raised concern about this, since it is difficult to assess whether the necessary information for comparibility of quantitative characters that use measurement units at the character level is available. This problem occurs both in the simplified string and in the object reference case (in the latter no guarantee is given that the specific relation used in the data is present).

In an attempt to solve the conflicting interest of flexibility, low entry level the final SDD 1.0 now proposes a different solution: MeasurementUnit is defined only at the character definition level. However, a scaling prefix may be defined at character definition (as default) and character data level (as override). Since the prefixes used in scientific SI units are completely enumerated (and provided as a UBIF enumeration), software can guarantee that it provides all necessary conversion methods.

With this structure, the initial problem of "450 µm, 8 mm, 6 cm, 1.7 m, or 85 m" can be solved. However, it is no longer possible to use both inch and cm in a single character. They must either be converted upon or after data entry or two different characters in the same dataset may be used. Theoretically it is possible to provide a special inch-to-cm scaling prefix by extending SDD, but this is not proposed generally because it is considered normally confusing (it would lead to reports like: 3 cm, 1 inch-to-cm, where the latter measurement would have to be understood by consumers as 2.54 cm.

-- Main.GregorHagedorn - 30 Sep 2005