OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

unitsml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [unitsml] Identity of units


From: "Martin S. Weber" <martin.weber@nist.gov>
To: <unitsml@lists.oasis-open.org>
Cc: <Joseph.F.Solsky@usace.army.mil>
Sent: Friday, April 17, 2009 5:55 PM
Subject: Re: [unitsml] Identity of units


> Quoting "Peter J. Linstrom" <peter.linstrom@nist.gov>:
> 
>> All,
>>
>>   I've added Joe Solsky to the distribution list as
>> noted in the agenda of Wednesday's teleconference.
> 
> Ooops, sorry Joe to forget about you.
> 
>>
>>   I just have a few comments about the proposed approach.
>>
>> 1.) The SI base, special derived units, and non-SI units
>>    approved for use with the SI are all enumerated in
>>    UnitsML, so units which are derived from them should
>>    generally not need to use the <ExternalRootUnits>
>>    element. (...) In any
>>    case I believe such usage [of External instead of Enumerated
>>    Root Unit] should be discouraged
> 
> I fully agree
> 
>>    and that
>>    there should be a need to resolve <ExternalRootUnit> URNs
>>    to deal with units which in the SI or approved for use
>>    in the SI. I believe this would also be largely true for
>>    units in the cgs and U.S. and U.K. customary unit systems.
> 
> I'm not sure I agree with this one. Why would we want to limit  
> unitsml's scope to that of SI units and their friends only? Even if  
> I'm marking up a unit whose use is discouraged by the SI, shouldn't I  
> use unitsml for it?

The intention was not to limit the use of UnitsML, but to
note that for the SI and several other common unit systems
you won't need <ExternalRootUnits>. Since the orginal
discussion refered exclusively to SI, I noted that I don't
think you would ever need <ExternalRootUnits> with SI units
and units approved for use with the SI.

> 
>>
>> 2.) The guidelines should mandate that enumerated root
>>    units be used whenever possible. (...)
> 
> Absolutely!
> 
>> 3.) The purpose of the <ExternalRootUnit> element is for
>>    units which can't be defined in terms of other units.(...)
> 
> Is it? I got the impression it's for units that indeed can be defined  
> in terms of other units, but whose underlying units are not in the  
> list provided by <EnumeratedRootUnit> (either because it's non-SI or  
> because it's itself a synthesized unit based on <EnumeratedRootUnit>s).

Would it make sense to define a derived unit without defining
the base unit? In this case would the derived unit not effectively
be a base unit? As a practical matter the number of units which
would need to be refered to by <EnumeratedRootUnit> would be
minimized (which we want) if you only used it for base units.
Consider two scenarios:

1.) Bethesda Units (BU) defined as a base unit in an external DB.
    BU / min and BU / s can be defined by refering to the external
    definition and the enumerated time unit. Only one external
    definition is required.

2.) BU / min and BU / s are defined in an external DB. Two external
    definitions are required.

> 
> Also the above all helps with determining the identity of derived  
> units, what is a hard issue for me atm is determining the identity of  
> two unit definitions of the same base unit (which will most likely  
> happen because not everybody's using UnitsDB / people do not need to  
> use UnitsDB). Any thoughts on that?

I think you are on the right track. There is no solution which
will work all the time since you can't control people's behavior.
I think that if you compare the enumerated root units and external
root units (without attempting to resolve the external source)
you will cover a very large fraction of the use cases. I don't
think trying to examine external root units will be useful because

1.) I don't think there is any gaurantee that the URL will
    resolve.
2.) I think (hope) that practically all external units will
    be base units.
3.) It might encourage behavior which should not be encouraged
    (unnecessary use of external definitions of derived units).

In practice, there will probably be some corner cases where
it will be beneficial to try to resolve external root units, but
I don't know if it would be worth the effort to implement this
in code at this time.

Peter

> 
> -Martin
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]