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