[eml-cvs] eml eml-unitDictionary.xml

[Matt Jones]

Chad,

Having been looking into this myself, I think I agree with Peter that 
parentSI is a required attribute for all non-SI units.  Here's an 
example from the STMML XSD file:

<stm:unit id="g" name="gram" unitType="mass"
   parentSI="kg"
   multiplierToSI="0.001"
   abbreviation="g">
   <stm:description>0.001 kg.</stm:description>
</stm:unit>

Note that they explicitly state both the multiplier and the parent unit. 
  I think we need to do that to make it clear.  For some units we 
already do this (the earliest ones we created), but for later derived 
units we omitted parentSI, I think incorrectly.  For SI units, we can 
and should omit both the parentSI and the multiplierTOSI attributes. 
Only SI units should have a unitType attribute according to the spec. 
Here's the relevant text from the spec:

         SI Units. These may be one of the seven fundamental types
         (e.g. meter) or may be derived (e.g. joule). An SI unit is
         identifiable because it has no parentSI attribute and will have
         a unitType attribute.

         nonSI Units. These will normally have a parent SI unit
         (e.g. calorie has joule as an SI parent).

As far as Peter's example about the dictionary working like an ontology 
for deconstructing units to their types and reasoning about them, I 
think it is possible if we make the changes I just described.  This 
would allow us to find the parentSI unit for any arbitrary unit, and 
then to find the unitType for that SI unit.  For example, tracing 
feetPerDay back would yield:

unit       -> SI Unit        -> unitType -> dimension
feetPerDay -> meterPerSecond -> speed    -> length/time

Note that the spec explicitly states that an SI unit is identifiable 
because it has no parentSI attribute and it has a unitType attribute!

Matt

Chad Berkley wrote:
> Hi Peter,
> 
> See my comments below.
> 
> On Fri, 2002-10-18 at 08:55, Peter McCartney wrote:
> 
>>Ok, i see now that i have some numbers in there to convert between units
>>that have a similar unitType attribute. but i still dont see how the content
>>model really explains the derivation of the unit. take speed for example.
>>the unitType definition is still very abstract (divide some length by some
>>time). metersPerSecond and feedPerDay both have multipliers that obviously
>>scale both the distance and the time unit to their respective bases, but i
>>still dont really know what those are (other than guessing from their names
>>or descriptions). I can tell that metersPerSecond must be the base unit for
>>all other units that have a unitType of Speed, but this isnt really
>>explicitly stated any where - I just guessed it by the fact that its  the
>>only one with a multiplier of 1. 
> 
> 
> You don't guess by that, that's how you know it.
> 
>>I can see that the math all works fine within emlUnitDictionary, but what
>>happens when i extend it? Show me how I know that the SI to which feetPerDay
>>is multplied is metersPerSecond. suppose i need to define metersPerDecade
>>for glacial research. how do i know that the SI im supossed to provide a
>>multliplier for is metersPerSecond. for that matter, who decides what the
>>parent SI is, anyway? Suppose i give you a multiplier to feetPerDay. how
>>will you know to convert between the two different bases we've used in order
>>to understand my unit? to fix this, you need to minimally name the parentSI
>>in all these units so that we know what the multiplier is to.  
>>
> 
> No, you don't.  NIST (and various other standards bodies) define the
> base SI units for the most basic types of measurements (see
> http://physics.nist.gov/cuu/Units/) which are the ones I used.  The unit
> with a multiplier of 1 is the base SI unit, thus a unit must always have
> a multiplier back to the unit with a multiplier of 1.If you want to
> define feetPerDecade, you figure out what the conversion factor is to
> metersPerSecond (which has multiplierToSI="1")
> 
> 
>>Even doing this seems like a patch that makes things work, but i still
>>question whether we really have a real ontology here rather than a big
>>enumeration with multipliers to standards. Theres still nothing here that
>>lets me track a unit back to its unitType derivation and make any
>>intelligent use of the mathematical relations defined there. Show me how i
>>know that feetPerDay is calculated as the product of foot (a length unit)
>>and day (a time unit raised to -1).
>>
> 
> I totally agree that it would be useful to be able to match the unit
> back to the dimension which it is defining.  Perhaps we should engage
> Peter Murray-Rust in a conversation about that, since I didn't really
> understand his enterpretation of my example in a previous email.
> 
> Can you give me an example of an application of this that would require
> us to be able to link, say, feet to length or Decade to time so I can
> have a concrete example to work with Peter on.
> 
> chad
> 


-- 
*******************************************************************
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
*******************************************************************