Date-Time Vocabulary Avatar
  1. OMG Specification

Date-Time Vocabulary — Closed Issues

  • Acronym: DTV
  • Issues Count: 195
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DTV13-103 Introductory text in 11.4 is confused DTV 1.2 DTV 1.3 Resolved closed
DTV13-101 Clause 10.5 should be in Clause 13 DTV 1.2 DTV 1.3 Resolved closed
DTV13-104 Clause 14 is not about time dissemination DTV 1.2 DTV 1.3 Resolved closed
DTV13-106 Definition of 'standard time' is inadequate and 'local time' is wrong DTV 1.2 DTV 1.3 Closed; No Change closed
DTV13-105 Characterization of time offset as a role of duration is inconsistent DTV 1.2 DTV 1.3 Duplicate or Merged closed
DTV13-13 UML operations are not defined DTV 1.0b1 DTV 1.3 Resolved closed
DTV13-12 Need Informal Definitions or Descriptions DTV 1.0b1 DTV 1.3 Resolved closed
DTV13-83 Missing subscript in definition of time interval1 ends during time interval2 DTV 1.2 DTV 1.3 Resolved closed
DTV13-81 Inadequate guidance for application vocabularies DTV 1.0 DTV 1.3 Closed; No Change closed
DTV13-74 In Annex D.3.2, in the entry for "base unit", the first caption should be "Definition" instead of "Concept Type". DTV 1.0 DTV 1.3 Closed; No Change closed
DTV13-75 DTV 1.2 issue: Ordinals DTV 1.1 DTV 1.3 Resolved closed
DTV13-69 Vestigial 'Gregorian week' in Clause 11 Figures DTV 1.2 DTV 1.3 Resolved closed
DTV13-67 'overlaps' is symmetric not synonymous DTV 1.2 DTV 1.3 Resolved closed
DTV13-87 Indefinite time intervals should not depend on occurrences DTV 1.2 DTV 1.3 Resolved closed
DTV13-66 Use of 'week' vs. 'ISO week' in clause 10 DTV 1.1 DTV 1.3 Resolved closed
DTV13-65 missing OCL DTV 1.1 DTV 1.3 Resolved closed
DTV13-64 merger of separate concepts in 8.2.5 DTV 1.2 DTV 1.3 Resolved closed
DTV13-2 DTV 1.2 issue: incorrect character styling DTV 1.1 DTV 1.3 Resolved closed
DTV13-99 time interval starts/ends on time point have wrong synonymous forms DTV 1.2 DTV 1.3 Closed; No Change closed
DTV13-102 The Gregorian calendar is not standardized by ISO 8601 DTV 1.2 DTV 1.3 Resolved closed
DTV13-27 Issue 19172 continued: Missing "exactly" in scale definitions DTV 1.0 DTV 1.3 Closed; No Change closed
DTV13-4 Date-Time Issue - Formulating Tense and Aspect DTV 1.0b1 DTV 1.3 Resolved closed
DTV13-25 Missing "exactly" in scale definitions DTV 1.0 DTV 1.3 Resolved closed
DTV13-9 DTV Issue: Add Necessity statements to indicate "result" of 3-way verbs DTV 1.0 DTV 1.3 Resolved closed
DTV13-11 spec should provide a simple library of datatypes for use in UML and data modeling DTV 1.0b1 DTV 1.3 Resolved closed
DTV13-82 'begins before' axiom contradicts the definition DTV 1.2 DTV 1.3 Resolved closed
DTV13-73 The "SBVR-DTV Vocabulary" in clause 4 has no namespace URI. That means it cannot be referenced across a network DTV 1.0 DTV 1.3 Closed; No Change closed
DTV13-26 Unusual use of 'that' in definitions DTV 1.0 DTV 1.3 Deferred closed
DTV13-3 Date-Time Issue: OCL should be integrated into UML model DTV 1.0b1 DTV 1.3 Deferred closed
DTV12-71 Necessities should be independent of placement DTV 1.1 DTV 1.2 Resolved closed
DTV12-70 Confusion of Axioms and Verb Concepts for Time Interval operations DTV 1.1 DTV 1.2 Resolved closed
DTV12-72 Occurrence does not specialize Situation Kind DTV 1.1 DTV 1.2 Resolved closed
DTV12-77 DTV Issue: Annex G: "OWL/UML Diagrams" DTV 1.1 DTV 1.2 Resolved closed
DTV12-76 There is no 'index origin element' DTV 1.1 DTV 1.2 Resolved closed
DTV12-75 ad-hoc time tables reference the same situation kind for all the time table entries DTV 1.1 DTV 1.2 Resolved closed
DTV12-74 DTV Issue: situation kind1 ends before situation kind2 DTV 1.1 DTV 1.2 Resolved closed
DTV12-73 week-of-year to day-of-year conversions ignore overlap DTV 1.1 DTV 1.2 Resolved closed
DTV12-81 Different 'time period' concept in Annex C DTV 1.1 DTV 1.2 Resolved closed
DTV12-80 member has index in sequence has no result DTV 1.1 DTV 1.2 Resolved closed
DTV12-79 Clause 7.17 is misplaced DTV 1.1 DTV 1.2 Resolved closed
DTV12-78 No indefinite time point sequences DTV 1.1 DTV 1.2 Resolved closed
DTV12-104 Date-Time Issue - Arithmetic Involving Years and Weeks DTV 1.0b1 DTV 1.2 Resolved closed
DTV12-106 DTV Issue: Inconsistency between designs of "Duration Value" an DTV 1.0 DTV 1.2 Duplicate or Merged closed
DTV12-105 Time Point Converts to Time Point Sequence DTV 1.0b2 DTV 1.2 Resolved closed
DTV12-107 DTV Issue: Inconsistency between designs of "Duration Value" and "Time Coordinate DTV 1.0 DTV 1.2 Resolved closed
DTV12-113 DTV Issue: Error in CLIF definition of consecutive sequence DTV 1.0 DTV 1.2 Resolved closed
DTV12-112 DTV 1.1 Issue: Errors in Clause 4 DTV 1.0 DTV 1.2 Resolved closed
DTV12-108 distinguishing business from "internal" concepts DTV 1.0 DTV 1.2 Resolved closed
DTV12-109 DTV issue: situation kind has first/last occurrence DTV 1.0 DTV 1.2 Closed; No Change closed
DTV12-110 DTV issue: missing caption for table in clause 16.9 DTV 1.0 DTV 1.2 Closed; No Change closed
DTV12-111 DTV issue: time point kind DTV 1.0 DTV 1.2 Resolved closed
DTV12-114 DTV Issue: OCL and CLIF Corrections DTV 1.0 DTV 1.2 Resolved closed
DTV12-116 DTV Issue: DTV SBVR Profile is not formally applied DTV 1.0 DTV 1.2 Resolved closed
DTV12-115 new DTV issue: Clause 4 has no semantics DTV 1.0 DTV 1.2 Resolved closed
DTV12-117 Why not fractional months? DTV 1.1 DTV 1.2 Resolved closed
DTV12-122 “stubs” at the beginning and end of a regular time table needed DTV 1.1 DTV 1.2 Duplicate or Merged closed
DTV12-121 what is the year of weekdays? DTV 1.1 DTV 1.2 Resolved closed
DTV12-120 The mythical 'weeks scale' DTV 1.1 DTV 1.2 Resolved closed
DTV12-119 time scale differs from time scale by time offset DTV 1.1 DTV 1.2 Resolved closed
DTV12-118 the Convention du Metre is not a time interval DTV 1.1 DTV 1.2 Resolved closed
DTV12-126 incorrect CLIF definition of time interval plus time interval DTV 1.0 DTV 1.2 Resolved closed
DTV12-125 Strange CLIF axiom for system of units DTV 1.0 DTV 1.2 Resolved closed
DTV12-124 DTV Typo: weekday definitions DTV 1.0 DTV 1.2 Resolved closed
DTV12-128 DTV Issue: time interval begins/ends time interval DTV 1.0 DTV 1.2 Resolved closed
DTV12-127 DTV issue: occurrence/situation kind precedes/ends before occurrence/situation kind DTV 1.0 DTV 1.2 Resolved closed
DTV12-130 DTV Issue: OCL in clause 8.2.1 DTV 1.1 DTV 1.2 Resolved closed
DTV12-129 Status of Annex F: Simplified Syntax for Logical Formulations DTV 1.1 DTV 1.2 Resolved closed
DTV12-133 Issue: misplaced Synonymous Forms on 'time set' DTV 1.1 DTV 1.2 Resolved closed
DTV12-136 definition of compound time coordinate is circular DTV 1.1 DTV 1.2 Duplicate or Merged closed
DTV12-135 Starting week day is a number DTV 1.1 DTV 1.2 Duplicate or Merged closed
DTV12-137 time point sequences specify time periods DTV 1.1 DTV 1.2 Resolved closed
DTV12-134 Gregorian years before 1600 have no starting day DTV 1.1 DTV 1.2 Resolved closed
DTV12-132 add 'time interval starts during time interval' DTV 1.1 DTV 1.2 Resolved closed
DTV12-131 DTV Issue: Unspecified Relationship of OWL files to DTV DTV 1.0 DTV 1.2 Resolved closed
DTV12-140 misplaced paragraph in 10.6.3 DTV 1.1 DTV 1.2 Duplicate or Merged closed
DTV12-139 Figures in 10.7 do not match the text DTV 1.1 DTV 1.2 Resolved closed
DTV12-138 Missing and incorrect text in clause 10.6 DTV 1.1 DTV 1.2 Resolved closed
DTV12-123 DTV Issue: Inadequate guidance for application vocabularies DTV 1.0 DTV 1.2 Deferred closed
DTV11-103 SBVR Convention issues in DTV DTV 1.0 DTV 1.1 Resolved closed
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
DTV11-102 DTV Issue: Included Vocabulary is wrong for Duration Values Vocabulary DTV 1.0 DTV 1.1 Resolved closed
DTV11-101 DTV Issue: incorrect reference schemes for time point sequence DTV 1.0 DTV 1.1 Resolved closed
DTV11-100 Relationship between "equals" and "is" DTV 1.0 DTV 1.1 Resolved closed
DTV11-97 DTV Issue: "unitary concept" missing from clause 4 DTV 1.0 DTV 1.1 Resolved closed
DTV11-96 DTV Issue: Errors in the axioms for ‘time interval1 is before time interval2’ DTV 1.0 DTV 1.1 Resolved closed
DTV11-99 DTV issue: No such verb as 'time scale of granularity' DTV 1.0 DTV 1.1 Resolved closed
DTV11-98 Diagrams in clause 10 refer to concepts in clause 12 DTV 1.0 DTV 1.1 Resolved closed
DTV11-90 Synonymous Forms Captioned as Synonyms DTV 1.0 DTV 1.1 Resolved closed
DTV11-89 incorrect formula for Gregorian year length DTV 1.0 DTV 1.1 Resolved closed
DTV11-88 inconsistent statements on day index DTV 1.0 DTV 1.1 Resolved closed
DTV11-87 DTV Issue: Necessity for "time table" in clause 17.2 DTV 1.0 DTV 1.1 Resolved closed
DTV11-86 incorrect formula for length of successive Gregorian years DTV 1.0 DTV 1.1 Resolved closed
DTV11-85 DTV typos DTV 1.0 DTV 1.1 Resolved closed
DTV11-93 DTV Issue: Reference Scheme problems DTV 1.0 DTV 1.1 Resolved closed
DTV11-92 DTV Issue: Relationship among time points, time scales, and time indices DTV 1.0 DTV 1.1 Resolved closed
DTV11-91 DTV Typo: 'atomic time coordinate of coordinate time coordinate' DTV 1.0 DTV 1.1 Resolved closed
DTV11-81 regular time table is strangely constrained DTV 1.0 DTV 1.1 Resolved closed
DTV11-80 DTV Typo: definition of "Gregorian date" DTV 1.0 DTV 1.1 Resolved closed
DTV11-95 DTV Issue: The definitions of 'starts before' and 'finishes after' are too complex DTV 1.0 DTV 1.1 Resolved closed
DTV11-94 DTV Issue: Figure 8.12 is the wrong diagram DTV 1.0 DTV 1.1 Resolved closed
DTV11-84 DTV Issue: time point sequence includes time point DTV 1.0 DTV 1.1 Resolved closed
DTV11-83 DTV Issue: use of "first element" in scale definitions DTV 1.0 DTV 1.1 Resolved closed
DTV11-78 DTV Typo: weeks scale DTV 1.0 DTV 1.1 Resolved closed
DTV11-77 DTV Typo in clause 9.5 DTV 1.0 DTV 1.1 Resolved closed
DTV11-79 DTV Issue: definition of 'time point kind' DTV 1.0 DTV 1.1 Resolved closed
DTV11-82 drop "Gregorian day of week" DTV 1.0 DTV 1.1 Resolved closed
DTV11-64 time interval1 precedes time interval2 DTV 1.0b2 DTV 1.1 Resolved closed
DTV11-63 Clause 8.3.2 dependency upon clause 10.2 DTV 1.0b2 DTV 1.1 Resolved closed
DTV11-73 DTV Issue: 'second' should be a base unit DTV 1.0 DTV 1.1 Resolved closed
DTV11-72 DTV Issue: Clause 11 depends on clause 9 DTV 1.0 DTV 1.1 Resolved closed
DTV11-71 DTV Issue: figure 8.11 Duration Operations DTV 1.0 DTV 1.1 Resolved closed
DTV11-66 time interval meets time interval is incorrectly defined in SBVR SE DTV 1.0 DTV 1.1 Resolved closed
DTV11-65 Time intervals defined by duration DTV 1.0b2 DTV 1.1 Resolved closed
DTV11-68 DTV Typo: first member DTV 1.0 DTV 1.1 Resolved closed
DTV11-67 DTV Issue: Error in 'time point1 to time point2 specifies time period' DTV 1.0 DTV 1.1 Resolved closed
DTV11-70 DTV Issue: Included Vocabulary is wrong for Duration Values Vocabulary DTV 1.0 DTV 1.1 Resolved closed
DTV11-69 Date-Time Vocabulary typo: index DTV 1.0 DTV 1.1 Resolved closed
DTV11-75 DTV Issue: representation has expression DTV 1.0 DTV 1.1 Resolved closed
DTV11-74 DTV Typo: 'd 71' in the index DTV 1.0 DTV 1.1 Resolved closed
DTV11-76 DTV Issue: Concept terms should not use algebraic symbols DTV 1.0 DTV 1.1 Resolved closed
DTV11-62 Year of Weeks and Year of Weekdays Scales are Misdefined DTV 1.0b1 DTV 1.1 Resolved closed
DTV-24 Clause 5.2 depicts the UML model as informative DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-23 Annex D should be Normative DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-22 Relationship of UML model to SBVR is undocumented DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-21 Relating time to states of affairs DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-10 Date-Time Issue - missing arithmetic on time point sequences DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-20 Date Time Issue - compound quantity value cardinality mismatch DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-19 Date-Time Issue: now is not synonymous with current DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-18 Date-Time Issue: CLIF file should include metadata DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-12 Date-Time Issue - states of affairs and situation models DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-11 Date-Time Issue - Atomic Quantity Value Conversion DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-14 Date-Time Issue: Time Zones DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-13 Date-Time Issue - Examples Related to Timezones DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-9 Date-Time Issue - time of day DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-8 Date Time Issue - time set2 is duration after time set1 DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-15 D0 Should be Quantified DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-17 Date Time Issue: quotation in OCL of UML symbols that include blanks DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-16 CLIF Logic Errors DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-53 ‘Time of Day’ misused DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-39 Confusing text for Gregorian calendar DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-38 UML vs. text inconsistencies in clause 12 DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-28 Corollaries to Axiom D.4 in 8.2.3 are misstated DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-27 Time point subdivision is out of place twice DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-26 DTV Editorial issue: Figures 9-5 and 9-7 should be reversed DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-25 Weekday definitions are inadequate DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-34 DTV time-of-day time point definitions are inaccurate DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-33 DTV Issue: inaccurate formulation of definitions in CLIF DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-35 DTV Issue: There is no smallest time interval DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-30 forever is misdefined DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-29 no syntax for indefinite time periods DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-37 rename 'calendar date' DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-32 Need Profile for UML Stereotypes DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-31 UML Model Should be Vendor-Independent DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-36 Quantity Kind is a categorization type DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-4 Date-Time Issue: Propositions, Situation Models, and Occurrences DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-3 Date-Time Issue - OCL Corrections DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-5 time scale1 differs from time scale2 by time offset DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-7 Date-Time Issue - week of year DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-6 Date-Time Issue - local time DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-41 Definition of Calendar Date DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-40 basic time coordinate concepts are badly described DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-43 Duration vs. Duration Value DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-42 DTV Issue: A calendar day is not a time period DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-44 Need to support infinite and indefinite time constructs DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-46 'Gregorian Month' Confused with 'Gregorian Month of Year' DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-45 Inconsistent Use of ‘Concept Type’ DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-49 Reference to 'conceptual schema' DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-48 time-of-day time point definitions are inaccurate DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-51 'Time Span' is defined twice DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-47 10pm to 2am does not specified a time period DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-50 Next Sequence Position DTV 1.0b1 DTV 1.0b2 Resolved closed
DTV-52 repair heading structure of Clause 16 DTV 1.0b1 DTV 1.0b2 Resolved closed

Issues Descriptions

Introductory text in 11.4 is confused

  • Key: DTV13-103
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The first paragraph of 11.4 contains: "the names of calendar periods are
    homonyms. The multiple meanings of such names can be understood by considering that each such name can refer to a set of
    time points collectively, to any member of such a set, or to a unique time point on a finite time scale." And the following example says similar things.
    This is confused. A term like January refers to either the time point (Gregorian month of year 1) or to one or more time periods/intervals that are instances of it. It is never a set of time points. The January of each year is a different time interval, but the same time point.
    Further, the subsequent text uses Tuesday as an example, while the subclause is about Gregorian months.

  • Reported: DTV 1.2 — Tue, 19 Jan 2016 18:32 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Correct the wording of 11.4 to describe named time points

    The cited text of 11.4 is misleading. A named time point, like any other time point designation, is usually used to refer to the corresponding time intervals. In some usages, it refers to the time point itself. The text is corrected to say this.
    Considering the placement of the text in 11.4, the example of Tuesday is replaced by April.
    Note also that the title of the section is inaccurate - the section is about Gregorian months of year.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Clause 10.5 should be in Clause 13

  • Key: DTV13-101
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 10.5 (Time zones) deals entirely with time-of-day issues and defines important time-of-day concepts. It defines time zones as distinct calendars, but that does not make the content about calendars in general. The entirety of the clause should be moved to clause 13 (time of day).

  • Reported: DTV 1.2 — Tue, 19 Jan 2016 18:15 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Move clause 10.5 to clause 13 and address DTV13-105

    The RTF agrees that the content of clause 10.5 (time zones) is more appropriate to clause 13 (time of day). The text of 10.5 is also somewhat disorganized in presenting the concepts. The text is moved and reorganized with minor editorial changes. It was noted that one concept in the UML diagrams (time of day scale) is not documented in the text, and one concept used in the text (locale) is not in the diagram. These disalignments are also corrected.

    The RTF agrees with Issue 13-105, that 'time offset' is not just a role of duration – it is the characterization of a difference between a calendar and UTC that involves a direction (ahead of or behind UTC) and a duration. The verb that introduces the term – calendar1 differs from calendar2 by time offset – actually refers to a role of 'duration' but 'differs from' is an ambiguous wording. It is replaced by 'calendar1 is duration ahead of calendar2', with the same synonymous forms using + and -. 'time offset' then characterizes the difference as 'ahead' or the inverse 'behind' together with the duration. The resolution of Issue 13-105 revises the concept ‘time offset’ and corrects the formal text that uses it.

    Because Issue 13-105 modifies the text being moved, the revised text is included in the resolution of issue 13-101.

  • Updated: Tue, 12 Jul 2016 14:45 GMT
  • Attachments:

Clause 14 is not about time dissemination

  • Key: DTV13-104
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The second sentence of Clause 14.1 reads: "Many time dissemination services are available; see ftp://ftp2.bipm.org/pub/tai/scale/TIMESERVICES/timeservices.pdf."
    The URI is out-of-date, but some time dissemination practices are just uses of Internet Time, and the previous sentence mentions that. The link should be to the IETF specification.

  • Reported: DTV 1.2 — Tue, 19 Jan 2016 18:38 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    In 14.1, remove the sentence about time dissemination

    The NTP reference should be to the IETF specification. Time dissemination services is not a concern of the DTV specification, and that sentence is removed.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Definition of 'standard time' is inadequate and 'local time' is wrong

  • Key: DTV13-106
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 10.5 defines standard time to be any local calendar that is specified as an offset from UTC. But British Summer Time, for example, is UTC+0100, and it is not typically considered to be a "standard time". The standard time for the UK is GMT (=UTC). Standard time is a specific local calendar that is specified as a UTC offset that is approximately consistent with local sun time.
    Similarly, local time is not about whether it has an offset from UTC, but rather the calendar that is in effect for a given place at a given time.

  • Reported: DTV 1.2 — Wed, 20 Jan 2016 16:41 GMT
  • Disposition: Closed; No Change — DTV 1.3
  • Disposition Summary:

    Correct the definitions of standard time and local time

    The definitions of 'standard time' and 'local time' given in clause 10.5 match the definitions given in the ISO 8601 "source". While these may not be the meanings some users expect, there is no good reason to invent other definitions for the terms.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Characterization of time offset as a role of duration is inconsistent

  • Key: DTV13-105
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 10.5 defines time offset to be a role of 'duration'. But the intent of time offset is to describe the difference between a local time and UTC time at a given instant. That difference is only a duration if we agree that there can be negative durations. Otherwise that difference must be described as a duration and a direction. The latter is what the introductory text describes.

  • Reported: DTV 1.2 — Wed, 20 Jan 2016 16:33 GMT
  • Disposition: Duplicate or Merged — DTV 1.3
  • Disposition Summary:

    Merge to Issue DTV13-101

    The RTF agrees that 'time offset' is not just a role of duration – it is the characterization of a difference between a calendar and UTC that involves a direction (ahead of or behind UTC) and a duration. The verb that introduces the term – calendar1 differs from calendar2 by time offset – actually refers to a role of 'duration' but 'differs from' is an ambiguous wording. It is replaced by 'calendar1 is duration ahead of calendar2', with the same synonymous forms using + and -. 'time offset' then characterizes the difference as 'ahead' or the inverse 'behind' together with the duration.

    Because Issue 13-101 moves the text in question, the revised text is included in the resolution of issue 13-101.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

UML operations are not defined

  • Key: DTV13-13
  • Legacy Issue Number: 16873
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

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

  • Reported: DTV 1.0b1 — Fri, 2 Dec 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Clarify UML operations construction in 5.3

    Clause 5.3 documents the derivation of the UML classes, associations, attributes, association end names, and operations from the SBVR glossary entries. The UML model is not otherwise explicitly documented at all in the text. Such documentation would be largely redundant with the glossary entry text. The RTF therefore sees no need to document the UML operations separately.

    There are some minor inaccuracies in the wording of clause 5.3, and they are corrected here.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Need Informal Definitions or Descriptions

  • Key: DTV13-12
  • Legacy Issue Number: 16934
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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.

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

    Improve wording for Allen relations

    There are multiple aspects to this issue. One is whether SBVR Structured English can be used to convey the needed precision in time concepts and still be intelligible to business persons. A second is about the choice of SBVR SE phrasing in the actual Definitions – can they be made clearer to business readers? The third question is: Which of the concepts and definitions in DTV is even useful for business readers, as distinct from the “ontology” audience that uses the CLIF and OWL versions?
    As stated, the issue is a recommendation for general editorial changes without guidance. The RTF agrees that the text of the definitions of the Allen relations can be improved, and the proposed text does that. But the text even says that the Allen relations are theoretical, and the more common business relationships are defined in the next section.
    Specific issues should be raised for sections that are important to business persons and hard to follow.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Missing subscript in definition of time interval1 ends during time interval2

  • Key: DTV13-83
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.2.4, in the Definition of 'time interval1 ends during time interval2', the last 'time interval' in the definition should have the subscript "2".

  • Reported: DTV 1.2 — Tue, 7 Jul 2015 03:05 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Replace missing subscript on 'time interval1 ends during time interval2'

    Editorial repair.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Inadequate guidance for application vocabularies

  • Key: DTV13-81
  • Legacy Issue Number: 18990
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The Date-Time Vocabulary has multiple concepts about amounts of time (duration, duration value), and locations in time (time interval, time point, time point set, time period, time coordinate), but very little guidance as to which of these concepts should be the basis for application business vocabularies. DTV should add a rationale section or additional commentary in Annex C to explain which concepts should be used for what purposes in business vocabularies.

    Table C.1 has a reference to a concept 'date' that does not exist.

  • Reported: DTV 1.0 — Sun, 6 Oct 2013 04:00 GMT
  • Disposition: Closed; No Change — DTV 1.3
  • Disposition Summary:

    Issue does not reflect revision of Annex C

    This issue was substantially addressed in v1.2 with the rewrite of Annex C as the Guidelines for Business Use. Further work on that Annex may be appropriate, but only if issues that cite specific weaknesses are raised.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

In Annex D.3.2, in the entry for "base unit", the first caption should be "Definition" instead of "Concept Type".

  • Key: DTV13-74
  • Legacy Issue Number: 18803
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In Annex D.3.2, in the entry for "base unit", the first caption should be "Definition" instead of "Concept Type".

  • Reported: DTV 1.0 — Wed, 10 Jul 2013 04:00 GMT
  • Disposition: Closed; No Change — DTV 1.3
  • Disposition Summary:

    Repair paragraph tags in D.3.2

    The Issue is out of date. The paragraph tags in D.3.2 are correct in v1.2.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

DTV 1.2 issue: Ordinals

  • Key: DTV13-75
  • Legacy Issue Number: 19734
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    These errors/typos occur in Annex D.2.6 “Ordinals”, of the dtc/2015-03-02 version of DTV 1.2:

    · The synonym for “eleventh member” is given as “third”; it should be “eleventh”.

    · All the ordinals are given as “General Concept: thing”; they should be “General Concept: member” for consistency with the names of these ordinals. “First member” in Annex D.2. should also be “General Concept: member”. (Comment: “member” is “General Concept: thing” in D.2.2. Making the ordinals “General Concept: member”, clarifies that the ordinals only apply to things that are members of unique sequences, not to things in general.)

  • Reported: DTV 1.1 — Sun, 15 Mar 2015 04:00 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Clarify the "Nth member" concepts in D.2.6

    'member' is a 'role', it is not a 'general concept', so it cannot be the text of a General Concept paragraph. But the concept 'second member' does specialize the (role) concept 'member', which is the point of the issue. The text is changed to state this.

    The clarification concern is valid. The problem is that 'second member' itself has no Definition; and is separated in the text from the verb concept that implicitly defines it. The text is reorganized to place the role declaration immediately before the verb concept to supply a Definition.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Vestigial 'Gregorian week' in Clause 11 Figures

  • Key: DTV13-69
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 11.2, Figure 11.1 contains a 'Gregorian week' class and Figure 11.2 contains a 'Gregorian week of year' class. These no longer exist. The corresponding 'ISO week' and 'ISO week of year' are in clause 12.

  • Reported: DTV 1.2 — Thu, 18 Jun 2015 22:55 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Delete all 'Gregorian week elements from the UML model

    See attached file DTV13-69.docx

  • Updated: Tue, 12 Jul 2016 14:45 GMT

'overlaps' is symmetric not synonymous

  • Key: DTV13-67
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause D.4, in the entry for 'part1 overlaps part2', we find:
    Synonymous Form: part2 overlaps part1
    Definition: There exists a part3 that is part of the part1 and the part3 is part of the part2.

    There are two problems here:
    1) 'part' is not a general concept, and the range of the roles part1 and part2 is not specified. The CLIF says they are both 'thing'. So the fact type should probably be 'thing1 overlaps thing2'. Similarly, we have no idea what a 'part3' might be. The definition should read: 'there exists a thing that is part of thing1 and is part of thing2'.

    2) part2 overlaps part1 is not a synonymous form of 'part1 overlaps part2'. It is the same form. The main entry defines the symbol 'overlaps' between two instances of type 'thing'. Since the placeholders do not appear in a use of 'overlaps', it makes no difference what their spelling is. What is intended here is in fact an "axiom of symmetry":
    Necessity: If a thing1 overlaps a thing2, then the thing2 overlaps the thing1.

    Similarly, in clause 8.2.1, in the entry for 'time interval1 overlaps time interval2', we find:
    Synonymous Form: time interval2 overlaps time interval1
    This is the same problem (s). 'time interval2 overlaps time interval1' is the same form as 'time interval1 overlaps time interval2' because the symbol and its context (the ranges of the roles) are the same. This should also be stated as an axiom:
    Necessity: If a time interval1 overlaps a time interval2, then the time interval2 overlaps the time interval1.

  • Reported: DTV 1.2 — Sat, 6 Jun 2015 00:09 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Replace the synonymous forms for 'overlaps' with necessities.

    As described in the Issue, x1 overlaps x2 and x2 overlaps x1 are the same form. In clause 8.2.1 replace the synonymous form: time interval2 overlaps time interval1 with a Necessity: If time interval1 overlaps time interval2 then time interval2 overlaps time interval1. And similarly for part1 overlaps part2 in D.4.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Indefinite time intervals should not depend on occurrences

  • Key: DTV13-87
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The indefinite time intervals are defined in Clause 16 in terms of occurrences that are not defined. The idea of indefinite time intervals should be in Clause 8, where it is needed for indefinite time point sequences. By defining Eternity to be the time interval that includes all time intervals, and primoridality to start Eternity and perpetuity to end Eternity, the concept can be divorced from occurrences and included in clause 8.

  • Reported: DTV 1.2 — Wed, 8 Jul 2015 22:20 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Define the indefinite time intervals in terms of time interval relationships and move them to Clause 8.

    The RTF agrees that the indefinite time intervals should be defined in clause 8, independently of the occurrence concept. The proposed approach for ‘eternity’ is essentially correct, but the concept ‘primordiality’ should be a unique time interval that starts Eternity.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Use of 'week' vs. 'ISO week' in clause 10

  • Key: DTV13-66
  • Legacy Issue Number: 19744
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    DTV v1.2 changed the model of the 'week' concept to distinguish the 'ISO week' concept. Several vestigial uses of 'week' in clause 10 should be corrected:

    • In clause 10.4, in the entry for finite time scale subdivides time point kind', the Note refers to 'day of week', which should be 'ISO day of week'.
    • In the introduction to clause 10.6, the example 'week 41 day 6' should be 'ISO week of year 41 ISO day of week 6' (really?, this wording has no business use).
    • In 10.6.3, under atomic time coordinate, the example "calendar week 53" should probably be "ISO week of year 53".
    • In 10.6.3, under 'atomic time coordinate uses index', the references to 'week of year' and 'day of week' should use "ISO".
    • In clause 10.7 (Time sets), the introduction twice refers to 'week of year' and 'weekday of year', which should use "ISO"
    • Clause 10.10 makes several references to the "year of weeks" and "week-based year", which should use "ISO"

    Also, the concept 'ISO weekday of year' in clause 12 appears to mean 'day of ISO week-based year', but that characterization in so many words does not appear in the description of the time scale or the time point. The time coordinate may have the (compound) week/day form described in clause 18, or the ungainly form noted above, but the time point only has an index, and the term 'weekday' (without the solidus) is misleading.

  • Reported: DTV 1.1 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Correct references to 'week' terms in Clause 10

    Correct clause 10 as indicated. Revise introduction to clause 10.7. Add a Note to 'weekday of year' in Clause 12.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

missing OCL

  • Key: DTV13-65
  • Legacy Issue Number: 19743
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: Date Time Vocabulary

    Version: v1.2

    Title: missing OCL

    Summary:

    The following DTV axioms have SBVR and CLIF formulations but no OCL formulation

    1. In clause 8.3.2, under ‘duration = duration plus duration’, in Axiom V.1

    2. In clause 8.3.2, under ‘duration = number times duration’, in Axiom V.8, first Corollary

    3. In clause 8.3.2, under ‘duration = number times duration’, in Axiom V.8, 2nd Corollary

    4. In clause 8.3.2, under ‘duration = number times duration’, in Axiom V.8, 3rd Corollary

    5. In clause 16.3, under ‘occurrence occurs for occurrence interval’

    6. In Annex D.2.3, under ‘sequence has index origin value’

    7. In Annex D.3.1, under ‘quantity has quantity kind’

    Note: This is a follow-on to Issue 19462

  • Reported: DTV 1.1 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Supply missing OCL Definitions and Axioms in Clauses 8, 16, Annex D

    The missing OCL text is added. Some entries are reworked to align the formulations. Note that some of the CLIF Axioms only state that the arguments of particular predicates have particular types, which is conveyed by the UML signatures of the operations for OCL.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

merger of separate concepts in 8.2.5

  • Key: DTV13-64
  • Legacy Issue Number: 19742
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 8.2.5 says it is about "time interval sum" and it introduces the concept "time interval plus time interval equals time interval" along with supporting axioms. But it apparently also introduces the concepts "time interval to time interval specifies time interval" and "time interval through time interval specifies time interval", which conceptually have nothing to do with "sum". Further, the UML diagram in Figure 8.8 only shows the 'to time interval' form.

    The merger of these two topics is caused by mis-characterizing "time interval through time interval specifies time interval" as a synonymous form for "time interval plus time interval equals time interval". The two verb concepts are co-extensive, but they are different concepts. The time interval that is specified by t1 through t2 is the same time interval as the sum of t1 and t2 as the sum is defined, but its definition is more like "t1 starts t3 and t2 finishes t3". And 't1 to t2' is a relative of 't1 through t2', and its definition is not related to the sum at all.

    The two concepts 't1 to t2 specifies t3' and 't1 through t2 specifies t3' should not be in 8.2.5 at all. They should be in a separate section, as another way of specifying time intervals in terms of other time intervals – one that is actually used by business people, while the verbs in 8.2.5, 8.2.6 and 8.2.7 are not.

  • Reported: DTV 1.2 — Fri, 17 Apr 2015 04:00 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Make 'time interval1 through time interval2 specifies time interval3' a separate concept

    The task force agrees that the ‘sum’ of two time intervals, and the time interval defined by ‘time interval1 through time interval2’ are distinct. The concepts are not even co-extensive, since the latter requires time interval1 to start no later than time interval2.
    At the same time, the concept ‘time interval1 to time interval2’ is unrelated to ‘sum’. Clauses 8.2.5 (sum), 8.2.6 (complement), 8.2.7 (intersection) all define means of constructing a time interval from two others. ‘time interval1 to/through time inteval2’ is a fourth means, and should be a separate section (8.2.8).

  • Updated: Tue, 12 Jul 2016 14:45 GMT

DTV 1.2 issue: incorrect character styling

  • Key: DTV13-2
  • Legacy Issue Number: 19733
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The following Synonymous Forms have incorrect character styling: although the roles appear to have ‘term’ styles, in fact they are styled in some other way:

    time point2 follows time point1

    time point2 is next after time point1

    time point starts time interval

    time point ends time interval

    time scale of calendar

    time scale on calendar

  • Reported: DTV 1.1 — Mon, 16 Mar 2015 04:00 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Repair the formatting of the cited entries

    Of the cited synonymous forms, all but one were apparently corrected in the formal text of version 1.2. The exception: "time point ends time interval" is repaired here.

    Note: this was corrected by in Ballot #1, but subsequently confused by inconsistencies in the v1.2 convenience documents.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

time interval starts/ends on time point have wrong synonymous forms

  • Key: DTV13-99
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.6, in the entry for 'time interval starts on time point', the Synonymous form reads: 'time point2 starts time point1', which involves roles that are not in the primary wording. And the same error occurs in 'time interval ends on time point'.

  • Reported: DTV 1.2 — Sun, 23 Aug 2015 17:36 GMT
  • Disposition: Closed; No Change — DTV 1.3
  • Disposition Summary:

    The cited text does not appear in 8.6 in v1.2

    The issue is a consequence of a discrepancy between the convenience documents for v1.2. The formal v1.2 specification (formal/15-11-02) does not contain the cited text.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

The Gregorian calendar is not standardized by ISO 8601

  • Key: DTV13-102
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The first paragraph of clause 11.2 reads: "The Gregorian calendar is standardized in ISO 8601, ..." The Gregorian calendar was standardized for international commerce by the Convention du Metre. ISO 8601 only standardizes certain representations of time coordinates.

  • Reported: DTV 1.2 — Tue, 19 Jan 2016 18:19 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Revise 11.2: replace ISO 8601 with the Convention du Metre

    The issue is correct. In the text of 11.2, replace "ISO 8601" with "the Convention du Metre".

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Issue 19172 continued: Missing "exactly" in scale definitions

  • Key: DTV13-27
  • Legacy Issue Number: 19343
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    This issue started with a complaint about the way that misuse of Structured English in various Necessity statements that are of the form “<time point> has <number> of <class”. Then (on 1 Jan 2014) I noticed an additional problem: typically, the “<time point> of <class>” verb concept is missing, so I proposed adding a verb concept “time period has time point”.

    It turns out that this solution is insufficient. It treats a Necessity such as “April has 30 of ‘Gregorian day of month‘” as though it meant “April has 30 of ‘time point‘” – which loses the semantic that the 30 time points that make up April are specifically “Gregorian day of month” time points. (Note: the fact that this is not valid Structured English is the main point of issue 19172).

    To fix this, we need instead to add the following verb concepts:

    · Gregorian year has Gregorian day of year

    · Gregorian year has Gregorian month of year

    · Gregorian month of year has Gregorian day of month

    We also need to change the definitions of the Gregorian months to make clear that they are such. For example, for January, instead of the definition “time interval that has duration 31 days and that starts an instance of a Gregorian year”, we should use “Gregorian month of year that has duration 31 days and that starts an instance of a Gregorian year”. With this change, “January” is still a ‘time interval’ since a ‘Gregorian month of year’ is ultimately a ‘time interval’.

  • Reported: DTV 1.0 — Thu, 17 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — DTV 1.3
  • Disposition Summary:

    Part of the Issue is resolved by Issue 13-25; the rest is incorrect.

    By substituting the actual “bindable targets” given in the Necessity for the corresponding placeholder terms in the Definition of ‘time point has number of time point kind’, the Necessity
    “April has 30 of Gregorian day of month”
    is defined by clause 10.4 to mean:
    the time point kind ‘Gregorian day of month’ has a finite time scale (Gregorian month of days) and there is a time point sequence that is on the finite time scale and that corresponds to each instance of April, and the first time point of the time point sequence is the index origin member of the finite time scale (Gregorian day of month 1), and 30 is the cardinality of the time point sequence.
    In the above, the parenthetical expressions can be inferred from other necessities for the Gregorian month of days time scale.
    Thus, interpretation defined by clause 10.4 is not “April has 30 of time point”, as the issue avers. It is rather a description of the subdivision of April into Gregorian day of month time points. This text has been revised and clarified by the resolution to Issue 19172 (now 13-25), and the proposed additions are unnecessary.

    The last recommendation in the issue is a consequence of a well-known problem with the SBVR-style definitions of concepts that are instances of concept types. The SBVR definition of a concept describes the properties of each of its instances, that is, the Definition of ‘January’ describes each January. The instances of the concept January are time intervals, not Gregorian months of year (as the issue proposes). So the existing definition is consistent with SBVR practice; the proposed definition is not. The concept ‘January’ is itself an instance of Gregorian month of year, and that relationship is described by the Necessity that follows the Definition.
    Thus, no technical change is appropriate. It is not clear to the RTF what editorial notes could be added to avoid creating the misconceptions in the issue. Therefore, no change is proposed.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Date-Time Issue - Formulating Tense and Aspect

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

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

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

    Replace 'state of affairs' with 'situation kind' in E.6 and E.7

    The task force agrees. Note that the Tense and Aspect section is now E.6. The first paragraph of section E.6 apparently captured this issue in the submission or the FTF and was overlooked. The use of 'corresponds to' in clause E.6 is incorrect – the SBVR verb is 'meaning corresponds to thing', not 'thing corresponds to meaning'; but here the DTV verb concept 'proposition describes situation kind' is clearer.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Missing "exactly" in scale definitions

  • Key: DTV13-25
  • Legacy Issue Number: 19172
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Many scale definitions in DTV include a Necessity that some time point "has <number> of <class>" some other time point. The issue here is that correct use of SBVR Structured English would employ the keyword "exactly", as in "has exactly <number> <class>". Examples of this problem occur in the glossary entries are listed below.

    Also, most of these examples quote the <class>, using keyword-style quotes. But the entry for "Gregorian year of months scale" does not quote the <class>. If the documented SBVR-SE style is used, such quotes should not be used.
    Gregorian year of months scale

    common year

    leap year

    January (and all the month definitions, except the one for February)

    week of days scale

    day of hours scale

    day of minutes scale

    day of seconds scale

    hour of minutes scale

    minute of seconds scale

  • Reported: DTV 1.0 — Mon, 30 Dec 2013 05:00 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Replace 'time point has number of time point kind' with 'time point subdivides into time point'

    The Necessities described in the issue use the verb concept ‘time point has number of time point kind’, which is defined in clause 10.4. In that usage, the <number> value plays a verb concept role, and is defined to be the cardinality of a time point sequence. The <number> is not a quantification (which would use ‘exactly’).
    The RTF agrees that the verb concept ‘time point has number of time point kind’ is unusual syntax for a quantifiable relationship between time points, and that the markup of the usages is incorrect. The verb concept is really a description of the structure of a subdivision, as the existing Note for the verb concept says. This revision improves the text by replacing the strange support verb concept with a simpler one, and by correcting all the previous uses.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

DTV Issue: Add Necessity statements to indicate "result" of 3-way verbs

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

    DTV has many verb concepts with three roles, where one particular role is the "result" of the verb concept. Examples are 'time interval1 plus time interval2 is time interval3', 'time interval1 to time interval2 specifies time interval3' (clause 8.2.5), 'time interval1 starts time interval2 complementing time interval3' (clause 8.2.6), 'duration3 equals duration1 plus duration2' and 'duration1 equals number times duration2' (8.3.2), etc.

    Proposal: add to these verb concepts a new Necessity that identifies which role contains the "result". For example, "Necessity: Each number times each duration2 is exactly one duration1."

    Motivations: (1) Add semantic knowledge that is currently not provided by the Date-Time Vocabulary; (2) When mapping DTV to OWL, this would provide the information needed to identify which role is the functional result of the verb concept. Specifically, the object property for the "result" role could be marked as an "functional object property" of the reified class that represents the 3-role verb concept.
    -----------------------------

  • Reported: DTV 1.0 — Mon, 30 Sep 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Add missing necessities for unique results

    The verbs in question are about verbs that specify unique time intervals and durations in various ways. It is important for the UML and CLIF functions that the uniqueness is stated. The uniqueness is stated for all of the basic operations on time intervals. Stating the uniqueness for time interval1 to/through time interval2 is resolved by another issue. The remaining verbs in clause 8 and 9 are addressed here. Other minor errors in the text of clause 9.5 are corrected.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

spec should provide a simple library of datatypes for use in UML and data modeling

  • Key: DTV13-11
  • Legacy Issue Number: 17349
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    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
  • Reported: DTV 1.0b1 — Fri, 4 May 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Revise clause 18 to define datatypes

    The principal DTV concepts that will be represented in software are time interval, time coordinate, duration value, occurrence, and various properties and relationships among time intervals and occurrences. The latter two are Classes and any Class implementation will be a view that incorporates only the desired associations. Time coordinate and duration value will have datatype representations. The representations of these concepts are specified in Clause 18. The text of Clause 18 is modified to describe them as 'datatypes'. In addition, the text of Clause 18 is reorganized and enhanced to reflect the 'datatype' view of representation.

    In the discussion of this issue, it was noted that the Internet Time representations (described in Clause 14) are omitted from Clause 18. The corresponding text is added to clause 18 as an alternative form.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

'begins before' axiom contradicts the definition

  • Key: DTV13-82
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.2.4, in the entry for 'time interval1 begins before time interval2', the Description says the start of time interval1 is before or the same as the start of time interval2, but the Definition is narrower. The Definition also requires the end of time interval1 to be before the end of time interval2. And therefore the axiom:
    Each time interval begins before the time interval.
    contradicts the Definition. The same problems arise with 'time interval1 ends after time interval2'

  • Reported: DTV 1.2 — Mon, 6 Jul 2015 23:13 GMT
  • Disposition: Resolved — DTV 1.3
  • Disposition Summary:

    Replace 'time interval begins before time interval' with 'occurrence occurs before time interval'

    The term ‘begins before’ suggests that the axiom was unintended, but the (only) uses of the verb concept in clause 16.5 and 16.10 require that the axiom is correct. So the term is misdefined and not business-friendly. The sense of the (internal) usage of ‘t1 begins before t2’ is “t1 does not start after t2”, which uses an existing verb concept, which the definitions in clause 16 can use.
    The definitions in clause 16 actually rely on a verb concept ‘occurrence begins before time interval’ that does not exist, while ‘occurrence starts before time interval’ does. So, the simple solution is to rephrase the uses and delete this verb concept altogether. And the same reasoning applies to ‘ends after’.
    The cited definitions in clause 16.5 also use ‘occurrence occurs before time interval’ and ‘occurrence occurs after time interval’, which are not declared, either. Those concepts have obvious business usage, and are added.
    The uses of ‘begins before’ and ‘ends after’ in 16.10 are addressed by Issue DTV13-87.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

The "SBVR-DTV Vocabulary" in clause 4 has no namespace URI. That means it cannot be referenced across a network

  • Key: DTV13-73
  • Legacy Issue Number: 18804
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Description: The "SBVR-DTV Vocabulary" in clause 4 has no namespace URI. That means it cannot be referenced across a network.

    Proposed Solution: Add a "Namespace URI" caption to this vocabulary.

  • Reported: DTV 1.0 — Wed, 10 Jul 2013 04:00 GMT
  • Disposition: Closed; No Change — DTV 1.3
  • Disposition Summary:

    There is no SBVR-DTV vocabulary in DTV v1.2

    The issue is long out of date. It appears to have been resolved in the FTF, and in any case, the concept 'SBVR-DTV vocabulary' was deleted in v1.2.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Unusual use of 'that' in definitions

  • Key: DTV13-26
  • Legacy Issue Number: 19344
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    OMG Specification: Date Time Vocabulary

    Version: 1.0

    Title: Unusual use of 'that' in definitions

    Summary:

    In clause 8.5, the Definition of ‘time scale’ reads:

    “regular sequence that each member of the regular sequence is a time point”

    I see nothing in SBVR Annex C that suggests a meaning for this. I would expect:

    <more general concept> that <verb> <other roles>

    where the ‘that’ is the subject (role 1) of the verb concept wording;

    or

    <more general concept> that <subject> <verb>

    where the ‘that’ is the direct object (role 2) of the verb concept wording.

    But in the given definition, the verb is ‘is’, the subject is ‘each member of the regular sequence’ and the direct object is ‘a time point’. What role does the ‘that’ play? How does this delimit ‘regular sequence’?

    The intention is: “regular sequence such that each member of the regular sequence is a time point”

    or: “regular sequence of which each member is a time point”

    or: “regular sequence (all of) whose members are time points”

    The first is a style that is conventional in mathematics, but perhaps not in business usage. It is not mentioned in SBVR Annex C, but neither of the others is, either. Is this an SBVR SE problem?

    Note: there are several definitions in DTV with ‘that’ playing no clear role in the delimiting verb. This is just one example of the usage.

  • Reported: DTV 1.0 — Thu, 17 Apr 2014 04:00 GMT
  • Disposition: Deferred — DTV 1.3
  • Disposition Summary:

    Defer for resolution of SBVR issue

    The underlying issue is the apparent limitations on the expressiveness of SBVR Structured English. All of the "misuses" of 'that' could be replaced by 'such that', if it were permissible in SBVR SE. Many could be rephrased for business users by permitting qualifier clauses that begin "of which" or "the <noun form> of which" or "whose <noun form>". A corresponding issue has been raised to the SBVR RTF. This issue is Deferred until that issue is resolved.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Date-Time Issue: OCL should be integrated into UML model

  • Key: DTV13-3
  • Legacy Issue Number: 16716
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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.

  • Reported: DTV 1.0b1 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Deferred — DTV 1.3
  • Disposition Summary:

    Merging OCL into the UML model should be automated

    The Task Force agrees that the OCL should be integrated into the UML model. However, in order to avoid duplication of effort and possible inconsistency between the formal files associated with the specification, all of the OCL text in the specification, the OCL file, and the OCL elements of the UML (XMI) file should be created from a common source by an appropriate software application. But the Task Force is unaware of any such tool for modifying the UML XMI file, and lacks the resources to create one.

  • Updated: Tue, 12 Jul 2016 14:45 GMT

Necessities should be independent of placement

  • Key: DTV12-71
  • Legacy Issue Number: 19516
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV

    Version: 1.1

    Source: Ed Barkmeyer, NIST, edbark(at)nist.gov

    Summary:

    In the Date Time Vocabulary v1.0 specification, clause 16.5 contains the following terminological entry:

    individual situation kind has occurrence interval

    Definition: the occurrence interval is the time span of the individual situation kind

    Necessity: The individual situation kind has exactly one occurrence

    ...

    In the Necessity, "the individual situation kind" is intended to refer to whatever plays the 'individual situation kind' role in an instance of the verb concept (wording). But that interpretation can only be made when the Necessity appears in the verb concept entry. SBVR practice is to make the meaning of the Necessity independent of where it is stated. To be consistent with SBVR practice, the above Necessity should read:

    Each individual situation kind that has an occurrence interval has exactly one occurrence.

    There are several Necessities in DTV that use this dubious form of reference. Each of them should be reformulated in the SBVR location-independent style.

  • Reported: DTV 1.1 — Fri, 11 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    After consultation with SBVR experts (see SBVR Issue 19361), the RTF agrees.
    There is a standard pattern to the revised Necessity statements. The pattern is:
    Each <subject> that <rest of verb concept wording> <rest of Necessity>.
    For the example given, the result is:
    Each individual situation kind that has an occurrence interval has exactly one occurrence.
    This pattern is applied to binary verbs, but it does not work well for ternary verbs, and other approaches were used to phrase those Necessities correctly.
    Some of the Necessities about occurrence intervals were redundant, because they were implied by the corresponding Necessities for time intervals.
    Several occurrences of the problem were omitted from this resolution because another issue corrects the same text.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Confusion of Axioms and Verb Concepts for Time Interval operations

  • Key: DTV12-70
  • Legacy Issue Number: 19628
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV v1.1

    Title: Confusion of Axioms and Verb Concepts for Time Interval operations

    Summary:

    In clause 8.2.5, there are two versions of Axiom Sum, but they seem to say mostly the same thing. There is a typo: t2+t2 in the first Axiom Sum.

    The two definitions of 'time interval1 to time interval2 is time interval3' conflict – the first half of each should be a condition.

    In clause 8.2.6, what starts as Axiom Start-complement becomes a verb concept declaration that somehow has a corollary. Similarly Axiom End-complement, and for Axiom Intersection in 8.2.7. This seems to be primarily a text organization problem, but there is no Necessity and no OCL Constraint for each of the Axioms.

  • Reported: DTV 1.1 — Thu, 2 Oct 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    In 8.2.5, remove the duplicate Axioms, rewrite the Definition of ‘sum’ to be the first two ‘Corollaries’, and change the multiple ‘Definitions’ and ‘CLIF Definitions’ of sum to SBVR Necessities and CLIF Axioms.
    In 8.2.5 merge the two partial definitions of ‘time interval1 to time interval2 specifies time interval3’ to one corrected definition.
    In 8.2.6, reorganize the axioms and corollaries to follow the definition of the verb concepts, and correct the SBVR definitions of the verb concepts.
    In 8.2.7, reorganize the axioms and corollaries to follow the definition of the verb concept, and correct the definitions of the verb concept.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Occurrence does not specialize Situation Kind

  • Key: DTV12-72
  • Legacy Issue Number: 19527
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV v1.1

    Title: Occurrence does not specialize Situation Kind

    Summary:

    In clause 16.3, in the entry for ‘occurrence occurs for occurrence interval’, the verb concept is said to have

    General Concept: situation kind occurs for time interval

    This would require that ‘occurrence’ specializes ‘situation kind’, which is not the case. This General Concept declaration should be deleted.

  • Reported: DTV 1.1 — Thu, 17 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Agreed. Delete the General Concept declaration.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: Annex G: "OWL/UML Diagrams"

  • Key: DTV12-77
  • Legacy Issue Number: 19589
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    DTV Informative Annex G contains a set of UML diagrams of the OWL mapping of DTV. There are two problems with this Annex: (1) it is out-of-date with respect to the informative OWL ontologies that were included in DTV 1.1; (2) the set is incomplete with respect to the DTV 1.1 OWL. The diagrams should be updated or the Annex should be deleted.

  • Reported: DTV 1.1 — Thu, 28 Aug 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Since the scope of the Annex is only the supporting concepts in Annex D, as opposed to the DateTime concepts, the RTF determined that its relevance to the DTV specification is marginal. Since it is no longer accurate even for Annex D, the RTF agrees to delete the Annex.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

There is no 'index origin element'

  • Key: DTV12-76
  • Legacy Issue Number: 19590
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The term 'index origin element' is used in several places in clauses 10-13.

    This term is not defined. The term defined in Annex D is 'index origin member', and it should be substituted for all occurrences of 'index origin element'.

  • Reported: DTV 1.1 — Thu, 28 Aug 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees

  • Updated: Wed, 8 Jul 2015 11:40 GMT

ad-hoc time tables reference the same situation kind for all the time table entries

  • Key: DTV12-75
  • Legacy Issue Number: 19652
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Experience with FIBO reveals two problems with the way schedules are defined in DTV:

    1. DTV schedules that are based on ad-hoc time tables reference the same situation kind for all the time table entries. This is a problem because financial contracts that use ad-hoc time tables need to specify a unique situation kind for each entry.

    For example a step-up bond pays different interest rates for different periods. An ad-hoc time table can adequately represent the different periods, but each interest rate needs to be a distinct situation kind – which is not possible in the current design.

  • Reported: DTV 1.1 — Sun, 2 Nov 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees with the problems raised by these issues. Their resolution requires reworking both the DTV ‘schedule’ and ‘time table’ concepts, because:
    • The time table concept was created to support the schedule concept but it does not properly support the business concept of ad hoc schedules. As defined, there are two kinds of ‘time table’ (‘regular’ and ‘ad hoc’) and one kind of ‘schedule’ that has a single general situation kind.
    • What is needed is two kinds of ‘schedule’, one of which associates a single situation kind with a regular time table, and the other associates multiple situation kinds, each with its own time period.
    • Also, the existing ‘regular time table’ is defined as a set of time periods, when what is really needed is a starting time, a repeat count, and a repeat interval.
    To solve these problems, the RTF is forced to entirely replace the original ‘schedule’ design.
    The resolution of issue 19653 is merged into this solution because the two issues are intimately connected. This resolution adds the ‘schedule stub’ idea.
    A verb concept 'time interval1 starts after time interval1' is added to clause 8.2.4 to simplify the definition of 'schedule has earliest time'.
    A synonym is added for DTV ‘situation kind’ to match the designation of the equivalent concept in FIBO.
    A verb concept "set1 is set2 plus element" is added to a new Annex D.2.6 to support the definition of regular schedules.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: situation kind1 ends before situation kind2

  • Key: DTV12-74
  • Legacy Issue Number: 19714
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The definition of “situation kind1 ends before situation kind2” depends upon a verb concept “time interval1 ends before time interval2” that does not exist. Probably it should use “time interval1 ends after time interval2” – and the “situation kind” version should use the same verb symbol for consistency and clarity.

  • Reported: DTV 1.1 — Wed, 28 Jan 2015 05:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agreed to create the synonymous form for “time interval1 ends before time interval2”. The situation kind verb and the related occurrence verb are parallel and both provide the corresponding synonymous form.
    A typographical error in the OCL is also corrected.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

week-of-year to day-of-year conversions ignore overlap

  • Key: DTV12-73
  • Legacy Issue Number: 19650
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 12.5, the very first Necessity reads:
    " Necessity: Each week of year shares the Gregorian year of days scale with each Gregorian day of year."

    According to 10.9 that means that each week of year corresponds to some time point sequence in Gregorian day of year. This is not possible. The week of year scale has 53 time points and any given Gregorian year has either 52 weeks (364 days) or 53 weeks (371 days). So, in a year that has 53 weeks, there must be at least 5 days that have no counterpart.

    Even in a 52-week year, the first and last weeks of the year may include days from the prior or following year. The mapping to day of year can work, but not necessarily to days of the same year; one must consider the repeating aspect, and time point sequences that wrap around the end of the finite scale. For example, week of year 1 can convert to day of year 364, 365, 1, 2, 3, 4, 5, if the year begins on Wednesday. If that is a valid 'time point sequence' on the year of days scale, then the rules given for the conversions in clause 12.5 do not support it.

  • Reported: DTV 1.1 — Thu, 30 Oct 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The Necessity is false. The problem is not overlap; the time point sequence can wrap around the end of the Gregorian day of year scale. The problem is that there is no single time point sequence on the Gregorian year of days that corresponds to the same time intervals as any given week of year (see 10.9). Both Necessities following Figure 12.4 are false. Some of the Examples are true, but only because they fall outside the related time sets. They have nothing to do with sharing the time scale.
    Similarly, the conversion to time sets on the year of days scale is misleading, because the wrap around the end of the Gregorian year of days causes the time points to refer to time periods in different Gregorian years. So, it would be necessary to add additional rules to explain the complex correspondences of the time sets to time intervals.
    The intent of this section cannot be preserved. The generic relationships between the year of weeks and the Gregorian year of days are defined by the year of weeks itself. There are no others. When the Gregorian year is given, the specific correspondences can be determined from the common Gregorian days scale, on which all of them are based.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Different 'time period' concept in Annex C

  • Key: DTV12-81
  • Legacy Issue Number: 19517
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV

    Version: 1.1

    Title: Different 'time period' concept in Annex C

    Source: Ed Barkmeyer, NIST, edbark(at)nist.gov

    Summary:

    In the Date Time Vocabulary v1.1 specification, Annex C contains the following terminological entries:

    fixed period

    Definition: time period that cannot be changed

    ...

    variable period

    Definition: time period that can be rescheduled

    In DTV clause 8.7, a time period is defined to be: time interval that instantiates some time point sequence

    No time interval can ever "be changed" , at least not in the sense of "modified". And similarly, time intervals are unlikely to be "rescheduled". One cannot alter the time interval designated July 25 into some other time interval, nor can one meaningfully reschedule it.

    The intent here seems to be that some kind of schedule entry can be changed or an event can be rescheduled, so that the entry refers to a different time interval. Therefore, the term 'time period', as used in Annex C.3, does not have the meaning given in 8.7.

    SBVR Annex A.2.6 discusses verbs of change and the idea of intensional roles. But in DTV Annex C, fixed period and variable period are apparently being defined as general noun concepts. (On the other hand, 'scheduled start time' is a role that is apparently declared to be a general concept.) It may be that the business use of 'time period' IS often a role of time interval, or a schedule entry that refers to a time interval, and that the DTV use of the term is not business-friendly.

  • Reported: DTV 1.1 — Fri, 11 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    In response to Issues 18990 and 19336, the RTF decided to replace the current EU Rent example in Annex C with some examples drawn from actual business experience. So this issue is moot. Formally, it can be said to be resolved via Issue 19336

  • Updated: Wed, 8 Jul 2015 11:40 GMT

member has index in sequence has no result

  • Key: DTV12-80
  • Legacy Issue Number: 19550
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In Annex D.2.2, the entry for ‘member has index in sequence’ has a main sentential form and two Synonymous noun Forms that are followed by definitions of CLIF functions and OCL operations. The first Note reads:

    The primary verb concept and the synonymous form given above are “sentential forms” that yield a Boolean result.

    A verb concept is not a sentential form and it does not “yield a boolean result”. What is meant is that the verb concept wording is a sentential form, and the corresponding CLIF predicate and the OCL operation yield a boolean result. This pattern must be true of many other verb concepts in the vocabulary. It is strange that it first appears in an Annex.

    The Definition can be simplified to: Some sequence position of the sequence has an index that is equal to the index and has a member that is the member.

    In addition, one of the synonymous forms has inconsistent type setting.

  • Reported: DTV 1.1 — Mon, 28 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Reword the Note to say that the CLIF predicate and the UML/OCL operation derived from the primary wording yield a Boolean result, while those derived from the noun forms return the index value or the member.
    The CLIF and OCL relations for index of member in sequence, however, have no corresponding function. The only things that have indices in a sequence are those that are members of exactly one sequence position in the sequence. So the would-be ‘function’ is not defined on ‘thing’. This ‘noun form’ is therefore deleted. The only use of it is in the definition of ‘time point has index’. That definition is corrected. All the rest of the uses in the text are as ‘index of time point’.
    The wording of an introductory paragraph to Section D.2 (Sequences) is somewhat misleading about the relationship of time points and time intervals to indices. It is revised.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Clause 7.17 is misplaced

  • Key: DTV12-79
  • Legacy Issue Number: 19573
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 7.17 is an overview of the specification structure. It is incorrectly placed at the end of Clause 7 (Rationale). It should be in Clause 6, following 6.3, which gives an overview of the specification.

  • Reported: DTV 1.1 — Mon, 11 Aug 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The issue is correct. The clause was inadvertently separated from Clause 6 when the Rationale section was added. It is moved back to follow 6.3.
    Note: Issue 19483 revises the Figure in clause 7.17 and some of the descriptive text. So, that revision is merged with this Issue.
    Note: Issue 19574 renames the ‘Week Calendar’ package to ‘ISO Week Calendar’ and that change is included in Figure 6.1 below.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

No indefinite time point sequences

  • Key: DTV12-78
  • Legacy Issue Number: 19546
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.7, the definition of time point sequence corresponds to time interval assumes that each time point sequence has a first time point and a last time point. Further, v1.1 introduced the “time points” primordial and perpetuity to provide the means for specifying indefinite time periods. That creates time points to be the first and last time points of the time point sequences that correspond to indefinite time periods.

    We must either redefine the correspondence concept or remove the possibility that there is no first/last time point. The latter simplifies the model. (Note also that most indefinite time periods DO have a last time point, we just don’t know what it is.)

  • Reported: DTV 1.1 — Fri, 25 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees that indefinite time point sequences are problematic. The text should recommend the use of ‘primordial’ and ‘perpetuity’ when those are explicitly intended. But when the first or last time point of a time point sequence is simply “unknown”, that is not clearly appropriate. In any case, however, every time point sequence has a first time point and a last time point, and the text is revised to eliminate features and wording that suggest otherwise.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Date-Time Issue - Arithmetic Involving Years and Weeks

  • Key: DTV12-104
  • Legacy Issue Number: 16675
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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.

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

    The current clause 10.10 (Mixed Base Time Arithmetic) does not address arithmetic on the weeks calendars. The revised text provides guidance. It also repairs minor typos in the text.
    The text below uses terms and concepts adopted by the resolution to Issue 19645 and Issue 19574

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: Inconsistency between designs of "Duration Value" an

  • Key: DTV12-106
  • Legacy Issue Number: 18989
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The concepts 'time coordinate' and 'duration value' serve similar purposes: one defines how time points are represented in terms of calendars, and the other addresses how durations are represented in terms of measurement units. 'Time Coordinate' is defined as a "representation of a time point" in clause 10.6.1, which is fine. In contrast, 'duration value' is defined in clause 9.2 as being either an 'atomic' or 'compound' duration value, with the former having a number and a unit. So 'duration value' is NOT a representation.

    I believe the final design of 'time coordinate' was decided late in the FTF phase after considerable discussion – and the FTF overlooked converting 'duration value' to a similar design. This should be fixed.
    -----------------------------

  • Reported: DTV 1.0 — Sun, 6 Oct 2013 04:00 GMT
  • Disposition: Duplicate or Merged — DTV 1.2
  • Disposition Summary:

    This issue is identical in text to Issue 18991. See the resolution to Issue 18991.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Time Point Converts to Time Point Sequence

  • Key: DTV12-105
  • Legacy Issue Number: 18190
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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.

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

    The RTF agrees that “on time scale” is redundant in the two conversion verb concepts. It is removed, the text preceding the verb concept entry, and the other elements of the entry, are revised to match. There is a corresponding Necessity (which is not stated): Each time point converts to at most one time point sequence/time set on any given time scale. Text in this section that refers to specializations for the Gregorian calendar is revised to refer to clause 11.
    'Gregorian month converts to time point sequence on the Gregorian days scale' is a binary verb concept whose definition should be a use of 'time point converts to time point sequence'. The Definition given is a means of stating a Necessity. And this is also the case with the other two uses of ‘converts to’ in 11.8 and 11.9. Most of the perceived problem is resolved by restating the binary verb concepts more simply, e.g., Gregorian month has Gregorian days sequence, using the ‘converts to’ verb concept in the Definition, and stating the computations as Necessities.
    The currently informal mechanism for relating month-of-year to day-of-year in 11.7 is formalized and used in converting a Gregorian month to Gregorian days.
    Tables 11.1 and 11.2 incorrectly identify the columns as properties of Gregorian month – they are properties of Gregorian month-of-year. The table headings are corrected.
    While the concepts in Section 11.8 and 11.9 are unchanged, the formulations are modified to use the simplified verbs and separate the Necessities.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: Inconsistency between designs of "Duration Value" and "Time Coordinate

  • Key: DTV12-107
  • Legacy Issue Number: 18991
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The concepts 'time coordinate' and 'duration value' serve similar purposes: one defines how time points are represented in terms of calendars, and the other addresses how durations are represented in terms of measurement units. 'Time Coordinate' is defined as a "representation of a time point" in clause 10.6.1, which is fine. In contrast, 'duration value' is defined in clause 9.2 as being either an 'atomic' or 'compound' duration value, with the former having a number and a unit. So 'duration value' is NOT a representation.

    I believe the final design of 'time coordinate' was decided late in the FTF phase after considerable discussion – and the FTF overlooked converting 'duration value' to a similar design. This should be fixed

  • Reported: DTV 1.0 — Sun, 6 Oct 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees that neither a duration value nor a time coordinate is a ‘representation’ in the SBVR sense. Each can have more than one ‘expression’. Rather, the instances of both are “conceptual structures of meaning”. A duration value is the instantiation of a reference scheme for duration. It is a structure of meaning that is interpreted as a definite description of a duration. A time coordinate is a structure of meaning that ‘indicates’ (is interpreted as) a concept that is a category of time interval. The text and the UML model are revised to state these characterizations.
    A reference scheme for the concept ‘time point’ that is actually used in Gregorian calendar time coordinates is (time point kind, index), and this is added to the reference schemes for time point.
    Issue 19547 identifies additional problems with the same sections of clause 10.6. It modifies many of the same diagrams and entries. Therefore the revised text of this issue resolution is merged with that of Issue 19547.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: Error in CLIF definition of consecutive sequence

  • Key: DTV12-113
  • Legacy Issue Number: 19459
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Spec: DTV

    Version: 1.0 and 1.1

    Source: Ed Barkmeyer, NIST

    Summary:

    In Annex D.2.4 of DTV, the CLIF Definition of ‘consecutive sequence’ is:
    (forall (s) (iff ("consecutive sequence" s)

    (and

    (sequence s)

    (forall (sp1)

    (if

    (and

    ("sequence has sequence position" s sp1)

    (exists (sp2)

    ("next sequence position succeeds sequence position" sp2 sp1)) )

    (forall (x1 x2)

    (if

    (and

    ("sequence position has index" sp1 x1)

    ("sequence position has index" sp2 x2))

    (= x2 (+ x1 1)) ))

    )) )))

    This is clearly incorrect. The scope of the quantification “exists (sp2)” ends with the right paren before “(forall (x1 x2))”. So the last occurrence of sp2 is not associated with the quantified variable.

    The correct formulation is:

    (forall (s) (iff ("consecutive sequence" s)

    (and

    (sequence s)

    (forall (sp1 sp2 x1 x2)

    (if

    (and

    ("sequence has sequence position" s sp1)

    ("next sequence position succeeds sequence position" sp2 sp1)

    ("sequence position has index" sp1 x1)

    ("sequence position has index" sp2 x2))

    (= x2 (+ x1 1)) ))

    )))

    The English definitions might also be improved by adding a Description:

    A consecutive sequence is a sequence in which consecutive sequence positions have consecutive indices.

  • Reported: DTV 1.0 — Wed, 11 Jun 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Accept the text correction

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV 1.1 Issue: Errors in Clause 4

  • Key: DTV12-112
  • Legacy Issue Number: 19445
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    DTV 1.1 clause 4 has several errors:

    1. “set includes thing”, “set has element” and “thing is in set” are listed as separate concepts. In SBVR, the first two are synonymous forms of the third.

    2. “intensional definition” is misspelled “intentional definition”.

    3. Many of the glossary entries have leading underscores – a minor typo.

    4. The only definition given for each concept is “

    {adopted concept}

    ”, which is not described anywhere. At least the generalization relationships among the clause 4 concepts should be captured since these relationships affect the meaning of the DTV terms that use them. Furthermore, the lack of these generalization relationships impacts the translation of DTV to OWL. Recommend adding “General Concept:” captions to the following: Concept General Concept
    -------------------------------------------------------------------------------
    categorization type concept type
    characteristic verb concept
    concept type general concept
    definite description intensional definition
    definition representation
    extensional definition definition
    general concept noun concept
    intensional definition definition
    meaning thing
    noun concept concept
    role noun concept
    unitary concept noun concept
    verb concept concept
    verb concept role role

  • Reported: DTV 1.0 — Wed, 4 Jun 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Issue 19463 rewrites Clause 4 to change the form to an ISO style, as opposed to an SBVR vocabulary. The list of additional terms above is incorporated in that revision.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

distinguishing business from "internal" concepts

  • Key: DTV12-108
  • Legacy Issue Number: 19336
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    I am concerned that the sheer size of the Date-Time Vocabulary – the number of concepts – may be a barrier to its use. So I propose that we introduce a distinction between concepts that are intended for business use, and concepts that are defined solely to support other concepts. Examples of these “internal” concepts are the various time scales (e.g. weeks scale), concepts that support calendar computations (e.g. months remainder of month value), supporting concepts (e.g. time set, time point sequence), and the Annex D fundamental concepts of sequences, quantities, and mereology. For someone coming new to the Vocabulary, I think the significant number of these internal concepts detracts from goals such as picking the right concept to use for a particular purpose, or understanding the overall design.

    Specifically, I propose a new caption called “Intended Use:”, with two possible values “business” and “internal”. By default, concepts would be “business use”, so we need only add this new caption to concepts that we decide are “internal use”. This choice of default fits with the SBVR philosophy that business vocabularies should define business concepts.

    When I brought up this idea during last Thursday’s phone call, Donald suggested using Notes. This is certainly possible, but I think there’s value in making this a little more formal. I think tools could use this to simplify things for business users by optionally limiting what is shown to them. Introducing an explicit caption and restricting the possible values used with the caption will work better for that purpose than free-form text in the existing Note caption. The downside of introducing a new caption is an implied need to extend the SBVR XMI format.

  • Reported: DTV 1.0 — Tue, 15 Apr 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    This resolution incorporates the resolution for issue 18990 (business users need better guidance for applying DTV concepts). The resolution adopts these measures to address these issues:
    1. Adds new convenience concepts with the intent of better supporting "calendar expressions". These convenience concepts build on existing DTV infrastructure.
    2. Replaces informative Annex C ("EU-Rent Date-Time Example") with a new version that:
    a. Adds a discussion of how to formulate complex calendar expressions, such as "the third Tuesday of each month".
    b. Provides a table of DTV concepts recommended for business use.
    3. Separates Annex C into a stand-alone document intended to enable business users to apply DTV without referencing the main normative document.
    Rather than identifying the intended use of business concepts within the normative text, the new table in Annex C provides a comprehensive list of business-oriented DTV concepts.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV issue: situation kind has first/last occurrence

  • Key: DTV12-109
  • Legacy Issue Number: 19424
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Clause 16.4 has a pair of verb concepts: “situation kind has first/last occurrence. Distinguishing between uses of these verb concepts is impossible, since they have the same verb symbol and role types. For example, does a rule that refers to “the time interval of the launching of the SpaceX Dragon” mean the first occurrence of the launching or the last occurrence?

    Suggestion: make the keywords “first” and “last” part of the verb symbols rather than the role names.

  • Reported: DTV 1.0 — Tue, 20 May 2014 04:00 GMT
  • Disposition: Closed; No Change — DTV 1.2
  • Disposition Summary:

    The example “the time interval of the launching of the SpaceX Dragon” does not use the verb concept wording ‘situation kind has first/last occurrence’ at all. The normal use will be in the noun form: “the first/last occurrence of launching the SpaceX Dragon”, and there is no ambiguity.
    Technically, the words ‘first occurrence’ and ‘last occurrence’ are part of the verb symbols. In the SBVR notation, the role ‘first occurrence’ is shown as a noun concept, but it is not a placeholder – the role term will appear verbatim in every use of the verb concept wording (in either form). The SBVR notation is confusing, but there is no ambiguity in the usage, just as there is no ambiguity between ‘set has cardinality’ and ‘set has element’. This is an SBVR notation issue, not a DTV issue.
    Revised Text:
    none
    Disposition: Closed, No Change

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV issue: missing caption for table in clause 16.9

  • Key: DTV12-110
  • Legacy Issue Number: 19425
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The table at the end of clause 16.9 should have a caption.

  • Reported: DTV 1.0 — Wed, 21 May 2014 04:00 GMT
  • Disposition: Closed; No Change — DTV 1.2
  • Disposition Summary:

    The caption is supplied and the reference is corrected.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV issue: time point kind

  • Key: DTV12-111
  • Legacy Issue Number: 19432
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The concept ‘time of day’ in clause 10.3 is supposed to be a ‘time point kind’ per the resolution of issue 19319. If that’s correct, ‘time of day’ is missing “Concept Type: concept type”. But ‘time point kind’ has a Necessity “Each time point kind has at most one time scale” – and ‘time of day’ has multiple time scales.

    It is not at all obvious, from their definitions, that clause 10.3 ‘calendar year’ and its siblings, are ‘time point kinds’. Either the definitions should make that clear, or Notes should be added to clarify these concepts.

  • Reported: DTV 1.0 — Thu, 22 May 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    DTV v1.1 says that ‘time point kind’ is a categorization type and thus a concept type.
    The intent of ‘time point kind’ is ‘category of time point that characterizes exactly the time points on some time scale. ‘time of day’ has no time scale –not all of its instances are on any given time scale. But it also has no granularity, which violates the second Necessity in the section. All of the uses of ‘time point kind’ intend that it is associated with exactly one time scale. The definition and the verb concept should be modified to convey that intent.
    With this narrower definition, ‘calendar day’ and its siblings are not ‘time point kinds’.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: OCL and CLIF Corrections

  • Key: DTV12-114
  • Legacy Issue Number: 19462
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Please register a DTV issue for this. All of these errors show up in dtc/2014-06-02, the June 10 version of the RTF 1.1 convenience document:

    1. In clause 8.2.4, under “time interval1 begins before time interval2” and “time interval1 ends after”, the OCL after the Necessity should be labelled “OCL Constraint” rather than “OCL Definition”.

    2. In clause 8.2.5, under “time interval1 plus time interval2 is time interval3”, the fourth CLIF definition does not match the fourth SBVR definition.

    3. In clause 8.3.3, under “time interval has particular duration”, the OCL for the first and second Corollaries of Axiom D.4 both have “OCL Definition” sections that are complete rubbish and should be removed. The “OCL Constraint” paragraphs for each of these are correct, but are missing “inv:”.

    4. In clause 16.6, the OCL Definitions for ‘situation kind1 starts before situation kind2’ and ‘situation kind1 ends before situation kind2’ have the correct content, but are for ‘situation kind1 precedes situation kind2’. The first line of each definition should be reworded.

    5. There are numerous places that have CLIF Definitions or Constraints without corresponding OCL Definitions or Constraints. The whole document should be reviewed to ensure consistency between the CLIF and OCL.

  • Reported: DTV 1.0 — Wed, 11 Jun 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    These entries in 8.2.4 are modified by Issue 19431.
    2. Section 8.2.5 is modified by Issue 19628
    3. The OCL under “time interval has particular duration” is corrected below.
    4. The OCL in clause 16.6 is corrected by Issue 19714.
    5. Some missing OCL is not supplied by this resolution. A separate issue is raised to address specific instances.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: DTV SBVR Profile is not formally applied

  • Key: DTV12-116
  • Legacy Issue Number: 19483
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV v1.1

    Title: DTV SBVR Profile is not formally applied

    Source: Pete Rivett, Adaptive (for the AB)

    Summary:

    In order for the SBVR Profile elements to be applied to model elements in the UML model, the containing package must Apply the Profile. The DTV UML model (DTV/v1.1/dtv-uml.xml) does not include any Profile Application for the SBVR Profile

  • Reported: DTV 1.0 — Fri, 20 Jun 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Correct the UML model. Replace Figure 7.3 to show the profile application. Add text to 7.17 to describe it.
    Clause 7.17 is moved into Clause 6 by the resolution to Issue 19573. Accordingly, the revised diagram and text for this issue is merged into the text moved to clause 6.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

new DTV issue: Clause 4 has no semantics

  • Key: DTV12-115
  • Legacy Issue Number: 19463
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    None of the concepts listed in Clause 4 have any semantics other than “

    {adopted concept}”, yet other aspects of DTV depend upon the “missing” semantics. For example, the Necessity “Each absolute time point corresponds to exactly one time interval.” appears in clause 8.5. This depends upon “meaning corresponds to thing” via the fact that ‘absolute time point’ is a concept because ‘time point’ is a concept type. But clause 4 does not show that ‘concept’ is a category of ‘meaning’, so the relationship among these is missing in DTV. This particularly matters when translating DTV to OWL, since “{adopted concept}

    ” has no semantics. Note that the symbol “

    {adopted concept}” is not defined either in SBVR-SE or DTV clause 5.



    Recommendation – adopt one of these two solutions:

    1. Formally specify the meaning of “{adopted concept}

    ”.

    2. Duplicate the entire glossary entries of the adopted concepts from SBVR.

    3. Add “General Concept” captions to these adopted concepts to capture the primary SBVR type hierarchy.

  • Reported: DTV 1.0 — Wed, 11 Jun 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees that the form of Clause 4 is unsatisfactory.
    SBVR does not specify what the form of an excerpt from another vocabulary, including selective adoption of terms should be. Further, the SBVR RTF does not agree that the form of Clause 4 is an appropriate form for a vocabulary. Therefore, the RTF determined that the form of Clause 4 should be consistent with ISO practice, which is to identify the source standard and cite the terms adopted from it. This requires the reader to be familiar with the source standard (SBVR), and that is not an unreasonable requirement for a reader of DTV.
    Clause 4 is rewritten in ISO style, and not as an SBVR vocabulary.
    Issue 19445 identifies a number of missing concepts in Clause 4, and those are incorporated in the revised text below.
    The RTF also notes that the term ‘business designation’ is not an SBVR term. The title of the DTV Index should be Index of Date Time Designations.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Why not fractional months?

  • Key: DTV12-117
  • Legacy Issue Number: 19531
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 9.3, in the entry for 'duration value equals number times duration value', we find the Necessity:

    Necessity: If duration value1 is a nominal duration value and the number is fractional then the time unit of each atomic duration value of the duration value is not ‘month’ and the fractional part of the number is ¼, ½, 2/4, or ¾.

    This Necessity, the four Necessities that follow, and the Note that follows them, are constraints on the number part of a nominal duration value. They are not necessities about scalar multiplication. At best all of this should be moved to 9.2.3.

    This necessity, however, is unnecessarily restrictive, and appears to be utterly inappropriate. 1/3 year is 4 months, 1/6 year is 2 months, and 1/12 year is 1 month, and their multiples are multiples of months, but they are apparently "not common in business usage". Moreover, in estimating a contract, why couldn’t one multiply a standard duration estimate stated in months by 1.2 to allow for some delaying factor? And similarly, if we average seven durations stated in years, the multiplier is 1/7. Business analytics will generate fractional multiples of months and years. Why should DTV disallow them?

    The Note provides the underlying motivation:

    Note: This specification defines only the fractional nominal duration values ¼ year, ½ year, 2/4 year, and ¾ year because these are in common business use and they equal an integral number of months. This specification does not support any fractional 'month' duration values

    because such fractions are not in common use [which is false] and because they are not equal to an integral number of years or days [which is the real reason].

    Integral number of months or years are not equal to an integral number of days, either. But, per 9.2.3, they correspond to time sets (in days), while a fractional number of either does not. How important is this?

  • Reported: DTV 1.1 — Fri, 18 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees that the cited Necessity is an unnecessary constraint. It is deleted, and the subsequent Note is revised.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

“stubs” at the beginning and end of a regular time table needed

  • Key: DTV12-122
  • Legacy Issue Number: 19653
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    DTV schedules that are based on regular time tables need a way to model “stubs” at the beginning and end of a regular time table. These stubs are time periods that fall immediately before or after the time span of the regular time table. They capture any special handling that is required before the start or after the end of the regular portion of the schedule.

    A typical financial example is a home mortgage where payments are due at the start of each calendar month. If the mortgage is initiated in the middle of a calendar month, then there will be an initial payment, covering the period to the beginning of the next calendar month. Similarly, there may be a final payment for the days after the last monthly payment. As currently defined, a DTV schedule that uses a regular time table can model the regular monthly mortgage payments. But DTV has no provision for the “stub” initial and final payments.

    These two problems should be fixed in order to make DTV schedules usable for typical financial contracts.

  • Reported: DTV 1.1 — Sun, 2 Nov 2014 04:00 GMT
  • Disposition: Duplicate or Merged — DTV 1.2
  • Disposition Summary:

    The RTF agrees to add the requested feature. The resolution is merged with that of issue 19652 since the latter replaces the affected clause.

    Disposition: Merged (see Issue 19652)

  • Updated: Wed, 8 Jul 2015 11:40 GMT

what is the year of weekdays?

  • Key: DTV12-121
  • Legacy Issue Number: 19645
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: Date Time Vocabulary v1.1

    Title: what is the year of weekdays?

    Summary:

    In clause 12.2, the year of weekdays is defined as:

    Definition: the finite time scale that has granularity 1 day and that has cardinality 366 and that repeats over the year of days scale

    Since the year of days also has 366 time points, it is impossible that the year of weekdays can repeat over it. The intent must be that it repeats over the Gregorian days scale. But that also describes the year of days scale. So it is inadequate.

    The Necessity provides the real delimiting characteristic:

    Necessity: Each time interval that is an instance of the first time point of the year of weekdays is a Monday and is an instance of a day of year that has an index that is less than 8.

    Now, if the intent is that the year of week days goes from the first Monday of one year to the Sunday before the first Monday of the following year (which is not at all clear from the above), then the scale must have 371 (7 x 53) time points, because a year that starts on a Monday ends on a Monday, and the first Monday of the following year is 6 days later.

    This structure has no relationship to the year of weeks calendar, because the year of weeks starts with the Monday of the week that contains the first Thursday, and 3 times in 7 years, the year of weekdays will begin in week of year 2.

    So, what (and why) is the 'year of weekdays'?

  • Reported: DTV 1.1 — Tue, 21 Oct 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The year of weekdays is intended to provide a subdivision of the “week-based year” that is defined by the year of weeks time scale, in order to support relative time coordinates of the week-day form. For that intent, the existing Definition and Necessity are incorrect.
    The ISO week-based year concept is introduced in parallel to the Gregorian year, and the weekday of year concept is then defined as a “day of ISO week-based year”.
    The revised text below incorporates terms from the resolution to Issue 19574.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

The mythical 'weeks scale'

  • Key: DTV12-120
  • Legacy Issue Number: 19574
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    DTV defines the indefinite 'weeks scale' in clause 12.2 as follows:

    Definition: indefinite time scale of granularity 'week' and of 'calendar week' time points

    Note: No special meaning is assigned to the indices of calendar weeks on the week scale. Therefore, no index origin element or index origin value is specified for this time scale.

    It then defines calendar week as follows:

    Definition: time point that is on the weeks scale and that is defined by a given calendar as 7 consecutive calendar days

    Note: ISO 8601 adds “starting on a Monday” to this definition. This vocabulary drops that phrase because it is culture-specific.

    The net effect of these is that weeks are some sequences of 7 days that are determined by a calendar. We don’t know where any such sequence begins, or what day-of-week it begins with. There is no significance to the indices because none of them is defined to refer to any particular point in time. So, DTV does not define a specific ' weeks scale' at all.

    Now, clause 12.1 says: "References to specific weeks are by week of year coordinate. This specification follows [ISO 8601] in defining 'Monday' as the first day of the week." This contradicts the above. But it does confirm that the finite 'year of weeks' scale is the only well-defined scale whose granularity is a week.

    Then in 12.4 we find this entry:

    year week coordinate indicates time point sequence

    Definition: the Gregorian year coordinate and the week of year coordinate of year week coordinate jointly specify a time point sequence of Gregorian days

    Note: Unlike other time coordinates, this one indicates a time point sequence, not a time point. This is because a year week coordinate means a sequence of calendar days rather an individual time point on some time scale.

    So a 'year week coordinate' does not refer to a 'week' on any 'weeks scale' . Now, since it does not indicate any time point, a year-week coordinate is NOT a time coordinate.

    The presented model is incomplete and inconsistent. The underlying model anchors a weeks scale to Gregorian days – every instance of a Gregorian day instantiates a particular day-of-week; and the relationship to Gregorian years is dependent on choosing Monday as the first day of week. It is absolutely necessary to anchor some day-of-week to some event or time interval, in order to have any idea which Gregorian days are Mondays. Somewhere in the text, it is mentioned that January 1, 2000 is a Saturday. (More useful is the fact that January 1, 1601 is a Monday.) And that, together with the assertion that Monday is the first day of a week-of-year, defines a weeks scale, except for assigning an index to the week containing January 1, 2000 (or 1601).

  • Reported: DTV 1.1 — Tue, 12 Aug 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The underlying problem here was the unwillingness of the FTF to commit to Monday as the first day of the week, as indicated in the cited Note. The assertion in 12.1 did not represent consensus of the RTF. As a consequence, the Week Calendar Vocabulary, and most of the terms introduced in the section, are now prefixed by “ISO” to distinguish them from weeks calendars that choose other conventions for the first day of the week. At the same time, the neutral concepts ‘calendar week’ and ‘week period’ are retained and moved to Clause 10 to support the original purpose of allowing other choices for first day of week.
    Establishing Monday as day of week 1 enables the specification of a reference time period for an index origin member for the indefinite weeks scale, choosing Monday, January 3, 2000, with an index consistent with the Gregorian day numbering.
    Aligning the Gregorian calendar with the weeks calendar eliminates the need for the verb concept ‘year week coordinate indicates time point sequence’ and the related ‘starting week day’ idea, which are deleted. In its place, we create the ‘starting week’ concept, which is parallel to ‘starting day’. This enables the correct axioms (Necessities) for the year of weeks and year of weekdays scales.
    Some related errors in terminology or arithmetic are also corrected.
    The RTF determined in resolving Issue 19525 that the definition of ‘starting day’ should be functional and the calculation should be a Necessity. The same idea is applied to ‘starting week’.
    Issue 19034 recommended editorial corrections to the terms for day of week time points. These are included in the modifications to the (ISO) day of week entry below.
    Issue 19526 asked for corrections to the description of ‘starting weekday’, which this resolution deletes. But the definition of ‘starting week’ requires the notion ‘first Thursday’, which was embedded in the ‘starting week day’ concept. So the revised text carries the intent of Issue 19526 forward.
    The resolution to Issue 19645 modifies the entry for the year of weekdays scale and incorporates text changes related to this issue. It also adds the concept ISO week-based year, which is mentioned in the revised introductory text below.
    The resolution to Issue 19650 deletes section 12.5. Nomenclature changes in 12.5 that are related to this issue are therefore omitted below.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

time scale differs from time scale by time offset

  • Key: DTV12-119
  • Legacy Issue Number: 19572
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 10.5, Figure 10.7 is titled Time Zones, and it shows a verb concept: “time scale differs from time scale by time offset”. This verb concept is in the UML model (in Time Infrastructure), but does not appear anywhere in the text of DTV v1.1. It appears to have been replaced by ‘calendar1 differs from calendar2 by time offset’ in Figure 10.8. But Figure 10.7 shows several other concepts that are defined in clause 10.5, and the definition of ‘local calendar’ refers to a time scale that “differs from the UTC day-of-hours time scale by a given time offset”, which appears to use the phantom verb concept.

  • Reported: DTV 1.1 — Thu, 7 Aug 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The UML diagram will be realigned with the text. The definition of ‘local calendar’ and the definitions of time coordinates ‘with time offset’ are modified to use the documented verb concept ‘calendar1 differs from calendar2 by time offset’.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

the Convention du Metre is not a time interval

  • Key: DTV12-118
  • Legacy Issue Number: 19566
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In DTV clause 11.2, the entry for Convention du Métre contains:

    Definition: time interval of the signing of the Convention du Métre

    Necessity: The Convention du Métre is at 20 May 1875.

    These are inconsistent. The Necessity uses an undefined verb concept 'time interval is at time interval'.

    It was intended that the Necessity uses 'occurrence is at (during) time interval'. The signing of the treaty is not a time interval; it is an event, an occurrence. The important fact is that the signing event occurred within the day, month and year denoted by 20 May 1875.

    The conventions for establishing which time interval was named 20 May 1875 were established at that time by observation of noon at the Greenwich observatory. That was used as the basis for definition of Gregorian days until 1972, when it was replaced by Universal Coordinated Time (UTC). By convention, 24-hour periods with a midpoint at Greenwich noon might also be used to define Gregorian days before 1875, although actual approaches were different. Without specifying these conventions as well, the concept Gregorian day is not defined by the date of the Convention du Métre. There are several thousand distinct time intervals that encompass the signing of the treaty and have a duration of 86400 seconds.

  • Reported: DTV 1.1 — Fri, 1 Aug 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The Convention du Mètre is intended to be an occurrence. Inaccurate references should refer to the Gregorian day of the signing, which is properly defined as the 24 hours beginning at midnight as determined by Greenwich Mean Time from 1884 to 1972 and by UTC thereafter.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

incorrect CLIF definition of time interval plus time interval

  • Key: DTV12-126
  • Legacy Issue Number: 19467
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.2.5, the verb concept 'time interval1 plus time interval2 is time interval3'

    has 4 CLIF Definitions. Actually, each of these is an Axiom and together they make up a definition of sorts.

    Further , each of them uses 'iff' incorrectly. The first has the form:

    (forall (t1 t2 t3)

    (if

    (or

    ("time interval1 is before time interval2" t1 t2)

    ("time interval1 properly overlaps time interval2" t1 t2))

    (iff

    ("time interval1 plus time interval2 is time interval3" t1 t2 t3)

    (and

    ("time interval1 starts time interval2" t1 t3)

    ("time interval1 finishes time interval2" t2 t3))

    )))

    It should be:

    (forall (t1 t2 t3)

    (if

    (and

    ("time interval1 plus time interval2 is time interval3" t1 t2 t3)

    (or

    ("time interval1 is before time interval2" t1 t2)

    ("time interval1 properly overlaps time interval2" t1 t2)))

    (and

    ("time interval1 starts time interval2" t1 t3)

    ("time interval1 finishes time interval2" t2 t3))

    ))

    and similarly for the others.

  • Reported: DTV 1.0 — Wed, 11 Jun 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The suggested text is no improvement; the Definition remains fragmented, and it loses the conditional equivalences. The OCL Definition is a definition. The others aren’t. As the issue says, the 4 “CLIF Definitions” are axioms. They should be identified as such.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Strange CLIF axiom for system of units

  • Key: DTV12-125
  • Legacy Issue Number: 19466
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Annex D.3.2 contains the following axiom for 'system of units is for system of quantities':

    Necessity: Each system of units is for exactly one system of quantities.

    CLIF Axiom:

    (forall (("system of units" "system of units"))

    (= (count ("system of units is for system of quantities" "system of units")) 1))

    I'm not sure what this is supposed to mean. The conventional form would be:

    (forall ((sou "system of units"))

    (exists ((soq "system of quantities"))

    (and

    ("system of units is for system of quantities" sou soq)

    (forall (soq2)

    (if ("system of units is for system of quantities" sou soq2)

    (= soq2 soq) ))

    )))

    Note also that there is no OCL form of this axiom.

  • Reported: DTV 1.0 — Wed, 11 Jun 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Replace the text as suggested. Add the OCL form.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Typo: weekday definitions

  • Key: DTV12-124
  • Legacy Issue Number: 19034
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The weekday definitions in clause 12.4 have incorrect definitions. They say that "Monday", etc., are kinds of "day of week 1", etc. But there is no object type called "day of week 1" – the styling is wrong. "Day of week" should be styled "term", and "1" should be styled "name". The intended meaning is "day of week" number 1.

  • Reported: DTV 1.0 — Sun, 27 Oct 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    In resolving Issue 18991, the RTF decided that notations of the form
    <time point kind><index>, such as ‘day of week 1’,
    are abbreviations of definite descriptions of the form
    “<time point kind> that has index <index>”, such as
    “day of week that has index 1”. These abbreviations are complex expressions used as designations for the time points defined by the definite descriptions. The notation is used in many places in the specification, and is explained in the revised text for Issue 18991.
    Accordingly, the styling recommended in the issue is correct.
    The day of week definitions are modified by the resolution to Issue 19574, which also corrects the formatting of the notation.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: time interval begins/ends time interval

  • Key: DTV12-128
  • Legacy Issue Number: 19431
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Clause 8.2.4 contains two verb concepts that make no sense, and the descriptions added by issue 18253 do not match their definitions. These verb concepts should be removed, since there are others that address the requirements:

    · time interval1 begins time interval2

    · time interval1 ends time interval2

  • Reported: DTV 1.0 — Thu, 22 May 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees that these verb concepts were left from a misunderstanding of business requirements. Other issues involve additions and modifications to verb concepts that eliminate any value of these. They will be deleted.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV issue: occurrence/situation kind precedes/ends before occurrence/situation kind

  • Key: DTV12-127
  • Legacy Issue Number: 19423
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Clause 16.4 has two verb concepts that appear to mean the same thing: ‘occurrence1 precedes occurrence2’ and ‘occurrence1 ends before occurrence2’.

    Clause 16.6 has two verb concepts that appear to mean the same thing: ‘situation kind1 precedes situation kind2’ and ‘situation kind1 ends before situation kind2’.

    Suggest making one of each pair a synonymous form of the other.

  • Reported: DTV 1.0 — Wed, 21 May 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    [NOTE: This replaces the resolution of this issue in Ballot 8]
    This is a misunderstanding. An occurrence A precedes an occurrence B if A ends before B starts. But A could start before or after B starts and end before B ends. The verb concept only compares the two ending times. The existing example reflects this, The text is clarified.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: OCL in clause 8.2.1

  • Key: DTV12-130
  • Legacy Issue Number: 19703
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The only OCL Constraint in DTV clause 8.2.1 reads:

    context: _'time interval'

    inv: 'time interval'.'time interval1 is proper part of time interval2'-->notEmpty()

    It should be:

    context: _'time interval'

    inv: self._'time interval1 is proper part of time interval2'-->notEmpty()

    (The first word after the “inv:” in the second line should be “self”, not “_’time_interval’”.)

  • Reported: DTV 1.1 — Wed, 7 Jan 2015 05:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees that the OCL is incorrect. Interpretation of the corrected OCL, however, seems to require any conforming M0 population of the UML/MOF model to be infinite, in that each ‘time interval’ object must have different ‘proper part’ time interval. The intent of the Axiom is that no time interval can be declared or assumed to be atomic, but in any given model population there will be time intervals that have no proper part in the population. The proposed OCL constraint would make such a population invalid.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Status of Annex F: Simplified Syntax for Logical Formulations

  • Key: DTV12-129
  • Legacy Issue Number: 19579
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    First, the notation introduced in Annex F is used nowhere in the DTV v1.1 specification. It was formerly used in Annex that was revised in DTV v1.0. The title of Annex F is confusing for DTV, since DTV provides normative logical formulations in CLIF and OCL. The intent is to describe SBVR logical formulations, for which DTV provides normative expressions in SBVR Structured English.

    Second, the Annex specifies a notation for SBVR logical formulations. If it is to have value, the notation should be specified in the SBVR specification. In any case, this Annex should be considered for adoption by the SBVR RTF (as the DTV FTF recommended). Indeed, the SBVR Logical Representation of Meaning clause might well profit from the ability to express examples in this form. There are some technical defects in the Annex F specification, but these could be remedied by the SBVR RTF, whereas specifications for the representation of SBVR are out of scope for the DTV RTF.

    Finally, the text of Annex F begins: “The table below is kindly provided by Don Baisley of Microsoft Corp.” This sentence is entirely inappropriate, and raises intellectual property concerns. If the Annex is retained, this sentence must be deleted. Don Baisley is properly included in the acknowledgements in 6.4, but the specification is the work of the submitters and the editing Task Forces, and this Annex is presumably not intended to be an exception.

  • Reported: DTV 1.1 — Thu, 14 Aug 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees that the Annex should not be a part of the Date Time Vocabulary. The Issue of incorporating in SBVR has been raised to the SBVR RTF, noting that the specification in Annex F was formally adopted by the OMG.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Issue: misplaced Synonymous Forms on 'time set'

  • Key: DTV12-133
  • Legacy Issue Number: 19524
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV v1.1

    Title: misplaced Synonymous Forms on 'time set'

    Summary:

    In DTV v1.1, clause 10.7, the two synonymous forms under ‘time set’

    Synonymous Form: time set1 equals time set2

    Synonymous Form: time set1 = time set2

    should be under ‘time set1 is equivalent to time set2’

  • Reported: DTV 1.1 — Wed, 16 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Agree. Editorial repair

  • Updated: Wed, 8 Jul 2015 11:40 GMT

definition of compound time coordinate is circular

  • Key: DTV12-136
  • Legacy Issue Number: 19529
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 10.6.3, the definition of 'compound time coordinate' is:

    Definition: time coordinate that combines more than one time coordinate

    and the definition of 'compound time coordinate combines atomic time coordinate' is:

    Definition: the atomic time coordinates jointly specify the compound time coordinate

    That makes them both circular. Prefer something like:

    compound time coordinate

    Definition: time coordinate that is a set of atomic time coordinates that jointly indicate a time point

    compound time coordinate combines atomic time coordinate

    Definition: the atomic time coordinate is an element of the compound time coordinate (set)

    These definitions match the first Necessity under the verb concept.

    The 'set' makes the second Necessity redundant.

    The third Necessity is misstated: it compares a time coordinate to a time scale.

  • Reported: DTV 1.1 — Fri, 18 Jul 2014 04:00 GMT
  • Disposition: Duplicate or Merged — DTV 1.2
  • Disposition Summary:

    The circular definitions are resolved more or less as suggested, and the related Necessities are revised.
    Because of other changes to the descriptions of compound time coordinates that affect the same definitions, and related changes to the UML diagrams, the revised text for this issue is merged with Issue 19547.
    Revised Text:
    See Issue 19547.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Starting week day is a number

  • Key: DTV12-135
  • Legacy Issue Number: 19526
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV v1.1

    Title: Starting week day is a number

    In clause 12.4, the entry for starting week day has the Definition:

    the index of the Gregorian day of year that is 3 days before the first Thursday of some Gregorian year

    It is at least unexpected that any category of ‘day’ would be a integer. The definition appears to be that of ‘starting Monday index’, or something the like. The expected concept would be “Gregorian day that is three days before the Gregorian day that corresponds to the first Thursday of the Gregorian year.’ In either case, one would have to define: Gregorian year has first Thursday. This suggests that the useful concept is in fact, Gregorian year has starting Thursday (or starting Monday).

    The verb concept is ‘starting week day of Gregorian year’ rather than ‘Gregorian year has starting week day’, and there is a Necessity that only Gregorian years after 1600 have starting week days, which is clearly wrong.

    This whole concept appears to be an artifice for determining which week of the ‘weeks calendar’ is the ‘first week’ of a Gregorian year. So there is no intended business use of these terms, but the entries should be corrected.

  • Reported: DTV 1.1 — Thu, 17 Jul 2014 04:00 GMT
  • Disposition: Duplicate or Merged — DTV 1.2
  • Disposition Summary:

    The last paragraph of the Issue Summary correctly indicates that the function of ‘starting week day’ is to support interpretation of ‘week of year’ and ‘year week coordinates’. The resolution of Issue 19574 restructures that interpretation by creating a fixed relationship between the Gregorian calendar and the weeks calendar. That restructuring eliminates the use of ‘starting week day’ per se, although it makes a similar concept ‘first Thursday’ necessary.
    The resolution of this issue is therefore merged with that of 19574.
    Revised Text:
    none. See Issue 19574

  • Updated: Wed, 8 Jul 2015 11:40 GMT

time point sequences specify time periods

  • Key: DTV12-137
  • Legacy Issue Number: 19530
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 8.7 includes two verb concepts:

    time point1 through time point2 specifies time period

    time point1 to time point2 specifies time period

    The definitions of these concepts describe the construction of a time point sequence followed by the correspondence to time period. Several of the Necessities in these entries restate Necessities for time point sequences. At least one Necessity for time point sequences in general is stated here but not in the entry for time point sequences:

    If the time scale of time point1 is an indefinite time scale then time point1 through time point2 specifies exactly one time period.

    That is, each time point sequence that is on an indefinite time scale corresponds to exactly one time period.

    By creating companion verb concepts:

    time point1 through time point2 defines time point sequence

    time point1 to time point2 defines time point sequence

    the redundancies can be eliminated and the Definitions and Necessities for the two verb concepts specifying time periods can be greatly simplified.

    E.g. for

    time point1 through time point2 specifies time period

    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 the time point sequence corresponds to the time period

    the Definition is replaced by:

    Definition: the time point sequence that is defined by time point1 through time point2 corresponds to the time period

  • Reported: DTV 1.1 — Fri, 18 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees that Necessities about time point sequences in general should be moved to the entry for time point sequence or the related verb concepts.
    The RTF notes that the UML diagram in Figure 8.25 is inconsistent with the existing text, and includes the two proposed intermediate verb concepts.
    The proposed verb concepts are added, the definitions and necessities for the cited concepts are revised accordingly, and the UML model is re-aligned with the text.
    Text is added to explain that ‘time point sequence’ is overall an artificial construct used to describe references to time periods.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Gregorian years before 1600 have no starting day

  • Key: DTV12-134
  • Legacy Issue Number: 19525
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV v1.1

    Title: Gregorian years before 1600 have no starting day

    Summary:

    In clause 11.7, in the entry for ‘Gregorian year has starting day’, the Definition is a formula for calculating the index of the ‘starting day’, as distinct from a definition of the verb concept (which is actually carried in the definition of the role ‘starting day’). The Definition is followed by the Necessity:

    Necessity: The index of Gregorian year is greater than 1600.

    We must conclude that either there are no Gregorian years before 1600, or the ones before 1600 have no starting day. The real intent is probably that the formula given in the Definition is not correct for Gregorian years before 1600.

    The correct definition is: The starting day is the Gregorian day that is the first calendar day of the Gregorian year.

    Necessity: Each Gregorian year has exactly one calendar day.

    Necessity: The starting day of Gregorian year 1875 is Gregorian day 684606.

    This relates the concept to the index origin for the Gregorian days scale. The rest are determined by the rules for the length of Gregorian years.

    How to compute the index of the starting day from 1601 on should be a Note. One would expect the rule to be how to calculate from the index origin, and there may be other such algorithms. The concept is not the computation algorithm.

  • Reported: DTV 1.1 — Thu, 17 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agrees that the definition should be corrected, and the first Necessity should be added.
    The Gregorian calendar algorithm is, however, a Necessity not a Note, and the starting day of 1601 is important to it. The second proposed Necessity is irrelevant – the index origin of the Gregorian days calendar is not the starting day of any Gregorian year, and is not useful to the calendar algorithm.
    Note also that there are no Gregorian years before 1582. That Necessity is corrected

  • Updated: Wed, 8 Jul 2015 11:40 GMT

add 'time interval starts during time interval'

  • Key: DTV12-132
  • Legacy Issue Number: 19521
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV

    Version: 1.1

    Source: Ed Barkmeyer, NIST, edbark(at)nist.gov

    Summary:

    Examination of some business usages of time concepts has led to the observation that several regulations use the concept:

    time interval1 starts during time interval2

    or

    occurrence starts during time interval

    These verb concepts can easily be phrased in terms of existing DTV concepts, but the phrasing is cumbersome. It would be useful to add these to the DTV business vocabulary.

  • Reported: DTV 1.1 — Fri, 11 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    The RTF agreed to add these, in order to simplify business usage.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: Unspecified Relationship of OWL files to DTV

  • Key: DTV12-131
  • Legacy Issue Number: 19484
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV v1.1

    Title: Unspecified Relationship of OWL files to DTV

    Source: Sridhar Iyengar, IBM (for the AB)

    Summary:

    The DTV v1.1 inventory formally includes a ZIP file that contains OWL ontologies for the DTV vocabularies, but no text in the specification refers to this file, or to these ontologies. Also, the text of the CLIF and OCL elements associated with vocabulary elements is contained directly in the specification, but the relationship between the OWL elements and the vocabulary elements is nowhere described. Some text should describe what the OWL ontologies are, and how the OWL model elements are derived from the vocabulary elements.

  • Reported: DTV 1.0 — Fri, 20 Jun 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    A brief description of the relationship of the OWL files to the specification is added to Clause 5.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

misplaced paragraph in 10.6.3

  • Key: DTV12-140
  • Legacy Issue Number: 19635
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Following the entry for ‘compound time coordinate combines atomic time coordinate’, the following paragraph appears:

    Calendar scales (i.e., those involving calendar years, calendar months, calendar weeks, and calendar days) use index origin value 1, while time-of-day scales (i.e., those involving hours of day, minutes of hour and seconds of minute) use index origin value 0. In all cases other than the Gregorian years scale, the index original element is the first element of the time scale. For clarity, the index origin value and index origin element of each time scale is included with the time scale.

    The paragraph has nothing to do with the nature of time coordinates, which is the topic of 10.6. It may belong in 10.8 or at the end of 10.1.

  • Reported: DTV 1.1 — Wed, 8 Oct 2014 04:00 GMT
  • Disposition: Duplicate or Merged — DTV 1.2
  • Disposition Summary:

    The paragraph is out of place, but it is most relevant to atomic time coordinates that involve the index of the time point. It is reworded to make that clear, and to clarify the forward references to clauses 11 and 13.
    The text revision is in the area modified by issues 19547 and 18991, and the corresponding text changes are merged with Issue 19547.
    Revised Text:
    see Issue 19547.

    Disposition: Merged (see Issue 19547)

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Figures in 10.7 do not match the text

  • Key: DTV12-139
  • Legacy Issue Number: 19570
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 10.7 (time sets), Figure 10.15 is followed by text that relates time sets to time point sequences, but time point sequences do not appear in the Figure. Similarly, Figure 10.16 is the same diagram, but it is followed by text that relates time sets to time periods, and time periods do not appear in the diagram.

  • Reported: DTV 1.1 — Tue, 5 Aug 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Both of these diagrams are out-of-date. They are replaced with the correct diagrams.
    Note also that Figure 10.15 correctly shows that ‘time point sequence matches time set’ specializes ‘thing is in set’. The entry is modified to capture this.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

Missing and incorrect text in clause 10.6

  • Key: DTV12-138
  • Legacy Issue Number: 19547
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV v1.1

    Title: Missing and incorrect text in clause 10.6

    Summary:

    In clause 10.6 (Time Coordinates), the introduction suggests that a time coordinate can represent more than one time point. This is false. A time coordinate represents exactly one time point (which is nowhere stated). It can only combine time point identifiers to refer to a different time point.

    The verb concept 'time coordinate has time scale' appears in the UML diagram and in one of the definitions, but nowhere in the text.

    In the entry for 'time coordinate', the two dichotomies are stated as possibilities in the Notes. They should be stated as Necessities.

    The definitions of absolute and relative time coordinates refer to their "corresponding to" time intervals. The time points correspond, but the coordinates only "refer to" them.

  • Reported: DTV 1.1 — Mon, 28 Jul 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.2
  • Disposition Summary:

    Upon examination, the RTF determined that an atomic time coordinate indicates exactly one time point. A compound time coordinate, and therefore time coordinates in general, indicates at most one time point, and may not indicate any (documented) time point. For example, March 3 does not indicate any documented time point. This necessitates a number of minor changes to the model, and to the wording of many definitions in 10.6.
    With this understanding, only an atomic time coordinate has a time scale, and that concept is added.
    The dichotomies are restated as Necessities, and shown in the UML diagrams. The definitions of absolute and relative time coordinates are modified as recommended, and other inconsistencies are also repaired.
    There is a significant overlap of the changes associated with this issue and the changes associated with Issues 18989, 18991, 19529, and 19635.
    Issue 18989 and 18991 (duplicates) were resolved to determine that a time coordinate is a conceptual structure of meaning rather than a representation of a time point. This affects the UML diagrams in 10.6, the wording of the introductory text, and the wording of many of the definitions being altered by Issue 19547. In particular this results in elaborating the model of atomic time coordinate.
    Issue 18991 also makes parallel changes to the wording of Clause 9.1 and 9.2.
    Issue 19529 points out that the definitions of ‘compound time coordinate’ and ‘compound time coordinate combines atomic time coordinate’ are circular. The resolution of that issue is to define a compound time coordinate to be a set of atomic time coordinates, but to ‘combine’ time coordinates in general. The revised definitions must also take into account the fact that compound time coordinates do not necessarily indicate time points. Those changes are therefore merged into the Revised Text below.
    Issue 19635 requires an editorial change to move a misplaced paragraph in 10.6.3. In addition, the revised entry for ‘compound time coordinate includes atomic time coordinate’ is moved to follow the entry for ‘compound time coordinate’.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

DTV Issue: Inadequate guidance for application vocabularies

  • Key: DTV12-123
  • Legacy Issue Number: 18990
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The Date-Time Vocabulary has multiple concepts about amounts of time (duration, duration value), and locations in time (time interval, time point, time point set, time period, time coordinate), but very little guidance as to which of these concepts should be the basis for application business vocabularies. DTV should add a rationale section or additional commentary in Annex C to explain which concepts should be used for what purposes in business vocabularies.

    Table C.1 has a reference to a concept 'date' that does not exist.

  • Reported: DTV 1.0 — Sun, 6 Oct 2013 04:00 GMT
  • Disposition: Deferred — DTV 1.2
  • Disposition Summary:

    The RTF recognizes the need to provide guidance to business analysts and other users. After some discussion, the RTF decided not to try to distinguish concepts that are “infrastructural” from “application concepts” within the body of the various vocabularies. Instead the need will be addressed by a revision of Annex C that provides the guidance. This issue is closely related to Issue 19336, and resolutions are merged into a single revision of Annex C.

  • Updated: Wed, 8 Jul 2015 11:40 GMT

SBVR Convention issues in DTV

  • Key: DTV11-103
  • Legacy Issue Number: 19361
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    SBVR experts:

    In the Date Time Vocabulary v1.0 specification, clause 16.5 contains the following terminological entry:

    individual situation kind has occurrence interval

    Definition: the occurrence interval is the time span of the individual situation kind

    Necessity: The individual situation kind has exactly one occurrence

    Note: The time span of an individual situation kind is exactly the occurrence interval of its only occurrence.

    Example: The occurrence interval of the Great Fire of London was 2 September 1666 through 5 September 1666 (English old style calendar).

    The technical aspects of this are not at issue. An ‘individual situation kind’ (state of affairs) can have at most one occurrence. An occurrence (actuality) has exactly one ‘occurrence interval’ – the time interval during which it is occurring. And any situation kind can have a ‘time span’ – the smallest time interval that includes all occurrences of the situation kind. (If it never occurs, it may have No time span.)

    There are two SBVR “style” problems here.

    First, the Definition of the verb concept is (appropriately) a sentence involving the placeholders, but the first character of the sentence is not capitalized. By convention in SBVR, the first character of a Definition is not capitalized, and this is also true of example sentences in SBVR v1.2, e.g., in clause 8.2.2. The question is: Which convention – English or SBVR – is appropriate here? Or do we even care?

    Second, and more importantly, the intent of the above Necessity is: If an individual situation kind has an occurrence interval, the individual situation kind has exactly one occurrence. But the text above omits the antecedent. Instead, it assumes that ‘the individual situation kind’ refers to whatever plays the ‘individual situation kind’ role in an instance of the verb concept (wording). Is it the intent of SBVR that such an omission is valid in this context (the terminological entry)? Or is the antecedent required (to establish the context of an instance of the verb concept)?

    The considered opinion of the SBVR RTF will dictate the nature of any related changes to this entry in the DTV.

  • Reported: DTV 1.0 — Thu, 24 Apr 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    No Data Available

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

"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 ( 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 ( Edward 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 ( Edward 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 ( Nicolas 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 ( Edward 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 ( Donald 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 ( Donald 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 ( Donald 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 ( Edward 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 ( Edward 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

DTV Issue: Included Vocabulary is wrong for Duration Values Vocabulary

  • Key: DTV11-102
  • Legacy Issue Number: 18959
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 9.0 of the Date-Time Vocabulary, the vocabulary entry for the "Duration Values Vocabulary" has "Included Vocabulary: Duration Values Vocabulary". Per diagram 7.3, it should be "Included Vocabulary: Time Infrastructure Vocabulary".

  • Reported: DTV 1.0 — Sun, 22 Sep 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    sduplicate of issue # 18950

  • Updated: Fri, 6 Mar 2015 23:16 GMT

DTV Issue: incorrect reference schemes for time point sequence

  • Key: DTV11-101
  • Legacy Issue Number: 19418
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: DTV v1.0
    Title: incorrect reference schemes for time point sequence

    Summary:
    In clause 8.7, the last two reference schemes for a time point sequence are incomplete, because they are misworded. They read:
    Reference Scheme: The first time point of the time point sequence, if the time point sequence has no last time point.
    Reference Scheme: The last time point of the time point sequence, if the time point sequence has no first time point.

    The problem is that the first time point of the time point sequence ALONE is not sufficient, whether the time point sequence has a last time point or not. When it has no last point, the fact that it has no last point must be a characteristic that is included in the reference scheme.
    The Reference Scheme should be worded:
    The first time point of the time point sequence and the characteristic ' the time point sequence has no last time point'.
    and similarly for the sequence that has no first time point.

  • Reported: DTV 1.0 — Thu, 15 May 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The reference schemes will be reworded as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship between "equals" and "is"

  • Key: DTV11-100
  • Legacy Issue Number: 19417
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In DTV Clause 8.2.3, in the entry for 'time interval1 equals time interval2', the second Note says:
    "SBVR uses the verb is for this relationship, but the equals relationship here is a specialization of 'thing is thing' for time intervals. Two time intervals are equal if they share particular properties of time interval, and the definition of equal does not involve properties that are suitable for a reference scheme."

    This relationship is important to business usage of the vocabulary. The SBVR formal mechanism for stating the first sentence is:
    General concept: 'thing1 is thing2'
    which makes the specialization clear. If two time intervals are equal, they are identical.
    One could also state it as a Necessity (with translations to CLIF and OCL):
    A time interval1 equals a time interval2 if and only if time interval1 is time interval2.
    which is actually a stronger (and correct) statement. It adds: if two time intervals are identical, they are necessarily equal.

    The second sentence of the Note is at best confusing, since reference schemes have nothing to do with equality. It should be deleted.

  • Reported: DTV 1.0 — Thu, 15 May 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    Resolution:
    This issue was discovered in an RTF discussion of another issue. The meeting agreed to the General concept and Necessity.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: "unitary concept" missing from clause 4

  • Key: DTV11-97
  • Legacy Issue Number: 19347
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Clause 15.3 has numerous entries that are “Concept Type: unitary concept”, but “unitary concept” is not defined. This concept should be added to clause 4.

  • Reported: DTV 1.0 — Fri, 18 Apr 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    Agreed. The adopted SBVR concept will be added to clause 4.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: Errors in the axioms for ‘time interval1 is before time interval2’

  • Key: DTV11-96
  • Legacy Issue Number: 19341
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    OMG Specification: Date Time Vocabulary

    Version: 1.0

    Title: Errors in the axioms for ‘time interval1 is before time interval2’

    Summary:

    In clause 8.2.2, the axioms for ‘time interval1 is before time interval2’ have several problems.

    1. In the first axiom, the second Corollary does not follow from the Axiom. if t1 overlaps t2, it is not before or after t2. So: if t1 is before or after t2, it does not overlap t2. But the so-called Corollary (the Axiom of totality) states the converse: if t1 does not overlap t2, then t1 is before or after t2.

    2. The SBVR SE statement of irreflexivity demonstrates a disconnect between Structured English and English. Surely the Axiom can be more clearly stated: No time interval is before itself. If the bizarre formulation is required for SBVR, the English expression should be given first.

    3. The current “totality” corollary to the Axiom of assymetry is actually just a partition that follows from the assymetry Axiom and the mislabeled axiom above.

  • Reported: DTV 1.0 — Wed, 16 Apr 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    Make the second Corollary to the first axiom an axiom in its own right. Add the English version of the irreflexivity axiom as the text of the Axiom proper. There is no problem with the “totality” corollary.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV issue: No such verb as 'time scale of granularity'

  • Key: DTV11-99
  • Legacy Issue Number: 19410
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 11.2, the definition of the Gregorian year scale is:

    “the indefinite time scale of granularity ‘year’ and of ‘Gregorian year’ time points”

    The definitions of the Gregorian months scale and the Gregorian days scale use the same pattern.

    This pattern relies on two verb concepts: ‘time scale of granularity’ (aka ‘granularity has time scale’) and ‘time scale of time point’ (aka ‘time point has time scale’). Neither of these verb concepts exists in Clause 8. The intended concepts are ‘time scale has granularity’ and ‘time scale has time point’.

    The Definitions should be reworded:

    “the indefinite time scale that has granularity ‘year’ and that has ‘Gregorian year’ time points”

    and similarly for the others.

  • Reported: DTV 1.0 — Mon, 12 May 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    Agreed. The intended verb concept wordings will be used.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagrams in clause 10 refer to concepts in clause 12

  • Key: DTV11-98
  • Legacy Issue Number: 19363
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Figure 10.2 includes ‘calendar week’, which is not defined in clause 10. Similarly, Figure 10.3 includes ‘week period’ and ‘hour period’ , which are not defined in Clause 10. None of these elements is in the Calendars package or in any package it imports. They are defined in clauses 12 and 13. These concepts should not appear in Clause 10, or at least not without a Note to the Figures.

  • Reported: DTV 1.0 — Fri, 25 Apr 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    These diagram elements were erroneously retained in the Figures when the DTV elements were re-packaged. They will be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Synonymous Forms Captioned as Synonyms

  • Key: DTV11-90
  • Legacy Issue Number: 19287
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In Annex D.3.3, in the entry for "quantity value quantifies quantity", the three synonymous forms are captioned "Synonym:" instead of "Synonymous Form:".

  • Reported: DTV 1.0 — Thu, 20 Mar 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The caption “Synonymous Form” was erroneously rendered as “Synonym” in a number of places in the specification. All of them are corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

incorrect formula for Gregorian year length

  • Key: DTV11-89
  • Legacy Issue Number: 19281
  • Status: closed  
  • Source: yahoo.com ( Michael Deckers)
  • Summary:

    REFERENCXE:
    section 11.7, 1st Definition on p 141:
    " In mathematical form, the definition
    above is:
    sd = 685 263 + (365 * y)
    + (y/4) - ((y/100)*2)
    + ((y/400) * 2)
    where:
    sd is the index of the starting day
    y is the index of a Gregorian
    year ­ 1601
    y >= zero
    / is integer division "

    PROBLEM:
    The formula is incorrect. For instance,
    for years 1700 and 1701 the formula gives
    sd(1700) = 685 263 + (365*99)
    + (99/4) - ((99/100)*2)
    + ((99/400)*2)
    = 685 263 + 365*99 + 24
    = 721 422
    sd(1701) = 685 263 + (365·100)
    + (100/4) - ((100/100)·2)
    + ((100/400)·2)
    = 685 263 + 365*100 + 25 - 2
    = 721 786
    implying that the year 1700 had only
    364 d, which is obviously incorrect.
    The formula gives the wrong year
    length of 364 d for all Gregorian
    years Y wher Y mod 400 is one
    of 100, 200, 300.

    PROPOSED CORRECTION:
    Omit the incorrect factor 2 twice, and
    correct the corresponding note trying
    to justify that factor. Many sources
    give the correct formula, valid for all
    integral year numbers 1601 + y:

    sd(1601 + y)
    = sd(1601) + (365 * y)
    + floor(y/4) - floor(y/100)
    + floor(y/400)
    where:
    y is the index of the Gregorian year
    with number (1601 + y)
    sd(1601 + y) is the index of the
    first day of the Gregorian
    year (1601 + y)
    floor is the largest integer
    that is <= x

  • Reported: DTV 1.0 — Fri, 7 Mar 2014 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The formula was incorrectly represented. It will be corrected as suggested. The changes below incorporate several changes from Issue 19280 that correct errors resulting from faulty calculation of year lengths and incorrect base values. Two Examples of coordinate computations are revised to use the corrected formula.
    The formula for the index origin of the Gregorian months scale is also incorrectly written.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inconsistent statements on day index

  • Key: DTV11-88
  • Legacy Issue Number: 19280
  • Status: closed  
  • Source: yahoo.com ( Michael Deckers)
  • Summary:

    REFERENCES:
    section 11.2, last Note on p 126:

    [a] "The calendar reform instituted by
    Pope Gregory XIII [Inter Gravissimas]
    deleted 10 days from the
    Gregorian calendar, starting on
    5 October 1582."

    [b] "The previous calendar day had
    index 577 739 on the Julian calendar,
    computed as 1581 years of 365 days
    plus 395 leap days + 279 days
    from 1 January 1852 to
    5 October 1582."

    [c] "The following day was
    15 October 1582."

    [d] "From that date to the Convention du
    Mètre on 20 May 1875, there were
    106 870 calendar days including
    leap days."

    section 11.7, in a Note on p 141:

    [e] "685 263 is the index of
    1 January 1601,
    computed as 684 609 (index of
    15 October 1582) plus 6654 days from
    15 October 1582 through
    1 January 1601."

    section 11.7, in the 2nd Example on p 141:

    [f] "The first calendar day of 2010
    is Gregorian day 830 991"

    PROBLEMS:
    The assertion in [a] is misunderstandable:
    no days were deleted from the Gregorian
    calendar by any pope. In fact, the
    proleptic Gregorian calendar without
    any "deletions" is
    used by ISO 8601:2004, by computer
    software and by some historians.
    What really is meant is:
    'The calendar reform instituted by
    Pope Gregory XIII and promulgated in
    the bull [Inter Gravissimas] started
    the use of the Gregorian calendar with
    the date 15 October 1582, which is the
    same as 05 October 1582 in the Julian
    calendar.'

    As for [b]: The "previous calendar day"
    would be 1582 Oct 04 in the Julian
    calendar, not 1582 Oct 05 as suggested in
    [b]. Whichever of the two is meant, the
    following computation in [b] is
    incorrect: the number of days from
    1582 Jan 01 until 1582 Oct 05 is 277 and
    not 279, as can be read directly from
    [table 11.3, p 146].

    As for [c]: It appears as if the
    "following day" means the day
    after J1582-10-05. This
    following day is
    J1582-10-06 = G1582-10-16,
    not G1582-10-15 as asserted.
    (We use prefixes
    J and G to distinguish Julian and
    Gregorian calendars.)

    The computation in [d] is incorrect: the
    number of days from G1582-10-15 to
    G1875-05-20 is 106 868, not 106 870
    as asserted,
    because G1582-10-15 = JD 2299 160.5
    and G1875-05-20 = JD 2406 028.5.

    Assertion [e] is clearly
    self-contradictory since
    685 263 - 684 609 is not 6654.

    Inconsistencies between [b, e, f]: If
    1 January 1601 is the day number 685 263
    as asserted in [e] then
    day 0 is JD 1620 550.5 = G-0276-10-25,
    and if day 684 609 is G1582-10-15 as
    also asserted in [e] then
    day 0 is JD 1614 551.5 = G-0292-05-23.
    Still another zero point follows from [f]:
    day 0 is JD 1624 206.5 = G-0266-10-29
    and finally, if [b] is meant to refer to
    G1582-10-14 as day number 577 739, then
    day 0 is JD 1721 420.5 = G0000-12-27.
    That last date might indicate that day 0
    was actually meant to be still another
    date, viz J0001-01-01 = G0000-12-30,
    but this is just a wild guess of mine.

    ANALYSIS OF THE ISSUES:
    The inconsistencies may come from
    several sources:
    • from typos (though I am not able to
    figure out which);
    • from the error in the formula for
    the duration of successive Gregorian
    years (eg in [d]);
    • from the use of intervals on the
    "time axis" instead of points on it.

    The time axis is an affine space whose
    translation space, formed by the
    differences T - T' for points T, T' on
    the time axis, is the vector space of
    "duration values". Intervals of
    lengths > 0 s, however, do not form an
    affine space. So one has to take the
    lower or the upper bounds of the involved
    intervals consistently to arrive at valid
    date arithmetic (eg, satisfying the rule
    T - T" = (T - T') + (T'- T")).

    An error in numerical examples for
    non-trivial specifications is particularly
    unfortunate because such examples are
    often taken as the very first test cases
    for an implementation. It is therefore
    appropriate to check all the examples
    before publishing. Many calendrical
    calculators are available online for that
    purpose; the one at [http://emr.cs.iit.edu
    /home/reingold
    /calendar-book/Calendrica.html]
    is particularly useful.

  • Reported: DTV 1.0 — Fri, 7 Mar 2014 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The suggested text clarification is accepted. The erroneous numbers will be corrected.
    Because the changes made necessary by this resolution overlap those made in the resolution of Issue 19281, this issue is merged with Issue 19281.
    Disposition: See issue 19281 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: Necessity for "time table" in clause 17.2

  • Key: DTV11-87
  • Legacy Issue Number: 19277
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    There are two problems with the Necessity in the entry for "time table" in clause 17.2:

    1) The Necessity assumes a verb concept "time table has table entry" that does not exist.
    2) The Necessity is misspelled as "Each time table must have at least one table entry." It should be "Each time table has at least one table entry. "

    Note: the definition of "time table has table entry" should make clear the relationship of this concept to the "table entries" mentioned in the definition of "time table" as a "set of table entries".

  • Reported: DTV 1.0 — Sun, 2 Mar 2014 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The UML diagram (Figure 17.1) disagrees with the definition of time table, and introduces the missing verb concept (time table has table entry) as a specialization of ‘set has element’ (from SBVR). The UML model reflects the intent. The text will be revised to support the model.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

incorrect formula for length of successive Gregorian years

  • Key: DTV11-86
  • Legacy Issue Number: 19197
  • Status: closed  
  • Source: yahoo.com ( Michael Deckers)
  • Summary:

    The formula given for the possible lengths
    for an integral number of successive
    Gregorian years is incorrect. It implies
    an average length of the year of 365.235 d
    while the correct value is 365.2425 d.
    For instance it is well known that any
    successive 400 Gregorian years comprise
    exactly 146 097 d, while the formula
    gives 146 094 d.
    For the record, with a little algebra,
    the number of days between Gregorian
    calendar(Y', Jan, 01) and Gregorian
    calendar(Y, Jan, 01) is easily seen
    to be
    floor( Δ·365.25 )
    + floor(-3/4·floor(Δ/100))
    + |Δ mod 4 > (Y - 1)mod 4|

    • Δ mod 100 > (Y - 1)mod 100

      + |Δ mod 400 > (Y - 1)mod 400|
      where Δ = Y - Y'.

  • Reported: DTV 1.0 — Tue, 28 Jan 2014 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The reference is to the formula in the entry for ‘year value specifies duration value set’. The formula includes two erroneous factors of 2, and does not account for year values greater than 400 properly. The formula and the supporting concepts will be corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV typos

  • Key: DTV11-85
  • Legacy Issue Number: 19175
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Here's some more typos:

    9. In clause 9.5, in the entry for "duration value set equals duration", the third synonymous form has the same wording as the primary form of the verb concept.
    10. In clause 16.4, in the primary verb form for "occurrence1 is between occurrence2 and occurrence3", the word "and" should use verb style, rather than keyword style. In the first synonymous form, the word "and" should use verb style, rather than keyword style. The second and third synonymous forms are identical; one should be removed.
    11. In Annex D.2.3, in the entry for "sequence has index origin position", the first Necessity should read "Each sequence has at most one index origin position.", rather than "Each sequence has at most one index origin value.".
    -----------------------------
    Mark H. Linehan
    STSM, IBM Research
    ----- Forwarded by Mark H Linehan/Watson/IBM on 01/02/2014 04:04 PM -----

    From: Mark H Linehan/Watson/IBM
    To: dtv-rtf@omg.org,
    Date: 12/30/2013 05:06 PM
    Subject: Fw: DTV typos

    --------------------------------------------------------------------------------

    Here's another typo:

    8. In clause 16.4, in the entry for "individual situation kind has occurrence interval", the Necessity "The individual situation kind has exactly one occurrence" should be "Each individual situation kind has exactly one occurrence interval".
    -----------------------------
    Mark H. Linehan
    STSM, IBM Research
    ----- Forwarded by Mark H Linehan/Watson/IBM on 12/30/2013 05:00 PM -----

    From: Mark H Linehan/Watson/IBM@IBMUS
    To: dtv-rtf@omg.org, issues@omg.org,
    Date: 12/30/2013 11:29 AM
    Subject: DTV typos

    --------------------------------------------------------------------------------

    I've noticed several more typos in the DTV spec (formal-13-08-01.pdf):

    1. In clause 11.2, in the entry for "Gregorian year of days scale", the first Necessity should be a Note.
    2. In clause 11.2, in the entry for "Gregorian month of days scale", the first Necessity should be a Note.
    3. In clause 16.7, in the entry for "time interval1 to occurrence specifies time interval2", "occurrence to time interval1 specifies time interval2", "occurrence1 to occurrence2 specifies time interval", "time interval1through individual situation kind specifies time interval2", the word "The" in the Necessity caption should have keyword style.
    4. In clause 17.1, in the entry for "time table", the use of the keyword "must " in the first Necessity is not consistent with SBVR-SE style because modal keywords are not used in Necessities and Possibilities. The Necessity should read "Each time table has at least one table entry.".
    5. In clause 17.2, in the entry for "schedule is for general situation kind", the first Necessity should read "Each schedule is for..." instead of "A schedule is for...".
    6. In Annex D.2.1, the modal keyword "may" is used in the Possibilities for "sequence has first position" and "sequence has last position". In SBVR-SE style, modal keywords are implicit, not explicit in Possibility and Necessity statements.
    7. In Annex D.2.3, the Necessity for "sequence has index origin position" should read "Each sequence has at most one index origin position." instead of "Each sequence has at most one index origin value.".
    -----------------------------
    Mark H. Linehan
    STSM, IBM Research

  • Reported: DTV 1.0 — Mon, 6 Jan 2014 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    All identified typographical errors will be corrected. Errors in SBVR entry subtitles will also be corrected.
    This issue resolution incorporates other changes that only repair typographical errors.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: Reference Scheme problems

  • Key: DTV11-93
  • Legacy Issue Number: 19327
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    I've noticed a number of problems with reference schemes in DTV:

    1) In clause 8.3, the reference scheme for 'duration' has a forward reference to the verb concept 'precise atomic duration value quantifies duration', which is in clause 9.2.2.
    2) In clause 8.5, the first reference scheme for 'time point', which reads 'an occurrence at the time point', has a forward reference to the synonymous form 'occurrence at time interval', which is in clause 16.2.
    3) In clause 8.5, the second reference scheme for 'time point', which reads 'a time coordinate that indicates the time point', has a forward reference to the verb concept 'time coordinate indicates time point', which is in clause 10.5.1.
    4) In clause 8.5, the third reference scheme for 'time point', which reads 'the time scale of the time point and the index of the time point', makes no sense, since a time point can belong to multiple time scales (e.g. 'time of day'). Suggested form: a time scale that has the time point and the
    5) In clause 8.5, the fourth reference scheme for 'time point', which reads 'a time point kind and an index', has a forward reference to the general concept 'time point kinds', which is in clause 10.3. Moreover, the reference scheme is not defined properly; it should read "a time point kind and an index of the time point'.
    6) In clause 8.5, the fifth reference scheme for 'time point', which reads 'the name of the time point', refers to a verb concept 'time point has name' that does not exist. Perhaps it is intended as 'a representation of the time point', but considering that a 'time coordinate' is a representation of a time point, it appears that this fifth reference scheme duplicates the second reference scheme, which read 'a time coordinate that indicates the time point'.
    7) In clause 10.1, the reference scheme for 'calendar', which reads 'the time scales that are defined by a calendar', refers to a missing synonymous form of 'calendar defines time scale'. Proposed solution: define this synonymous form.
    8) In clause 10.4, the reference scheme for 'local calendar', which reads "a time offset by which the local calendar's day of hours-scale difference from the day-of-hours scale of UTC", has multiple problems: (a) the words 'by which' should be verb-styled; (b) apparently this is trying to use a synonymous form of 'calendar1 differs from calendar2 by offset' but the reference scheme talks about scales of calendar, whereas the verb concept is about calendars; (c) there is no such synonymous form. Proposed solution: define synonymous form 'time offset of calendar1 from calendar2' of existing verb concept 'calendar1 differs from calendar2 by time offset', and reword the reference scheme as "the time offset of the local calendar from UTC".
    9) In Annex D.3, the reference scheme for 'particular quantity', which reads 'A definite description of the particular quantity', depends upon a noun concept 'definite description' that is not listed in Clause 4. Proposed solution: Change the reference scheme to 'a definite description that represents the particular quantity'. Add 'definite description' to clause 4, per SBVR, as a kind of 'intensional definition', which should be updated to define it as a kind of 'definition'. And 'definition' should be added as a kind of 'representation'. Also, make sure that clause 4 defines 'concept' as a kind of 'meaning' and 'meaning' as a kind of 'thing'.

  • Reported: DTV 1.0 — Wed, 2 Apr 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    Entries 1, 2, 3: Forward references are made necessary because there is only one glossary entry for the concept. There are similar examples in SBVR itself.
    4. Clause 8.6, in the entry for ‘time scale has time point’, makes a time point a part of exactly one time scale.; ‘time of day’ and ‘calendar day’ are time point kinds, not time points.
    5. The cited reference scheme is invalid – a time point kind does not necessarily identify a scale, and thus the index is ambiguous. Consider ‘calendar day’ and 1.
    6. The redundant reference scheme will be deleted. (It is a vestige of a draft in which time coordinates did not include terms for time points.)
    7. The missing synonymous form will be defined.
    8. The suggested synonymous (noun) form will be defined.
    9. It is sufficient to adopt ‘definite description’ and ‘concept has definition’ from SBVR. (Note: intensional definition is already present)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: Relationship among time points, time scales, and time indices

  • Key: DTV11-92
  • Legacy Issue Number: 19319
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In DTV clause 8.5, the second Necessity of 'time scale has time point' reads 'Each time point is of exactly one time scale.' This is clearly wrong. Several of the time points defined in clause 10.2 are on multiple time scales. For example, 'time of day' is defined as a 'time point that is on a time scale that has a granularity that is less than 1 day'. Examples include 'second of day' and 'second of hour'.

    Also in clause 8.5, the verb concept 'time point has index' makes no sense. A time point has different indices, depending upon what scale is used. This should be a ternary verb concept: 'time point has index on time scale'.

    Numerous Definitions and Necessities depend upon a verb concept 'time point is on time scale' that is not defined anywhere but could be a Synonymous Form of 'time scale has time point'. Examples include:

    • clause 10.2, definition of 'time of day' (see above)
    • clause 11.2, most definitions
    • clause 13.2, most definitions
  • Reported: DTV 1.0 — Sun, 30 Mar 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    There are no time points in 10.2 (or any other clause) that are on multiple time scales. ‘time of day’ is not a time point; it is a ‘time point kind’ – a general category of time points. Each ‘second of day’ time point is only on the day of seconds time scale, and each ‘second of hour’ is only on the ‘hour of seconds time scale’. The referenced Necessity in 8.5 is valid, and is important. As a consequence of it, the concept ‘index of time point’ is well-defined.
    The form ‘time point is on time scale’ is used as described, and it should be a synonymous form for ‘time scale has time point’.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Typo: 'atomic time coordinate of coordinate time coordinate'

  • Key: DTV11-91
  • Legacy Issue Number: 19309
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 10.6.3, in the entry for 'compound time coordinate combines atomic time coordinate', the Synonymous Form that reads 'atomic time coordinate of coordinate time coordinate' should be 'atomic time coordinate of compound time coordinate'. There is no general concept that is termed 'coordinate time coordinate'.

  • Reported: DTV 1.0 — Wed, 26 Mar 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    a stated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

regular time table is strangely constrained

  • Key: DTV11-81
  • Legacy Issue Number: 19076
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In DTV Clause 17.1, in the entry for ‘regular time table’, the following Necessity appears:

    If the index of some table entry2 of the time table is 1 greater than the index of some

    table entry1 of the time table, then the duration from table entry1 to table entry2 is the

    repeat interval of the time table.

    This goes well beyond the definition, which says only that the time table has an ‘intensional definition’, i.e., a rule that determines the entries. This Necessity states one kind of scheduling rule, but it prevents the use of a rule that specifies table entries by events, or by event plus or minus duration. (Consider military time tables, which state schedules for preparatory actions relative to a planned event whose occurrence interval is not fixed. These time tables have clear intensional definitions, but they don’t have ‘repeat intervals’.)

    If the Description (“A regular time table has time table entries that repeat...”) is what is intended, then the Definition is not even close to conveying that. That concept is a regular sequence of not necessarily contiguous time intervals, which are determined by a starting point and a repeat interval. If this is what is intended, this is what the Definition should say.

    If the intent is as general as the definition leads one to believe, this Necessity should be deleted, or used in a Note as a pattern for a kind of intensional definition that is based on a fixed repeat interval.

    The above Necessity also assumes that the time table has exactly one repeat interval, which is not itself stated as a Necessity. It should be a requirement that a regular time table has at most 1 repeat interval. If the Description is what is meant, it must have exactly one. Note also that the second “Definition” under ‘repeat interval’ should be “Possibility”.

    If the definition is what is intended, there should also be a requirement that the time table has exactly 1 ‘intensional definition’, since the term is marked as an SBVR concept.

  • Reported: DTV 1.0 — Fri, 8 Nov 2013 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The Definition in the v1.0 specification says that the table entries “repeat according to the repeat interval”. That is the intent. A regular time table is a repeating sequence of time intervals with a fixed repeat interval. The Necessity that the issue refers to is correct. The Definition will be reworded to clarify this by eliminating ‘intensional definition’.
    The term ‘repeat interval’ is confusing, because it refers to a duration, not a time interval. It will be replaced.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Typo: definition of "Gregorian date"

  • Key: DTV11-80
  • Legacy Issue Number: 19063
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 11.7, in the Definition of 'Gregorian date', the reference to "Gregorian year month date coordinate" should be spelled "Gregorian year month day coordinate". The reference to "year weekday coordinate" should be spelled "year week day coordinate". Also, the concept 'year week day coordinate' is defined in the Week Calendar Vocabulary, which (according to figure 7.3) is not included by the Gregorian Calendar Vocabulary – and cannot be included without creating a circular inclusion problem.

  • Reported: DTV 1.0 — Sun, 3 Nov 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The erroneous term “Gregorian year month date coordinate” occurs in the entry for Gregorian year month day coordinate as well as in the entry for Gregorian day.
    The reference to year week day coordinate in clause 11.7 is a consequence of the definition of Gregorian day. It is properly a “calendar date that refers to a Gregorian day”. The definitions of the other three concepts should refer to ‘Gregorian date’ as the more general type.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: The definitions of 'starts before' and 'finishes after' are too complex

  • Key: DTV11-95
  • Legacy Issue Number: 19340
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    OMG Specification: Date Time Vocabulary

    Version: 1.0

    Title: The definitions of 'starts before' and 'finishes after' are too complex

    Summary:

    In clause 8.2.4, the definition of ‘time interval1 starts before time interval2’ enumerates several possible Allen relations, but what is intended can be stated more simply: There is a time interval3 that is part of time interval1 and precedes time interval2.

    Similarly ‘time interval1 ends after time interval2’ is: There is a time interval3 that is part of time interval1 and follows time interval2.

    Time interval1 begins time interval2 seems to be misdefined. The example says 2009 begins 2010 and that is false. The intent of this verb concept should be clarified. Similarly, in Time interval1 ends time interval2, the example that is mislabeled Definition is the only example that a business person would recognize as T1 ends T2 and that is an instance of the Allen relation: T1 finishes T2.

  • Reported: DTV 1.0 — Wed, 16 Apr 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The Definitions of ‘time interval1 starts before time interval2’ and ‘time interval1 finishes after time interval2’ are incorrect. The definition of ‘starts before’ omits the case where time interval2 finishes time interval1, and similarly ‘finishes before’ omits the case where time interval2 starts time interval1. The definitions will be corrected as suggested.
    The example “2009 begins 2010” is not valid and will be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: Figure 8.12 is the wrong diagram

  • Key: DTV11-94
  • Legacy Issue Number: 19339
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    OMG Specification: Date Time Vocabulary

    Version: 1.0

    Summary:

    In clause 8.3.3, Figure 8.12 has no relationship to the terms and concepts in the clause. (It is a duplicate of Figure 8.8)

    Replace it with a proper diagram of the concepts in the clause.

  • Reported: DTV 1.0 — Wed, 16 Apr 2014 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    Replace the Figure with the correct UML diagram. Issue 18253 modifies the text of this section and modifies the diagram accordingly. This issue is merged with Issue 18253.
    Disposition: See issue 18253 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: time point sequence includes time point

  • Key: DTV11-84
  • Legacy Issue Number: 19173
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The second Necessity in the glossary entry for "time point sequence" in clause 8.7 reads "Each time point sequence includes at least one time point.". The Necessity depends upon a verb concept "time point sequence includestime point" that does not exist.

    Suggested solution: add a glossary entry for "time point sequence includestime point".

  • Reported: DTV 1.0 — Fri, 3 Jan 2014 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The verb ‘includes’ should be a reference to ‘sequence has member’. No new entry is needed. The wording will be corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: use of "first element" in scale definitions

  • Key: DTV11-83
  • Legacy Issue Number: 19171
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 11.2, the glossary entries for "Gregorian year of months scale", "Gregorian year of days scale", and "Gregorian month of days scale" each include Necessities of the form "The first element of the ...", where "first" is unstyled. This is a problem because Necessities should never have unstyled text. More importantly, these Necessities could instead by written as "The first member of the ...." If not, the second Note under "index origin member" in Annex D.2.3 is wrong.
    -----------------------------

  • Reported: DTV 1.0 — Mon, 30 Dec 2013 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The issue is correct and the recommended approach solves the problem.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Typo: weeks scale

  • Key: DTV11-78
  • Legacy Issue Number: 19033
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 12.3 of the Date-Time Vocabulary, in the Definition of 'weeks scale', the term 'indefinite time scale' should be styled as a term, rather than as an individual concept. Also, the definition should probably start "the indefinite time scale that ...."

  • Reported: DTV 1.0 — Sun, 27 Oct 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    as stated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Typo in clause 9.5

  • Key: DTV11-77
  • Legacy Issue Number: 19032
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 9.5, the first caption under "duration value set2 = duration – duration value set1", should be a Synonymous Form, not a Definition. And the second caption should be a Definition rather than a Synonymous Form.

    Also (following on a previous request), the primary term for several glossary entries in this section should use English words rather than algebraic symbols, as in "duration value set2 equals duration minus duration value set1".

  • Reported: DTV 1.0 — Sat, 26 Oct 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The second paragraph above is not about a typo. It requires correcting the primary verb terms for three of the entries in 9.5, which is the subject of Issue 19016.
    Disposition: See issue 19016 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: definition of 'time point kind'

  • Key: DTV11-79
  • Legacy Issue Number: 19060
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause xx, the definition of 'time point kind' is "concept that is a specialization of the concept 'time point'", where 'specialization' is styled as a term. However, 'specialization' is not defined anywhere in either DTV or SBVR.

    The definition should read "concept that specializesthe concept 'time point'"
    -----------------------------

  • Reported: DTV 1.0 — Fri, 1 Nov 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    as described

  • Updated: Fri, 6 Mar 2015 20:58 GMT

drop "Gregorian day of week"

  • Key: DTV11-82
  • Legacy Issue Number: 19169
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 11.2, "Gregorian Time Points", the definition of "Gregorian calendar day" is "Gregorian day or Gregorian day of year or Gregorian day of month or Gregorian day of week". The problem with this definition is that there is no term "Gregorian day of week" anywhere in DTV – probably because the week calendar and the Gregorian calendar are unrelated.

    Recommended solution: drop "Gregorian day of week" from this definition

  • Reported: DTV 1.0 — Fri, 27 Dec 2013 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    As described

  • Updated: Fri, 6 Mar 2015 20:58 GMT

time interval1 precedes time interval2

  • Key: DTV11-64
  • Legacy Issue Number: 18241
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

  • Reported: DTV 1.0b2 — Thu, 1 Nov 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    ‘Time interval1 precedes time interval2’ is redundant. It and its synonymous forms should be made synonymous forms for ‘time interval1 is before time interval2’ in clause 8.2.2. The entry can be kept in 8.2.4 with a See reference to the entry in 8.2.2. The UML model (which only captures primary terms) need not be modified.
    Note: In 8.2.2, one of the synonymous forms for ‘is before’ is incorrect. It is also corrected by the changes below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clause 8.3.2 dependency upon clause 10.2

  • Key: DTV11-63
  • Legacy Issue Number: 18240
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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

  • Reported: DTV 1.0b2 — Thu, 1 Nov 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    It is not necessary for any of these units to make definitive references to the concepts in clause 10.2. Two of these units are taken to be precise multiples of ‘day’. The other two are nominal units that approximate the time intervals of astronomical events. Those same intervals are cited in the definitions in clause 10.2. They can be used in both places, so that (v1.0) clause 8.4.2 does not definitively reference clause 10.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: 'second' should be a base unit

  • Key: DTV11-73
  • Legacy Issue Number: 18962
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The individual concept 'second' is defined in clause 8.4.2 as a 'precise time unit', which is a kind of 'measurement unit'. 'Second' should also be defined as a kind of 'base measurement unit' (annex D.3.2) because 'second' is one in the SI system.

  • Reported: DTV 1.0 — Mon, 30 Sep 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    Since all the other precise time units are derived from ‘second’, it is important to say that this is the base measurement unit. Add a second Definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: Clause 11 depends on clause 9

  • Key: DTV11-72
  • Legacy Issue Number: 18961
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Clause 11, Gregorian Calendar, defines concepts 'year value', 'years duration value set', 'month value', and 'months duration value set' – all of which are dependent upon concepts defined in clause 9, 'Duration Values'. But (1) the 'Gregorian Calendar Vocabulary' does not include the 'Duration Values Vocabulary', and (2) figure 7.3 fails to show the dependency. Both of these should be fixed.

  • Reported: DTV 1.0 — Mon, 30 Sep 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    As described. The included calendar references in the Gregorian Calendar Vocabulary are corrected. Introductory text is also added to the beginning of Clause 11.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: figure 8.11 Duration Operations

  • Key: DTV11-71
  • Legacy Issue Number: 18960
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    (See red circle in attached diagram). Figure 8.11, Duration Operations, shows that each instance of the class 'duration' participates in exactly one instance of the class 'duration1 equals number times duration2' as role 'duration1'. Clearly this is false. For example, the duration "4 hours" is the result of both "2 times 2 hours" and "4 times 1 hour".

    Note that the UML diagrams show that instances of each role can participate in any number of instances of the reified classes. For example, see "duration1 equals duration2 minus duration3".

  • Reported: DTV 1.0 — Mon, 30 Sep 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The erroneous multiplicity in the diagram is corrected to 0..*.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

time interval meets time interval is incorrectly defined in SBVR SE

  • Key: DTV11-66
  • Legacy Issue Number: 18822
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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.

  • Reported: DTV 1.0 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    Correct the text as recommended

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Time intervals defined by duration

  • Key: DTV11-65
  • Legacy Issue Number: 18253
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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.

  • Reported: DTV 1.0b2 — Thu, 8 Nov 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The intent of these two verb concepts is to define time intervals, but there are two ways to define time intervals in terms of durations. ‘the two weeks before the meeting’ refers to a time period of two weeks, ending with the meeting, as the issue describes. ‘two weeks before the meeting’ refers to a time interval (a day) that is separated from the meeting by two weeks, which is the intent of the existing text. The concepts in the issue statement are additional concepts, not replacement concepts. They are added.
    The RTF also notes that the most common bases for duration before and after are used with events rather than time intervals. This simplifies the business usage by avoiding the circumlocution ‘the time interval when ...’. The corresponding verbs are added to clause 16. These are simplifications of concepts that use the verb concepts at issue.
    Clause 16.7 was already very large. The edit also formally creates two subsections at the obvious boundary.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Typo: first member

  • Key: DTV11-68
  • Legacy Issue Number: 18828
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

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

  • Reported: DTV 1.0 — Fri, 19 Jul 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    These errors were corrected in DTV v1.0.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: Error in 'time point1 to time point2 specifies time period'

  • Key: DTV11-67
  • Legacy Issue Number: 18827
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    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

  • Reported: DTV 1.0 — Thu, 18 Jul 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    Correct the text as recommended.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: Included Vocabulary is wrong for Duration Values Vocabulary

  • Key: DTV11-70
  • Legacy Issue Number: 18950
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 9.0 of the Date-Time Vocabulary, the vocabulary entry for the "Duration Values Vocabulary" has "Included Vocabulary: Duration Values Vocabulary". Per diagram 7.3, it should be "Included Vocabulary: Time Infrastructure Vocabulary".
    An extension of the same issue:

    In clause 10.0, the vocabulary entry for the "Calendars Vocabulary" has "Included Vocabulary: Calendars Vocabulary". It should have "Included Vocabulary: Time Infrastructure Vocabulary".

    In clause 11.0, the vocabulary entry for the "Gregorian Calendars Vocabulary" has "Included Vocabulary: Gregorian Calendars Vocabulary". It should have "Included Vocabulary: Calendars Vocabulary".

  • Reported: DTV 1.0 — Sun, 22 Sep 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    as described. These are editorial errors. The changes to clause 11.1 are incorporated in the resolution to Issue 18961, which changes the “included vocabularies”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Vocabulary typo: index

  • Key: DTV11-69
  • Legacy Issue Number: 18875
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The Date-Time Vocabulary 1.0 entry for "index" reads "Definition: integer". It should be "General Concept: integer".

  • Reported: DTV 1.0 — Sun, 18 Aug 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    as stated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: representation has expression

  • Key: DTV11-75
  • Legacy Issue Number: 18995
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    DTV clause 4 has a list of concepts that are extracted from the SBVR specification. This clause includes "representation uses expression", which does not in fact appear in SBVR. The correct concept is "representation has expression".

    Also, DTV clause 4 includes "meaning has representation", which is a Synonymous Form, not a primary term, of "representation represents meaning" in the SBVR specification. Both the primary term and the two Synonymous Forms should be copied from the SBVR specification.

  • Reported: DTV 1.0 — Wed, 9 Oct 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The references to the SBVR vocabulary entries will be corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Typo: 'd 71' in the index

  • Key: DTV11-74
  • Legacy Issue Number: 18963
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The DTV index has an entry 'd 71' that appears nowhere in the text. It should be removed.

  • Reported: DTV 1.0 — Mon, 30 Sep 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    as stated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: Concept terms should not use algebraic symbols

  • Key: DTV11-76
  • Legacy Issue Number: 19016
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Algebraic symbols (<, <=, =) are incorporated in the terms of various concepts, such as "duration1 < duration2". This causes problems when these concepts are mapped to UML, CLIF, or OWL because these languages restrict the character set of names to alphanumeric characters. You can see this in figure 8.10, where this concept is mapped to the "is less than" method name – probably because OCL does not support the "<" character.

    Suggestion: use primary terms that are only alphanumeric, and restrict algebraic symbols to Synonymous Forms. For example, as is already done for "time interval1 is before time interval2".

  • Reported: DTV 1.0 — Sat, 12 Oct 2013 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The RTF agrees that the mathematical symbols should not be the primary terms, in order to simplify mappings to implementation languages that restrict the characters permitted in terms. In each case, the mathematical symbol will be retained as a synonymous form for the verb concept. In addition, the specification of the ‘noun forms’ for the arithmetic verbs is inconsistent; both the sign form and the word form will be specified for both plus and minus.
    The revised text also corrects a paragraph labeling error (Issue 19032), and removes a redundant copy of the axioms for the duration ordering.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Year of Weeks and Year of Weekdays Scales are Misdefined

  • Key: DTV11-62
  • Legacy Issue Number: 17533
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    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.

  • Reported: DTV 1.0b1 — Mon, 30 Jul 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.1
  • Disposition Summary:

    The issue is correct: subdivides does not characterize the year of weeks or the year of weekdays scales. These time scales are finite sequences that map directly to the weeks calendar and year of days calendar respectively

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clause 5.2 depicts the UML model as informative

  • Key: DTV-24
  • Legacy Issue Number: 16874
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In Clause 5.2, in explaining the conventions used for the UML models, the first two paragraphs contain the follwing text:

    "The intent of the model is two-fold: (a) to illustrate this vocabulary with UML diagrams; (b) to satisfy the RFP requirement for a matching UML model.

    The UML model is derived manually from the SBVR-based text in this document. In case of any discrepancies between the SBVR-based text in this document and the UML model, the text prevails because it is the original model."

    This text suggests that the purpose of the UML model is illustrative, rather than normative, and that it is derived from, and inferior in status to, the SBVR model. Bullet (b) belies the rest – the RFP asked for a normative UML model. This specification presents one, and that is what should be said here.

    The Date/Time Vocabulary is (mostly) presented as a formal SBVR "business vocabulary" using the text conventions of SBVR. Clause 5.1 should say that, and does not. The interpretation of the vocabulary presentation is more important than the use of SBVR Structured English as the pseudo-formal form for definitions. It is the interpretation of the vocabulary structure that leads to the normative SBVR XML files attached to the specification.

    The UML model is a normative representation of that part of the Date/Time Vocabulary that can be conveniently represented in UML. The later text of 5.2 specifies the conventions used in creating the normative UML representation. They differ in some ways from the conventions presented in SBVR clause 13. That difference should be expressly stated in 5.2. The differences are primarily related to enabling effective formal specification of definitions and necessities in OCL.

    The SBVR business vocabulary includes normative elements that are not represented in the UML model, typically because UML does not support Synonyms and Synonymous forms. That is the extent of the inferiority of the UML model. Any other discrepancy between the two models is an inconsistency in the specification.

    SBVR SE is not a standard language and SBVR Annex C provides neither a grammar nor a formal interpretation for it. Formally, it is just a style that clarifies the use of English text. The formal forms of the Date/Time definitions and necessities are (incompletely) provided as OCL (and CLIF) formulations, that is, in standard languages with standard formal interpretations. Any discrepancy between the perceived meaning of the SBVR SE formulation and the OCL formulation may be an inconsistency in the specification, or just a misreading of the SBVR SE, but in any case the OCL formulation should take precedence – it is well-defined.

  • Reported: DTV 1.0b1 — Fri, 2 Dec 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The FTF agrees that Clause 5 should specify that the DTV is structured as an SBVR Vocabulary and is intended to be interpreted into the SBVR XML form for a vocabulary as specified in Clause 15 of SBVR.
    The FTF also agrees that the UML and OCL models are intended to be normative. Clause 5 will be modified to make this clear. In addition, clause 5 will be modified to reflect other corrections to the style of the UML and OCL models.
    Editorial instruction 10 below, on OCL style, describes the current text, but may be amended by the resolution to Issue 16714.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex D should be Normative

  • Key: DTV-23
  • Legacy Issue Number: 16872
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The Date/Time Annex D "Fundamental Concepts" says that it is 'informative'. But the declarations and definitions in Annex D are formally specified in SBVR and UML. Moreover, the UML classes and associations defined in Annex D are used directly in the formal normative specifications in the body of Date/Time. The 'quantities' model (D.3) is used in peripheral way in defining 'duration' and 'time unit', and might be considered informative only, since only some 'time units' are 'measurement units' (as defined in D.3). But the part/whole relationship (D.4) is used normatively in clause 8, and the sequences (D.1) and scales (D.3) concepts are critical to the formulation of definitions and necessities in clause 8 and in clause 12. So, it appears that Annex D.1, D.2 and D.4 are critical to the normative specification.

    It is the stated intent of the Date/Time specification that the Annex D models are outside the scope of the Date/time specification, and are used only because no appropriate formal specification of these concepts has been found. Thus a later specification with focused expertise in these areas can be expected to supplant these elements of the Date/Time specification at some future time. Nonetheless, the text of the Date/Time specification, and its formal models, depend on Annex D being interpreted normatively until some future time when it is formally replaced by a specification with wider support.
    Recommendation: Make Annex D 'normative', and retain the caveat that it is an interim specification.

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

    The FTF proposes to make Annex D.2 “Sequences” and Annex D.4 “Mereology” normative, and leave Annex D.3 “Quantities Vocabulary” informative. The “Sequences” and “Mereology” vocabularies are complete and self-consistent, and do not overlap with any other known standards effort. The “Quantities Vocabulary” annex deliberately addresses only the subset of the Quantities topic that is needed by the Date-Time Vocabulary. Other efforts – the QUDV activity of SysML and the QUOMOS standards work at OASIS – are working in this area. Consequently, the FTF prefers to keep the “Quantities Vocabulary” informative.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship of UML model to SBVR is undocumented

  • Key: DTV-22
  • Legacy Issue Number: 16870
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The Date/tTime UML model contains a package called "SBVR", which is a selective subset of SBVR concepts from the SBVR Meaning and Representation Vocabulary (MRV). The specification itself does not identify that vocabulary as 'adopted' or 'included'. If it is actually adopted into the Date/Time vocabularies, the Date/Time UML model should import the SBVR MRV MOF model and not include an ad hoc replacement.

    The Date/Time UML model also uses a set of undefined stereotypes: fact type, fact type role, etc. These stereotypes appear in the diagrams in the specification. The stereotypes use SBVR terms, but they are not defined in the SBVR v1.1 specification, nor are they defined anywhere else. If nothing else, these should be defined in Clause 5.

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

    After discussion with the SBVR v1.2 RTF, and the resolution of DTV Issue 16660, it was decided that the DTV UML model should contain a package that consists of exactly the SBVR terms and concepts that are explicitly adopted into the DTV vocabularies. The UML package SBVR-DTV replaces the package called "SBVR", and contains only the UML model elements for the adopted SBVR elements, as specified in the revised Clause 4, per Issue 16660.
    The stereotypes are specified in a UML Profile for SBVR (-DTV) that is the result of resolution of issue 17129.
    Figures that are affected by the change of the name of stereotype <<fact type>> to <<verb concept>> – and are otherwise unchanged from the beta2 specification – are updated by this issue to correct the stereotype name. These figures are otherwise unchanged.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relating time to states of affairs

  • Key: DTV-21
  • Legacy Issue Number: 16768
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Date-Time specification has verb concepts defining temporal relations to states of affairs that occur once, but not to states of affairs that recur. This means that the Date-Time specification cannot support all the needs of business concepts systems that are based on typical business language. The problem has also led to some erroneous formulations within the specification itself.
    The relations to time include tense, aspect, duration, relations to time intervals (throughout/within/for/at/before/after <time interval>) and relative temporal positioning (before/after). They are defined for only the subset of states of affairs called “occurrences” and so are not helpful to semantic communities and businesses that refer to states of affairs more generally.
    Discussion:
    A common conceptualization approach is to objectify states of affairs, making them the subjects of verb concepts represented by adverbs, adjuncts and other verbal clauses. That approach, which often refers to states of affairs as “events”:
    • does not limit states of affairs to being in the subset that the Date-Time submission calls “occurrences”, but uses objectification generally for any event, activity, situation or circumstance;
    • is seen in modern language processing systems and their lexicons;
    • is a mainstream approach in the field of computational linguistics;
    • is a recommended approach in text books on mapping language to logic.
    Whether a situation can recur across time depends on how the situation is identified, which is a conceptualization decision chosen by a semantic community. A situation that is identified without regard to time (e.g., the situation of a given person’s being in a given location, identified by person and location) can recur. The same situation occurs twice if the same person is in the same location twice.
    Most verb concepts do not have roles that range over time, so their instances are identified independently of time. E.g., each instance of the verb concept ‘person is in place’ is identified by a person and a place. These instances are not “occurrences” as defined by the Date-Time specification because they can obtain at multiple different times. The same person can be in the same place multiple times.
    The problem is illustrated in the following examples:
    1. Consider the situation of there being snow in Seattle and a statement that the situation has occurred in the past, is not occurring now, and will occur in the future. The Date-Time vocabulary cannot be used for the three temporal relations in that statement; it includes a means to express such temporal relations, but not for situations that recur. An earlier version of the Date-Time submission supported this capability.
    2. Consider the same situation of there being snow in Seattle, and that the situation occurred throughout both 12/25/2008 and 11/25/2010. “Throughout” from the Date-Time vocabulary cannot be used to say so. The Date-Time vocabulary does not define “throughout” generally for states of affairs (which includes situations). An earlier draft of Date-Time supported this capability.
    3. It may be required to relate the same situation to its different occurrences. Date-Time defines “occurrence”, but does not provide the relationship between a state of affairs, such as the situation of there being snow in Seattle, and its separate occurrences. The Date-Time specification needs a verb concept by which a state of affairs can be related to its (possibly multiple) occurrences across time: ‘state of affairs has occurrence’.
    4. In describing aspect and tense, the Date-Time specification shows incorrect formulations for some cases, partly because it does not relate states of affairs generally to time. Several specified formulations include “the occurrence (that John writes a book)”. But “that John writes a book” is a state of affairs that can recur – it does not qualify as an “occurrence”.
    Also, some of the formulations should use nesting, but don’t. E.g., “John will have written a book”, which is misformulated in the Date-Time table on tenses and aspects, can be properly formulated using nesting: “the occurrence (that the state of affairs (that John writes a book) has occurred) will occur”.
    If the Date-Time specification is finalized without resolving these concerns, semantic communities will have to create their own temporal concept systems (or find another standard) in order to relate states of affairs generally to time. Those concept systems could adopt basic time concepts from the Date-Time specification, but would also need concepts for relating time to events, activities, situations and circumstance - and would not find them in the Date-Time specification. This would be an unfortunate shortcoming of the Date-Time specification.
    SBVR’s usual practice is to objectify states of affairs in order to make them subjects of verb concepts, and to nominalize propositions only when propositions themselves are the subjects of discourse. This enables a first-order logic interpretation when discourse is about states of affairs and not about propositions. The Date-Time specification must also support this practice. There is a notion indicated in the Date-Time specification that propositions can be nominalized in order to relate states of affairs indirectly to time. People who want to nominalize propositions can, of course, do so but they need to be aware that doing so requires a problematic, higher-order approach.
    Regardless of anyone’s interest in nominalizing propositions, states of affairs are commonly objectified in business discourse (such as in business rules) and are referenced by common terms (such as “situation”, “event”, “circumstance” and “activity”). If the Date-Time specification is to be used for business discourse, it needs to provide for relating time to states of affairs generally.
    Resolution:
    A resolution should provide verb concepts for relating states of affairs to time. A survey of business rules acquired from “business rules practitioners” shows that the following verb concepts will meet common needs for relating states of affairs to time.
    The following verb concepts should be provided:
    • state of affairs occurs throughout time interval
    • state of affairs occurs within time interval
    synonymous form: state of affairs occurs during time interval
    • state of affairs occurs for time interval
    • state of affairs1 occurs before state of affairs2 occurs
    synonymous form: state of affairs2 occurs after state of affairs1 occurs
    • state of affairs1 occurs while state of affairs2 occurs
    • state of affairs has occurrence
    The compound verb phrases using “starts” and “ends” that are already defined for “occurrence” could be added for states of affairs, but they are less important because they can be constructed. E.g., “John starts to eat before Mary comes home” can be formulated “(that (that John eats) starts) occurs before (that Mary comes home)”.
    Also following verb concepts should be provided in support of tense/aspect for states of affairs:
    • state of affairs occurred
    synonymous form: state of affairs happened
    • state of affairs has occurred
    synonymous form: state of affairs has happened
    • state of affairs is occurring
    synonymous form: state of affairs is happening
    • state of affairs will occur
    synonymous form: state of affairs will happen
    The compound cases of tense/ aspect, such as “will have …” are covered using the verb concepts listed above with nesting. E.g., “John will have eaten” can be formulated as “that (that (John eats) has occurred) will occur”. If compound forms are to be defined within the Date-Time specification, they should be defined by nesting the others.
    The wordings for the four tense/aspect verb concepts above differ from wordings of similar verb concepts in the Date-Time specification for occurrences. This is deliberate in order to capture the intent of past, present perfect, present continuous and future as they occur in natural language. For example, a phrase like “is in the past” might be seen as appropriate about an occurrence that has already happened (since the time of an occurrence is intrinsic in its being an occurrence). Timing need not be intrinsic in a state of affairs, so a state of affairs that has occurred and that will occur again would not be understood as “is in the past”. It has occurred and it will occur.
    Also, the Date-Time specification rightly defines “occurrence” as a specialization of SBVR’s ‘state of affairs’ by the way that it uses SBVR’s definition of ‘state of affairs’ within its definition of ‘occurrence’. Therefore, ‘state of affairs’ should be clearly indicated as a more general concept of ‘occurrence’.

  • Reported: DTV 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    Most of the concerns raised by this issue are addressed by the resolution of issue 18173. This resolution contains changes that update table 16.1 to match the latest Date-Time terminology.

    The authors of this issue apparently did not appreciate that the Date-Time Vocabulary permits 'occurrences' of a 'situation kind' (formerly 'situation model') to recur using the 'occurrence exemplifies situation model' verb concept. This aspect of the issue requires no change.

    The beta-1 Date-Time specification explicitly avoided the term 'state of affairs' to avoid possible confusion at the request of the SBVR-RTF. Upon further discussion with the SBVR-RTF, the resolution of 18173 makes 'situation kind' (formerly 'situation model') and 'occurrence' specializations of 'state of affairs'. This solution integrates the Date-Time Vocabulary with "base" SBVR, thus:

    • Enabling objectification in the form called for in this issue.
    • Distinguishing potential states of affairs from occurrences, and enabling verb concepts to be explicit about their semantics.

    The authors of this issue proposed a set of verb concepts that relate 'state of affairs' to time. The original proposal overlooks the fact that SBVR's 'state of affairs' concept is ambiguous: in some uses, it refers to potential situations (which may recur), and in other uses, it refers to what DTV calls 'occurrences'. The time relationships of each of these two aspects of 'state of affairs' are clarified in the existing Date-Time Vocabulary 'occurs' verb concepts.

    This issue argues that the formulation "the occurrence (that John writes a book)" is invalid because "John writes a book" is a state of affairs, not an occurrence. With the 18173 resolution that 'occurrence' is a kind of 'state of affairs', this argument is incorrect. A sentence is added to the text to explain the formulation.

    The issue also argues that formulations such as "John will have written a book" should use nesting. The FTF-2 agrees, and has updated table 16.1 to use nesting.

    While preparing this resolution, the DTF FTF-2 noticed some minor corrections required to table 16.1 to make it match the latest Date-Time Vocabulary. These corrections are made in the following revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue - missing arithmetic on time point sequences

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

    This issue was recorded in the final submission document, under the entry for "Gregorian month converts to time point sequence on the Gregorian days scale":
    Issue: We have not defined arithmetic on time point sequences.

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

    (The references in this text are to the beta-2 version of the specification.)

    The verb concept ‘time point converts to time point sequence on time scale’ is used in 4 places in the specification. The similar verb concept ‘‘time point converts to time set on time scale’ is used in 3 places. We discuss each of these separately.

    Descriptions are added to each of these glossary entries to help future readers understand them.

    Clause 11.7

    Gregorian year converts to time point sequence on the Gregorian days scale

    The definition of this concept relies on normal everyday arithmetic, not on time point arithmetic. As discussed in clause 5.1, this specification uses but does not define ordinary arithmetic.

    The definition fails to specify that the resulting time point sequence is a part of the Gregorian days scale. It is updated to make that clear. This requires a new verb concept ‘time point sequence is on time scale’.

    Gregorian month converts to time point sequence on the Gregorian days scale
    The definition of this concept relies upon the concept of adding a number to a time point sequence. This concept is entirely missing from the specification, and is added as a new verb concept ‘time point sequence2 is time point sequence1 plus integer’.

    The definition claims to subtract ‘1 day’ from an index; it should be simply the number ‘1’. The definition is updated to fix these errors.

    Clause 11.8
    Gregorian month converts to time set on Gregorian year of days scale
    The definition refers to a table with unstyled text. No change needed.

    Clause 12.5
    week of year converts to time set on the Gregorian year of days scale
    The definition relies upon the verb concept ‘time point sequence2 is time point sequence1 plus integer’ that is discussed above, and on a verb concept wording that is an assumed Synonymous Form of the existing ‘time set1 is equivalent to time set2’ in clause 10.6. The verb concept and Synonymous Form are added.

    This glossary entry requires no change.

    weekday of year converts to time set on the Gregorian year of days scale
    The definition has the same structure as the previous one, and requires no further changes.

    Clause 13.4

    hour of day converts to time point sequence on the day of seconds scale

    The definition of this concept relies on normal everyday arithmetic, not on time point arithmetic. As discussed in clause 5.1, this specification uses but does not define ordinary arithmetic.

    The definition fails to specify that the resulting time point sequence is a part of the day of seconds scale. It is updated to make that clear. This is another definition that requires the new verb concept ‘time point sequence is on time scale’.
    minute of day converts to time point sequence on the day of seconds scale
    As with the previous glossary entry, the definition of this one uses ordinary arithmetic but fails to state that the result is on the day of seconds scale.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date Time Issue - compound quantity value cardinality mismatch

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

    A Necessity under "compound quantity value has atomic quantity value" in Annex D.2.3 says:

    Necessity: Each compound quantity value has at least two atomic quantity values.

    I believe this is correct.

    Problem: the UML diagram in figure 79 at the start of Annex D.2.3 shows cardinality "1..*" at the "atomic quantity value" end of the corresponding association.

  • Reported: DTV 1.0b1 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    Accepted. The UML diagram will be changed. Other minor improvements are also made to the diagram.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue: now is not synonymous with current

  • Key: DTV-19
  • Legacy Issue Number: 16717
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    There are some terms that map to the same underlying concepts, but they are not synonymous because one cannot be substituted for the other. Often this is a matter of how they fit into context as being relative or not. In particular:
    a. “now” is not synonymous with “is current”
    b. “today” is not synonymous with “current day”
    c. “tomorrow” is not synonymous with “upcoming day”
    d. “yesterday” is not synonymous with “previous day”
    Proposed Resolution:
    (The submission team adopted these changes after the final submission. They are recorded here so that the FTF team can reconsider them.)

    Make these changes in clause 9.2:
    • Insert the article "the" in front of the Definition of "time interval is current" so that the Definition reads: "the time interval includes a time interval1 that is past and includes a time interval2 that is not past"
    • Add a new glossary entry:
    time interval is now
    Definition: the time interval overlaps the time interval of utterance
    Note: "Time interval of utterance" means the time interval when a proposition is given, as opposed to when the proposition is evaluated.

    The following actions are pending, from the minutes of the submission team conference call on September 9, 2011:
    • Distinguish “today” (and similar concepts) from “current day”.
    • Make sure all fact type definitions use the appropriate style
    • Find and fix relative times that are styled as individual concepts but aren't.
    • Clarify note under “day” to make it clear (if it isn't already) that we ignore leap seconds.

  • Reported: DTV 1.0b1 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The DTV FTF-2 team chose to focus clause 15 "Indexical Concepts" on 'current time' and delete all support for 'now'. Reasons for this include:

    • As best practice and to avoid ambiguity, rules that need to refer to the time when a rule is stated (put into effect) should reference that time by a time coordinate or as an occurrence.
    • To avoid an 'explosion' in the number of indexical concepts in this clause.

    To implement this decision, clause 15 "Indexical Concepts" is reworked to provide only indexical concepts that are relative to 'current time'.

    Similar changes are made to the characteristic 'state of affairs is now', and related characteristics, in clause 16.7.

    For ease of use, the FTF-2 team decided to adopt a consistent naming pattern for the indexical time concepts. The naming pattern is described in the new clause 15.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue: CLIF file should include metadata

  • Key: DTV-18
  • Legacy Issue Number: 16715
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The machine-readable CLIF file contains the CLIF axioms mechanically stripped out of the specification document. Currently, it is very difficult to trace back from the individual CLIF file entries to the matching source entries in the document. The CLIF file should include metadata (presumably as annotations) that relate each axiom to the appropriate place in the document.

  • Reported: DTV 1.0b1 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    In the CLIF and OCL machine-readable files, the text of the preceding SBVR Definition or Necessity caption is inserted as a comment in front of each CLIF axiom or OCL constraint. This provides traceability from the CLIF and OCL entries back to the specification document.

    The following metadata is added to the start of both the CLIF and OCL machine-readable files, each as commentary in the syntax appropriate to each file format. This metadata is modeled after the proposal by Elisa Kendall to the OMG Architecture Board.

    • moduleName: Date-Time Vocabulary
    • moduleAbbreviation: DTV
    • moduleVersion: 1.0
    • moduleAbstract: This file contains CLIF (or OCL) for portions of the Date-Time Vocabulary. See http://www.omg.org/spec/DTV.
    • filename: dtv.clif
    • documentNumber: dtc/2012-10-12
    • documentURL: http:/www.omg.org/spec/DTV/20121201/dtv.clif
    • isNormative: true
    • contentType: vocabulary
    • contentLanguage: http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007%28E%29.zip
    • format: CLIF
    • directSource: http:/www.omg.org/cgi-bin/doc?dtc/2012-10-09
    • copyright: Copyright (c) 2012, Object Management Group

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue - states of affairs and situation models

  • Key: DTV-12
  • Legacy Issue Number: 16678
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    During the development of the submission, the submission team could not reconcile its requirements against the SBVR "state of affairs" and related concepts. The submission team resolved this problem by developing its own "situation model" approach. It assumed that the "situation model" design would be a stand-in for a better long-term design agreed with the SBVR RTF.

    The issue is highlighted by these two paragraphs that were in the submission and which the Architecture Board asked to have removed from the specification:

    • In clause 7.3 introduction, "Temporal Concepts for Situations":

    " Note: This specification introduces the concepts 'situation model' and 'occurrence' in order to present a complete and self-consistent vocabulary. SBVR has similar concepts 'state of affairs' and 'actuality' but, to date and after discussion with the SBVR RTF, the Date-Time submission team does not understand how to relate the Date-Time concepts with the existing SBVR concepts. The most pressing concern that Date-Time has with SBVR is that it is unclear how to relate a single proposition to multiple occurrences."

    • In the clause 7.3.6 introduction:

    " NOTE: In this section, situation model is said to be a specialization of the SBVR concept 'res', i.e., a thing that is not a 'meaning'. This is to distinguish 'situation model' from both SBVR 'concept' and 'proposition'. This specification treats the situation model as a thing in its own right, even though it is an abstraction, and relates it to occurrences by 'occurrence exemplifies situation model', rather than by SBVR 'meaning corresponds to thing'. It is worth noting that this specification may be misusing the SBVR concept 'proposition', for the reasons discussed above."
    The SBVR RTF has been considering a number of formal Issues raised against SBVR regarding "state of affairs". The SBVR RTF has committed to addressing these issues in the SBVR RTF 2 by February 28, 2012. Once those Issues are resolved in the SBVR RTF, then this Issue should be addressed in the Date-Time FTF.

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

    The resolution to issue 18173 addresses the concerns raised in this issue by defining 'situation kind' (new term for 'situation model') and 'occurrence' as specializations of 'state of affairs'. 18173 also adds to the Date-Time Vocabulary a detailed discussion of the meaning of propositions in possible worlds that have time, and the interpretation of SBVR's 'state of affairs is actual'. This firmly ensconces the relationship between these DTV terms and SBVR.

    Revised Text:
    (none)

    Disposition: Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue - Atomic Quantity Value Conversion

  • Key: DTV-11
  • Legacy Issue Number: 16674
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The final submission document recorded the following issue under the OCL Definition for "atomic quantity value1 is atomic quantity value2 converted to measurement unit":
    Issue: These definitions are inadequate because they depend upon "quantity1 = quantity2" which is not defined. We need the concept "quantity value1 is equivalent to quantity value2".

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

    Annex D.3.3 defines 'atomic quantity value' and 'compound quantity value', and related verb concepts, but (a) these are not defined in VIM; (b) arguably, they are out-of-scope for DTV; (c) although originally intended as the basis for 'atomic duration value' and 'compound duration value' in clause 9.1, they are barely mentioned in that clause; (d) some of the definitions in clause 9.1 have technical errors. Because of the nominal durations of the time units 'month' and 'year' Clause 9.1 goes further by also defining "precise" and "nominal" versions of each kind of 'duration value'. In effect, clause 9.1 completely redefines all aspects of duration values. The dependencies in clause 9.1. on Annex D.3.3 can be eliminated with very little change.

    To simplify the specification, to fix some definitional errors, and to avoid concepts that may be out of scope, clause 9.1 concepts are adjusted to delete the dependencies on 'atomic quantity value' and 'compound quantity value', and the latter are dropped from Annex D.3.3.

    • Fix the Definition of 'precise atomic duration value' in clause 9.1.2, which should define 'precise atomic duration value' as a kind of 'quantity value'.
    • Fix the Definition of 'precise compound duration value' in clause 9.1.2 to show that it is a kind of 'compound duration value'.
    • Fix the Definition of 'nominal atomic duration value' in clause 9.1.2 to show that it is a kind of 'atomic duration value', and correct a reference in a Note.
    • Fix the Definition of 'nominal compound duration value' in clause 9.1.3, which should define 'nominal compound duration value' as a kind of 'compound duration value' rather than a kind of 'compound quantity value', and should say that it is composed of 'atomic duration values' rather than 'atomic quantity values'.
    • Change a reference in table C.1 to 'atomic quantity value' to instead reference 'duration value'.
    • Delete a note in an example in Annex C.2 that references 'compound quantity value'.
    • Update a note in 'particular quantity' in Annex D.3.1 to remove a reference to 'compound quantity value'.
    • Update the definition of 'quantity value' in Annex D.3.3 to use the definition from VIM.
    • Update a Note in 'quantity value quantifies quantity' to remove a reference to 'atomic quantity value'.

    Add 'quantity1 = quantity2", as a "See:" reference to SBVR's "thing1 is thing2".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue: Time Zones

  • Key: DTV-14
  • Legacy Issue Number: 16682
  • Status: closed  
  • Source: NIST ( David Flater)
  • Summary:

    13.5.4 "When there are two calendars for a time zone, one is standard time and the other is daylight savings time. The dates and time of day for changing between them is determined by local authorities for each time zone."

    Said authorities do, on occasion, change not only the dates and time of day for changing between local calendars, but the time offsets that apply within a locale. I would like to see the example that demonstrates how this specification would be used to reason coherently about events both prior to and after such a time zone transition in a continuously operating system (no big-bang updates allowed).

    Comment #2

    The Annex B references do not include the Zoneinfo database, ftp://elsie.nci.nih.gov/pub/, http://en.wikipedia.org/wiki/Tz_database.

    (Zoneinfo handles the situation mentioned in Comment #1 by making the locale identifier be the primary key. For example, if your time zone is America/New_York, then the different rules for Daylight Savings Time before and after the 2007 changeover are implicit in any conversion between local time and universal time.)

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue - Examples Related to Timezones

  • Key: DTV-13
  • Legacy Issue Number: 16679
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    (This comment came from the Architecture Board's review of the final submission.)

    The later sections of the specification (13.5.4 & 16.5) contain very detailed discussion of Time Zones and Daylight Saving Time. However, some of the earlier sections contain informal comments that don't always take this into account. For instance, on page 45 (clause 7.1.2) it says "Example: The time interval identified by 2010 is before the time interval identified by 2011." This glosses over the fact that 2010 and 2011 overlap by 24 hours, because 1 Jan 2011 was almost over in New Zealand before 1 Jan 2011 started in Hawaii. It might be worth quickly scanning all the examples, and perhaps amending language in some to take account of Time Zones.

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

    The entire document was scanned, and every example examined. Updates are made as necessary to avoid this confusion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue - time of day

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

    This issue was recorded in the final submission document regarding the concept "time of day":

    Issue: Consider whether "time of day" is a separate concept from "time of day coordinate".

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

    This issue duplicates issue 18167, which is merged with Issue 17425.

    Revised Text:
    See Issue 17425.

    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date Time Issue - time set2 is duration after time set1

  • Key: DTV-8
  • Legacy Issue Number: 16671
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The final submission document recorded the following issues about these verb concepts:

    Immediately under the glossary entry "time set2 is duration value after time set1":
    Issue: Should the second role be 'duration' instead of 'duration value'?
    Under the Definition for that entry:
    Issue: This is not quite right, because we do not have a verb concept that adds durations to time point sequences.
    And similarly, immediately under the glossary entry for "time set2 is duration value before time set1":
    Issue: Should the second role be 'duration' instead of 'duration value'?
    Under the Definition for that entry:
    Issue: This is not quite right, because we do not have a verb concept that subtracts durations from time point sequences

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

    These two verb concepts are about adding or subtracting duration values from time sets. They are not used anywhere in the specification, are superfluous, and are deleted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

D0 Should be Quantified

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

    Clause 7.2.2 has several CLIF axioms that reference 'D0' but fail to quantify that variable. They should each existentially quantify 'D0'.

  • Reported: DTV 1.0b1 — Thu, 17 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    In 8.2.2, D0 is declared to be an individual concept – a logical constant – under Axiom V.4. The problem is that there is no CLIF rendition of this axiom, and there needs to be a theorem that D0 is unique.
    In resolving this issue, the FTF noted that the CLIF operators (+, –, *) must be defined between durations, because they are not the same as the operators for numbers. And the closure axiom does not follow from the definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date Time Issue: quotation in OCL of UML symbols that include blanks

  • Key: DTV-17
  • Legacy Issue Number: 16714
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    During the Architecture Board's review of the final submission, Pete Rivett asserted that the document quotes UML symbols incorrectly when they are referenced in OCL statements. When a UML symbol includes a blank or other special character, the final submission wraps the symbol with double-quote characters. Peter Rivett says that UML has adopted another quoting mechanism. We need to check the UML standard and also what the tools actually support.

  • Reported: DTV 1.0b1 — Thu, 17 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The specification is updated to quote OCL symbols using a leading underscore-single-quote character pair and a trailing single-quote character per the latest OCL specification. For example, the symbol 'time interval' is quoted as _'time interval' in OCL.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CLIF Logic Errors

  • Key: DTV-16
  • Legacy Issue Number: 16690
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Various logical errors in the CLIF axioms need correction:

    1. In clause E.1.2, the axiom under concept "sequence is of concept" reads:

    (forall ((member thing) (s sequence))
    (exists ((c concept))
    (iff ("sequence is of concept" s c)
    (if "member participates in sequence" member s)
    ("concept corresponds to instance" c member)))))

    and should probably read:

    (forall (s sequence)
    (exists (c concept)
    (iff ("sequence is of concept" s c)
    (forall (member thing)
    (if ("member participates in sequence" member s)
    ("concept corresponds to instance" c
    member))))))
    2. Several of the verb concepts in clause E.1.5 range specifically over "unique sequences". In several cases, the axioms are not written to match the concept types that the roles range over.

  • Reported: DTV 1.0b1 — Thu, 17 Nov 2011 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The formulations in (1) are logically equivalent, but neither is the definition of ‘sequence is of concept’. Issue 17225 points out that the structure of the definitions in Annex D is generally poor. The text that resolves this issue is included in that resolution.

    Revised Text:
    none.

    Disposition: Merged with Issue 17225

  • Updated: Fri, 6 Mar 2015 20:58 GMT

‘Time of Day’ misused

  • Key: DTV-53
  • Legacy Issue Number: 18167
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Title: ‘Time of Day’ misused
    Source: Mark Linehan, IBM, mlinehan@us.ibm.com

    Summary:
    The term ‘time of day’ is a synonym for ‘time of day coordinate’ in clause 12.1, but is used in the sense of a time point in several places in clauses 9.5.4 and 9.5.6

    The glossary entry for ‘local time’ in clause 9.5.4 refers to a non-existent term ‘standard time of day’.

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

    The term 'local time' is redefined as meaning a kind of 'time point'.

    The reference to 'standard time of day' is replaced with a reference to the existing term 'standard time'.

    This issue was merged with Issue 17425, which moves the time of day concept to clause 10.

    Revised Text:
    See Issue 17425.

    Disposition: Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Confusing text for Gregorian calendar

  • Key: DTV-39
  • Legacy Issue Number: 17427
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    It is not clear what list the text bullets following the diagram in 12.3.1 are members of, and they are not sentences. Further, they have the pattern: "Gregorian year coordinate composed of a Gregorian year, for example 2010", but coordinates are defined to 'indicate' time points. They are not "composed of" time points in any sense. On the other hand, a 'G. year month coordinate' is composed of two time coordinates, but not two time points.

    The definition of 'Gregorian year coordinate' is: "absolute atomic time coordinate that indicates a Gregorian year that has the index equal to the index of the Gregorian year coordinate". The term 'Gregorian year coordinate' is being used in its own definition. The definition should read: "absolute atomic time coordinate that indicates a Gregorian year". (There are no other time coordinates that indicate Gregorian year time points.) There is a related Necessity: Each Gregorian year coordinate indicates the Gregorian year that has an index that is equal to the index of the Gregorian year coordinate. This pattern also applies to G. day of month, G. day of year coordinates, and hour, minute, second coordinates. It applies to numeric 'Gregorian month coordinates', but the time coordinate "January" does not have an index, per se. "January" is a term for the time point, but not an index (integer). The UML model (Figure 12.3) makes 'atomic time coordinate has index' a derived relationship, but that is false, given the intent: the index of the time coordinate is used to identify the time point, not taken from the identified time point. And in that case, the non-derived 'index' property is 0..1.

    The definition of 'Gregorian year month coordinate' misuses the verb concept 'compound time coordinate combines atomic time coordinate': "Definition: absolute compound time coordinate that combines the set of

    {a Gregorian year coordinate, a Gregorian month coordinate}

    and indicates the Gregorian month that..." A 'set' is not an 'atomic time coordinate' and cannot play that role. What is intended is:
    "Definition: absolute compound time coordinate that combines a Gregorian year coordinate and that combines a Gregorian month coordinate and that indicates a Gregorian month." That is sufficiently delimiting. The structural rule that determines which month it indicates can be stated as a separate Necessity. This "combines the set of" pattern is used in every compound time coordinate definition in 12.3.

    Note also that the formal statement of these definitions/necessities suffers from the lack of a basic arithmetic vocabulary (in Annex D?). Elsewhere DTV just says the arithmetic expressions are described in English or mathematical notations. If the arithmetic expressions are removed from the definitions, it becomes easier to do that. The mathematical formulations can be stated in CLIF and OCL.

  • Reported: DTV 1.0b1 — Thu, 14 Jun 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    Clauses references in this second are to the beta-2 specification.

    The lists of Gregorian calendar, week calendar, and time of day time coordinates are revised to make them clearer and more formally linked to the glossary entries. The glossary entries themselves are revised along the lines suggested in the summary.

    ‘January’ is a term for a time point on the Gregorian year of months scale. That time point does have an index on that scale. Hence the construction ‘index of January’ is valid.

    The use of ordinary arithmetic, unstyled, is described in clause 5.1 and continues with this resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML vs. text inconsistencies in clause 12

  • Key: DTV-38
  • Legacy Issue Number: 17426
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 12.1.2, Figure 12.3 shows an association 'atomic time coordinate has index', but no such verb concept is declared in the text. (The verb concept, however, is used in numerous definitions.)
    In clause 12.3.1, the UML diagram refers to a 'G. month of year coordinate', which is not documented in the text, and it says the 'G. day of year coordinate' is compound, but it is defined in the text to be atomic.

  • Reported: DTV 1.0b1 — Thu, 14 Jun 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The missing ‘atomic time coordinate has index’ is added and the diagram is corrected to match the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Corollaries to Axiom D.4 in 8.2.3 are misstated

  • Key: DTV-28
  • Legacy Issue Number: 16992
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.2.3 (p.54), the first corollary to axiom D.4 is stated in mathematical English:
    If t1 and t2 are time intervals such that t1 starts t2, then D(t1 starts t2 complementing t3) = D(t2) ­
    D(t1).
    But "t1 starts t2 complementing t3" is a proposition, which does not have a duration. The intent is:
    If t1, t2 and t3 are time intervals such that t1 starts t2 complementing t3, then D(t3) = D(t2) ­ D(t1).

    There is a further requirement, namely that time interval t2 is "finite" (which does not seem to be a concept in clause 8). 'Time interval has particular duration' cannot always be satisfied. So it appears that the term 'finite time interval' must be defined: A time interval that has a duration.

    The CLIF formulation of this corollary is also incorrect. It should read:
    (forall ((t1 "time interval") (t2 "time interval") (t3 "time interval"))
    (if
    (and
    (exists ((d duration))
    ("time interval has duration" t2 d)
    ("time interval1 starts time interval2 complementing
    time interval3" t1 t2 t3))
    (= ("duration of" t3)
    (- ("duration of" t2) ("duration of" t1))) ))

    If the concept 'finite time interval' is added, then this can be simplified:
    (forall ((t1 "finite time interval") (t2 "finite time interval")
    (t3 "finite time interval"))
    (if
    ("time interval1 starts time interval2 complementing
    time interval3" t1 t2 t3)
    (= ("duration of" t3)
    (- ("duration of" t2) ("duration of" t1))) ))

    The second Corollary has the same problem. It reads:
    If t1 and t2 are time intervals such that t1 finishes t2, then D(t1 finishes t2 complementing t3) = D(t2) ­
    D(t1).
    It should read:
    If t1, t2 and t3 are time intervals such that t1 finishes t2 complementing t3, then D(t3) = D(t2) ­ D(t1).

    The CLIF formulation of the second corollary is also incorrect. It should read:
    (forall ((t1 "finite time interval") (t2 "finite time interval")
    (t3 "finite time interval"))
    (if
    ("time interval1 finishes time interval2 complementing
    time interval3" t1 t2 t3)
    (= ("duration of" t3)
    (- ("duration of" t2) ("duration of" t1))) ))

    In both cases, the existence of time interval t3 is the subject of a different axiom. So it suffices to say, for any three time intervals that are related in a certain way, their durations are related in a certain way.

    The remaining issue is that Clause 8.2 does not define the CLIF function for the SBVR attributive construct 'duration of'. Axiom D.2 suddenly introduces the notation "duration of" as a function. The intent is that the fact type 'time interval has duration' introduces both a CLIF predicate "time interval has duration" AND a CLIF function, which can be defined axiomatically as:
    (forall ((t "finite time interval") (d duration))
    (iff ("time interval has duration" t d)
    (= ("duration of" t) d) ))
    This declaration should be added to the entry for the fact type that introduces the "attributive role" 'duration'.

    Note also that construction of a CLIF function from an SBVR attributive role pattern only behaves as expected when the role is played by a unique thing for each possible value of the function argument. If it is possible that the role is empty or multivalued for a valid argument, the CLIF function would have to be described as returning a set. So this construct does not follow some general pattern. It must be appropriately declared in each case. In this case, the supporting axiom:
    Necessity: Each time interval has at most one particular duration.
    should be stated, and then the above function axiom completes the model.

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

    The technical changes to the CLIF formulations are accepted in principle. The formulation of the Corollaries is corrected. The CLIF function "duration of" is defined. The definition of 'particular duration' and the related axioms are modified. The style of the CLIF formulations, however, follows Issue 17225.
    The FTF disagrees that the concept “finite time interval” is needed. It is the intent of the DTV that all time intervals are “finite” – they have a beginning and an end. But the open world assumption may apply: Time intervals can be “indefinite” in the sense that we don’t know the beginning or the end. This is clarified in the text.
    There are other errors in the formulation of the axioms in 8.2.3 with respect to the “duration of” role, and they are also corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Time point subdivision is out of place twice

  • Key: DTV-27
  • Legacy Issue Number: 16951
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    At the end of section 9.3 the fact type 'finite time scale subdivides time point' is defined and depicted in Figure 9-6. This fact type is a commonly used property of finite time scales, and is not specific to individual time points. That is, the finite time scale day-of-hours subdivides every day-of-month, for example. So the text and diagram should be at the end of 9.2, where finite time scale is defined.

    Also, diagram 9-6 does not show the operations on time point and finite time scale that are associated with this fact type and shown in diagram 12-12.

    Finally, diagram 12-12 (section 12.4) shows this fact type as well, but section 12.4 never uses it, and diagram 12-12 shows a <<specialization>> relationship that is never discussed anywhere in the text. If the relationship is important, it should be discussed. Otherwise, the subdivision association is out of place in diagram 12-12 and the "specialization" dependency should be deleted from the UML model.

    Recommendation:

    Move the diagram and text for 'finite time scale subdivides time point' to the end of 9.2, include the operations on the diagram. Delete the fact type from diagram 12-12, and delete the "specialization" dependency altogether.

  • Reported: DTV 1.0b1 — Tue, 10 Jan 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The FTF agrees that the fact-type 'finite time scale subdivides time point' should be moved, along with Figure 9-6, but it depends on concepts defined in 9.3 and 9.4. It is an important concept that should have its own subsection. This concept is used only in defining finite time scales within Calendars. So the new section goes in clause 10 (formerly 9.5) Calendars.
    The verb concept 'finite time scale subdivides time point' is not quite the way it is used. All of the existing usages have the form: 'finite time scale subdivides time point into number of time point kind.' But the finite time scale determines the time point kind, so that is redundant. Also, it is not clear whether the intent is to specify the cardinality of the finite time scale or the cardinality of the time point sequence that is the subdivision of individual time points, such as months of the year. The text is revised to distinguish subdivides as a characteristic of finite time scales from the specification of the actual time point sequences used to subdivide individual time points. The term exactly subdivides is used when all the time points have the same subdivision; and the special cases use the (now defined) verb 'time point has number of time point kind' that was already present in the entries for the special cases.
    Note: This clarification was not applied to the 'year of weeks' and 'year of weekdays' time scales, whose nature is addressed by a different issue. Simply stated, the year of weeks does not subdivide a calendar year.
    The concept in diagram 10.14 (formerly 12.12) – time point converts to time point sequence on time scale – is only distantly related. The nature of the time point sequences involved is different, and the purposes are different. The purpose of time point subdivision is to be part of the definition of finite time scales. Diagram 10.14 (formerly 12.12) no longer shows the "specialization"; it was removed by resolution of another issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Editorial issue: Figures 9-5 and 9-7 should be reversed

  • Key: DTV-26
  • Legacy Issue Number: 16949
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    On p.82, in the middle of section 9.3, the UML diagram that is Figure 9-5 is about the concepts that are in section 9.4, and the UML diagram that is Figure 9-7 (in section 9.4) depicts the concepts on p.82.

    I don't know whether to file this as an official issue or not. We can fix this if we have to change the diagrams anyway.

  • Reported: DTV 1.0b1 — Tue, 10 Jan 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The issue is correct – the diagrams don’t match the text. The problem, however, is that part of the concept set for 8.5 (was 9.3) is missing, and part of it should be in 8.6 (was 9.4).
    Two concepts on the UML diagram in Figure 8.16 are missing from the text. They are added.
    The entire subsection in 8.5 that is about time point sequences is moved to 8.6.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Weekday definitions are inadequate

  • Key: DTV-25
  • Legacy Issue Number: 16944
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The definitions of the weekdays in 9.5.6 simply identify them as 'day of week' time points. ('day of week' is erroneously represented as a name instead of a noun concept) What is being defined in the textDTV is apparently the individual time point, but the UML diagram shows that each day of week time point is in fact a general concept (that corresponds to time intervals). The text should make this clear.

    Further, the delimiting property for each of these concepts is specified in a Necessity that is intended to be taken as part of the definition: e.g., Each Tuesday is met by a Monday. That is, the intended definition of the general concept 'Tuesday' is: time interval that is an instance of a calendar day and that is met by an instance of Monday. The definition of the individual concept "Tuesday" is: the time point that has index 2 in the week of days scale, and that is the concept 'Tuesday'. Somehow the text has to make these two definitions clear.
    It takes significant effort for the reader to understand that the individual 'Tuesday the time point' can have instances, so that "each Tuesday" makes sense. It may be sufficient to phrase the Necessity as:
    Each instance of (time point) Tuesday is met by an instance of (time point) Monday. (SBVR Annex C provides a notation [Tuesday] to refer to the concept as a thing, and CLIF has no problem with the designation (symbol+concept) playing both predicate and argument roles.)

    Finally, the following Necessity should appear under 'calendar day' in 9.5.3:
    For each calendar, each instance of a 'calendar day' that is defined by the calendar is met by at most one instance of a calendar day that is defined by the calendar. Otherwise, the ontology could technically permit a day to be both a Tuesday and a Friday. It may be that this follows from the necessities for the relationships of the time scales to the Time Axis. If so, the Necessity is not needed, but a Note should mention the sequencing rules.

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

    The last element above, the missing axiom, is added to clause 10.2.
    The FTF agrees that the Necessities in 12.3 (was 9.5.6) do not follow from the definitions, and they are not quite accurate as concept definitions: For example, a time interval is a Tuesday if and only if it is a Gregorian calendar day and is met by a Monday. The current definitions just state facts about the concepts. So the text is revised to define the day-of-week time points generally as concepts and relate the terms ‘Monday’, etc., to the time points defined by their positions in the time scale.
    This problem was found to apply to the definitions of Gregorian months in 11.3 (was 9.5.5) as well, and this resolution corrects those definitions as well. The month-of-year concepts, however, must be defined individually – there is no general definition of the corresponding time intervals.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV time-of-day time point definitions are inaccurate

  • Key: DTV-34
  • Legacy Issue Number: 17232
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In DTV Clause 9.5.2, all the time-of-day time point definitions are similar. For example, it defines 'hour of day' as: time point that is on the day of hours scale and that is identified by the number of elapsed full hours since midnight on a given calendar day

    But each 'hour of day' is a category of time intervals. The time point is "identified by" its index. The "number of elapsed full hours" is how the index and the time point relate to the corresponding time intervals. The definition should read something more like:
    time point that is on the day of hours scale and that /corresponds to/ each time interval that has duration 1 hour and that starts a calendar day, if the index of the time point is 0, or that has duration 1 hour and that is met by a time interval that starts a calendar day and that has duration n hours, where n is the index of the time point and is not 0.

    The other definitions should be similar. Similarly, 'midnight' appears to be the time point that corresponds to each time interval that has duration 1 second and that starts a calendar day. It is nominally an event that occurs exactly 12 hours before a reference "noon" – a zenith of the sun.

  • Reported: DTV 1.0b1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The FTF agrees that the relationship between the time of day time points and the time intervals should be clarified. The general approach is to define these relationships as axioms (SBVR Necessities

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: inaccurate formulation of definitions in CLIF

  • Key: DTV-33
  • Legacy Issue Number: 17225
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: Date Time Vocabulary
    Version: beta-1
    Title: inaccurate formulation of definitions in CLIF
    Source: Michael Gruninger <gruninger@mie.utoronto.ca>

    Summary:
    In the OMG Date Time Vocabulary, all of the axioms use relativized quantifiers,
    even for defined relations. For example,

    (forall ((t1 "time interval") (t2 "time interval"))
    (iff ("time interval1 equals time interval2" t1 t2)
    (and ("time interval1 is part of time interval2" t1 t2)
    ("time interval1 is part of time interval2" t2 t1))))

    This sentence is equivalent to

    (forall (t1 t2)
    (if (and ("time interval" t1) ("time interval" t2))
    (iff ("time interval1 equals time interval2" t1 t2)
    (and ("time interval1 is part of time interval2" t1 t2)
    ("time interval1 is part of time interval2" t2 t1))))

    It seems to me that what is really wanted is
    (forall (t1 t2)
    (iff ("time interval1 equals time interval2" t1 t2)
    (and ("time interval" t1) ("time interval" t2)
    ("time interval1 is part of time interval2" t1 t2)
    ("time interval1 is part of time interval2" t2 t1))))

    Recommendation:
    For all of the predicates that are type-specific, change all the definitions to use simple quantifiers and make the typing of the arguments part of the equivalent condition. This would also eliminate the need for many uses of relativized quantifiers in other Date Time Vocabulary axioms.

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

    The FTF concurs with the proposed change of practice for specification of definitions in CLIF.
    The resolution of this issue addresses a number of changes to the CLIF specification elements, including other changes in the style of formulations and the repair of various CLIF syntax errors, including those noted in Issue 16690.

    These corrections are applied in a single "bulk" change in order to ensure that that the CLIF logic matches the SBVR design and because it is easiest to work in one language at a time.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: There is no smallest time interval

  • Key: DTV-35
  • Legacy Issue Number: 17367
  • Status: closed  
  • Source: NIST ( Fabian Neuhaus)
  • Summary:

    Section 8.1.1 of the Date Time Vocabulary specifies a minimal mereology for time intervals, but fails to address the question of whether there are any "atoms" – time intervals that contain no other time intervals.
    If there could be atomic time intervals, then the axioms in section 8.1 are insufficient to prove some of the "corollaries". It appears that the intent of 8.1 requires an axiom that is not stated: There is no smallest time interval. For each time interval t, there is a time interval that is a proper part of t.

    Also, it is not clear from 8.1.3 that any time interval must have a proper part that starts it, or a proper part that finishes it. A proper part need not have a complement, and no axiom asserts that "time interval1 is properly during time interval2" implies the existence of "complementary" time intervals that start and end time interval2. It only implies the existence of two disjoint proper parts

  • Reported: DTV 1.0b1 — Tue, 15 May 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The issue is accepted. The missing axiom will be added to 8.1.1, and a third complement axiom will be added to 8.1.6.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

forever is misdefined

  • Key: DTV-30
  • Legacy Issue Number: 16997
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 9.4, 'forever' is defined as: "the time period that does not
    start on some time point and does not end on some time point". This is
    interpreted "there are two time points t1 and t2 such that the time
    period does not start on t1 and does not end on t2". What is intended
    is "the time period that starts on no time point and that ends on no
    time point". Further, this definition does not identify any time point
    sequence that makes the term 'time period' appropriate, and it
    eliminates all described ways to define a time point sequence. It seems
    that 'forever' should be classified 'time interval', with the above
    qualifications, not 'time period'. Or perhaps the intent is: "the time
    period that is the instance of each time point sequence that has no
    first time point and that has no last time point".

    Also, some Note should clarify the relationship of 'forever' to the Time
    Axis. Clause 8.1 does not say that the Time Axis is a time interval.
    Is 'forever' the time interval that is the "segment of the Time Axis"
    that covers all of it? Or is 'forever' the same thing as the Time
    Axis? I.e., is the Time Axis itself a time interval and 'forever' a
    synonym?

  • Reported: DTV 1.0b1 — Tue, 10 Jan 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    Resolved by issue 17540 and 16993.

    Revised Text:
    Disposition: Duplicate or Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no syntax for indefinite time periods

  • Key: DTV-29
  • Legacy Issue Number: 16993
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    A time interval that starts at a definite time (be it "now", or "starting when 13 states have signed the declaration", or "starting when the exchange offers our stock on the floor", and continues without end is a different kind of "forever" than the time period specified in 9.4.

    Similarly, there are intervals that start at indefinite time in the past and end at a stated time ("now" or whatever). Such intervals are referred to in phrases such as "Until the Wildlife Protection Act goes into effect in 2016", where no event marks the start of the interval in question - only its end.
    These are cases in which
    a) a time period has a first time point but no last time point, or
    b) a time period has a last time point but no first time point.

    Unlike 'forever', which is unique, those categories of time period have infinitely many instances. And unlike time periods that have a start time and an end time, or a start time and a duration, the DTV does not provide a simple fact type for specifying them: the time interval 'after (time point)' or 'from (time point) on', and the time interval 'until (time point)'.

    Some such fact types would clearly be useful in a business vocabulary.

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

    The resolution of issue 17540 adds the concepts ‘primordiality’ and ‘perpetuity’ as individual time interval concepts. This resolution adds verb concepts such as ‘time interval1 to situation model specifies time interval2’ that can be used with any time interval, including ‘primordiality’ and ‘perpetuity’, to mean a time interval that extends until an occurrence of the situation model.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

rename 'calendar date'

  • Key: DTV-37
  • Legacy Issue Number: 17425
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    DTV section 12.3.4 defines 'calendar date' as: "Gregorian year month date coordinate or Gregorian day of year coordinate or year weekday coordinate".
    This is clearly a definition of 'Gregorian calendar date' or 'Gregorian date'. The general concept 'calendar date' is "absolute time coordinate that indicates a time point that corresponds to exactly one calendar day". The list given in the definition is just the ones defined for Gregorian calendars. The general concept 'calendar date' is useful, and the term should not be assigned to Gregorian dates only. As defined, a 'date time' (date and time) also requires a Gregorian date, but it is not clear that there is a useful generalization.

    Recommendation: Rename 'calendar date' to 'Gregorian date' or something the like, and define the general concept 'calendar date' as well.

  • Reported: DTV 1.0b1 — Wed, 13 Jun 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    (All references hereafter are to the Beta-2 specification.)
    This resolution addresses the concerns in Issues 16669, 16672, 17429 and 18167, which are interrelated and change the same parts of the specification.
    The FTF agrees that the general concept ‘calendar date’ is useful, and that the current concept should be renamed ‘Gregorian date’. Similarly, the term ‘date coordinate’ is generalized, and ‘Gregorian date coordinate’ is added. The generalized definition of ‘calendar date’ takes into account the recommendation in issue 17429 that it refer to absolute time coordinate.
    Issue 17429 points out that the definition of ‘calendar date’, now ‘Gregorian date’, confuses ‘Gregorian day of year coordinate’ with ‘Gregorian year day coordinate’, and that is also corrected.
    The FTF also determined that the general concept ‘time of day’ goes beyond UTC and its derivatives, and should also be included in Clause 10. Together with 'calendar date', this permits the notion ‘date and time coordinate’ to be generalized and included in Clause 10.
    Issue 18167 and Issue 16672 point out that ‘time of day’ and ‘time of day coordinate’ are distinct concepts and need to be properly distinguished in the process of generalization.
    Issue 18167 and 16669 point out that the glossary entry for ‘local time’ in clause 10.3 refers to a non-existent term ‘standard time of day’. The term 'local time' is implicitly clarified to mean a kind of 'time point', and the reference to 'standard time of day' is replaced with a reference to the existing term 'standard time'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need Profile for UML Stereotypes

  • Key: DTV-32
  • Legacy Issue Number: 17129
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The DTV UML model uses various stereotypes that are document in clause 5.2. These should be "documented" in a UML profile.

    Also, SBVR changed the primary term for "fact type" to "verb concept" and for "fact type role" to "verb concept role". The stereotypes and the description in 5.1 should be updated to match.

  • Reported: DTV 1.0b1 — Mon, 13 Feb 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The FTF agrees that there should be a formal UML profile for the stereotypes in the DTV specification.
    The FTF believes that it is in the best interest of SBVR users and developers that a UML Profile for SBVR be developed by the OMG as an extension to SBVR. In the interim, the FTF agrees to document the profile used in DTV in a DTV annex.
    The FTF intended to represent a verb concept that involves more than two roles in UML by an N-ary Association. However, support for N-ary associations in UML v2.4 tools is highly variable. For this reason, this specification represents a verb concept with 3 or more participating verb concept roles as a Class with a «verb concept» stereotype.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Model Should be Vendor-Independent

  • Key: DTV-31
  • Legacy Issue Number: 17128
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The UML model included in the beta-1 specification contains a number of Magic Draw extensions. The extensions make the file unreadable by any but the Magic Draw tool. An OMG machine-readable file should be vendor-independent.

  • Reported: DTV 1.0b1 — Mon, 13 Feb 2012 05:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The FTF-2 decided to provide both a CMOF-standard machine-readable file and a Magic Draw vendor-specific machine-readable UML file. The former contains no diagrams since CMOF does not support diagrams. The latter offers those users who have Magic Draw a UML file with the diagrams.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Quantity Kind is a categorization type

  • Key: DTV-36
  • Legacy Issue Number: 17404
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: Date Time Vocabulary
    Version: beta-1
    Title: Quantity Kind is a categorization type
    Source: Ed Barkmeyer, NIST, edbark@nist.gov (as directed by the FTF)

    Summary:

    Section D.3.1 of the Date Time Vocabulary declares the concept 'quantity type' as follows:
    Definition: categorization type for ‘quantity’ that characterizes quantities as being mutually comparable
    Concept Type: concept type
    Figure D.5 shows 'quantity kind' as a <<concept type>>

    It appears that the SBVR tag Concept Type should have the value 'categorization type', to match the definition. Moreover, the UML <<concept type>> stereotype does not carry the more important "powertype" semantics that typifies a categorization type. The UML diagram should show 'quantity kind' as a powertype or categorization type. Making it a powertype should also result in a formal UML specification that its instances classify 'quantity'.

  • Reported: DTV 1.0b1 — Mon, 4 Jun 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The FTF agrees that that quantity kind is a categorization type. The powertype aspect is addressed in the UML Profile for SBVR.
    Also a CLIF Axiom for ‘quantity kind’ is mis-stated.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue: Propositions, Situation Models, and Occurrences

  • Key: DTV-4
  • Legacy Issue Number: 16664
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Comments about section 7.3.6, "Propositions, Situation Models, and Occurrences"
    > “This is because many propositions describe a single situation
    > (a "general situation model") that may have multiple occurrences.”
    The paragraph containing this statement and the paragraph above are reworded by Mark. But this statement remains unchanged. If the statement is about a single general situation model, then it should not say “single situation”. Situations are not models. On the other hand, if it is about the single situation, it would be more clear to say that where a proposition corresponds to a single situation, that situation might occur at various other times than at the current time of the world for which the truth of the proposition is being considered.

    > “For example, the proposition "rental car 123 is inspected", using a fact
    > type "rental car is inspected", describes multiple occurrences if the rental
    > car is inspected more than once.”
    This is from Mark’s rewrite of paragraph 2.
    The problem with the statement is that the proposition given as an example does not fully describe occurrences. It describes a circumstance that is included by multiple occurrences. Each of the occurrences is a situation that includes Rental Car 123 being inspected and that further includes some other circumstance that distinguishes one occurrence from the others, such as it being a certain time. It could be said that the proposition partially describes those occurrences.

    > “In a temporal world, a logical sentence need not be true or false; it can be
    > sometimes true and sometimes false, and therefore neither true nor false.”
    This statement presumes the temporal world has no past/present/future. A “logical sentence” that is an interpretation of a natural language sentence about a world is considered to be true or false with respect to the current time in that world. Tense is used when describing past or future situations. There is no need to abandon truth-functional logic when temporal concepts are used. Indeed, time concepts are used widely and effectively in logic systems where “logical sentences” are either true or false, and never both, with respect to any world.

    > “For example, the proposition "activity A precedes activity B for a given order" …”
    This is unclear. But it might demonstrate the point made at the end of the same paragraph that the Date-Time submission might be misusing SBVR’s concept ‘proposition’. A more clear example would help us understand whether there is misuse or not.

    > “… each of the occurrences of John actually writing a book.”
    These words from an example in 12.3.6 (and similarly in 12.3.1) illustrate something missing from the Date-Time submission that, if provided, would help it to align with SBVR. According to the submission, there are occurrences of “John actually writing a book”. But the actual writing of a book by John is not a model. There are multiple occurrences of it and it is not a model, but an activity (a kind of state of affairs, or what Date-Time calls a “situation” in its clause 5.9). The Date-Time submission does not provide a fact type to relate a temporal occurrence to the activity, situation or circumstance that has the occurrence. That is unfortunate.

    > “Brazil wins the FIFA World Cup.”
    > “…both true and false, or neither, in a world that includes all of
    > the last 20 years.”
    The example under ‘proposition describes occurrence’ starts with an ambiguous statement. It is in present tense, so it either means that the winning is happening presently (the news bulletin at the final horn) or, by another interpretation, it means that Brazil wins from time to time: winning the FIFA World Cup is something that Brazil does. A world in which the current year is 2002 includes 1994 being in the past and excludes 1994 being the current year. The final statement describing the example seems to describe a world in which the present year is all of 20 different years, which is impossible. A possible world has one past, one present and one future. If the Date-Time submission abandons that fundamental idea, then it is no wonder that they claim that propositions are “both true and false, or neither”. It would be best to have a clear example and separates the ideas of whether a situation has been or will be actual from whether it is actual in the world under consideration. The truth of a proposition is based on whether the state of affairs to which it corresponds is actual. It is not based on how many times that state of affairs has occurred in that world’s past or will occur in that world’s future. I am not arguing against the fact type, ‘proposition describes occurrence’, which relates a proposition to occurrences across time. I am arguing against using a bad example to create confusion about how propositions are true or false.

    > “The situation model is the bindable target of an objectification…”
    I recall that there was already agreement to remove the statement above. Related notes were already corrected. A situation model is not a bindable target unless it is one of these: an individual concept, a variable or an expression. Also, a situation model is not a referent of a bindable target of an objectification unless it is a state of affairs.

    > “The proposition “John is writing a book” is true during the time periods of each of the occurrences of John actually writing a book”
    The proposition is true if John is writing a book. That’s all. The situation of John’s writing a book is actual if John is writing a book. That situation might be actual at different times, but other propositions would refer to those other times. E.g., “John was writing a book in 2010”, which is true or false on its own – that’s a different proposition. The primary failure in the thinking behind this section is the failure to recognize that a proposition corresponds to just what the proposition proposes and no more. The explanation of the example fails to explain how occurrences are distinguished, and therefore, fails to show how the proposition “John is writing a book” describes any of them other than that it describes one circumstance included in each of them. The proposition gives no indication of whether occurrences are distinguished by book (if John is writing multiple books, perhaps simultaneously) or by place (if writing on different devices) or by contiguous time interval (if John interrupts writing to eat dinner). Perhaps the verb phrase should be changed to “indefinitely describes” or “partially describes”.

    Proposed Resolution:
    (These changes were adopted by the submission team after the final submission. They are recorded in this Issue for reconsideration by the FTF).

    Replace the first two paragraphs of 7.3.6 with the following:
    In a possible world that has no notion of time, there is a 1-to-1 relationship between propositions and states of the possible world: A proposition is true if the state it describes is the state of that world, and it is false if the state it describes is not the state of that world. SBVR truth semantics reflect this model.
    When temporal concepts are introduced into the formal logic model, a distinction must be made between two aspects of the SBVR concept ‘proposition’ – a 'meaning' that is either true or false, and that corresponds to at most one situation. This is because many propositions describe a single situation (a "general situation model") that may have multiple occurrences. For example, the proposition "rental car 123 is inspected", using a fact type "rental car is inspected", describes multiple occurrences if the rental car is inspected more than once.

    Under "proposition describes situation model":

    Delete the Definition that reads " The situation model is the bindable target of an objectification that considers a closed logical formulation that means the proposition."

    Delete the Example that reads " The proposition “John is writing a book” is true during the time periods of each of the occurrences of John actually writing a book."
    Change the date in the Example that reads " It is true in the world of 1998 ..." to read "1994".

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

    (These changes were adopted by the submission team after the final submission. They are recorded in this Issue for reconsideration by the FTF). Replace the first two paragraphs of 7.3.6 with the following:
    In a possible world that has no notion of time, there is a 1-to-1 relationship between propositions and states of the possible world: A proposition is true if the state it describes is the state of that world, and it is false if the state it describes is not the state of that world. SBVR truth semantics reflect this model.
    When temporal concepts are introduced into the formal logic model, a distinction must be made between two aspects of the SBVR concept ‘proposition’ – a 'meaning' that is either true or false, and that corresponds to at most one situation. This is because many propositions describe a single situation (a "general situation model") that may have multiple occurrences. For example, the proposition "rental car 123 is inspected", using a fact type "rental car is inspected", describes multiple occurrences if the rental car is inspected more than once.

    Under "proposition describes situation model":

    Delete the Definition that reads " The situation model is the bindable target of an objectification that considers a closed logical formulation that means the proposition."

    Delete the Example that reads " The proposition “John is writing a book” is true during the time periods of each of the occurrences of John actually writing a book."
    Change the date in the Example that reads " It is true in the world of 1998 ..." to read "1994".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue - OCL Corrections

  • Key: DTV-3
  • Legacy Issue Number: 16662
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The OCL text throughout the specification needs to be checked for consistency against the UML diagrams. The following places were specifically noted in the submission document as requiring review:
    • The OCL definition for "time interval1 plus time interval2 is time interval3"
    • The OCL definition for "time interval1 to time interval2 specifies time interval3"
    • The OCL for the Axioms under "duration3 equals duration1 plus duration2", " duration3 equals duration1 minus duration2", "duration2 equals number times duration1"

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

    The OCL constraints throughout clause 8 are updated to match the SBVR text. These corrections are applied through this one "bulk" resolution update because it is the easiest way to ensure consistency between the text and the OCL.

    Most of these changes are needed to align the operation names in the OCL with the corresponding operation names in the UML diagrams. This realignment is needed because the diagrams and OCL were originally developed in parallel without the opportunity to match them up

  • Updated: Fri, 6 Mar 2015 20:58 GMT

time scale1 differs from time scale2 by time offset

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

    concept "time scale1 differs from time scale2 by time offset" in clause 8.5.4 "Time Zones":

    Issue: This verb concept needs to be reconciled vis-à-vis "calendar1 differs from calendar2 by time offset" in clause 16.5.
    Issue: 'Time offset' is defined above with reference to calendars but is used here as the difference between time scales.
    The same concerns were raised under the glossary entry for "calendar1 differs from calendar2 by time offset" in clause 11.5:

    Issue: 'Calendar has time offset' is not defined anywhere.
    Issue: Reconcile this verb concept vis-à-vis 'time scale1 differs from time scale2 by time offset' in clause 13.5.2.
    The following issue came after the glossary entry for "date time coordinate with time offset" in clause 11.5:
    Rework the definitions given above once we work out the "differ" relationships between calendars or time scales.

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

    Combine the ‘time scale1 differs from time scale2 by time offset’ and the ‘calendar1 differs from calendar2 by time offset’ verb concepts.

    No change to ‘date time coordinate with time offset’ is required.

    Combine beta-2 clause 10.4 “Time Zones and Daylight Savings Time” with clause 10.3 “Time Zones” since they address the same subject

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue - week of year

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

    The final submission document recorded this issue regarding the concept "week of year":

    Issue: This concept (and also 'weekday of year', 'year of weeks', and 'year of weekdays' are really about relating the weeks scale to the Gregorian calendar. Consider whether these concepts should be moved into the section that describes the Gregorian calendar.

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

    The beta-2 version of the specification contained a complete reorganization of the specification. At that time, the decision was made to keep these concepts in the "Week Calendar" clause.
    Revised Text:
    Disposition: No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Date-Time Issue - local time

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

    The final submission document recorded the following issue regarding the concept " local time" in clause 8.5.4 "Time Zones":

    Issue: "standard time of day" is not defined anywhere, and "standard time" is a time scale, not a time coordinate (as is "time of day"). "Standard time" and "local time" should be "time of day time scales" (e.g. time of day scales parallel to calendars).

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

    This issue is addressed by the resolution of issue 17425.
    Revised Text:
    Disposition: Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of Calendar Date

  • Key: DTV-41
  • Legacy Issue Number: 17429
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The definition of ‘calendar date’ is wrong. It reads ‘Gregorian year month date coordinate or Gregorian day of year coordinate or year weekday coordinate’. A calendar date should indicate a specific time interval, but a Gregorian day of year coordinate does not. It appears that the definition confuses ‘Gregorian day of year coordinate’ with ‘Gregorian year day coordinate’.

    Recommendation: change the definition to mention ‘Gregorian year day coordinate’ rather than ‘Gregorian day of year coordinate’. Clarify the intent of ‘calendar date’ by adding “General Concept: absolute time coordinate”, and by adding a Description such as “A calendar date indicates a specific time interval of duration ‘day’.”

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

    Correct the definition of calendar date (actually its successor 'Gregorian date') to include the ‘Gregorian year day coordinate’. Merge the other corrections to ‘calendar date’ with the changes to calendar date in Issue 17425.

    Revised Text:
    See Issue 17425.

    Disposition: Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

basic time coordinate concepts are badly described

  • Key: DTV-40
  • Legacy Issue Number: 17428
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Figure 12.1 shows 'time coordinate' as a specialization of SBVR 'representation', which is said to be the relationship between an expression and the meaning it denotes. No UML diagram shows 'time expression' (from 12.1.2), which one would expect to be the corresponding specialization of 'expression'.

    In 12.1, the definition of 'time coordinate' is: "representation of a time point by an atomic time coordinate or compound time coordinate that indicates the time point". This is both circular and incorrect. A time coordinate cannot represent a time point by a subtype of itself, it must represent a time point by an expression. The definition should read: "representation of a time point by a time expression" (to exclude representation by a definite description).

    One would expect a 'time expression' to be "the expression of a time coordinate" (from SBVR 'representation has expression', mislabeled 'expression uses representation' in the diagram), but it isn't. It is said to be an expression involving an index (integer) and a time scale, which means it is not the expression of a compound time coordinate.

    In 12.1.2, the definition of 'atomic time coordinate indicates time point' requires the time expression to contain an index, which means that the "February" example is invalid. The expression (string) "February" includes neither an index nor a time scale. The time coordinate, as a 'representation', is the association of "February" with the time point that is month of year 2. The atomic time coordinate thus acquires the time scale and index properties from the time point it indicates. But the expression "February" does not have those properties. "February" is associated with that time point via 'concept has designation'. If DTV is to explain how a time expression is associated with a time point, it has to distinguish the properties of the expression from the properties of the association (that SBVR calls a 'representation').

    A 'simple time expression' is either the expression of an 'index', which would be some expression of an integer, OR a 'signifier' for a time point (from SBVR 'concept has designation' and 'designation has signifier (expression)'). The signifier could be a given name, like "March", or a constructed term involving the scale and the index, like "Gregorian month 3". (What 12.1.2 describes is only the last case.)
    A 'compound time expression' is some syntax that combines two or more simple time expressions.

    In SBVR style, then, an atomic time coordinate is a time coordinate whose expression is a simple time expression, and a compound time coordinate is a time coordinate whose expression is a compound time expression.

    And the rules for determining what a simple time expression indicates, i.e., how the link that is the atomic time coordinate is constructed, depend on the nature of the time expression. In particular, the context of a compound time expression may make the intent of an index expression clear, as in "3/31/2012", where the "3" is only recognized as a month of year index because of its placement.

  • Reported: DTV 1.0b1 — Thu, 14 Jun 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The definition of ‘time coordinate’ is simplified to say just that it is a representation of a time point. To support this:

    • ‘time expression’ and related concepts are deleted
    • ‘atomic time coordinate’ is a time coordinate that has an expression that is either the name of a time point or a time point kind and an index
    • ‘compound time coordinate’ is redefined as a “time coordinate that combines more than one atomic time coordinate”
    • ‘time coordinate indicates time point’ is defined in terms of SBVR's 'representation represents meaning'
    • 'compound time coordinate indicates time point' is redefined in terms of the existing verb concept 'compound time coordinate combines atomic time point'

    Other miscellaneous changes:
    • Several new reference schemes are added to 'time point'
    • The text at the start of clause 10.5.1 is instead made the introductory text for all of 10.5.
    • References to the clauses where time coordinates are defined are fixed.
    • The definitions of ‘absolute time coordinate’ and ‘relative time coordinate’ are corrected
    • Missing SBVR concepts are added to clause 4
    • Delete 'atomic time coordinate has index', which was added by the resolution of issue 17426. This concept is no longer required.

    The issue summary made the comment that “the context of a compound time expression may make the intent of an index expression clear, as in "3/31/2012", where the "3" is only recognized as a month of year index because of its placement.” This specification does not describe the internal structure of a time coordinate, NOT the external representation of one. The interpretation of a date such as “3/31/2012” is a function of a tool, not of this specification.

    Note: this issue is dependent upon 16951, which defines 'time point kind'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Duration vs. Duration Value

  • Key: DTV-43
  • Legacy Issue Number: 17465
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    D&T makes a subtle but very important between Duration and DurationValue.

    Consider adding a note in 8.2 to alert the reader about this important distinction:

    A Duration can be specified by choosing a particular Duration Value as the expression of that Duration. (See Duration Value in …)

  • Reported: DTV 1.0b1 — Mon, 2 Jul 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The requested Note is added to the text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTV Issue: A calendar day is not a time period

  • Key: DTV-42
  • Legacy Issue Number: 17446
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Specification: Date Time Vocabulary
    Version: Beta-1
    Title: A calendar day is not a time period
    Source: Ed Barkmeyer, NIST, edbark@nist.gov

    Summary:

    DTV section 9.5.3 defines 'calendar day', 'calendar month' and 'calendar year' to be time points, as shown in figure 9.10.
    The entry for 'day period', however, contains a Note that reads: "Calendar day is a period that starts and ends as defined by a calendar. Day period starts and ends at any time within a calendar day."
    And there are similar notes under 'month period' and 'year period'.

    A calendar day is not a '(time) period'; it is a 'time point'. But a 'day period' time interval can indeed start and end at any time point "within", i.e., on some time scale that subdivides, a calendar day.

    The Note could be modified to read: "A calendar day corresponds to time intervals that start and end as defined by a calendar." Or, the concept "calendar day period" could be introduced to refer to time intervals that instantiate calendar days. The juxtposition of the two otherwise unrelated sets of concepts in Figure 9.10 suggests that the latter may be what was intended. And in any case, the repair must be applied to year period and month period as well.

    It appears that a 'day period' is not just a time interval whose duration is one day, because of leap seconds. A note to that effect would be valuable. (It is clear that months and years are of variable duration.)

  • Reported: DTV 1.0b1 — Wed, 13 Jun 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The Notes are incorrect and are reworded, essentially as suggested. The FTF agrees that Figure 10.2 (formerly 9.10) suggests a relationship between two sets of concepts that was not intended, and that two separate diagrams are wanted. The proposed Note about leap seconds is broadened to include any changes in time offset that affect the definition of local time of day on consecutive days.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need to support infinite and indefinite time constructs

  • Key: DTV-44
  • Legacy Issue Number: 17540
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    The Date Time Vocabulary needs to be able to support statements about periods of time which extend indefinitely into the future, and also describe periods of time which will have begun at indeterminate times in the past. As an example of the former, it is possible and meaningful for a contract to make statements about commitments or rights which extend in perpetuity, such as “Perpetual Bonds” which are bonds that pay interest forever.

    In general, it is necessary to be able to make meaningful statements which embody the concept of “Forever”. Similarly, it is necessary to be able to make meaningful statements which have been going on in perpetuity up to the present time.

    The DTV specification does currently allow for making statements about infinite time going forward, but not about time periods which have started at some indefinite time in the past. Meanwhile there are three other issues in play which touch on this same area. These may have an impact on the current ability to make statements about infinite time into the future as well, depending on their final resolution.

    The issues which have a bearing or potential bearing on this matter are:

    • Issue 16992: “Corollaries to Axiom D.4 in 8.2.3 are misstated”;
    • Issue 16993: “no syntax for indefinite time periods (date-time-ftf)”;
    • Issue 16997: “forever is misdefined”

    In summary, the requirement that needs to be met with the resolution of this and the above-referenced issues is:

    • Extend ‘forever’ with two new concepts:
      1. Indeterminate time in the past
      2. Indefinite time in the future
    • Ensure that the concept “forever” can be adequately defined (per 16997) including with reference to the time axis;
    • That there is syntax for the specification of indeterminate time periods that began at some point in the past and last up until the present (per 16993)
    • That the restatement of the axiom and corollaries referenced in 16992 take account of the two concepts above (indeterminate time in the past and indefinite time in the future)
  • Reported: DTV 1.0b1 — Mon, 6 Aug 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    The FTF decided that there is no value in distinguishing ‘indefinite’ from ‘infinite’. It chose to add new concepts that provide the basis for time intervals that extend indefinitely into the past or the future.

    New individual concepts ‘primordiality’ and ‘perpetuity’ are defined respectively as the occurrence interval of the earliest occurrence and of the latest occurrence. ‘Eternity’ (synonym ‘forever’) is defined as ‘primordiality through perpetuity’. This permits formulations such as “primordiality through today” and “2012 through perpetuity”. A tool might support these formulations with a syntax such as “… until today …” and “… from 2012 on …”.

    Issue 16993 adds verb concepts such as ‘time interval until situation model’. ‘primordiality’ and ‘perpetuity’ can substitute for the ‘time interval’ role to enable formulations such as “primordiality until the Industrial Revolution”.

    To support the definitions of these concept, two new verb concepts are added to clause 8.1.4, and an existing verb concept in 8.1.4 is renamed to avoid a name conflict.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

'Gregorian Month' Confused with 'Gregorian Month of Year'

  • Key: DTV-46
  • Legacy Issue Number: 17555
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Clause 11.8 in the beta-2 specification claims to enable comparison of ‘Gregorian months’ with ‘Gregorian days of year’. These time point kinds are not comparable because one is on an infinite time scale and the other is on a finite time scale. In fact, this section should be referring to ‘Gregorian month of year’

  • Reported: DTV 1.0b1 — Mon, 20 Aug 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    Clause 11.8 is updated to refer to ‘Gregorian month of year’ rather than ‘Gregorian month’.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent Use of ‘Concept Type’

  • Key: DTV-45
  • Legacy Issue Number: 17541
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Each kind of time point is a ‘concept type’. That is, the instances of each kind of time point are themselves concepts.

    The specification is inconsistent about this. Referring to the beta 2 document:

    Figure 10.2 shows the following as <<concept type>> but the text does not:
    calendar day
    calendar week
    calendar month
    calendar year
    Figure 11.1 and the associated text do not mark these concepts as ‘concept type’, but should:
    Gregorian day
    Gregorian week
    Gregorian month
    Gregorian year
    Figure 11.3 and the associated text do not mark these concepts as ‘concept type’, but should:
    common year
    leap year
    centennial year
    quadricentennial year
    Gregorian day of year
    Gregorian day of month
    Gregorian month of year
    Figure 11.7 shows the following concepts that should be marked <<concept type>>
    Gregorian year
    Gregorian day
    Figure 12.1 and the associated text do not mark these concepts as ‘concept type’, but should:
    calendar week
    week of year
    day of week
    weekday of year
    Figure 13.1 and the associated text do not mark these concepts as ‘concept type’, but should:
    hour of day
    minute of day
    second of day
    leap second
    minute of hour
    second of minute
    Figure 13.3 shows the following concepts that should be marked <<concept type>>
    hour of day
    minute of day
    Figure 14.1 shows the following class ‘internet time point’ that should be marked <<concept type>>, but that