${taskforce.name} Avatar
  1. OMG Task Force

Date-Time (DTV) 1.0 FTF 2 — Closed Issues

  • Key: DTV_
  • Issues Count: 24
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DTV_-24 "General Concept" for "Time Axis" should be "Definition" DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-22 Mischaracterized description of 'properly overlaps' in text DTV 1.0b2 DTV 1.0 Resolved closed
DTV_-21 Calendar day is misdefined DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-23 Description of time point conversion is confused DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-20 Between DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-19 ISO 80000 & Date/Time Foundation Vocabulary DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-18 UML packages don't match specification sections DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-17 Date-Time Issue: Gregorian calendar introduction DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-16 Date-Time Issue - leap seconds DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-15 Date-Time Issue - scale has scale point DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-14 Minor Errors in Duration Value Verb Concepts DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-11 "Law of Monogamy" example is poorly stated DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-13 Date-Time Issue - Definition of "Situation Model" DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-12 Date-Time Issue - granularity appears twice DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-10 Date-Time Vocabulary - terms for referenced vocabularies DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-9 Date-Time Issue - Need Inventory of SBVR Terms DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-8 Date-Time issue: Specification Should Contain List of Date-Time DTV 1.0b1 DTV 1.0 Resolved closed
DTV_-7 UML Profile is Specifically for DTV, not for SBVR in General DTV 1.0b2 DTV 1.0 Resolved closed
DTV_-6 Atomic Time Coordinate has Index DTV 1.0b2 DTV 1.0 Resolved closed
DTV_-5 time point1 shares common time scale with time point2 DTV 1.0b2 DTV 1.0 Resolved closed
DTV_-2 Adopt ‘occurrence’ and ‘what-happens state of affairs’ from SBVR DTV 1.0b2 DTV 1.0 Resolved closed
DTV_-1 Conflicting models of 'leap second' DTV 1.0b2 DTV 1.0 Resolved closed
DTV_-4 invalid indexical time references DTV 1.0b2 DTV 1.0 Resolved closed
DTV_-3 Definition of 'time interval is current' DTV 1.0b2 DTV 1.0 Resolved closed

Issues Descriptions

"General Concept" for "Time Axis" should be "Definition"

  • Key: DTV_-24
  • Legacy Issue Number: 17431
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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:’.

  • Reported: DTV 1.0b1 — Fri, 15 Jun 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Correct the caption in the ‘Time Axis’ glossary entry. Also, correct the wording of the definition to avoid the terms ‘representation’ and ‘instantaneous’ since the former could be confused with SBVR’s ‘representation’, and the latter is not true of the model we use.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Mischaracterized description of 'properly overlaps' in text

  • Key: DTV_-22
  • Legacy Issue Number: 16990
  • Status: closed  
  • Source: Object Management Group ( Mr. Mike Bennett)
  • Summary:

    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."

  • Reported: DTV 1.0b2 — Wed, 11 Jan 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Replace text as described below.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Calendar day is misdefined

  • Key: DTV_-21
  • Legacy Issue Number: 16943
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    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.

  • Reported: DTV 1.0b1 — Thu, 5 Jan 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    The recommendation is adopted as given.

    (The change to the definition of ‘time point’ is accomplished by the resolution to issue 16665.)

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Description of time point conversion is confused

  • Key: DTV_-23
  • Legacy Issue Number: 17227
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    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.

  • Reported: DTV 1.0b1 — Mon, 12 Mar 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Replace the glossary entry for 'time point converts to time period on time scale' with 'time point converts to time point sequence on time scale'. Also for clarity, add 'time point converts to time set on time scale'. Include these verb concepts in figure 12-2. Add "General Concept" captions to each specialization of these verb concepts to relate the specializations to the general concepts

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Between

  • Key: DTV_-20
  • Legacy Issue Number: 16935
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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.

  • Reported: DTV 1.0b1 — Thu, 29 Dec 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Add the suggested verb concepts to the vocabulary. Use "and" in the primary form of the verb concepts (even though it is also a keyword for conjunction), and provide an alternate synonymous form that does not use 'and'.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

ISO 80000 & Date/Time Foundation Vocabulary

  • Key: DTV_-19
  • Legacy Issue Number: 16921
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • 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.

  • Reported: DTV 1.0b1 — Mon, 19 Dec 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    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.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

UML packages don't match specification sections

  • Key: DTV_-18
  • Legacy Issue Number: 16869
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    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.

  • Reported: DTV 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    The FTF decided to reorganize the document itself, and then repackage the UML model to match the new document organization. The goals of this reorganization are:

    • To modularize the document, the vocabulary, and the UML model so that users do not need to accept the entire design in order to adopt parts.
    • To reconcile dependencies among the parts of the specification, so that each concept is introduced before any dependencies upon that concept.
    • To create an individual SBVR vocabulary and UML package matching the content of each top-level Clause of the specification.
    • To clearly show the dependencies among the Clauses, and correspondingly among the SBVR vocabularies and UML packages.
    • To separate the generic time and calendar concepts from the definitions of the Gregorian, week, time of day, and Internet calendars so that users can model other calendars using the generic concepts without dependencies on these calendars.

    See the new text for clause 6.3 (below) for a summary of the new organization.

    The definition of ‘nominal time unit’ is updated to resolve a forward dependency from ‘nominal time unit’ to ‘duration value sets’.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Date-Time Issue: Gregorian calendar introduction

  • Key: DTV_-17
  • Legacy Issue Number: 16681
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    (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.

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Remove the extraneous text under ‘nominal time unit’ that discusses the history of the Gregorian Calendar.

    Add Notes to the definition of ‘Gregorian Calendar’ explaining when this calendar was adopted in various countries, and cautioning that some historical dates may not use this calendar.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Date-Time Issue - leap seconds

  • Key: DTV_-16
  • Legacy Issue Number: 16680
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    (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".

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Currently, the Date-Time Vocabulary describes the Gregorian Calendar in terms of the UTC time scale. To support leap seconds, add definitions of the TAI time scale and leap seconds, and add text saying that leap seconds add discontinuities in the UTC time scale. These discontinuities affect use cases that are sensitive to leap seconds.
    Per ISO 80000-3, the definition of the 'day' time unit remains as a fixed 86 400 seconds.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Date-Time Issue - scale has scale point

  • Key: DTV_-15
  • Legacy Issue Number: 16676
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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.

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    The resolution of issue 16665 deleted this Annex. Therefore this issue is moot.
    Revised Text:
    Disposition: Merged: See issue 16665

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Minor Errors in Duration Value Verb Concepts

  • Key: DTV_-14
  • Legacy Issue Number: 16667
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    • 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.

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    In clause 11.5 on page 135, there are two glossary entries named “years centennial quotient of year value”. Rename the second one to “years quadricentennial quotient of year value”. Correct the definition of this entry to read:

    Definition: the years quadricentennial quotient is the remainder produced by dividing the number of the year value by 400

    In clause 11.6 on page 138, there are two glossary entries named “months centennial quotient of year value”. Rename the second one to “months quadricentennial quotient of year value”. Correct the definition of this entry to read:

    Definition: the months quadricentennial quotient is the remainder produced by dividing the number of the month value by 4 800

  • Updated: Sun, 8 Mar 2015 17:51 GMT

"Law of Monogamy" example is poorly stated

  • Key: DTV_-11
  • Legacy Issue Number: 16663
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    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 doesn’t 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 that’s 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.

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Chose a different example from EU-Rent that illustrates the point. Add a new Rationale section that discusses in more detail different techniques for writing rules that refer to situations and time. Add new verb concepts 'occurrence1 overlaps occurrence2' and 'situation model1 overlaps situation model2' to simplify rules that talk about two situation models occurring at the same time.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Date-Time Issue - Definition of "Situation Model"

  • Key: DTV_-13
  • Legacy Issue Number: 16666
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Clarify that a situation model may or may not occur

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Date-Time Issue - granularity appears twice

  • Key: DTV_-12
  • Legacy Issue Number: 16665
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    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.

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    (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.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Date-Time Vocabulary - terms for referenced vocabularies

  • Key: DTV_-10
  • Legacy Issue Number: 16661
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Merged into Issue 16659

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Date-Time Issue - Need Inventory of SBVR Terms

  • Key: DTV_-9
  • Legacy Issue Number: 16660
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Add the list as recommended in the Issue statement as the content of Clause 4 Terms and Definitions

  • Updated: Sun, 8 Mar 2015 17:51 GMT

Date-Time issue: Specification Should Contain List of Date-Time

  • Key: DTV_-8
  • Legacy Issue Number: 16659
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • 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.

  • Reported: DTV 1.0b1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Add a “Vocabulary Registration Vocabulry” annex to formally name and register the contents of the vocabularies in the Date-Time Vocabulary (DTV ) specification.

  • Updated: Sun, 8 Mar 2015 17:51 GMT

UML Profile is Specifically for DTV, not for SBVR in General

  • Key: DTV_-7
  • Legacy Issue Number: 18284
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Issue 17129 added a new Annex I titled "UML Profile for SBVR". The title is misleading; this is a profile for SBVR as used in the Date-Time Vocabulary, not a profile for SBVR in general.

    Recommendation: change the title of this Annex and related text to make clear this profile documents the stereotypes used in the UML model of the Date-Time Vocabulary. The profile does not address all of SBVR and is not intended for use beyond DTV.

  • Reported: DTV 1.0b2 — Tue, 27 Nov 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    The UML model in the original Date-Time Vocabulary (DTV) submission incorporated a number of stereotypes in order to capture SBVR semantics where UML does not provide equivalents. Issue 17129 thoroughly documented these stereotypes in the new Annex I. The documentation is needed to ensure consistent and complete implementations.

    The title and introduction of the Annex imply that this profile is intended for generic use in any SBVR vocabulary mapped to SBVR. This was not the intent. The Annex selectively addresses only those SBVR concepts that are both used in the Date-Time Vocabulary and do not "map" directly to UML concepts. However, the Annex title and introduction imply otherwise. Therefore the resolution for issue 17129 is revised to:

    • Clarify a sentence in clause 5.3 that introduces the UML model.
    • Changethe title of Annex I.
    • Reword the introduction of Annex I.

    During the preparation of the resolution for this issue, the resolution author noticed that Annex I is omitted from the specification introduction in clause 6.3. That omission is also corrected by the revised version of 17129.

    Revised Text:
    None: all revisions are incorporated in the revised resolution of 17129.
    Disposition: Merged

  • Updated: Sun, 8 Mar 2015 17:50 GMT

Atomic Time Coordinate has Index

  • Key: DTV_-6
  • Legacy Issue Number: 18283
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Issue 17426 added a verb concept 'atomic time coordinate has index' to clause 10.5.3 for consistency with figure 10.10. Issue 17428 redefined 'atomic time coordinate', and deleted this concept from the figure but failed to delete 'atomic time coordinate has index' because it was not in the convenience document of the time.

    Recommendation: delete 'atomic time coordinate has index'.

  • Reported: DTV 1.0b2 — Tue, 27 Nov 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    The resolution of issue 17428 is revised to delete the 'atomic time coordinate has index'. Therefore this resolution is merged with that of 17428.

    Revised Text:

    Disposition: Merged

  • Updated: Sun, 8 Mar 2015 17:50 GMT

time point1 shares common time scale with time point2

  • Key: DTV_-5
  • Legacy Issue Number: 18191
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Clause 10.8 defines the verb concept 'time point1 shares common time scale with time point2'. This verb concept is then specialized with verb concepts such as 'Gregorian year shares the Gregorian days scale with Gregorian month'. These specialized verb concepts are defining 'ground facts', and probably should be given as Necessities rather than verb concepts.

  • Reported: DTV 1.0b2 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    The various verb concepts are changed to Necessities, capturing the same meaning in a form that is more consistent with SBVR usage.

  • Updated: Sun, 8 Mar 2015 17:50 GMT

Adopt ‘occurrence’ and ‘what-happens state of affairs’ from SBVR

  • Key: DTV_-2
  • Legacy Issue Number: 18173
  • Status: closed  
  • Source: Rule ML Initiative ( Mr. Donald R. Chapin)
  • Summary:

    In support of the addition of a very generic concept for all kinds of occurrences to SBVR at the DTV RTF’s request, so that all specifications that define a particular kind of occurrence based on this generic SBVR concept, the Date-Time Vocabulary needs entries to do this.
    Resolution:
    1. Adopt ‘occurrence‘ from SBVR as specialize it as ‘temporal occurrence’.
    2. Adopt ‘what-happens state of affairs has occurrence’ from SBVR as specialize it as ‘what-happens state of affairs has temporal occurrence’.

    Revised Text:
    In clause 16 immediately before the entry for ‘situation model', INSERT two new entries:
    temporal occurrence
    Definition: occurrence that occurs for a given time interval

    … add whatever contraints are required by DTV on ‘temporal occurrence’, which is adopted from SBVR …

    Necessity: A state of affairs will have occurred for a time interval if and only if the state of affairs has an occurrence and the occurrence interval of the occurrence is the time interval.

    Necessity: A state of affairs has been actual if and only if an occurrence of the state of affairs is in the past.
    Necessity: A state of affairs is actual if and only if an occurrence of the state of affairs is current.
    Necessity: A state of affairs will be actual if and only if an occurrence of the state of affairs is in the future.

    Necessity: An occurrence has been actual if and only if the occurrence is in the past.
    Necessity: An occurrence is actual if and only if the occurrence is current.
    Necessity: An occurrence will be actual if and only if the occurrence is in the future.
    what-happens state of affairs

    … add whatever contraints are required by DTV on ‘what-happens state of affairs’, which is adopted from SBVR …

    what-happens state of affairs has temporal occurrence
    Definition: ’ what-happens state of affairs has occurrence’ that includes only temporal occurrences

    … add whatever contraints are required by DTV between ‘temporal occurrence’ and ‘what-happens state of affairs’, which are adopted from SBVR …

    In clause 16.7, in the entry for ' situation model occurs now', ADD a Nole:
    Note: The statement “the state of affairs has an occurrence that is current” is semantically equivalent to the SBVR characterisitc “state of affairs is actual”.

  • Reported: DTV 1.0b2 — Mon, 15 Oct 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    The SBVR-RTF has decided not to add support for 'occurrence' or 'what-happens state of affairs' to SBVR, leaving them entirely to the Date-Time Vocabulary. Therefore, the DTV FTF-2 has chosen to retain the original Date-Time approach to these concepts but adapt them to more closely align them with SBVR. The following changes are made by this issue resolution:
    1. 'Situation model' is renamed 'situation kind' on the belief that this term is more acceptable to business users, and that it is a better match to the intended meaning. 'Individual situation model' and 'general situation model' are renamed to 'individual situation kind' and 'general situation kind' to match.
    2. 'Situation kind' and 'occurrence' are redefined as specializations of SBVR 'state of affairs', thus defining the relationship between SBVR 'state of affairs' and these DTV concepts.
    3. The SBVR Necessity ' Each proposition corresponds to at most one state of affairs.' is replaced with ' Each proposition corresponds to exactly one situation kind.' because the original SBVR Necessity prevents a proposition from having multiple occurrences.
    4. A Necessity is added to make clear that 'occurrences' are 'actual' iff they are current.
    5. A Necessity is added to make clear that a 'situation kind' is actual iff there exist occurrences of the situation kind at the current time.
    6. The relationship of verb concepts and verb concept objectification with 'state of affairs', 'situation kind', and 'occurrence' is described.
    7. An unused Date-Time concept is removed to improve the alignment with SBVR:
    situation model is realized
    8. The 'proposition describes situation model' is dropped in favor of SBVR's 'proposition corresponds to state of affairs'.
    Examples are used to explain how and why the Date-Time Vocabulary differs from SBVR with respect to 'states of affairs'.

    This resolution also addressed most of the concerns raised by issues 16664, 16678, 16768, and 17597:

    • 16664 raises a number of issues about the relationship of 'situation kind' and 'occurrence' to 'state of affairs', about when a proposition is true, and related concerns. These issues are all resolved here.
    • 16678 asked for a better integration with SBVR 'state of affairs' and 'state of affairs is actual'. This resolution addresses that concern in detail.
    • 16768 also asked for a better integration with SBVR 'state of affairs'.
    • 17597 asked for a reorganization of the 16.1 and 16.1.1 headings. That reorganization is made in this resolution.

  • Updated: Sun, 8 Mar 2015 17:50 GMT

Conflicting models of 'leap second'

  • Key: DTV_-1
  • Legacy Issue Number: 18130
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The UML diagram in Figure 13.1 shows 'leap second' as a subtype of 'second of day'.
    The Definition of 'leap second' in clause 13.2 defines it to be an instance of 'second of day'.
    The text is correct. The UML diagram should show that it is an instance, like 'midnight'.

  • Reported: DTV 1.0b2 — Mon, 1 Oct 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    Correct the UML diagram

  • Updated: Sun, 8 Mar 2015 17:50 GMT

invalid indexical time references

  • Key: DTV_-4
  • Legacy Issue Number: 18189
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The definitions of the indexical time intervals in clause 15 include references to time point concepts that either do not exist or are not visible in the included vocabularies. These concepts include:

    day of year (which does not exist)
    hour of day (in clause 13, which is not included in clause 15)
    minute of hour (in clause 13, which is not included in clause 15)
    calendar week (in clause 12, which is not included in clause 15)
    week period (in clause 12, which is not included in clause 15)

    Recommendation: define 'day of year' in clause 10.2, and move the other concepts from their current locations to clause 10.2.

  • Reported: DTV 1.0b2 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    The structure of the Date-Time Vocabulary is revised to make the Indexical Time Vocabulary include the vocabularies that define these concepts, thus resolving the issue. The reference to 'day of year' is corrected to reference 'Gregorian day of year'.

  • Updated: Sun, 8 Mar 2015 17:50 GMT

Definition of 'time interval is current'

  • Key: DTV_-3
  • Legacy Issue Number: 18187
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In clause 15.1 page 154 DTV defines 'time interval is current' as:
    "time interval that includes a time interval1 that is past and that includes a time interval2 that is not past"

    That definition is ambiguous and the most likely parse is nonsense. The problem is that 'and that includes' might be parsed to refer to time interval1, which is not what was intended. The intent is
    "time interval that includes both a time interval that is in the past and a time interval that is not past". I believe SBVR SE might support this latter formulation (perhaps without the 'both').

  • Reported: DTV 1.0b2 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0
  • Disposition Summary:

    This is a minor problem with formulating the definition in SBVR Structured English. The definition is reworded to eliminate the 'and that includes'.

  • Updated: Sun, 8 Mar 2015 17:50 GMT