[eml-cvs] eml eml-unitDictionary.xml

[Dan Higgins]

Matt,
    I thought I would add a comment to your discussion (which may be of 
little value based on the fact that I have not been following all the 
unit discussions).

    Assuming that SI units are actually the starting point for your unit 
ontology, what you seem to be proposing is linking every derived unit to 
the parent SI unit. That works just fine, but it is like an ontology 
where every new term must be defined in terms of some base set of terms. 
The alternative is to only require that a new unit be defined in using 
any previously defined units, not just the base units. As an example, 
inches might be defined as a certain number of feet and feet then 
defined as a certain number of meters. This means that a conversion 
process would need to traverse the unit definition network (i.e. convert 
inches to feet and then feet to meters), but it might make it easier for 
the user than having to figure out the conversion to SI for every new unit.

Dan

Matt Jones wrote:

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


-- 
---------------------------------
Dan Higgins
Software Developer
National Center for Ecological Analysis and Synthesis (NCEAS) 
735 State St. Rm 205 
Santa Barbara, CA 93101 
805-892-2531 
higgins at nceas.ucsb.edu 
---------------------------------