Issue 16921: ISO 80000 & Date/Time Foundation Vocabulary (date-time-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: The Date-Time Vocabulary (DTV) document FTF beta 1 draft Mike sent on Dec. 8, 2011 shows a concept of 'time unit' specialized as: - 'precise time unit', a specialization of 'measurement unit' - 'nominal time unit' It is understood that in DTV, a 'precise time unit' is a kind of ISO 80000 measurement unit (i.e., 3.8 in ISO-80000-1): real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the second quantity to the first one as a number The DTV names for 'time unit' and 'nominal time unit' are misleading because in the Dec. 2011 DTV FTF 1 beta document, these terms are not defined as kinds of ISO 80000 measurement units. From the DTV FTF perspective, the objection against defining 'time unit' and 'nominal time unit' as ISO 80000 measurement units is that 'month', a kind of 'nominal time unit', varies between 28 and 31 days and therefore does not exactly fit the definition of measurement unit per ISO 80000. In pure ISO 80000 terms, this would suggest that 'month' would be a measurement unit with a variable conversion factor from 'day', which is defined as a normative measurement unit in ISO 80000-3, item 3-7.d. I believe that the DTV interpretation of ISO 80000 measurement unit is too restrictive and should be changed such that a DTV 'time unit' is in fact a kind of ISO 80000 'measurement unit'. There is compelling evidence to support this change in ISO 80000 itself: 1) The definition of year as a non-SI measurement unit in ISO 80000-3, Annex C, item 3-7 shows an example where the conversion factor is variable: a := 365d or 366d One tropical year is the duration between two successive passages of the Sun through the mean vernal equinox. This duration is related to the corresponding difference in mean longitude of the Sun, which depends on time in a not exactly linear form; i.e. the tropical year is not constant but decreases at a rate of nearly per century. The tropical year is approximately equal to 365,242 20 d ≈ 31 556 926 s. 2) The value of a quantity can be expressed in three ways according to ISO 80000-1, item 3.19: - a product of a number and a measurement unit - a number and a reference to a measurement procedure - a number and a reference material 3) 'month' could be defined as an ISO 80000 'conventional reference scale', that is, a quantity-value scale defined by formal agreement. This could facilitate defining that 'month' is a 'conventional reference scale' varying between 28 and 31 'days'. Specializations of 'month' could be made for 28-days months, 29-days months, 30 days months, 31 days months where such specializations can be defined as ISO 80000 derived units of 'days' with a precise conversion factor. 4) 'amount of substance', one of the 7 base quantities in the International System of Quantities, ISQ, is intrinsically context-dependent: See the remarks in ISO-80000-9, 9-1: Amount of substance of a pure sample is that quantity that can often be determined by measuring its mass and dividing by the molar mass of the sample. Amount of substance is defined to be proportional to the number of specified elementary entities in a sample, the proportionality constant being a universal constant which is the same for all samples. The name “number of moles” is often used for “amount of substance”, but this is deprecated because the name of a quantity should be distinguished from the name of the unit. In the name “amount of substance”, the words “of substance” could, for simplicity, be replaced by words to specify the substance concerned in any particular application, so that one may, for example, talk of “amount of hydrogen chloride, HCl”, or “amount of benzene, C6H6”. It is important to always give a precise specification of the entity involved (as emphasized in the second sentence of the definition of the mole); this should preferably be done by giving the molecular chemical formula of the material involved. Just like 'amount of hydrogen chloride' is a specialization of 'amount of substance', 'January' is a specialization of 'month. All are measurement units in the sense of ISO 80000. The DTV specification should clearly indicate the correspondence between the DTV vocabulary and the corresponding ISO 80000 vocabulary. These correspondences are important to clarify the relationship between the use of ISO 80000 vocabulary in DTV and SysML's QUDV. Resolution: Revised Text: Actions taken: December 19, 2011: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "date-time-ftf@omg.org" Date: Mon, 19 Dec 2011 11:07:29 -0800 Subject: ISO 80000 & Date/Time Foundation Vocabulary. Thread-Topic: ISO 80000 & Date/Time Foundation Vocabulary. Thread-Index: Acy+gXTwFnwmced/TIGfu5BlHWtYwA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized The Date-Time Vocabulary (DTV) document FTF beta 1 draft Mike sent on Dec. 8, 2011 shows a concept of 'time unit' specialized as: - 'precise time unit', a specialization of 'measurement unit' - 'nominal time unit' It is understood that in DTV, a 'precise time unit' is a kind of ISO 80000 measurement unit (i.e., 3.8 in ISO-80000-1): real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the second quantity to the first one as a number The DTV names for 'time unit' and 'nominal time unit' are misleading because in the Dec. 2011 DTV FTF 1 beta document, these terms are not defined as kinds of ISO 80000 measurement units. From the DTV FTF perspective, the objection against defining 'time unit' and 'nominal time unit' as ISO 80000 measurement units is that 'month', a kind of 'nominal time unit', varies between 28 and 31 days and therefore does not exactly fit the definition of measurement unit per ISO 80000. In pure ISO 80000 terms, this would suggest that 'month' would be a measurement unit with a variable conversion factor from 'day', which is defined as a normative measurement unit in ISO 80000-3, item 3-7.d. I believe that the DTV interpretation of ISO 80000 measurement unit is too restrictive and should be changed such that a DTV 'time unit' is in fact a kind of ISO 80000 'measurement unit'. There is compelling evidence to support this change in ISO 80000 itself: 1) The definition of year as a non-SI measurement unit in ISO 80000-3, Annex C, item 3-7 shows an example where the conversion factor is variable: a := 365d or 366d One tropical year is the duration between two successive passages of the Sun through the mean vernal equinox. This duration is related to the corresponding difference in mean longitude of the Sun, which depends on time in a not exactly linear form; i.e. the tropical year is not constant but decreases at a rate of nearly per century. The tropical year is approximately equal to 365,242 20 d â 31 556 926 s. 2) The value of a quantity can be expressed in three ways according to ISO 80000-1, item 3.19: - a product of a number and a measurement unit - a number and a reference to a measurement procedure - a number and a reference material 3) 'month' could be defined as an ISO 80000 'conventional reference scale', that is, a quantity-value scale defined by formal agreement. This could facilitate defining that 'month' is a 'conventional reference scale' varying between 28 and 31 'days'. Specializations of 'month' could be made for 28-days months, 29-days months, 30 days months, 31 days months where such specializations can be defined as ISO 80000 derived units of 'days' with a precise conversion factor. 4) 'amount of substance', one of the 7 base quantities in the International System of Quantities, ISQ, is intrinsically context-dependent: See the remarks in ISO-80000-9, 9-1: Amount of substance of a pure sample is that quantity that can often be determined by measuring its mass and dividing by the molar mass of the sample. Amount of substance is defined to be proportional to the number of specified elementary entities in a sample, the proportionality constant being a universal constant which is the same for all samples. The name ânumber of molesâ is often used for âamount of substanceâ, but this is deprecated because the name of a quantity should be distinguished from the name of the unit. In the name âamount of substanceâ, the words âof substanceâ could, for simplicity, be replaced by words to specify the substance concerned in any particular application, so that one may, for example, talk of âamount of hydrogen chloride, HClâ, or âamount of benzene, C6H6â. It is important to always give a precise specification of the entity involved (as emphasized in the second sentence of the definition of the mole); this should preferably be done by giving the molecular chemical formula of the material involved. Just like 'amount of hydrogen chloride' is a specialization of 'amount of substance', 'January' is a specialization of 'month. All are measurement units in the sense of ISO 80000. The DTV specification should clearly indicate the correspondence between the DTV vocabulary and the corresponding ISO 80000 vocabulary. These correspondences are important to clarify the relationship between the use of ISO 80000 vocabulary in DTV and SysML's QUDV. - Nicolas. To: "date-time-ftf@omg.org" Subject: [Date-Time] Re: ISO 80000 & Date/Time Foundation Vocabulary. X-KeepSent: 0EDAF3B8:839BB61F-85257975:0067F568; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Thu, 29 Dec 2011 15:20:41 -0500 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 12/29/2011 15:20:41, Serialize complete at 12/29/2011 15:20:41 x-cbid: 11122920-8974-0000-0000-000004B85C9D Nicolas, If you look further in the Date Time Vocabulary, you will see that it models "nominal time units" as kinds of "duration value sets", which are "sets of duration values". In particular, the nominal time unit "year" is "{365 days, 366 days}", and "month" is "{28 days, 29 days, 30 days, 31 days}". This formally models the definition of "year" that you cited from Annex C of ISO 80000-3, and provides a similar definition for "month". One motivation for defining nominal time units as sets is to get a precise meaning for "compound duration values" (i.e. durations that involve multiple time units, such as "1 year and 1 day"). Date-Time defines the meaning of such compound duration values in terms of the precise time unit "day". So "1 year and 1 day" is {366 days, 367 days}, and "1 month 1 day" is {29 days, 30 days, 31 days, 32 days}. But "2 years 1 day" is {731 days, 732 days}, NOT {732 days, 733 days}, because any two-year time span can include at most 1 leap day. Date-Time takes great care to define the conversion of nominal time units to sets of precise time units to deal with such issues, and to provide appropriate arithmetic and comparison relationships among these sets, and between sets and singular duration values. The conversions, arithmetic operators, and comparison relationships for precise time units are quite simple, in comparison. Distinguishing "precise" and "nominal" time units has the benefits of (a) making clear the formal relationship between "precise time unit" and ISO 80000-3 "measurement unit"; (b) enabling the special semantics outlined above for "nominal time units" while not adding complexity or confusion to "precise time units"; (c) providing the common supertype "time unit" for use when it makes sense to jointly refer to both kinds of time units. I notice that we do not have a Rationale section that discusses this topic. I hope this note convinces you that we should not change the current Date-Time approach, and that what's really needed is a layman's discussion of that approach. So I propose that the resolution of this issue is to add such a Rationale section. If you disagree with me, let's correspond this way and/or by phone. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" Cc: "date-time-ftf@omg.org" Date: 12/19/2011 02:08 PM Subject: ISO 80000 & Date/Time Foundation Vocabulary. -------------------------------------------------------------------------------- The Date-Time Vocabulary (DTV) document FTF beta 1 draft Mike sent on Dec. 8, 2011 shows a concept of 'time unit' specialized as: - 'precise time unit', a specialization of 'measurement unit' - 'nominal time unit' It is understood that in DTV, a 'precise time unit' is a kind of ISO 80000 measurement unit (i.e., 3.8 in ISO-80000-1): real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the second quantity to the first one as a number The DTV names for 'time unit' and 'nominal time unit' are misleading because in the Dec. 2011 DTV FTF 1 beta document, these terms are not defined as kinds of ISO 80000 measurement units. From the DTV FTF perspective, the objection against defining 'time unit' and 'nominal time unit' as ISO 80000 measurement units is that 'month', a kind of 'nominal time unit', varies between 28 and 31 days and therefore does not exactly fit the definition of measurement unit per ISO 80000. In pure ISO 80000 terms, this would suggest that 'month' would be a measurement unit with a variable conversion factor from 'day', which is defined as a normative measurement unit in ISO 80000-3, item 3-7.d. I believe that the DTV interpretation of ISO 80000 measurement unit is too restrictive and should be changed such that a DTV 'time unit' is in fact a kind of ISO 80000 'measurement unit'. There is compelling evidence to support this change in ISO 80000 itself: 1) The definition of year as a non-SI measurement unit in ISO 80000-3, Annex C, item 3-7 shows an example where the conversion factor is variable: a := 365d or 366d One tropical year is the duration between two successive passages of the Sun through the mean vernal equinox. This duration is related to the corresponding difference in mean longitude of the Sun, which depends on time in a not exactly linear form; i.e. the tropical year is not constant but decreases at a rate of nearly per century. The tropical year is approximately equal to 365,242 20 d ¡Ö31 556 926 s. 2) The value of a quantity can be expressed in three ways according to ISO 80000-1, item 3.19: - a product of a number and a measurement unit - a number and a reference to a measurement procedure - a number and a reference material 3) 'month' could be defined as an ISO 80000 'conventional reference scale', that is, a quantity-value scale defined by formal agreement. This could facilitate defining that 'month' is a 'conventional reference scale' varying between 28 and 31 'days'. Specializations of 'month' could be made for 28-days months, 29-days months, 30 days months, 31 days months where such specializations can be defined as ISO 80000 derived units of 'days' with a precise conversion factor. 4) 'amount of substance', one of the 7 base quantities in the International System of Quantities, ISQ, is intrinsically context-dependent: See the remarks in ISO-80000-9, 9-1: Amount of substance of a pure sample is that quantity that can often be determined by measuring its mass and dividing by the molar mass of the sample. Amount of substance is defined to be proportional to the number of specified elementary entities in a sample, the proportionality constant being a universal constant which is the same for all samples. The name ¡°number of moles¡± is often used for ¡°amount of substance¡±, but this is deprecated because the name of a quantity should be distinguished from the name of the unit. In the name ¡°amount of substance¡±, the words ¡°of substance¡± could, for simplicity, be replaced by words to specify the substance concerned in any particular application, so that one may, for example, talk of ¡°amount of hydrogen chloride, HCl¡±, or ¡°amount of benzene, C6H6¡±. It is important to always give a precise specification of the entity involved (as emphasized in the second sentence of the definition of the mole); this should preferably be done by giving the molecular chemical formula of the material involved. Just like 'amount of hydrogen chloride' is a specialization of 'amount of substance', 'January' is a specialization of 'month. All are measurement units in the sense of ISO 80000. The DTV specification should clearly indicate the correspondence between the DTV vocabulary and the corresponding ISO 80000 vocabulary. These correspondences are important to clarify the relationship between the use of ISO 80000 vocabulary in DTV and SysML's QUDV. - Nicolas. To: date-time-ftf@omg.org Subject: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary X-KeepSent: BD67591F:D936AE26-852579D4:007FF0E0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 2 Apr 2012 19:18:13 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/02/2012 19:18:15 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040223-1976-0000-0000-00000C01971A Here is a proposed resolution: -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research Date-Time Issue 16921 - ISO 8000 & Date-Time Foundation Vocabulary.doc Disposition: Resolved OMG Issue No: 16921 Title: ISO 80000 & Date/Time Foundation Vocabulary Source: Nicolas F Rouquette, nicolas.f.rouquette@jpl.nasa.gov, NASA JPL Summary: The Date-Time Vocabulary (DTV) document FTF beta 1 draft Mike sent on Dec. 8, 2011 shows a concept of 'time unit' specialized as: - 'precise time unit', a specialization of 'measurement unit' - 'nominal time unit' It is understood that in DTV, a 'precise time unit' is a kind of ISO 80000 measurement unit (i.e., 3.8 in ISO-80000-1): real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the second quantity to the first one as a number The DTV names for 'time unit' and 'nominal time unit' are misleading because in the Dec. 2011 DTV FTF 1 beta document, these terms are not defined as kinds of ISO 80000 measurement units. From the DTV FTF perspective, the objection against defining 'time unit' and 'nominal time unit' as ISO 80000 measurement units is that 'month', a kind of 'nominal time unit', varies between 28 and 31 days and therefore does not exactly fit the definition of measurement unit per ISO 80000. In pure ISO 80000 terms, this would suggest that 'month' would be a measurement unit with a variable conversion factor from 'day', which is defined as a normative measurement unit in ISO 80000-3, item 3-7.d. I believe that the DTV interpretation of ISO 80000 measurement unit is too restrictive and should be changed such that a DTV 'time unit' is in fact a kind of ISO 80000 'measurement unit'. There is compelling evidence to support this change in ISO 80000 itself: 1) The definition of year as a non-SI measurement unit in ISO 80000-3, Annex C, item 3-7 shows an example where the conversion factor is variable: a := 365d or 366d One tropical year is the duration between two successive passages of the Sun through the mean vernal equinox. Resolution: The FTF consulted with NIST authors of VIM and ISO 80000-3, who confirmed that 'month' and 'year' are not defined by SI and do not fit the VIM definition of 'measurement unit'. Therefore, the proposal made above is not adopted. Instead, a Rationale section is added to discuss the issue. Revised Text: Add a new clause 7.14 at the end of clause 7: 7.14 Precise and Nominal Time Units This specification distinguishes precise time units from nominal time units, as defined in clause 9.1.1. Precise time units are measurement units (annex D.3.2) in the sense of VIM: quantities of quantity kind 'duration' that are defined by convention. All precise time units are defined (clause 9.1.2) in terms of the SI 'second': picosecond, nanosecond, millisecond, microsecond, minute, hour, day, week. 'Day' and 'week' are precise because this document does not address leap seconds. Two other time units . 'month' and 'year' . are called 'nominal time units' because their duration varies, depending upon whether a given calendar year includes a leap day. These time units are mentioned but not formally defined in [SI]. This specification formally defines these nominal time units (clause 9.1.2) in terms of duration values, which are sets of durations. For example, 'year' is defined as the set {365 days, 366 days}. Clauses 11.5 and 11.6 develop algorithms that specify the meaning of multiples of these time units. For example, 2 years is {730 days, 731 days}, not {730 days, 732 days} because 2 calendar years contains just one leap day. This method enables well-defined results for comparisons such as "2 years . 730 days" and arithmetic expressions such as "4 years . 3 months", which is {1369 days, 1370 days, 1371 days, 1372 days}. This permits logical reasoning systems to infer results that otherwise would be unreachable. Disposition: Resolved To: date-time-ftf@omg.org Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary X-KeepSent: 21553150:4682FA7A-852579D5:000921C4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 2 Apr 2012 21:43:58 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/02/2012 21:43:59, Serialize complete at 04/02/2012 21:43:59 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040301-7408-0000-0000-000003EBAF81 Nicolas, I'm happy with your proposed textual change and have updated my copy. I'm not quite sure what you mean by: "It would be great if the NIST metrology experts could tell us whether it is possible to explain DTV's nominal time unit => precise time unit conversion algorithms in terms of ISO 80000 concepts. This is not obvious to me and I believe this is a gap in terms of allowing us at the OMG to use DTV in conjunction with the SysML QUDV. Both have clear relationships to ISO 80000 but DTV seems to go beyond what we can do with ISO 80000 alone." As confirmed by the NIST experts, nominal time units are out of scope for ISO 80000. So I don't know what it would mean to "explain DTV's ... time unit conversion algorithms in terms of ISO 80000 concepts." Could you explain what you are thinking of? And how would this be a " gap in terms of allowing us at the OMG to use DTV in conjunction with the SysML QUDV"? My view is that DTV clearly goes beyond ISO 80000, but in a way that is compatible with the established standards. "Compatible with" means that DTV does not conflict with any aspect of those standards. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Rouquette, Nicolas F (313K)" To: Mark H Linehan/Watson/IBM@IBMUS Cc: "date-time-ftf@omg.org" Date: 04/02/2012 09:21 PM Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary -------------------------------------------------------------------------------- Mark, Thanks for writing a proposed resolution for this issue. I really like this resolution and in particular the strategy defined in DTV's clause 11.5 & 11.6 where conversion algorithms are used to formally specify the relationship between multiples of nominal units with value sets defined in terms of precise units. I believe this conversion algorithm approach is applicable to other units besides time. It would be great if the NIST metrology experts could tell us whether it is possible to explain DTV's nominal time unit => precise time unit conversion algorithms in terms of ISO 80000 concepts. This is not obvious to me and I believe this is a gap in terms of allowing us at the OMG to use DTV in conjunction with the SysML QUDV. Both have clear relationships to ISO 80000 but DTV seems to go beyond what we can do with ISO 80000 alone. This is probably a topic for a separate issue. As far as the resolution is concerned, I suggest replacing the sentence: Clauses 11.5 and 11.6 develop algorithms that specify the meaning of multiples of these time units. with: Clauses 11.5 and 11.6 develop algorithms that specify the meaning of multiples of these nominal time units. - Nicolas. On Apr 2, 2012, at 4:18 PM, Mark H Linehan wrote: Here is a proposed resolution: -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Rouquette, Nicolas F (313K)" To: Mark H Linehan CC: "date-time-ftf@omg.org" Date: Tue, 3 Apr 2012 13:52:33 -0700 Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary Thread-Topic: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary Thread-Index: Ac0R27EMfH90UCuxQs+3MOBOnjSJlw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Mark, See below. On Apr 2, 2012, at 6:43 PM, Mark H Linehan wrote: Nicolas, I'm happy with your proposed textual change and have updated my copy. I'm not quite sure what you mean by: "It would be great if the NIST metrology experts could tell us whether it is possible to explain DTV's nominal time unit => precise time unit conversion algorithms in terms of ISO 80000 concepts. This is not obvious to me and I believe this is a gap in terms of allowing us at the OMG to use DTV in conjunction with the SysML QUDV. Both have clear relationships to ISO 80000 but DTV seems to go beyond what we can do with ISO 80000 alone." As confirmed by the NIST experts, nominal time units are out of scope for ISO 80000. I'm not convinced of that. Read again Chuck's message, particularly the last sentence (see Ed's forwarded message on March 14) Ed, I.ll pick up on your last question about whether .month. and .year. are measurement units .in the VIM sense.. The VIM3 definition of .measurement unit. is .real scalar quantity, defined and adopted by convention, .. Therefore, in order to use .month. or .year. as a VIM3 measurement unit, it would have to be .defined and adopted. for your particular application. If the vagaries of the terms was not clarified, then I agree that it would not make a lot of sense to use them as measurement units (unless the resulting .definitional uncertainty. of a few days was acceptable for the given application). I hope this helps. Please let me know if you have any questions/comments. Chuck Chuck says that, for a particular application (e.g., using the DTV specification in some business context), then we can say that a DTV nominal time unit [X] is an ISO 80000 measurement unit if 2 conditions are met: a) clarifying the vagaries of the term [X] in this application domain b) bounding the resulting 'definitional uncertainty' inherent in [X] to an acceptable level for this application domain The DTV definition of 'month' and 'year' address (a). Based on my understanding of ISO 80000 & of metrology, I believe that the DTV conversion algorithms in clause 11.5 & 11.6 do an excellent job for addressing (b). As far as I can tell, I believe that Chuck would agree with me that DTV 'month' and DTV 'year' could be sensibly used as ISO 80000 measurement units in the context of a DTV application. This means that it should be sensible to define an ISO 80000 system of units for DTV in which we would have as ISO 80000 base measurement units all DTV precise time units and as ISO 80000 derived units all DTV nominal units. Such a DTV system of units wouldn't be coherent in the sense of an ISO 80000 coherent system of units but that's OK. So I don't know what it would mean to "explain DTV's ... time unit conversion algorithms in terms of ISO 80000 concepts." Could you explain what you are thinking of? And how would this be a " gap in terms of allowing us at the OMG to use DTV in conjunction with the SysML QUDV"? Let's say that Ed Barkmeyer asks Chuck if he agrees with my reasoning. Let's suppose that Chuck does agree. Now, I'm not sure how we can define what a DTV clauses 11.5 & 11.6 are in ISO 80000 terms. It's clear that a DTV nominal time unit would be an ISO 80000 derived time unit but it's not clear to me whether it's OK to say that the conversion algorithms in DTV 11.5 & 11.6 can be called ISO 80000 unit equations: mathematical relation between base units, coherent derived units or other measurement units If this makes sense, then we could consider using the scope of a DTV system of units to be restricted to ISO 80000 measurement units that are DTV precise time units and exclude the ISO 80000 measurement units that are DTV nominal time units. With such a DTV system of units, then all DTV nominal time units would be considered ISO 80000 off-system measurement units. My view is that DTV clearly goes beyond ISO 80000, but in a way that is compatible with the established standards. "Compatible with" means that DTV does not conflict with any aspect of those standards. It depends. If we can say that a DTV conversion algorithm from a DTV nominal time unit to DTV precise time units is in fact a legitimate way to specify an ISO 80000 unit equation involving ISO 80000 base & derived measurement units, then I think that we could say that DTV is within ISO 80000. Now, I really would like to ask Ed to ask the NIST metrology experts whether this makes sense or not. If it doesn't, then I would appreciate suggestions about how to rethink the relationship between DTV & ISO 80000. Just saying that DTV goes beyond ISO 80000 isn't enough for me; I want more rigor than that. - Nicolas. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Rouquette, Nicolas F (313K)" To: Mark H Linehan/Watson/IBM@IBMUS Cc: "date-time-ftf@omg.org" Date: 04/02/2012 09:21 PM Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary -------------------------------------------------------------------------------- Mark, Thanks for writing a proposed resolution for this issue. I really like this resolution and in particular the strategy defined in DTV's clause 11.5 & 11.6 where conversion algorithms are used to formally specify the relationship between multiples of nominal units with value sets defined in terms of precise units. I believe this conversion algorithm approach is applicable to other units besides time. It would be great if the NIST metrology experts could tell us whether it is possible to explain DTV's nominal time unit => precise time unit conversion algorithms in terms of ISO 80000 concepts. This is not obvious to me and I believe this is a gap in terms of allowing us at the OMG to use DTV in conjunction with the SysML QUDV. Both have clear relationships to ISO 80000 but DTV seems to go beyond what we can do with ISO 80000 alone. This is probably a topic for a separate issue. As far as the resolution is concerned, I suggest replacing the sentence: Clauses 11.5 and 11.6 develop algorithms that specify the meaning of multiples of these time units. with: Clauses 11.5 and 11.6 develop algorithms that specify the meaning of multiples of these nominal time units. - Nicolas. On Apr 2, 2012, at 4:18 PM, Mark H Linehan wrote: Here is a proposed resolution: -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research To: date-time-ftf@omg.org Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary X-KeepSent: D588CEF5:09B18DCF-852579D6:0045503E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Wed, 4 Apr 2012 08:48:20 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/04/2012 08:48:42, Serialize complete at 04/04/2012 08:48:42 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040412-5806-0000-0000-00001404AB2E My comments like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Rouquette, Nicolas F (313K)" To: Mark H Linehan/Watson/IBM@IBMUS Cc: "date-time-ftf@omg.org" Date: 04/03/2012 04:53 PM Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary -------------------------------------------------------------------------------- Mark, See below. On Apr 2, 2012, at 6:43 PM, Mark H Linehan wrote: Nicolas, I'm happy with your proposed textual change and have updated my copy. I'm not quite sure what you mean by: "It would be great if the NIST metrology experts could tell us whether it is possible to explain DTV's nominal time unit => precise time unit conversion algorithms in terms of ISO 80000 concepts. This is not obvious to me and I believe this is a gap in terms of allowing us at the OMG to use DTV in conjunction with the SysML QUDV. Both have clear relationships to ISO 80000 but DTV seems to go beyond what we can do with ISO 80000 alone." As confirmed by the NIST experts, nominal time units are out of scope for ISO 80000. I'm not convinced of that. Read again Chuck's message, particularly the last sentence (see Ed's forwarded message on March 14) Ed, Iâll pick up on your last question about whether âmonthâ and âyearâ are measurement units âin the VIM sense.â The VIM3 definition of âmeasurement unitâ is âreal scalar quantity, defined and adopted by convention, .â Thereforre, in order to use âmonthâ or âyearâ as a VIM3 measurement unit, it would have to be âdefined and adoptedâ for your particular application. If the vagaries of the terms was not clarified, then I agree that it would not make a lot of sense to use them as measurement units (unless the resulting âdefinitional uncertaintyâ of a few days was acceptable for the given application). I hope this helps. Please let me know if you have any questions/comments. Chuck Chuck says that, for a particular application (e.g., using the DTV specification in some business context), then we can say that a DTV nominal time unit [X] is an ISO 80000 measurement unit if 2 conditions are met: a) clarifying the vagaries of the term [X] in this application domain b) bounding the resulting 'definitional uncertainty' inherent in [X] to an acceptable level for this application domain I think you mean that DTV nominal time units meet the definition that Chuck stated; not that nominal time units are defined in ISO 80000-3. The DTV definition of 'month' and 'year' address (a). Based on my understanding of ISO 80000 & of metrology, I believe that the DTV conversion algorithms in clause 11.5 & 11.6 do an excellent job for addressing (b). As far as I can tell, I believe that Chuck would agree with me that DTV 'month' and DTV 'year' could be sensibly used as ISO 80000 measurement units in the context of a DTV application. This means that it should be sensible to define an ISO 80000 system of units for DTV in which we would have as ISO 80000 base measurement units all DTV precise time units and as ISO 80000 derived units all DTV nominal units. No. "Second" is the base measurement unit for quantity kind "time". Derived units include picosecond, hour, etc. These are all multiples or fractions of "second"; they are "coherent". Such a DTV system of units wouldn't be coherent in the sense of an ISO 80000 coherent system of units but that's OK. I'm not sure whether that's ok or not for ISO 80000. So I don't know what it would mean to "explain DTV's ... time unit conversion algorithms in terms of ISO 80000 concepts." Could you explain what you are thinking of? And how would this be a " gap in terms of allowing us at the OMG to use DTV in conjunction with the SysML QUDV"? Let's say that Ed Barkmeyer asks Chuck if he agrees with my reasoning. Let's suppose that Chuck does agree. Now, I'm not sure how we can define what a DTV clauses 11.5 & 11.6 are in ISO 80000 terms. It's clear that a DTV nominal time unit would be an ISO 80000 derived time unit but it's not clear to me whether it's OK to say that the conversion algorithms in DTV 11.5 & 11.6 can be called ISO 80000 unit equations: mathematical relation between base units, coherent derived units or other measurement units If this makes sense, then we could consider using the scope of a DTV system of units to be restricted to ISO 80000 measurement units that are DTV precise time units and exclude the ISO 80000 measurement units that are DTV nominal time units. With such a DTV system of units, then all DTV nominal time units would be considered ISO 80000 off-system measurement units. My view is that DTV clearly goes beyond ISO 80000, but in a way that is compatible with the established standards. "Compatible with" means that DTV does not conflict with any aspect of those standards. It depends. If we can say that a DTV conversion algorithm from a DTV nominal time unit to DTV precise time units is in fact a legitimate way to specify an ISO 80000 unit equation involving ISO 80000 base & derived measurement units, then I think that we could say that DTV is within ISO 80000. I don't know why this matters to you. There are no conflicts between DTV and ISO 80000. ISO 80000 does not object to people defining other units of measurement, and in fact recognizes that there are such units, such as the old English inch-foot-mile system. Such units are simply out-of-scope for ISO 80000 but they not "illegal" in any sense. Now, I really would like to ask Ed to ask the NIST metrology experts whether this makes sense or not. If it doesn't, then I would appreciate suggestions about how to rethink the relationship between DTV & ISO 80000. Just saying that DTV goes beyond ISO 80000 isn't enough for me; I want more rigor than that. I don't understand what your motivation is here. The DTV treatment of 'month' and 'year' is mathematically rigorous. The relationship of these with ISO 80000 is very clear: they are out of scope for that standard -- which means that ISO 80000 has no objection to someone else defining them. What's the problem with that? If what you want is to add the DTV definition of nominal time units to ISO 80000 -- good luck! I'd rather spent my time getting DTV finalized at OMG and then perhaps "graduating" to an ISO standard itself. - Nicolas. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Rouquette, Nicolas F (313K)" To: Mark H Linehan/Watson/IBM@IBMUS Cc: "date-time-ftf@omg.org" Date: 04/02/2012 09:21 PM Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary -------------------------------------------------------------------------------- Mark, Thanks for writing a proposed resolution for this issue. I really like this resolution and in particular the strategy defined in DTV's clause 11.5 & 11.6 where conversion algorithms are used to formally specify the relationship between multiples of nominal units with value sets defined in terms of precise units. I believe this conversion algorithm approach is applicable to other units besides time. It would be great if the NIST metrology experts could tell us whether it is possible to explain DTV's nominal time unit => precise time unit conversion algorithms in terms of ISO 80000 concepts. This is not obvious to me and I believe this is a gap in terms of allowing us at the OMG to use DTV in conjunction with the SysML QUDV. Both have clear relationships to ISO 80000 but DTV seems to go beyond what we can do with ISO 80000 alone. This is probably a topic for a separate issue. As far as the resolution is concerned, I suggest replacing the sentence: Clauses 11.5 and 11.6 develop algorithms that specify the meaning of multiples of these time units. with: Clauses 11.5 and 11.6 develop algorithms that specify the meaning of multiples of these nominal time units. - Nicolas. On Apr 2, 2012, at 4:18 PM, Mark H Linehan wrote: Here is a proposed resolution: -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research Date: Wed, 04 Apr 2012 16:35:35 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Rouquette, Nicolas F (313K)" CC: "date-time-ftf@omg.org" Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q34KZeJu006286 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1334176546.56428@l/svImQjkx9W4pr2obcsgA X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark wrote: As confirmed by the NIST experts, nominal time units are out of scope for ISO 80000. Nicolas wrote: I'm not convinced of that. Read again Chuck's message, particularly the last sentence (see Ed's forwarded message on March 14) ... Chuck says that, for a particular application (e.g., using the DTV specification in some business context), then we can say that a DTV nominal time unit [X] is an ISO 80000 measurement unit if 2 conditions are met: a) clarifying the vagaries of the term [X] in this application domain b) bounding the resulting 'definitional uncertainty' inherent in [X] to an acceptable level for this application domain The DTV definition of 'month' and 'year' address (a). Based on my understanding of ISO 80000 & of metrology, I believe that the DTV conversion algorithms in clause 11.5 & 11.6 do an excellent job for addressing (b). Based on the BIPM Guide to Uncertainty in Measurement (GUM) definition of 'definitional uncertainty', they do, in the sense that they specify a range in which the actual value corresponding to any stated value must fall. So, if you are content with the idea that a 'month' is a length of time that is somewhere between 28 and 31 days, i.e., 29.5 days plus or minus 1.5 days, then you can use month as a measurement unit. Now, the definition of 'quantity values' says that the quantity of time expressed by '6 months' is a quantity of time whose ratio to 'month' is 6. Assuming that your '6 months' is a specification with a tolerance of 1 day, the quantity of time in question must be 177 days plus or minus 10 days. Is that what you want? DTV specifies a way to compute the definitional uncertainty for each duration value that is much better than that, but only for integer multiples of months. Is 6.5 months a valid duration value? How does one use the DTV tables to calculate the definitional uncertainty in 6.5 months? We would have to specify that. But I agree that this could be done, if it is important to define 'month' in such a way as to make it an ISO 80000 'measurement unit'. As far as I can tell, I believe that Chuck would agree with me that DTV 'month' and DTV 'year' could be sensibly used as ISO 80000 measurement units in the context of a DTV application. That is a different matter. We agree that there is a model of 'month' that is a 'measurement unit'. The next question is: can that model be "sensibly" used in some applications? The application must find this definition useful. I can think of applications in which it might be, e.g., for estimated time to complete a survey task, or an engineering task. On the other hand, such applications would probably just define a 'month' to be 30 days. If, however, the application wants 6 months to mean 'the duration of the time interval that is from the date of some event to the same day-of-month in the 6th succeeding month, then the "definition with uncertainty" model is not at all what they mean, and it is not "sensible". 6 months from 15 April is 15 October, not some date between 13 October and 17 October. DTV defined 'month' to be this latter idea, so that it can be the 'granularity' of a time scale of calendar months. There is no definitional uncertainty in the duration of any calendar month, or any sequence of calendar months; the duration is defined in exact multiples of ISO 'day' by the time scale. To express durations of intervals defined on a time scale of calendar months in terms of smaller time units, DTV associates each multiple of 'month' with a duration value set that behaves like a measurement with uncertainty. But that is not the definition of 'month'. We don't define 'month' to be that duration value set. That is the problem. It is not clear that defining 'month' to be the duration value set is appropriate to anyone's use of 'month', and doing so screws up the model of the time scales for years. We are back to the original question. As DTV defines 'month', it is not an ISO 80000 measurement unit. DTV could define 'month' in such a way as to make it an ISO 80000 measurement unit, yes. But that will create problems in defining calendars, and it is not clear what applications, if any, would want that definition. DTV preferred to make a consistent model for calendars, and that "date to date" model is known to meet certain common business needs. Is there some application in the SysML community that needs a definition of 'month' that is a quantity with uncertainty on the order of 'days'? Is there some application in any community that wants such a definition, rather than simply creating their own 'month' concept(s)? -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: "Rouquette, Nicolas F (313K)" To: "edbark@nist.gov" CC: "date-time-ftf@omg.org" Date: Wed, 4 Apr 2012 15:59:04 -0700 Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary Thread-Topic: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary Thread-Index: Ac0StuhyD3z0UNzqRHqDsaaxUjKQEg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized On Apr 4, 2012, at 1:35 PM, Ed Barkmeyer wrote: Mark wrote: As confirmed by the NIST experts, nominal time units are out of scope for ISO 80000. Nicolas wrote: I'm not convinced of that. Read again Chuck's message, particularly the last sentence (see Ed's forwarded message on March 14) ... Chuck says that, for a particular application (e.g., using the DTV specification in some business context), then we can say that a DTV nominal time unit [X] is an ISO 80000 measurement unit if 2 conditions are met: a) clarifying the vagaries of the term [X] in this application domain b) bounding the resulting 'definitional uncertainty' inherent in [X] to an acceptable level for this application domain The DTV definition of 'month' and 'year' address (a). Based on my understanding of ISO 80000 & of metrology, I believe that the DTV conversion algorithms in clause 11.5 & 11.6 do an excellent job for addressing (b). Based on the BIPM Guide to Uncertainty in Measurement (GUM) definition of 'definitional uncertainty', they do, in the sense that they specify a range in which the actual value corresponding to any stated value must fall. So, if you are content with the idea that a 'month' is a length of time that is somewhere between 28 and 31 days, i.e., 29.5 days plus or minus 1.5 days, then you can use month as a measurement unit. Consider an application domain where using the combination of DTV and SysML is a reasonable proposition because these two specifications address recognized needs of this application domain. Now, for this application domain, I'm proposing to the DTV FTF that if the following is true: - DTV 'month' is a useful criteria for measuring time - DTV 11.6 (month values) provides an acceptable bound on the 'definitional uncertainty' inherent in DTV 'month' then can we also say that it is a legitimate application of the DTV spec to do the following: - define an ISO 80000 'system of units' where DTV 'month' is an ISO 80000 'measurement unit' with an ISO 80000 'unit equation' specified per DTV 11.6 in terms of DTV 'day', itself another ISO 80000 'measurement unit' - whether DTV 'second', DTV 'minute', DTV 'hour', DTV 'day', DTV 'month' are included or not and whether any of them are ISO 80000 'base measurement unit' or ISO 80000 'derived measurement unit' is purely a function of the definition of ISO 80000 'system of unit' Now, the definition of 'quantity values' says that the quantity of time expressed by '6 months' is a quantity of time whose ratio to 'month' is 6. Assuming that your '6 months' is a specification with a tolerance of 1 day, the quantity of time in question must be 177 days plus or minus 10 days. Is that what you want? Almost; it makes better sense to use 11.6 as an ISO 80000 'unit equation' relating DTV 'month' to DTV 'day in which case 6 DTV 'month' = the value set {181, 182, 183, 184} DTV 'day' per DTV 11.6 DTV specifies a way to compute the definitional uncertainty for each duration value that is much better than that, but only for integer multiples of months. Is 6.5 months a valid duration value? How does one use the DTV tables to calculate the definitional uncertainty in 6.5 months? We would have to specify that. Agreed. But I agree that this could be done, if it is important to define 'month' in such a way as to make it an ISO 80000 'measurement unit'. I don't believe this is necessary. I'm saying that DTV 'month' + DTV 11.6 is already sufficient to use DTV 'month' as ISO 800000 'measurement unit' as long as DTV 'day' is also an ISO 80000 'measurement unit' in the application domain. As far as I can tell, I believe that Chuck would agree with me that DTV 'month' and DTV 'year' could be sensibly used as ISO 80000 measurement units in the context of a DTV application. That is a different matter. We agree that there is a model of 'month' that is a 'measurement unit'. ok The next question is: can that model be "sensibly" used in some applications? DTV specifies a model of DTV 'month' in terms of DTV 'day' via 11.6 Whether this model is useful or not for some application is outside the scope of the DTV spec, it's for someone to decide. The application must find this definition useful. I can think of applications in which it might be, e.g., for estimated time to complete a survey task, or an engineering task. On the other hand, such applications would probably just define a 'month' to be 30 days. If, however, the application wants 6 months to mean 'the duration of the time interval that is from the date of some event to the same day-of-month in the 6th succeeding month, then the "definition with uncertainty" model is not at all what they mean, and it is not "sensible". 6 months from 15 April is 15 October, not some date between 13 October and 17 October. I agree that DTV 'month' wouldn't be a sensible choice here for an ISO 80000 'measurement unit'; however, that does not make DTV 'month' categorically unsuitable as an ISO 80000 'measurement unit' for all domains. There are some application domains where DTV 'month' is well-suited as an ISO 80000 'measurement unit'. The concept of ISO 80000 'system of units' is a great way to specify whether DTV 'month', as an ISO 80000 'measurement unit' is included or not. THis decision is extrinsic to the inherent nature of DTV 'month' as a well-defined ISO 80000 'measurement unit' based on DTV 11.6. DTV defined 'month' to be this latter idea, so that it can be the 'granularity' of a time scale of calendar months. Again, you further convince me that DTV 'month' is a darn good definition of an ISO 80000 'measurement unit'. There is no definitional uncertainty in the duration of any calendar month, or any sequence of calendar months; the duration is defined in exact multiples of ISO 'day' by the time scale. To express durations of intervals defined on a time scale of calendar months in terms of smaller time units, DTV associates each multiple of 'month' with a duration value set that behaves like a measurement with uncertainty. But that is not the definition of 'month'. We don't define 'month' to be that duration value set. I understand the distinction; I hope that what you said is consistent with my assertion that 11.6 is an ISO 80000 'unit equation' to convert multiples of DTV 'month' into multiples of DTV 'day'. It just happens that this conversion provides multiple answers as a way of specifying the measurement uncertainty involved in that conversion. That is the problem. It is not clear that defining 'month' to be the duration value set is appropriate to anyone's use of 'month', and doing so screws up the model of the time scales for years. We are back to the original question. As DTV defines 'month', it is not an ISO 80000 measurement unit. It is! DTV could define 'month' in such a way as to make it an ISO 80000 measurement unit, yes. But that will create problems in defining calendars, and it is not clear what applications, if any, would want that definition. It simply means that we may need to have DTV 'month' (per 9.1.2) as well as DTV 'calendar month' as you described above. However, it's clear that DTV 'month' has a very good measurement model (11.6) that makes it a very good ISO 80000 'measurement unit'. It's not clear to me whether we could make a good measurement model in the sense of ISO 80000 to define DTV 'calendar month' as a well-defined ISO 80000 'measurement unit'. DTV preferred to make a consistent model for calendars, and that "date to date" model is known to meet certain common business needs. Ok. Is there some application in the SysML community that needs a definition of 'month' that is a quantity with uncertainty on the order of 'days'? I like DTV 'month' as defined. Is there some application in any community that wants such a definition, rather than simply creating their own 'month' concept(s)? DTV 'month' is definitely relevant for the kind of longitudinal simulation models we're building for a DARPA F6 project at JPL. In this project, we are simulating lifecycles of building, deploying, operating multiple generations of spacecraft & services. I believe that for several aspects of this problem, DTV 'month' is definitely an appropriate choice of ISO 80000 'measurement unit' and that for other aspects, we might need different definitions of 'month', perhaps the 'day-of-month' notion you mentioned above. Whether such notions would be legitimate ISO 80000 'measurement units' is a different matter. - Nicolas. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Wed, 04 Apr 2012 20:02:47 -0400 From: Edward Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Rouquette, Nicolas F (313K)" CC: "date-time-ftf@omg.org" Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov Rouquette, Nicolas F (313K) wrote: Consider an application domain where using the combination of DTV and SysML is a reasonable proposition because these two specifications address recognized needs of this application domain. Now, for this application domain, I'm proposing to the DTV FTF that if the following is true: - DTV 'month' is a useful criteria for measuring time - DTV 11.6 (month values) provides an acceptable bound on the 'definitional uncertainty' inherent in DTV 'month' then can we also say that it is a legitimate application of the DTV spec to do the following: - define an ISO 80000 'system of units' where DTV 'month' is an ISO 80000 'measurement unit' with an ISO 80000 'unit equation' specified per DTV 11.6 in terms of DTV 'day', itself another ISO 80000 'measurement unit' - whether DTV 'second', DTV 'minute', DTV 'hour', DTV 'day', DTV 'month' are included or not and whether any of them are ISO 80000 'base measurement unit' or ISO 80000 'derived measurement unit' is purely a function of the definition of ISO 80000 'system of unit' What is that application? I can envisage a SysML application in which monkeys are trained to ride zebras while aiming SAMs at incoming asteroids, but I don't have any intention of making standards to support it. And my guess is that most SysML users would prefer an analytical model of time, with time points being real numbers, not calendar months. I'm saying that DTV 'month' + DTV 11.6 is already sufficient to use DTV 'month' as ISO 800000 'measurement unit' as long as DTV 'day' is also an ISO 80000 'measurement unit' in the application domain. And I repeat: 'month' is an ISO 80000 measurement unit only if it is defined to be a quantity of time between the bounds specified in 11.6, rather than the amount of time between two occurrences of the same 'day-of-month'. That is, we would have to change the definition of 'month'. And if we do that, the duration of January is not 1 'month'; it is exactly 31 days. That is the problem. I think it vastly preferable that the JPL SysML application that needs 'month' to be an ISO 80000 measurement unit should define 'month' or 'JPLmonth' in such a way as to be an ISO 80000 measurement unit for the ontology for that application. DTV specifies a model of DTV 'month' in terms of DTV 'day' via 11.6 Yes, but that model is not the definition. It is for conversion purposes. Whether this model is useful or not for some application is outside the scope of the DTV spec, it's for someone to decide. Well, we know the current definition is useful for business applications, and if we didn't know that, we would have tried to find out what definition would be likely to be useful to business applications. We have yet to hear what application requires a definition of month that is an ISO 80000 'measurement unit'. And it is not OMG practice to make standards for no known use, or NIST practice to work on them. There are some application domains where DTV 'month' is well-suited as an ISO 80000 'measurement unit'. Name one. We are back to the original question. As DTV defines 'month', it is not an ISO 80000 measurement unit. It is! No, it isn't. You mistake a conversion table for a definition. DTV could define 'month' in such a way as to make it an ISO 80000 measurement unit, yes. But that will create problems in defining calendars, and it is not clear what applications, if any, would want that definition. It simply means that we may need to have DTV 'month' (per 9.1.2) as well as DTV 'calendar month' as you described above. Calendar month is a time point. What you mean is that we need a concept called F6month that has the ISO 80000 conformant definition using 11.6, for the unknown application that might use it. Is there some application in any community that wants such a definition, rather than simply creating their own 'month' concept(s)? DTV 'month' is definitely relevant for the kind of longitudinal simulation models we're building for a DARPA F6 project at JPL. You don't mean DTV 'month'. You mean 'F6month' defined to be a variable number of days bounded by the table in 11.6. At least we have finally identified a potential application. If what you want is a precise measurement unit called 'xxxmonth' that has the ISO 80000-compatible definition, we could probably add that. Pick a term. -Ed In this project, we are simulating lifecycles of building, deploying, operating multiple generations of spacecraft & services. I believe that for several aspects of this problem, DTV 'month' is definitely an appropriate choice of ISO 80000 'measurement unit' and that for other aspects, we might need different definitions of 'month', perhaps the 'day-of-month' notion you mentioned above. Whether such notions would be legitimate ISO 80000 'measurement units' is a different matter. - Nicolas. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." To: date-time-ftf@omg.org Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary X-KeepSent: F560C3FF:FB1A0292-852579D7:0045B20C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Thu, 5 Apr 2012 08:43:56 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/05/2012 08:44:20, Serialize complete at 04/05/2012 08:44:20 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040512-7408-0000-0000-000003FD5EDD Ed, We have two definitions of 'month' in DTV clause 9.1.2. One is indeed specified in terms of 'duration value set'. I think you and Nicolas are talking past each other because Nicolas recognizes this and you are thinking of some other definition. month Definition: the nominal time unit that is the duration of some calendar month Definition: the nominal time unit that is quantified by {28 days, 29 days, 30 days, 31 days} Note: A lunar month is about 28 days, and is incommensurable with a year. Different calendars define the number of days in a month differently. And the same calendar may define different calendar months to have different numbers of days. The Gregorian calendar has 12 calendar months that were rather arbitrarily set to a certain number of days by Roman politicians, without synchronizing with the lunar cycle. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Edward Barkmeyer To: "Rouquette, Nicolas F (313K)" Cc: "date-time-ftf@omg.org" Date: 04/04/2012 08:04 PM Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary -------------------------------------------------------------------------------- Rouquette, Nicolas F (313K) wrote: Consider an application domain where using the combination of DTV and SysML is a reasonable proposition because these two specifications address recognized needs of this application domain. Now, for this application domain, I'm proposing to the DTV FTF that if the following is true: - DTV 'month' is a useful criteria for measuring time - DTV 11.6 (month values) provides an acceptable bound on the 'definitional uncertainty' inherent in DTV 'month' then can we also say that it is a legitimate application of the DTV spec to do the following: - define an ISO 80000 'system of units' where DTV 'month' is an ISO 80000 'measurement unit' with an ISO 80000 'unit equation' specified per DTV 11.6 in terms of DTV 'day', itself another ISO 80000 'measurement unit' - whether DTV 'second', DTV 'minute', DTV 'hour', DTV 'day', DTV 'month' are included or not and whether any of them are ISO 80000 'base measurement unit' or ISO 80000 'derived measurement unit' is purely a function of the definition of ISO 80000 'system of unit' What is that application? I can envisage a SysML application in which monkeys are trained to ride zebras while aiming SAMs at incoming asteroids, but I don't have any intention of making standards to support it. And my guess is that most SysML users would prefer an analytical model of time, with time points being real numbers, not calendar months. I'm saying that DTV 'month' + DTV 11.6 is already sufficient to use DTV 'month' as ISO 800000 'measurement unit' as long as DTV 'day' is also an ISO 80000 'measurement unit' in the application domain. And I repeat: 'month' is an ISO 80000 measurement unit only if it is defined to be a quantity of time between the bounds specified in 11.6, rather than the amount of time between two occurrences of the same 'day-of-month'. That is, we would have to change the definition of 'month'. And if we do that, the duration of January is not 1 'month'; it is exactly 31 days. That is the problem. I think it vastly preferable that the JPL SysML application that needs 'month' to be an ISO 80000 measurement unit should define 'month' or 'JPLmonth' in such a way as to be an ISO 80000 measurement unit for the ontology for that application. DTV specifies a model of DTV 'month' in terms of DTV 'day' via 11.6 Yes, but that model is not the definition. It is for conversion purposes. Whether this model is useful or not for some application is outside the scope of the DTV spec, it's for someone to decide. Well, we know the current definition is useful for business applications, and if we didn't know that, we would have tried to find out what definition would be likely to be useful to business applications. We have yet to hear what application requires a definition of month that is an ISO 80000 'measurement unit'. And it is not OMG practice to make standards for no known use, or NIST practice to work on them. There are some application domains where DTV 'month' is well-suited as an ISO 80000 'measurement unit'. Name one. We are back to the original question. As DTV defines 'month', it is not an ISO 80000 measurement unit. It is! No, it isn't. You mistake a conversion table for a definition. DTV could define 'month' in such a way as to make it an ISO 80000 measurement unit, yes. But that will create problems in defining calendars, and it is not clear what applications, if any, would want that definition. It simply means that we may need to have DTV 'month' (per 9.1.2) as well as DTV 'calendar month' as you described above. Calendar month is a time point. What you mean is that we need a concept called F6month that has the ISO 80000 conformant definition using 11.6, for the unknown application that might use it. Is there some application in any community that wants such a definition, rather than simply creating their own 'month' concept(s)? DTV 'month' is definitely relevant for the kind of longitudinal simulation models we're building for a DARPA F6 project at JPL. You don't mean DTV 'month'. You mean 'F6month' defined to be a variable number of days bounded by the table in 11.6. At least we have finally identified a potential application. If what you want is a precise measurement unit called 'xxxmonth' that has the ISO 80000-compatible definition, we could probably add that. Pick a term. -Ed In this project, we are simulating lifecycles of building, deploying, operating multiple generations of spacecraft & services. I believe that for several aspects of this problem, DTV 'month' is definitely an appropriate choice of ISO 80000 'measurement unit' and that for other aspects, we might need different definitions of 'month', perhaps the 'day-of-month' notion you mentioned above. Whether such notions would be legitimate ISO 80000 'measurement units' is a different matter. - Nicolas. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Fri, 06 Apr 2012 12:13:15 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "date-time-ftf@omg.org" Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q36GDKQG007298 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1334333601.46199@eKJvnsoQPKlOilGLZZOrhw X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark H Linehan wrote: Ed, We have two definitions of 'month' in DTV clause 9.1.2. One is indeed specified in terms of 'duration value set'. I think you and Nicolas are talking past each other because Nicolas recognizes this and you are thinking of some other definition. *month * Definition: the nominal time unit that /is /the duration /of /some calendar month Definition: the nominal time unit that /is quantified by /{*28 days*, *29 days*, *30 days*, *31 days*} Note: A lunar *month *is about *28 days*, and is incommensurable with a *year*. Different calendars define the number of days in a *month *differently. And the same calendar may define different calendar months to have different numbers of *days*. The *Gregorian calendar *has *12 *calendar months that were rather arbitrarily set to a certain number of days by Roman politicians, without synchronizing with the lunar cycle. Ah. I should have looked. Most of what I said was wrong. DTV does NOT define 'month' to be the duration between two consecutive instances of a 'day of month'. 6 DTV 'months' from April 15 is one of {October 13, October 14, October 15, October 16}. (I believe that definition is not "business-friendly", but I could be wrong again. I would expect "6 months from April 15" to be October 15, not 'any of the above'. DTV does not have a term that could be substituted for 'month' in that expression.) So DTV clearly defines 'month' to be one of four values. Nicolas is right that that could be construed as 'a quantity of time within 1.5 days of 29.5 days', which is a precise unit with a definitional uncertainty. We would have to define multiples to use the table, that is, make the table part of the definition, and explain how to use it for fractional multiples of 'month'. Now that I think of it however, the integral values are then incorrect. If 'month' is a unit with a crude definitional error bound, then 30.4 days is also a valid value for 'month'. And 'month' is really: any scalar multiple of 'day' that is in the real interval [29..31]. It is not limited to one of four values. The table really defines only the lower and upper bounds on the scalar interval. That definition is really different from what we have. I'm no longer sure where we go from here. (The 'definitional uncertainty' relates to the problem of measuring the particular quantity of the particular phenomenon that defines the unit. The frequency of some wave form of the Cesium atom can only be measured up to a certain accuracy. The measurement uncertainty for a 'second' with current technology is plus or minus 6 x 10^-16 seconds [see SI Appendix 2 "practical realization of time", via http://www.bipm.org/en/si/base_units/]. So a 'day' is actually 86400 seconds plus or minus 50 picoseconds. The original atomic clocks were not nearly that good. Now we are asking how long that accuracy will be good enough.) -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Edward Barkmeyer To: "Rouquette, Nicolas F (313K)" Cc: "date-time-ftf@omg.org" Date: 04/04/2012 08:04 PM Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary ------------------------------------------------------------------------ Rouquette, Nicolas F (313K) wrote: Consider an application domain where using the combination of DTV and SysML is a reasonable proposition because these two specifications address recognized needs of this application domain. Now, for this application domain, I'm proposing to the DTV FTF that if the following is true: - DTV 'month' is a useful criteria for measuring time - DTV 11.6 (month values) provides an acceptable bound on the 'definitional uncertainty' inherent in DTV 'month' then can we also say that it is a legitimate application of the DTV spec to do the following: - define an ISO 80000 'system of units' where DTV 'month' is an ISO 80000 'measurement unit' with an ISO 80000 'unit equation' specified per DTV 11.6 in terms of DTV 'day', itself another ISO 80000 'measurement unit' - whether DTV 'second', DTV 'minute', DTV 'hour', DTV 'day', DTV 'month' are included or not and whether any of them are ISO 80000 'base measurement unit' or ISO 80000 'derived measurement unit' is purely a function of the definition of ISO 80000 'system of unit' What is that application? I can envisage a SysML application in which monkeys are trained to ride zebras while aiming SAMs at incoming asteroids, but I don't have any intention of making standards to support it. And my guess is that most SysML users would prefer an analytical model of time, with time points being real numbers, not calendar months. I'm saying that DTV 'month' + DTV 11.6 is already sufficient to use DTV 'month' as ISO 800000 'measurement unit' as long as DTV 'day' is also an ISO 80000 'measurement unit' in the application domain. And I repeat: 'month' is an ISO 80000 measurement unit only if it is _defined to be_ a quantity of time between the bounds specified in 11.6, rather than the amount of time between two occurrences of the same 'day-of-month'. That is, we would have to _change the definition_ of 'month'. And if we do that, the duration of January is not 1 'month'; it is exactly 31 days. That is the problem. I think it vastly preferable that the JPL SysML application that needs 'month' to be an ISO 80000 measurement unit should define 'month' or 'JPLmonth' in such a way as to be an ISO 80000 measurement unit for the ontology for that application. DTV specifies a model of DTV 'month' in terms of DTV 'day' via 11.6 Yes, but that model is not the definition. It is for conversion purposes. Whether this model is useful or not for some application is outside the scope of the DTV spec, it's for someone to decide. Well, we know the current definition is useful for business applications, and if we didn't know that, we would have tried to find out what definition would be likely to be useful to business applications. We have yet to hear what application requires a definition of month that is an ISO 80000 'measurement unit'. And it is not OMG practice to make standards for no known use, or NIST practice to work on them. There are some application domains where DTV 'month' is well-suited as an ISO 80000 'measurement unit'. Name one. We are back to the original question. As DTV defines 'month', it is /not/ an ISO 80000 measurement unit. It is! No, it isn't. You mistake a conversion table for a definition. DTV /could/ define 'month' in such a way as to make it an ISO 80000 measurement unit, yes. But that will create problems in defining calendars, and it is not clear what applications, if any, would want that definition. It simply means that we may need to have DTV 'month' (per 9.1.2) as well as DTV 'calendar month' as you described above. Calendar month is a time point. What you mean is that we need a concept called F6month that has the ISO 80000 conformant definition using 11.6, for the unknown application that might use it. Is there some application in any community that wants such a definition, rather than simply creating their own 'month' concept(s)? DTV 'month' is definitely relevant for the kind of longitudinal simulation models we're building for a DARPA F6 project at JPL. You don't mean DTV 'month'. You mean 'F6month' defined to be a variable number of days bounded by the table in 11.6. At least we have finally identified a potential application. If what you want is a precise measurement unit called 'xxxmonth' that has the ISO 80000-compatible definition, we could probably add that. Pick a term. -Ed In this project, we are simulating lifecycles of building, deploying, operating multiple generations of spacecraft & services. I believe that for several aspects of this problem, DTV 'month' is definitely an appropriate choice of ISO 80000 'measurement unit' and that for other aspects, we might need different definitions of 'month', perhaps the 'day-of-month' notion you mentioned above. Whether such notions would be legitimate ISO 80000 'measurement units' is a different matter. - Nicolas. -Ed -- Edward J. Barkmeyer Email: _edbark@nist.gov_ National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." -- Edward J. Barkmeyer Email: _edbark@nist.gov_ National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: "Rouquette, Nicolas F (313K)" To: "edbark@nist.gov" CC: Mark H Linehan , "date-time-ftf@omg.org" Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary Thread-Topic: Issue 16921- ISO 80000 & Date/Time Foundation Vocabulary Thread-Index: Ac0UEFTwJdz9QPR3RZOlQxJp9zdiEQCkmCeA Date: Mon, 9 Apr 2012 15:47:16 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q39FlZ4a013178 Ed, Can we say in the DTV spec that DTV 'month' is an ISO 80000 'derived unit' where DTV clause 11.6 specifies the ISO 80000 'unit equation' to convert integer-multiples of DTV 'month' in terms of integer-multiples of DTV 'day' ? - Nicolas. On Apr 6, 2012, at 9:13 AM, Ed Barkmeyer wrote: > > > Mark H Linehan wrote: >> Ed, >> >> We have two definitions of 'month' in DTV clause 9.1.2. One is indeed >> specified in terms of 'duration value set'. I think you and Nicolas >> are talking past each other because Nicolas recognizes this and you >> are thinking of some other definition. >> >> *month * >> Definition: the nominal time unit that /is /the duration /of /some >> calendar month >> Definition: the nominal time unit that /is quantified by /{*28 >> days*, *29 days*, *30 days*, *31 days*} >> Note: A lunar *month *is about *28 days*, and is incommensurable >> with a *year*. Different calendars define the number of days in a >> *month *differently. And the same calendar may define different >> calendar months to have different numbers of *days*. The *Gregorian >> calendar *has *12 *calendar months that were rather arbitrarily set to >> a certain number of days by Roman politicians, without synchronizing >> with the lunar cycle. > > Ah. I should have looked. Most of what I said was wrong. > DTV does NOT define 'month' to be the duration between two consecutive > instances of a 'day of month'. 6 DTV 'months' from April 15 is one of > {October 13, October 14, October 15, October 16}. (I believe that > definition is not "business-friendly", but I could be wrong again. I > would expect "6 months from April 15" to be October 15, not 'any of the > above'. DTV does not have a term that could be substituted for 'month' > in that expression.) > > So DTV clearly defines 'month' to be one of four values. Nicolas is > right that that could be construed as 'a quantity of time within 1.5 > days of 29.5 days', which is a precise unit with a definitional > uncertainty. We would have to define multiples to use the table, that > is, make the table part of the definition, and explain how to use it for > fractional multiples of 'month'. Now that I think of it however, the > integral values are then incorrect. If 'month' is a unit with a crude > definitional error bound, then 30.4 days is also a valid value for > 'month'. And 'month' is really: any scalar multiple of 'day' that is > in the real interval [29..31]. It is not limited to one of four > values. The table really defines only the lower and upper bounds on the > scalar interval. That definition is really different from what we have. > > I'm no longer sure where we go from here. > > (The 'definitional uncertainty' relates to the problem of measuring the > particular quantity of the particular phenomenon that defines the unit. > The frequency of some wave form of the Cesium atom can only be measured > up to a certain accuracy. The measurement uncertainty for a 'second' > with current technology is plus or minus 6 x 10^-16 seconds [see SI > Appendix 2 "practical realization of time", via > http://www.bipm.org/en/si/base_units/]. So a 'day' is actually 86400 > seconds plus or minus 50 picoseconds. The original atomic clocks were > not nearly that good. Now we are asking how long that accuracy will be > good enough.) > > -Ed > >> >> -------------------------------- >> Mark H. Linehan >> STSM, Model Driven Business Transformation >> IBM Research >> >> >> >> From: Edward Barkmeyer >> To: "Rouquette, Nicolas F (313K)" >> >> Cc: "date-time-ftf@omg.org" >> Date: 04/04/2012 08:04 PM >> Subject: Re: Issue 16921- ISO 80000 & Date/Time Foundation >> Vocabulary >> ------------------------------------------------------------------------ >> >> >> >> Rouquette, Nicolas F (313K) wrote: >> >> Consider an application domain where using the combination of DTV and >> SysML is a reasonable proposition because these two specifications >> address recognized needs of this application domain. >> >> Now, for this application domain, I'm proposing to the DTV FTF that if >> the following is true: >> >> - DTV 'month' is a useful criteria for measuring time >> - DTV 11.6 (month values) provides an acceptable bound on the >> 'definitional uncertainty' inherent in DTV 'month' >> >> then can we also say that it is a legitimate application of the DTV >> spec to do the following: >> >> - define an ISO 80000 'system of units' where DTV 'month' is an ISO >> 80000 'measurement unit' with an ISO 80000 'unit equation' specified >> per DTV 11.6 in terms of DTV 'day', itself another ISO 80000 >> 'measurement unit' >> >> - whether DTV 'second', DTV 'minute', DTV 'hour', DTV 'day', DTV >> 'month' are included or not and whether any of them are ISO 80000 >> 'base measurement unit' or ISO 80000 'derived measurement unit' is >> purely a function of the definition of ISO 80000 'system of unit' >> >> What is that application? I can envisage a SysML application in which >> monkeys are trained to ride zebras while aiming SAMs at incoming >> asteroids, but I don't have any intention of making standards to >> support it. And my guess is that most SysML users would prefer an >> analytical model of time, with time points being real numbers, not >> calendar months. >> >> >> I'm saying that DTV 'month' + DTV 11.6 is already sufficient to use >> DTV 'month' as ISO 800000 'measurement unit' as long as DTV 'day' is >> also an ISO 80000 'measurement unit' in the application domain. >> >> And I repeat: 'month' is an ISO 80000 measurement unit only if it is >> _defined to be_ a quantity of time between the bounds specified in >> 11.6, rather than the amount of time between two occurrences of the >> same 'day-of-month'. That is, we would have to _change the >> definition_ of 'month'. And if we do that, the duration of January is >> not 1 'month'; it is exactly 31 days. That is the problem. >> >> I think it vastly preferable that the JPL SysML application that needs >> 'month' to be an ISO 80000 measurement unit should define 'month' or >> 'JPLmonth' in such a way as to be an ISO 80000 measurement unit for >> the ontology for that application. >> >> >> DTV specifies a model of DTV 'month' in terms of DTV 'day' via 11.6 >> >> Yes, but that model is not the definition. It is for conversion purposes. >> >> Whether this model is useful or not for some application is outside >> the scope of the DTV spec, it's for someone to decide. >> >> Well, we know the current definition is useful for business >> applications, and if we didn't know that, we would have tried to find >> out what definition would be likely to be useful to business >> applications. We have yet to hear what application requires a >> definition of month that is an ISO 80000 'measurement unit'. And it >> is not OMG practice to make standards for no known use, or NIST >> practice to work on them. >> >> >> There are some application domains where DTV 'month' is well-suited as >> an ISO 80000 'measurement unit'. >> >> Name one. >> >> >> >> We are back to the original question. As DTV defines 'month', it is >> /not/ an ISO 80000 measurement unit. >> >> It is! >> >> No, it isn't. You mistake a conversion table for a definition. >> >> DTV /could/ define 'month' in such a way as to make it an ISO 80000 >> measurement unit, yes. But that will create problems in defining >> calendars, and it is not clear what applications, if any, would want >> that definition. >> >> It simply means that we may need to have DTV 'month' (per 9.1.2) as >> well as DTV 'calendar month' as you described above. >> >> Calendar month is a time point. What you mean is that we need a >> concept called F6month that has the ISO 80000 conformant definition >> using 11.6, for the unknown application that might use it. >> >> >> Is there some application in any community that wants such a >> definition, rather than simply creating their own 'month' concept(s)? >> >> DTV 'month' is definitely relevant for the kind of longitudinal >> simulation models we're building for a DARPA F6 project at JPL. >> >> You don't mean DTV 'month'. You mean 'F6month' defined to be a >> variable number of days bounded by the table in 11.6. >> >> At least we have finally identified a potential application. If what >> you want is a precise measurement unit called 'xxxmonth' that has the >> ISO 80000-compatible definition, we could probably add that. Pick a term. >> >> -Ed >> >> >> In this project, we are simulating lifecycles of building, deploying, >> operating multiple generations of spacecraft & services. >> I believe that for several aspects of this problem, DTV 'month' is >> definitely an appropriate choice of ISO 80000 'measurement unit' >> and that for other aspects, we might need different definitions of >> 'month', perhaps the 'day-of-month' notion you mentioned above. >> Whether such notions would be legitimate ISO 80000 'measurement units' >> is a different matter. >> >> - Nicolas. >> >> >> -Ed >> >> >> -- >> Edward J. Barkmeyer Email: _edbark@nist.gov_ >> >> National Institute of Standards & Technology >> Manufacturing Systems Integration Division >> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 >> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 >> >> "The opinions expressed above do not reflect consensus of NIST, >> and have not been reviewed by any Government authority." >> >> >> >> >> -- >> Edward J. Barkmeyer Email: _edbark@nist.gov_ >> >> National Institute of Standards & Technology >> Manufacturing Systems Integration Division >> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 >> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 >> >> "The opinions expressed above do not reflect consensus of NIST, >> and have not been reviewed by any Government authority." >> > > -- > Edward J. Barkmeyer Email: edbark@nist.gov > National Institute of Standards & Technology > Manufacturing Systems Integration Division > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > "The opinions expressed above do not reflect consensus of NIST, > and have not been reviewed by any Government authority." >