Issue 16659: Date-Time issue: Specification Should Contain List of Date-Time
Issue 16660: Date-Time Issue - Need Inventory of SBVR Terms
Issue 16661: Date-Time Vocabulary - terms for referenced vocabularies
Issue 16663: "Law of Monogamy" example is poorly stated
Issue 16665: Date-Time Issue - granularity appears twice
Issue 16666: Date-Time Issue - Definition of "Situation Model"
Issue 16667: Minor Errors in Duration Value Verb Concepts
Issue 16675: Date-Time Issue - Arithmetic Involving Years and Weeks
Issue 16676: Date-Time Issue - scale has scale point
Issue 16677: Date-Time Issue - Formulating Tense and Aspect
Issue 16680: Date-Time Issue - leap seconds
Issue 16681: Date-Time Issue: Gregorian calendar introduction
Issue 16716: Date-Time Issue: OCL should be integrated into UML model
Issue 16869: UML packages don't match specification sections
Issue 16873: UML operations are not defined
Issue 16921: ISO 80000 & Date/Time Foundation Vocabulary
Issue 16934: Need Informal Definitions or Descriptions
Issue 16935: Between
Issue 16943: Calendar day is misdefined
Issue 16990: Mischaracterized description of 'properly overlaps' in text
Issue 17227: Description of time point conversion is confused
Issue 17349: spec should provide a simple library of datatypes for use in UML and data modeling
Issue 17431: "General Concept" for "Time Axis" should be "Definition"
Issue 17533: Year of Weeks and Year of Weekdays Scales are Misdefined
Issue 18190: Time Point Converts to Time Point Sequence
Issue 18240: Clause 8.3.2 dependency upon clause 10.2
Issue 18241: time interval1 precedes time interval2
Issue 18253: Time intervals defined by duration
Issue 18822: time interval meets time interval is incorrectly defined in SBVR SE
Issue 18827: DTV Issue: Error in 'time point1 to time point2 specifies time period'
Issue 18828: DTV Typo: first member
Issue 16659: Date-Time issue: Specification Should Contain List of Date-Time (dtv-rtf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: International Business Machines (Mr. Mark H. Linehan, mlinehan(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:
The specification should contain a formal list of all the SBVR vocabularies defined by the specification. An example of such a list is given in SBVR clause 7. The list is needed by software that converts the specification text to XMI.
The specification should contain a list of the SBVR terms and verb wordings that are referenced in the document, in order to make it clear where these terms come from. Proposed text for clause 4 "Terms and Definitions": __________________________________________________ SBVR Meaning and Representation Vocabulary General Concept: vocabulary Language: English ___________________________________________________ concept concept1 specializes concept2 concept type fact type fact type has fact type role fact type role integer instance meaning meaning corresponds to thing meaning has representation name non-negative integer noun concept number proposition representation representation uses expression role set statement statement expresses proposition term text thing thing has name thing is in set Synonymous Form: set includes thing Synonymous Form: set has element thing1 is thing2 verb concept __________________________________________________ __________________________________________________ __________________________________________________ Vocabulary for Describing Business Vocabularies General Concept: vocabulary Language: English ___________________________________________________ categorization type res terminological dictionary vocabulary vocabulary namespace
The start of clause 7 has a set of SBVR terms for referenced vocabularies. The following are missing from this list: IKL Definition: The proposal of the IKRIS Interoperability Group, entitled IKL Specification Document, available at http://www.ihmc.us/users/phayes/IKL/SPEC/SPEC.html Inter Gravissimas Definition: The papal bull issued by Pope Gregory XIII, 24 February 1582. Prepared in English, Latin, and French by R.T.Crowley for ISO TC154 on 27 December 2002. ISO 18026 Definition: The standard of the International Standards Organization (ISO), number 18026, Information technology Spatial Reference Model (SRM), 2009 ISO 80000-3 Definition: The standard of the International Standards Organization (ISO), number 80000-3, named: Quantities and units -- Part 3: Space and time, 2006 OCL Definition: The specification of the Object Management Group (OMG) named: Object Constraint Language, version 2.0, May 2006
Regarding the "monogamy" example in clause 7.3 > Consider the law of monogamy as it exists in some countries: > It is prohibited that a person1 is married to person2, if that person1 is married to another person3 and person2 is different from person3. > This rule is not entirely correct . I cannot imagine a country with the law of monogamy stated like that. It is not proper English nor is it proper SBVR SE. How about this: A person must not be married to more than one person. This section argues that the rule statement is not entirely correct because it doesnt say at the same time. But that is nonsense. Based on that argument, every rule would need to explicitly tie every relation it uses to time. E.g.: Rule A: It is prohibited that a drunk driver operate a EU-Rent vehicle. Rule B: It is prohibited that there exists a time interval such a driver is drunk throughout that time interval and the driver operates a vehicle throughout that time interval and the vehicle is a EU-Rent vehicle throughout that time interval. It would be better to point out that in any situation there is at most one present time. Therefore, the law of monogamy stated as A person must not be married to more than one person is perfectly correct and it logically implies that A person must not be married to more than one person at the same time. occurrence is defined in the introduction to be a possible state of affairs. This is OK, if thats what is intended. But occurrence is defined differently later. Proposed Resolution: Change the text at the start of the clause from: Consider the law of monogamy as it exists in some countries: It is prohibited that a person is married to more than one person. This rule is correct only on the understanding that the rule is evaluated at a point in time, as specified in this document. A version of the rule that uses the concepts defined in this section to make this understanding explicit is: If a person1 is married to some person2 occurs for some time interval, it is prohibited that person1 is married to another person3 during the time interval. to: Consider the law of monogamy as it exists in some countries: It is prohibited that a person is married to more than one person. This rule is correct only on the understanding that the rule is evaluated at a point in time, as specified in this document. A version of the rule that uses the concepts defined in this section to make this understanding explicit is: If a person1 is married to some person2 occurs for some time interval, it is prohibited that person1 is married to another person3 during the time interval.
The term "granularity" has two glossary entries, one in clause 8.2, and another in D.4. One should be renamed to avoid confusion, although they mean almost the same thing. Proposed Resolution: (The submission team adopted this resolution after the final submission. The change is recorded here as an Issue so that it can be considered by the FTF.) Under "time scale has granularity" in clause 8.2, add a new Necessity: Necessity: The scale of the time scale is the granularity of the time scale if and only if the granularity of the time scale is a precise time unit. In Annex E.3: rename the glossary entry "granularity" to "scale granularity" rename the glossary entry "scale has granularity" to "scale has scale granularity" reword the Necessity under " scale has scale granularity" to read: Necessity: Each scale has at most one scale granularity. Add 1 note and 2 examples: Note: Time scales are kinds of scales, but time scales of nominal time units (which are not true measurement units) do not have true scale granularities (which are always measurement units). Example: The Gregorian years scale has a granularity of 'year'. This granularity is the scale granularity of the scale. Example: The Gregorian months scale has a granularity of 'month'. This scale does not have a scale granularity because 'month' is a nominal time unit, not a precise time unit.
The definition of "situation model" should be clarified to make it clear that it "may or may not occur". Proposed Resolution: (At it's conference call on September 9, the submission team agreed to the following change. Since this change was after the final submission, it is recorded here for consideration by the FTF.) Change the Definition of "situation model" to read: Definition: res that is an abstract model or conceptualization of an event, activity, situation, or circumstance that may or may not occur in some possible worlds
The fact type form months centennial quotient of month value is used in two different glossary entries in clause 10.6, Duration Values. The second entry should be months quadricentennial quotient of month value. Both the glossary entry and the definition should be updated. The fact type form years centennial quotient of year value in clause 10.5 has the same error as above and needs the same fix.
The final submission document recorded this issue in clause 11.6 "Mixed-Base Arithmetic": Need to add a paragraph discussing arithmetic involving weeks and years because these are incommensurable. This depends upon defining a concept that computes the number of weeks in any particular year.
The final submission document recorded this issue regarding figure 80 "Scales" in clause Annex E.3:
The "black diamond" and {redefines...} on the "scale has scale point" association are wrong.
The final submission document recorded the following issue at the start of Annex F.5 "Formulating Tense and Aspect": This section needs to be updated to reflect the term "situation model" as used in this specification, instead of "state of affairs".
(This comment came from the Architecture Board's review of the final submission.) This comment on page 16 [now Annex A.3 jarred somewhat: "These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant." It seems a bit arrogant to assert that "leap seconds are insignificant to business". If (for instance) your company's Telephone PABX were to crash at midnight on New Year's Eve because its software couldn't cope with leap-seconds, I suggest that would be "significant to business".
(This comment came from the Architecture Board's review of the final submission.) On p100 it is stated that "the Gregorian Calendar was introduced in 1582" and corrected calendar drift by "skipping over the dates between October 5-15, 1582". This is true, but it's worth noting that only Spain, Portugal, the Polish-Lithuanian Commonwealth, and parts of Italy implemented the new calendar on Friday 15 October 1582 (following Julian Thursday 4 October 1582). Other countries stayed with the Julian calendar, so those "lost dates" (e.g. 10th October 1582) are valid in those countries. France adopted the Gregorian calendar on Monday 20 December 1582 (following Sunday 9 December 1582). Other countries followed over the centuries, with the UK and East-Coast American colonies not switching until 1752 (Wednesday 2 September 1752 was followed by Thursday 14 September 1752). Russia didn't change until 1918. The last countries to change seems to have been Greece, where Thursday 1 March 1923 followed Wednesday 15 February 1923, and Turkey, which switched in 1926. (Yes, I got all those dates from Wikipedia :-). Hence I think this section would benefit from a comment saying that although the Gregorian Calendar begins in 1582, various countries switched on various later dates, so that to be completely unambiguous, dates after October 1582 should really state which calendar they use. (For instance, today, Sunday 11th September 2011 in the Gregorian Calendar is Monday 29th August 2011 in the Julian calendar). Similarly, at the top of page 121 it says that the Gregorian calendar was "introduced in 1582". It might be more accurate to say it was "first defined" in 1582 (or some similar wording), and "introduced" in different countries at different later dates.
Currently, OCL statements are created directly in the specification document, then "stripped out" of the document into a separate file via an XSLT transform. In a further step, the OCL should be integrated into the UML model so that the model includes the OCL constraints.
The UML packages in the supporting UML document (bmi/2011-08-01.mdzip) are not consistently aligned with the sections of the specification. In particular: Sections 8.1 and 8.2 of the specification are both in the TimeInfrastructure package, but section 8.3 is not. Section 8.3 of the specification matches the Situations package, except that 8.3.7 Schedules is in a separate Schedules package. And the Situations package also contains the Tense concepts from 10.3. Sections 9.1 to 9.4 of the specification are all in the TimeScales package, but sections 9.5 and 9.6 are not. Section 9.5 of the specification matches the Calendars package, except that Gregorian calendar (9.5.5) is a separate UML package, and Internet Time (9.5.7) is a separate UML Package. Section 9.6 of the specification (Time Tables) is in the Schedules package, along with the Schedules concepts from 8.3.7. Section 10 of the specification matches the Indexicals package, except that Tense and Aspect (10.3) is in the UML Situations package. (The UML model treats tense as a relationship of situations to time, but the time concepts involved are indexical.) Section 11 of the specification matches the DurationValues package, except that month values (11.6) and year values (11.5) are in the UML Gregorian calendar package. Section 12 of the specification matches the UML TimeCoordinates Package, except that Section 12.4 is in the Gregorian calendar package. Annex D of the specification matches the UML Packages: Sequences (D.1), Quantities (D.2), Mereology (D.4), except that D.3 Scales is included in the UML Quantities package. In sum, some reorganization of the specification did not result in a consistent reorganization of the UML model. In general, the UML packaging should be made consistent with the text. But, if the Gregorian calendar package is intended to be separable, then Gregorian elements in other parts of the specification may need to be treated as exceptions. In addition, one can argue that the 'time table' and 'schedule' concepts are closely related and should be together in the specification. I do not recommend the use of nested UML Packages. It complicates the UML model and all references to the UML concepts defined in it.
Many of the UML classes defined in Clause 8 have several UML operations. While it may be easy to guess the relationship between the operations and the associations, there is no text that defines these operations, or even mentions their relationship to the associations. In each case, these operations should be formally documented under the "glossary entry" for the class. (The description in clause 5.2 is helpful, but it alone does not meet the documentation requirement. It just says that each such operation is somehow related to some defined association.)
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.
Many Date Time Vocabulary concepts have very formal definitions that are hard for one of the target audiences business users to understand. For example, the definition of the Allen Relationship 'time interval1 is properly before time interval2' reads: Definition: the time interval1 is before the time interval2 and the time interval1 is before a time interval3 and the time interval3 is before the time interval2 This formal definition provides a precise meaning for use by reasoning engines, but it takes even an expert human awhile to understand. Business users have little chance of understanding it. The solution proposed by this Issue is that this and every other Date Time Vocabulary concept should have an informal definition or description that explains the concept to the business user audience. Note that SBVR permits a concept to have multiple definitions, so adding informal definitions need not displace any existing formal definitions.
The Date Time Vocabulary provides verb concepts that relate the time order of any two time intervals (e.g. 'time interval1 is before time interval2'), any two situation models ('situation model1 precedes situation model2'), and any two occurrences ('occurrence1 precedes occurrence2'). Another common ordering relationship is among three time intervals, situation models, or occurrences, as in 'time interval1 is between time interval2 and time interval3', 'situation model1 is between situation model2 and situation model3', and 'occurrence1 is between occurrence2 and occurrence3'. These ternary verb concepts should be added to the Date Time Vocabulary.In clause 9.5.3, 'calendar day' is defined as: 'time point that is defined by a given calendar and during which approximately one revolution of the earth occurs on its axis'. Clause 9.3 defines 'time point' as 'scale point that is in a time scale and that specializes the concept 'time interval'. Fortunately, 9.3 also says 'time point' is a concept type, so the idea of specialization makes sense. That is, the definition in 9.3 means: a time point is a scale point on a time scale, and a time point is a concept that specializes 'time interval'. A concept that specializes time interval is not a time interval during which the earth rotates -- its instances are. Recommendation: In clause 9.5.3, change the definition of calendar day to 'time point that is defined by a given calendar and that corresponds to time intervals during which approximately one revolution of the earth on its axis occurs'. In clause 9.3 reword the definition of time point to 'concept that specializes the concept time interval and that is a scale point on a time scale.
The description for "Properly overlaps" in this section is as follows: "The properly overlaps relation distinguishes the case in which there is a part of each time interval that is not a part the other from all the cases in which one time interval is entirely a part of the other. The general overlaps relation subsumes all of them. Properly overlaps describes the first time interval as starting and ending earlier than the second, whereas is properly overlapped by describes the first time interval as starting and ending later." Problem: In the phrase "Properly overlaps describes the first time interval as starting and ending earlier than the second," the sense which is intended is in fact "Properly overlaps describes the first time interval as starting earlier than the second starts and ending earlier than the second ends" That is, a word was left implied in this phrase, but no one word would, when inserted here, have carried the correct meaning. For example "starting and ending earlier than the second [starts]" would be incorrect, as would "starting and ending earlier than the second [ends]". So when the reader parses this surface-level syntax and inserts any implied words for a deeper level cognitive representation of the meaning, any such representation would be incorrect compared to the intended sense of this term. Similarly in the phrase which follows: "... whereas is properly overlapped by describes the first time interval as starting and ending later." should then (presumably) be: "... whereas is properly overlapped by describes the first time interval as starting later than the second starts, and ending later than the second ends." Proposed Solution: Rewrite the offending paragraph as follows: "The properly overlaps relation distinguishes the case in which there is a part of each time interval that is not a part the other from all the cases in which one time interval is entirely a part of the other. The general overlaps relation subsumes all of them. Properly overlaps describes the first time interval as starting earlier than the second starts and ending earlier than the second ends, whereas is properly overlapped by describes the first time interval as starting later than the second starts, and ending later than the second ends."
Clause 12.4 contains the following: "The concept time point converts to time period on time scale enables conversion of a time point on some time scale1, to a time period on the given time scale. The target time scale always is finer, meaning that it has a granularity that is less than or equal to the granularity of time scale1. This means that time point is equivalent to a time period on time scale2. "For example, the Gregorian month that is indicated by January (on the Gregorian year of months scale) is the time period from Gregorian day of year 1 through Gregorian day of year 31 on the Gregorian year of days scale." In all of this text, the term 'time period' should probably be replaced by 'time point sequence'. Clause 12.4 then contains this entry: "time point converts to time period on time scale "Definition: time point converts to a time point sequence on the time scale and the time period instantiates the time point sequence" The verb concept 'time point converts to time point sequence' appears in diagram 12-12, but is not defined anywhere, and 'time point converts to time period on time scale' does not appear on the diagram. So the obvious interpretation is that 'time period' should be replaced by 'time point sequence' in the verb concept entry. But then the definition is circular.
This spec should provide a simple library of datatypes for use in UML and data modeling. This is present in many physical data standards (e.g. SQL/JDBC, XML Schema) but is lacking in OMG for platform independent modeling. That would include types such as: - Date - DateTime - TimeStamp - Duration
The glossary entry for Time Axis has a General Concept: entry that reads mathematical representation of the succession in time of instantaneous events along a unique axis. The caption is wrong; it should be a Definition:.
Summary: These two year of weeks scale and year of weekdays scale are defined using the time scale subdivides time point verb concept. That verb concept assumes that the start of the time point coincides with the start of the scale, but this is not true for these two scales because calendar weeks are not coherent with calendar years. A special verb concept needs to be used to relate weeks and weekdays to calendar years.
In the beta-2 document, clause 10.8 defines a verb concept 'time point converts to time point sequence on time scale'. A typical use is 'Gregorian month converts to time point sequence on the Gregorian days scale', which is given as a specialization. The 'time scale' role is redundant in the main verb concept, and the use of individual concepts in the derived verb concepts is poor practice.
Title: Clause 8.3.2 dependency upon clause 10.2 Source: Mark H. Linehan, IBM Research, mlinehan@us.ibm.com Summary: The definitions of several standard time units that are defined in clause 8.3.2 are dependent upon "period" concepts that are defined in clause 10.2. Specifically: The Definition of day in 8.3.2 references calendar day, which is in 10.2 The Definition of year in 8.3.2 references calendar year, in 10.2 The Definition of month in 8.3.2 references calendar month, in 10.2 The Definition of week in 8.3.2 references calendar week, in 10.2 This violates the Vocabulary structure shown in figure 7.3
Source: Mark H. Linehan, IBM Research, mlinehan@us.ibm.com Summary: The verb concept 'time interval1 precedes time interval2', defined in clause 8.1.4, appears to have the same semantics as 'time interval1 is before time interval2' in clause 8.1.2. Also, figure 8.5 fails to show 'time interval1 precedes time interval2'.
In DTV Beta-2,Clause 8.2.3, there are two verb concepts: time interval1 is duration before time interval2 time interval1 is duration after time interval2 From the alternative form: "duration before/after time interval2", it seems clear that the intent of these verb concepts is to allow a time interval to be defined by a reference time interval and a duration, e.g., the two weeks before the jump-off date, the day after the meeting (day). Each of these denotes exactly one time interval. But the Definitions mean that the verb concepts simply state the duration between two time intervals. This may be useful when the intent is to state the duration between two events, but it is not the meaning of 'duration before time interval', and it cannot be used to define a time interval. Either these verb concepts should be defined to be the ones intended by the alternative forms, or the alternative forms should be separate verb concepts.
In clause 8.1.3, the definition of time interval1 meets time interval2: the time interval1 is before the time interval2 and the time interval1 is not before a time interval3 that is before the time interval2 is inaccurate at best. The CLIF and OCL definitions are correct. As stated, the definition says that there is one time interval3 that is before time interval2 and that time interval1 is not before, but it does not say that there is no other time interval3 is before time interval2 and that time interval1 is not before. The definition should read: time interval1 is before time interval2 and there is NO time interval3 that is after time interval1 that is before time interval2 This revised statement matches the CLIF and OCL definitions. There may be other such misstatements in 8.1.3.
In DTV clause 8.6, the Definition of time point1 to time point2 specifies time period reads: Definition: time point1 is the first time point of a time point sequence and some time point3 is the last time point of the time point sequence and time point2 is just before time point3 in the time point sequence and time point1 through time point2 specifies the time period The subscripts on time point2 and time point3 are reversed. It should read: Definition: time point1 is the first time point of a time point sequence and time point2 is the last time point of the time point sequence and there is a time point3 that is just before time point2 in the time point sequence and time point1 through time point3 specifies the time period
In annex D.2, Sequences, the entry for "first member" has "General Concept: role" and "Possibility: thing". It should be "Concept Type: role" and "General Concept: thing".