Last week, at the ontology PSIG, last week, I said I would make available to the QUDV group the latest internal Date-Time submission draft. It's attached to this email: (See attached file: Date-Time v3.doc)
I also proposed that we have a joint conference call between the QUDV group and the Date-Time group, to discuss the topics that I raised in my email of August 4, which I copy below. I can provide a conference call line. Best times for the date-time team seem to be Friday afternoons. However, I am not available on October 2. Other alternatives are Tuesday and Wednesday afternoons.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 784-7002 or IBM tieline 863-7002
internet: [email protected]
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
August 4, 2009
Roger,
I read through the QUDV proposal (http://wiki.omg.org/OMGSysML/doku.php?id=sysml-qudv:quantities_units_dimensions_values_qudv) and have the following comments. I do think this could be a basis for the Date-Time effort, although there are some aspects that need discussion. One concern is that the Date-Time effort decided to work with discrete time, rather than continuous time. Our reasoning is that, from a business point-of-view, time is always viewed discretely. The continuous model adds complication without value for business purposes. QUDV apparently supports continuous units of measure. Is there a way to use QUDV while restricting it to discrete units?
I note that conversions are defined for all three of (1) Units; (2) QuantityKinds, (3) Dimensions -- and (3) are derived from (2). Even given the derivation with the provided algorithm, it seems like this is triple-redundant. Did you consider just providing (1)? For example, in figure C.12 it seems like the DimensionFactors and QuantityKindFactors for the dimension "force" are the same as the UnitFactors for the "newton" DerivedUnit. Instead of modeling QuantityKindFactor and DimensionFactor, why not just use the UnitFactors of the base unit associated with a QuantityKind (i.e. QuantityKind.unit.UnitFactor)? In this regard, note that VIM 1.24 "conversion factor between units" defines conversions among units but not conversions among dimensions or quantity kinds. Although I admit that VIM 1.7 "Quantity Dimension" discusses what you model as DimensionFactor.
ISO 18206 "Spatial Reference Model", makes an important distinction between the concepts of "quantity" and "coordinate". A coordinate is a position in space or time, such as "mile 3 of the marathon" or "3pm" as opposed to "3 miles" or "3 hours". This distinction shows up in the spring example in section C.5.4.2 as "LinearPosition" versus "LinearDistance". I think you should elevate "coordinate" to a first-class concept in the vocabulary. This is especially important for Date-Time because we want to support repeating times, as in "3pm every day". So we need to talk explicitly about coordinates.
I'm glad to see a model of Scales, but I think it should be much richer to capture the full semantics of Scales such as time scales, weight scales, and length scales. (1) A Coordinate value can be read from a Scale. (2) Scales may be anchored to one or more reference points. (For example, the Centigrade scale is anchored to the freezing and boiling points of water.) (3) Successive values of a Scale monotonically increase by 1. (4) Some (but not all) Scales have a first value or a last value, or both. (For example, the scale of hours in a day runs from 0 to 23.) (5) There can be a mapping between Scales of Units that are Derived from each other. (For example, there is a mapping from a scale of seconds to a scale of minutes.)
I think the definitions of Units (e.g. "metre", "second") provided in section C.5.4.1 should be formal components of the library, not usage examples. These will be widely needed in many applications.
The model of "Quantity" doesn't seem to provide for composite quantities, as in "3 hours, 30 minutes" or "3 kilometres, 3 metres". Reference VIM note 5 under "Quantity": "A quantity as defined here is a scalar. However, a vector or a tensor, the components of which are quantities, is also considered to be a quantity."
VIM defines both "Quantity" and "Quantity Value", although the distinction is unclear in VIM. I believe that "Quantity" is the quantity of a generic thing (e.g. the quantity "height of the concept 'person' "), whereas "Quantity Value" is the quantity of a specific thing (e.g. the quantity value "height of Mark"). In my experience, making this distinction helps when applying a units of measure vocabulary.
A comment about QuantityKind: in our Date-Time discussions, we decided that QuantityKind is what SBVR calls a "categorization type" for Quantity. This is what UML calls a PowerType (see the UML SuperStructure document, sections 7.3.8 and 7.3.21). This makes each instance of QuantityKind (e.g. length, mass, time, etc.) a kind (subtype) of Quantity. This (a) strengthens the relationship between Quantity and QuantityKind; (b) eliminates the need for Quantity.quantityKind; (c) makes the instances of QuantityKind themselves be concepts. Point (c) permits the various kinds of Quantities to be used as types of UML Properties.
I strongly disagree with the concept "SpecializedQuantityKind". The text in C.5.3.19 says that 'For example, “distance”, “width”, “depth”, “radius” and “wavelength” can all be specified as specializations of the “length” SimpleQuantityKind.' But example C.5.4.1 shows that "lengthQK" would be an *instance* of SimpleQuantityKind. You can't specialize an instance! This can be solved by defining QuantityKind as a UML Powertype. In any case, I suggest that concepts such as "distance", "width", etc. are best modeled as Properties typed by (rather than specializations of ) the appropriate QuantityKind. For example, a class "box" might have three Properties called "height", "depth", and "width" all typed as "Length" where "Length" is a subtype of "Quantity" and an instance of "QuantityKind".
In figure C.9, I think you should show both associations between SystemOfQuantities and QuantityKind, as well as the subsets relationship between them. This would emphasize the parallel construction between SystemOfUnits and SystemOfQuantities.
There is an important difference between UML and SBVR in naming and synonyms. You give each major concept (e.g. Unit, QuantityKind, Prefix, etc.) both a "name" and a "symbol" property. So figure C.11 shows that the SimpleUnit called "metre" has a name "metre" and a symbol "m". In an SBVR model, this SimpleUnit would be named in the vocabulary as "metre" and would have a synonym "m", but it would not need the properties "name" and "symbol". Is there a reason why these properties are needed in the instances? Ditto for "description".
Why does Dimension have both "symbolicExpression" and "factor" properties? Why is only "factor" shown in diagram C.10? If Dimension keeps "symbolicExpression" then shouldn't it also have "expressionLanguageUri"?
In GeneralConversionUnit, why is the unit conversion relationship defined in terms of "valueRU / valueCU"?
In Quantity, why does only one of the three properties have to be specified? Under what conditions would it be useful to have only one of them?
Why would Unit ever not have a QuantityKind?
I noticed the following in the OCL algorithm associated with SystemOfQuantities:
* Several uses of an undefined method called "getDimension(QuantityKind)"
* Why does the derQFactors definition add together the exponents from the DimensionFactors and the QuantityKindFactors?
Typos:
* C.5.3.10 PrefixUnit: "106" should be "10 raised to the sixth power" (twice)
* C.5.3.14 has a second section number 8.3.3.2
* C.5.3.15 Scale is missing the Property "quantityKind" shown in figure C.8
* C.5.4.2 2nd sentence, "arbitraty"
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 784-7002 or IBM tieline 863-7002
internet: [email protected]
Attachment: Date-Time v3.doc
Description: MS-Word document