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


All,

   I've added Joe Solsky to the distribution list as
noted in the agenda of Wednesday's teleconference.

   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. The only case I can think of where this might
    make sense is if the unit used a named derived unit
    based on SI units whose name is outside of the SI and
    hence referred to using <ExternalRootUnits>. An example
    of this would be if you came up with a named unit for
    area which corresponds to square meters and then referred
    to it using <ExternalRootUnits>. I don't know if such an
    approach is technically legal for use in the SI. In any
    case I believe such usage should be discouraged 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.

2.) The guidelines should mandate that enumerated root
    units be used whenever possible. Otherwise it will be
    impossible to determine if two definitions refer to
    the same unit are the same unless they refer to the same
    external definitions. Since anybody can create a unit
    definition, there is absolutely no way to force everyone
    to use the same external definitions.

3.) The purpose of the <ExternalRootUnit> element is for
    units which can't be defined in terms of other units.
    I believe these will largely show up in specific
    domains so there may be some hope the industrial and
    professional groups will provide definitions for
    units in their field. For example, a definition for
    Bethesda Units (http://en.wikipedia.org/wiki/Bethesda_unit)
    might be provided by a medical society or institute.

Peter

======================================================
Peter J. Linstrom
NIST, Chemical and Biochemical Reference Data Division
Phone: (301) 975-5422
======================================================

----- Original Message ----- 
From: "Martin S. Weber" <martin.weber@nist.gov>
To: <unitsml@lists.oasis-open.org>
Sent: Friday, April 17, 2009 4:07 PM
Subject: [unitsml] Identity of units


> I've had a talk with Robert today about a point that was brought up by
> Prof James Davenport (and also transported by him to the OM-3 ML), which
> is the point of deciding about identity of units.
>
> To refresh your memories: what I had suggested to use for the openmath
> people is to have < OMFOREIGN > elements wrap up UnitsML unit vocabulary
> and put this into a OM Content Dictionary. To go one step further, they
> could even use XInclude or XPointer to pull in these definitions by URL
> from the UnitsDB but that is beyond the scope of the TC :-)
>
> What James then brought up was, to my interpretation, a scenario like
> the following: Something is using openmath or mathml and refers to an
> openmath content dictionary unit. Something else is using (one of the
> possible ways to) embed(ded) UnitsML to mark up units of measure related
> to some formulae or numerals. Now the question of identity arises, i.e.,
> are the two using the same units?
>
> If e.g. both parties instead would simply be referencing the UnitsDB
> the answer would be simple, if the URLs and the GET request are the
> same, then, obviously, they are talking about the same unit. For other
> types of referencing we still could look at the unit's xml:id. But that
> only works so long when talking about the same dictionary of units. In
> the event of combination of OM and UnitsML units, the ids are likely to
> be different: one top-level xml:id for the < OMFOREIGN > definition,
> one for the unit on the other side. The wrapped up unitsml markup within
> the omforeign -could- carry the same xml:id as the one in UnitsDB, but
> from unitsml 1.0 to unitsdb being the canonical unitsml source of units
> there's still "some" way to go. It is thus likely that the unitsml
> content will be different.
>
> So how do we decide if two units are the same? We have a lot of optional
> information which can be left out, so we can only rely on that to a
> certain extent. In talking with robert, I think though we've realised
> a practical way to determine identity of units, by a inductive process:
>
> 1) Different representations of the same seven SI base units are 
> identical.
> 2) Identity of derived units is determined by their contained root units.
>
> To realize 2) above, we simply follow all the < ExternalRootUnit >
> mentions, and recursively collect the < EnumeratedRootUnit>  mentions(*)
> to build up a list of the base units. At some point there should be no
> more < ExternalRootUnit >s to collect, and then we can decide whether
> two derived units are the same.
>
> Now about 1): We don't have to care about that if people stick to using
> the < EnumeratedRootUnit >(*). But it is likely that at least for some
> period of time where there exists no canonical data source for unitsml
> markup (aka unitsdb) there will be concurring unitsml markups of the
> legal, definitive definitions of the seven SI base units. So to some
> extent we also have to worry about when to decide that two unitsml marked
> up representations of e.g. the "metre" (en-UK :) are identical. We have
> considered to require via the guidelines, that there are < UnitDefinition
>> s available that ultimately refer to the BIPM normative legal definition
> of the metre (or meter how you people call it) etc., but for that we'd
> need the BIPM to have stable identifiers of different versions of the
> metre etc., which we still have to find out. Also it's not as easy in
> the light of updated fundamental physical constants, are we referencing
> the old metre per default? Or an updated one? Always the latest? etc.
>
> So some food for thought: How to decide if two unitsml marked up units
> are "identical"? What should we REQUIRE (**) in the guidelines to enable
> a UnitsML processor to decide about identity? IMO this is a question we
> have to solve before we can deliver "1.0" as it's very likely to be
> asked by implementors (heck your early adopter #1 -- me -- is stumbling
> over it. Help!:)
>
> -Martin
>
> (*) The guidelines should mention that base root units SHOULD(**) or
> even MUST be referred to via < EnumeratedRootUnit >, and
> < ExternalRootUnit > SHOULD be used if referring to another non-base
> unit ("or else"!)
> (**) in RFC2199 parlese
>
> ---------------------------------------------------------------------
> 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]