[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]