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

Date-Time (DTV) 1.0 FTF — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
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

Clause 5.2 depicts the UML model as informative

  • Key: DTV-24
  • Legacy Issue Number: 16874
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Dr. Nicolas F. 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 ( Mr. Edward J. 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 ( Mr. 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 is missing from the text

  • Reported: DTV 1.0b1 — Mon, 6 Aug 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    Every specialization of ‘time point’ is marked ‘concept type’. The text and the figures are aligned wherever required.

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

Reference to 'conceptual schema'

  • Key: DTV-49
  • Legacy Issue Number: 17593
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    The definition of 'calendar' in clause 10.1 relies upon SBVR's 'conceptual schema'. However:
    1. 'conceptual schema' is not included in the list of adopted SBVR concepts in clause 4.
    2. SBVR 1.1 moved 'conceptual schema' to clause 10.1.2.1, which means this concept is part of the semantic and logical foundation of SBVR, but not actually in any of the SBVR vocabularies.

  • Reported: DTV 1.0b1 — Mon, 17 Sep 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    Text from the SBVR definition of 'conceptual schema' is integrated into the existing definition of 'calendar' to combine them and eliminate the dependency upon the SBVR concept.

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

time-of-day time point definitions are inaccurate

  • Key: DTV-48
  • Legacy Issue Number: 17573
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The UML diagram Figure 13.1 shows leap second as a subclass of second-of-day.
    The text in 13.2 defines it to be an instance of second of day, and the definition of day-of-seconds confirms this. The UML diagram is incorrect.

    'leap second' may be an intercalary time point that arises from a change in time offset, rather than a second-of-day.

  • Reported: DTV 1.0b1 — Thu, 30 Aug 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    This issue duplicates issue 18130.
    Revised Text:
    see Issue 18130

    Disposition: Duplicate

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

'Time Span' is defined twice

  • Key: DTV-51
  • Legacy Issue Number: 17595
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    There are two glossary entries for the concept 'time span', one in clause 16.4 and one in clause 17.2. The two glossary entries are not identical, nor do they define coextensive concepts.

  • Reported: DTV 1.0b1 — Mon, 17 Sep 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    Delete the second 'time span' entry and combine the definitions of both glossary entries into the associated 'has' verb concepts.

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

10pm to 2am does not specified a time period

  • Key: DTV-47
  • Legacy Issue Number: 17556
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    In clause 8.6 of the beta-2 specification, the verb concepts ‘time point1 through time point2 specifies time interval’ and ‘time point1 to time point2 specifies time interval’ do not work for the example ‘10pm to 2am’. Reason: the Definitions of these verb concepts form a time point sequence over the time between the two time points, but for this example, the time point sequence “wraps around’ the end of the day of hours scale. And no time point sequence can do that.

  • Reported: DTV 1.0b1 — Mon, 20 Aug 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    Redefine 'time period' to drop the words "of exactly one time scale". Instead, add a Necessity that all the time points of a time period are on the same time scale. The purpose is to allow a time period to 'wrap around' the end of a finite time scale.

    Rework the glossary entries of 'time point1 through time point2 specifies time period' and 'time point1 through time point2 specifies time period' to specify how a time period is formed when the time points 'wrap around' a finite time scale.

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

Next Sequence Position

  • Key: DTV-50
  • Legacy Issue Number: 17594
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    Annex D.2.1 includes a verb concept 'next sequence position succeeds sequence position' that references a concept 'next sequence position' that is not defined anywhere

  • Reported: DTV 1.0b1 — Mon, 17 Sep 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    'next sequence position' is a role of sequence position derived from the cited verb concept and should be so defined.

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

repair heading structure of Clause 16

  • Key: DTV-52
  • Legacy Issue Number: 17597
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    Clause 16 is titled "Situations", and there is no text that describes the scope of the section. But subclause 16.1 is titled 'Temporal Concepts for Situations', which is the intended scope, and is followed by a description of the scope. Further, clause 16.1 has a single subclause, which defines only the situations concepts.

    It appears that Clause 16 should be titled 'Temporal Concepts for Situations', the current heading "16.1 Temporal Concepts for Situations" should be deleted, thus placing the subsequent paragraphs at the head of Clause 16, and subclause 16.1.1 should be numbered 16.1 with its current title.

  • Reported: DTV 1.0b1 — Mon, 17 Sep 2012 04:00 GMT
  • Disposition: Resolved — DTV 1.0b2
  • Disposition Summary:

    This issue is addressed by the resolution of issue 18173 because that issue substantially reworks sub-clause 16.1.1.
    Revised Text:
    Disposition: Merged

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