Issue 18724: QUDV's Unit::quantityKind and Unit::primaryQuantityKind are redundant and too limiting for reuse across systems of unit (sysml-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: SysML issue 18692 raised the problem of reuse of definitions of Units and QuantityKinds across SystemOfUnit and SystemOfQuantities respectively. For example, the SI SystemOfUnits has 7 base units: meter, kilogram, second, ampere, kelvin, mole and candela. These base units are in 1-1 correspondence with base quantity kinds in the ISQ: length, mass, time, electric current, thermodynamic temperature, amount of substance and luminous intensity. (See SysML 1.3, Figure D.5). The association between Unit and QuantityKind where a QuantityKind is the Unit::primaryQuantityKind for a given Unit is redundant with the choice of SystemOfUnits::baseUnit and SystemOfQuantities::baseQuantityKind. For example, in the context of the SI, length as a baseQuantityKind of the ISQ is the "primary quantity kind" for metre as a baseUnit in the SI. Conversely, length as a baseQuantityKind of the ISQ is not the "primary quantity kind" for kilometre in the SI because kilometre is not a baseUnit of the SI. From a reuse perspective, it should be possible to define a coherent, non-SI SystemOfUnit whose baseUnits are the same as those of the SI except for replacing metre with kilometre. This non-SI SystemOfUnit would be coherent with respect to the ISQ because length, as a baseQuantityKind of the ISQ would still be the "primary quantity kind" for kilometre as a baseUnit of this non-SI SytemOfUnit. To support this flexibility of reuse of Unit and QuantityKind definitions, it is necessary to eliminate the Unit::primaryQuantityKind association from QUDV and instead derive the "primary quantity kind" of a given Unit in the context of a particular SystemOfUnit. Furthermore, such a non-SI SystemOfUnit could define "inch" as a QUDV::LinearConversionUnit by reference to metre. In SysML 1.3 QUDV, this would require "inch" to specify that its Unit::quantityKinds are length. This is redundant with the fact that metre already specifies length as its Unit::quantityKinds. This redundancy could lead to inconsistencies if users define derived units and forget to specify their Unit::quantityKind or do so differently than the Unit::quantityKind of their referenced unit. The only kind of Unit where it is logically necessary to specify Unit::quantityKind is for QUDV::SimpleUnit. In all other cases, the Unit::quantityKind collection can be derived. For example, for any kind of ConversionBasedUnit, it can be derived by following ConversionBasedUnit::referenceUnit and querying that Unit for its quantityKind collection. For a DerivedUnit, it can be derived by following DerivedUnit::factor and UnitFactor::unit and querying the Units for their quantityKind collections. Resolution: Revised Text: Actions taken: May 17, 2013: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "sysml-rtf@omg.org" Subject: QUDV's Unit::quantityKind and Unit::primaryQuantityKind are redundant and too limiting for reuse across systems of units Thread-Topic: QUDV's Unit::quantityKind and Unit::primaryQuantityKind are redundant and too limiting for reuse across systems of units Thread-Index: AQHOUy4x0BjxBbDePEy8ejHHKBW5tA== Date: Fri, 17 May 2013 18:41:50 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR3FGB0= X-Brightmail-Tracker: AAAAAA== SysML issue 18692 raised the problem of reuse of definitions of Units and QuantityKinds across SystemOfUnit and SystemOfQuantities respectively. For example, the SI SystemOfUnits has 7 base units: meter, kilogram, second, ampere, kelvin, mole and candela. These base units are in 1-1 correspondence with base quantity kinds in the ISQ: length, mass, time, electric current, thermodynamic temperature, amount of substance and luminous intensity. (See SysML 1.3, Figure D.5). The association between Unit and QuantityKind where a QuantityKind is the Unit::primaryQuantityKind for a given Unit is redundant with the choice of SystemOfUnits::baseUnit and SystemOfQuantities::baseQuantityKind. For example, in the context of the SI, length as a baseQuantityKind of the ISQ is the "primary quantity kind" for metre as a baseUnit in the SI. Conversely, length as a baseQuantityKind of the ISQ is not the "primary quantity kind" for kilometre in the SI because kilometre is not a baseUnit of the SI. From a reuse perspective, it should be possible to define a coherent, non-SI SystemOfUnit whose baseUnits are the same as those of the SI except for replacing metre with kilometre. This non-SI SystemOfUnit would be coherent with respect to the ISQ because length, as a baseQuantityKind of the ISQ would still be the "primary quantity kind" for kilometre as a baseUnit of this non-SI SytemOfUnit. To support this flexibility of reuse of Unit and QuantityKind definitions, it is necessary to eliminate the Unit::primaryQuantityKind association from QUDV and instead derive the "primary quantity kind" of a given Unit in the context of a particular SystemOfUnit. Furthermore, such a non-SI SystemOfUnit could define "inch" as a QUDV::LinearConversionUnit by reference to metre. In SysML 1.3 QUDV, this would require "inch" to specify that its Unit::quantityKinds are length. This is redundant with the fact that metre already specifies length as its Unit::quantityKinds. This redundancy could lead to inconsistencies if users define derived units and forget to specify their Unit::quantityKind or do so differently than the Unit::quantityKind of their referenced unit. The only kind of Unit where it is logically necessary to specify Unit::quantityKind is for QUDV::SimpleUnit. In all other cases, the Unit::quantityKind collection can be derived. For example, for any kind of ConversionBasedUnit, it can be derived by following ConversionBasedUnit::referenceUnit and querying that Unit for its quantityKind collection. For a DerivedUnit, it can be derived by following DerivedUnit::factor and UnitFactor::unit and querying the Units for their quantityKind collections. - Nicolas.