Many of the UML classes defined in Clause 8 have several UML operations.
While it may be easy to guess the relationship between the operations and the associations, there is no text that defines these operations, or even mentions their relationship to the associations. In each case, these operations should be formally documented under the "glossary entry" for the class. (The description in clause 5.2 is helpful, but it alone does not meet the documentation requirement. It just says that each such operation is somehow related to some defined association.)

Clarify UML operations construction in 5.3

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

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

Many Date Time Vocabulary concepts have very formal definitions that are hard for one of the target audiences – business users – to understand. For example, the definition of the Allen Relationship 'time interval1 is properly before time interval2' reads:
Definition: the time interval1 is before the time interval2 and the time interval1 is before a time interval3 and the time interval3 is before the time interval2

This formal definition provides a precise meaning for use by reasoning engines, but it takes even an expert human awhile to understand. Business users have little chance of understanding it.

The solution proposed by this Issue is that this and every other Date Time Vocabulary concept should have an informal definition or description that explains the concept to the business user audience. Note that SBVR permits a concept to have multiple definitions, so adding informal definitions need not displace any existing formal definitions.

Improve wording for Allen relations

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

The final submission document recorded the following issue at the start of Annex F.5 "Formulating Tense and Aspect":

This section needs to be updated to reflect the term "situation model" as used in this specification, instead of "state of affairs".

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

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

This spec should provide a simple library of datatypes for use in UML and data modeling. This is present in many physical data standards (e.g. SQL/JDBC, XML Schema) but is lacking in OMG for platform independent modeling. That would include types such as:

• Date

• DateTime

• TimeStamp

• Duration

Revise clause 18 to define datatypes

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

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

Currently, OCL statements are created directly in the specification document, then "stripped out" of the document into a separate file via an XSLT transform. In a further step, the OCL should be integrated into the UML model so that the model includes the OCL constraints.

Merging OCL into the UML model should be automated

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

Currently, OCL statements are created directly in the specification document, then "stripped out" of the document into a separate file via an XSLT transform. In a further step, the OCL should be integrated into the UML model so that the model includes the OCL constraints.

The final submission document recorded this issue in clause 11.6 "Mixed-Base Arithmetic":
Need to add a paragraph discussing arithmetic involving weeks and years because these are incommensurable. This depends upon defining a concept that computes the number of weeks in any particular year.

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

The glossary entry for Time Axis has a ‘General Concept:’ entry that reads “mathematical representation of the succession in time of instantaneous events along a unique axis”. The caption is wrong; it should be a ‘Definition:’.

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

In clause 9.5.3, 'calendar day' is defined as: 'time point that is defined by a given calendar and during which approximately one revolution of the earth occurs on its axis'. Clause 9.3 defines 'time point' as 'scale point that is in a time scale and that specializes the concept 'time interval'. Fortunately, 9.3 also says 'time point' is a concept type, so the idea of specialization makes sense. That is, the definition in 9.3 means: a time point is a scale point on a time scale, and a time point is a concept that specializes 'time interval'. A concept that specializes time interval is not a time interval during which the earth rotates – its instances are.

Recommendation:

In clause 9.5.3, change the definition of calendar day to 'time point that is defined by a given calendar and that corresponds to time intervals during which approximately one revolution of the earth on its axis occurs'.
In clause 9.3 reword the definition of time point to 'concept that specializes the concept time interval and that is a scale point on a time scale.

The recommendation is adopted as given.

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

Clause 12.4 contains the following:
"The concept “time point converts to time period on time scale” enables conversion of a time point on some time scale1, to a time period on the given time scale. The target time scale always is finer, meaning that it has a granularity that is less than or equal to the granularity of time scale1. This means that time point is equivalent to a time period on time scale2.
"For example, the Gregorian month that is indicated by “January” (on the Gregorian year of months scale) is the time period from Gregorian day of year 1 through Gregorian day of year 31 on the Gregorian year of days scale."

In all of this text, the term 'time period' should probably be replaced by 'time point sequence'.

Clause 12.4 then contains this entry:

"time point converts to time period on time scale
"Definition: time point converts to a time point sequence on the time scale and the time period
instantiates the time point sequence"

The verb concept 'time point converts to time point sequence' appears in diagram 12-12, but is not defined anywhere, and 'time point converts to time period on time scale' does not appear on the diagram. So the obvious interpretation is that 'time period' should be replaced by 'time point sequence' in the verb concept entry. But then the definition is circular.

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

The Date Time Vocabulary provides verb concepts that relate the time order of any two time intervals (e.g. 'time interval1 is before time interval2'), any two situation models ('situation model1 precedes situation model2'), and any two occurrences ('occurrence1 precedes occurrence2'). Another common ordering relationship is among three time intervals, situation models, or occurrences, as in 'time interval1 is between time interval2 and time interval3', 'situation model1 is between situation model2 and situation model3', and 'occurrence1 is between occurrence2 and occurrence3'. These ternary verb concepts should be added to the Date Time Vocabulary.

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

The Date-Time Vocabulary (DTV) document FTF beta 1 draft Mike sent on Dec. 8, 2011 shows a concept of 'time unit' specialized as:

• 'precise time unit', a specialization of 'measurement unit'
• 'nominal time unit'

It is understood that in DTV, a 'precise time unit' is a kind of ISO 80000 measurement unit (i.e., 3.8 in ISO-80000-1):

real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can
be compared to express the ratio of the second quantity to the first one as a number

The DTV names for 'time unit' and 'nominal time unit' are misleading because in the Dec. 2011 DTV FTF 1 beta document,
these terms are not defined as kinds of ISO 80000 measurement units.

From the DTV FTF perspective, the objection against defining 'time unit' and 'nominal time unit' as ISO 80000 measurement units is that 'month',
a kind of 'nominal time unit', varies between 28 and 31 days and therefore does not exactly fit the definition of measurement unit per ISO 80000.
In pure ISO 80000 terms, this would suggest that 'month' would be a measurement unit with a variable conversion factor from 'day', which is defined as a normative measurement unit in ISO 80000-3, item 3-7.d.

I believe that the DTV interpretation of ISO 80000 measurement unit is too restrictive and should be changed such that a DTV 'time unit' is in fact a kind of ISO 80000 'measurement unit'.

There is compelling evidence to support this change in ISO 80000 itself:

1) The definition of year as a non-SI measurement unit in ISO 80000-3, Annex C, item 3-7 shows an example where the conversion factor is variable:

a := 365d or 366d

One tropical year is the duration between two
successive passages of the Sun through the mean
vernal equinox.

This duration is related to the corresponding difference
in mean longitude of the Sun, which depends on time in
a not exactly linear form; i.e. the tropical year is not
constant but decreases at a rate of nearly per
century. The tropical year is approximately equal to
365,242 20 d ≈ 31 556 926 s.

2) The value of a quantity can be expressed in three ways according to ISO 80000-1, item 3.19:

• a product of a number and a measurement unit
• a number and a reference to a measurement procedure
• a number and a reference material

3) 'month' could be defined as an ISO 80000 'conventional reference scale', that is, a quantity-value scale defined by formal agreement.

This could facilitate defining that 'month' is a 'conventional reference scale' varying between 28 and 31 'days'.
Specializations of 'month' could be made for 28-days months, 29-days months, 30 days months, 31 days months where such specializations can be defined as ISO 80000 derived units of 'days' with a precise conversion factor.

4) 'amount of substance', one of the 7 base quantities in the International System of Quantities, ISQ, is intrinsically context-dependent:
See the remarks in ISO-80000-9, 9-1:

Amount of substance of a pure
sample is that quantity that can
often be determined by
measuring its mass and
dividing by the molar mass of
the sample.

Amount of substance is
defined to be proportional to
the number of specified
elementary entities in a
sample, the proportionality
constant being a universal
constant which is the same for
all samples.

The name “number of moles”
is often used for “amount of
substance”, but this is
deprecated because the name
of a quantity should be
distinguished from the name of
the unit.

In the name “amount of
substance”, the words “of
substance” could, for
simplicity, be replaced by
words to specify the substance
concerned in any particular
application, so that one may,
for example, talk of “amount of
hydrogen chloride, HCl”, or
“amount of benzene, C6H6”.
It is important to always give a
precise specification of the
entity involved (as emphasized
in the second sentence of the
definition of the mole); this
should preferably be done by
giving the molecular chemical
formula of the material
involved.

Just like 'amount of hydrogen chloride' is a specialization of 'amount of substance',
'January' is a specialization of 'month.
All are measurement units in the sense of ISO 80000.

The DTV specification should clearly indicate the correspondence between the DTV vocabulary and the corresponding ISO 80000 vocabulary.
These correspondences are important to clarify the relationship between the use of ISO 80000 vocabulary in DTV and SysML's QUDV.

The FTF consulted with NIST authors of VIM and ISO 80000-3, who confirmed that 'month' and 'year' are not defined by SI and do not fit the VIM definition of 'measurement unit'. Therefore, the proposal made above is not adopted. Instead, a Rationale section is added to discuss the issue.

The UML packages in the supporting UML document (bmi/2011-08-01.mdzip) are not consistently aligned with the sections of the specification. In particular:
Sections 8.1 and 8.2 of the specification are both in the TimeInfrastructure package, but section 8.3 is not.
Section 8.3 of the specification matches the Situations package, except that 8.3.7 Schedules is in a separate Schedules package. And the Situations package also contains the Tense concepts from 10.3.
Sections 9.1 to 9.4 of the specification are all in the TimeScales package, but sections 9.5 and 9.6 are not.
Section 9.5 of the specification matches the Calendars package, except that Gregorian calendar (9.5.5) is a separate UML package, and Internet Time (9.5.7) is a separate UML Package.
Section 9.6 of the specification (Time Tables) is in the Schedules package, along with the Schedules concepts from 8.3.7.
Section 10 of the specification matches the Indexicals package, except that Tense and Aspect (10.3) is in the UML Situations package. (The UML model treats tense as a relationship of situations to time, but the time concepts involved are indexical.)
Section 11 of the specification matches the DurationValues package, except that month values (11.6) and year values (11.5) are in the UML Gregorian calendar package.
Section 12 of the specification matches the UML TimeCoordinates Package, except that Section 12.4 is in the Gregorian calendar package.
Annex D of the specification matches the UML Packages: Sequences (D.1), Quantities (D.2), Mereology (D.4), except that D.3 Scales is included in the UML Quantities package.

In sum, some reorganization of the specification did not result in a consistent reorganization of the UML model. In general, the UML packaging should be made consistent with the text. But, if the Gregorian calendar package is intended to be separable, then Gregorian elements in other parts of the specification may need to be treated as exceptions. In addition, one can argue that the 'time table' and 'schedule' concepts are closely related and should be together in the specification.

I do not recommend the use of nested UML Packages. It complicates the UML model and all references to the UML concepts defined in it.

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

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

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

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

(This comment came from the Architecture Board's review of the final submission.)

On p100 it is stated that "the Gregorian Calendar was introduced in
1582" and corrected calendar drift by "skipping over the dates between
October 5-15, 1582". This is true, but it's worth noting that only Spain, Portugal, the Polish-Lithuanian Commonwealth, and parts of Italy implemented the new calendar on Friday 15 October 1582 (following Julian Thursday 4 October 1582). Other countries stayed with the Julian calendar, so those "lost dates" (e.g. 10th October 1582) are valid in those countries. France adopted the Gregorian calendar on Monday 20 December 1582 (following Sunday 9 December 1582). Other countries followed over the centuries, with the UK and East-Coast American colonies not switching until 1752 (Wednesday 2 September 1752 was followed by Thursday 14 September 1752). Russia didn't change until 1918. The last countries to change seems to have been Greece, where Thursday 1 March 1923 followed Wednesday 15 February 1923, and Turkey, which switched in 1926.

(Yes, I got all those dates from Wikipedia .

Hence I think this section would benefit from a comment saying that although the Gregorian Calendar begins in 1582, various countries switched on various later dates, so that to be completely unambiguous, dates after October 1582 should really state which calendar they use. (For instance, today, Sunday 11th September 2011 in the Gregorian Calendar is Monday 29th August 2011 in the Julian calendar).

Similarly, at the top of page 121 it says that the Gregorian calendar was "introduced in 1582". It might be more accurate to say it was "first defined" in 1582 (or some similar wording), and "introduced" in different countries at different later dates.

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

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

(This comment came from the Architecture Board's review of the final submission.)
This comment on page 16 [now Annex A.3 jarred somewhat:
"These variations are accounted for by incorporating intercalary leap days and leap seconds into some calendar and timekeeping schemes. This specification chooses to support leap days, but not leap seconds, because leap days are significant to business while leap seconds are insignificant."
It seems a bit arrogant to assert that "leap seconds are insignificant to
business". If (for instance) your company's Telephone PABX were to crash at
midnight on New Year's Eve because its software couldn't cope with
leap-seconds, I suggest that would be "significant to business".

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

The final submission document recorded this issue regarding figure 80 "Scales" in clause Annex E.3:
The "black diamond" and

on the "scale has scale point" association are wrong.

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

• The fact type form “months centennial quotient of month value” is used in two different glossary entries in clause 10.6, “Duration Values”. The second entry should be “months quadricentennial quotient of month value”. Both the glossary entry and the definition should be updated.
• The fact type form “years centennial quotient of year value” in clause 10.5 has the same error as above and needs the same fix.

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

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

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

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

Regarding the "monogamy" example in clause 7.3
> “Consider the law of monogamy as it exists in some countries:”
> “It is prohibited that a person1 is married to person2, if that person1 is married to another person3 and person2 is different from person3.”
> “This rule is not entirely correct….”
I cannot imagine a country with the law of monogamy stated like that. It is not proper English nor is it proper SBVR SE. How about this: “A person must not be married to more than one person.” This section argues that the rule statement is “not entirely correct” because it doesn’t say “at the same time”. But that is nonsense. Based on that argument, every rule would need to explicitly tie every relation it uses to time. E.g.:
Rule A: It is prohibited that a drunk driver operate a EU-Rent vehicle.
Rule B: It is prohibited that there exists a time interval such a driver is drunk throughout that time interval and the driver operates a vehicle throughout that time interval and the vehicle is a EU-Rent vehicle throughout that time interval.
It would be better to point out that in any situation there is at most one present time. Therefore, the law of monogamy stated as “A person must not be married to more than one person” is perfectly correct and it logically implies that “A person must not be married to more than one person at the same time.”

“occurrence” is defined in the introduction to be a possible state of affairs. This is OK, if that’s what is intended. But “occurrence” is defined differently later.

Proposed Resolution:
Change the text at the start of the clause from:
Consider the law of monogamy as it exists in some countries:
It is prohibited that a person is married to more than one person.
This rule is correct only on the understanding that the rule is evaluated at a point in time, as specified in this document. A version of the rule that uses the concepts defined in this section to make this understanding explicit is:
If a person1 is married to some person2 occurs for some time interval, it is prohibited that person1 is married to another person3 during the time interval.

to:
Consider the law of monogamy as it exists in some countries:
It is prohibited that a person is married to more than one person.
This rule is correct only on the understanding that the rule is evaluated at a point in time, as specified in this document. A version of the rule that uses the concepts defined in this section to make this understanding explicit is:
If a person1 is married to some person2 occurs for some time interval, it is prohibited that person1 is married to another person3 during the time interval.

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

The definition of "situation model" should be clarified to make it clear that it "may or may not occur".

Proposed Resolution:
(At it's conference call on September 9, the submission team agreed to the following change. Since this change was after the final submission, it is recorded here for consideration by the FTF.)

Change the Definition of "situation model" to read:

Definition: res that is an abstract model or conceptualization of an event, activity, situation, or circumstance that may or may not occur in some possible worlds

Clarify that a situation model may or may not occur

The term "granularity" has two glossary entries, one in clause 8.2, and another in D.4. One should be renamed to avoid confusion, although they mean almost the same thing.
Proposed Resolution:
(The submission team adopted this resolution after the final submission. The change is recorded here as an Issue so that it can be considered by the FTF.)

Under "time scale has granularity" in clause 8.2, add a new Necessity:

Necessity: The scale of the time scale is the granularity of the time scale if and only if the granularity of the time scale is a precise time unit.
In Annex E.3:

• rename the glossary entry "granularity" to "scale granularity"
• rename the glossary entry "scale has granularity" to "scale has scale granularity"
• reword the Necessity under " scale has scale granularity" to read:

Necessity: Each scale has at most one scale granularity.
• Add 1 note and 2 examples:
Note: Time scales are kinds of scales, but time scales of nominal time units (which are not true measurement units) do not have true scale granularities (which are always measurement units).
Example: The Gregorian years scale has a granularity of 'year'. This granularity is the scale granularity of the scale.
Example: The Gregorian months scale has a granularity of 'month'. This scale does not have a scale granularity because 'month' is a nominal time unit, not a precise time unit.

(The submission team adopted this resolution after the final submission. The change is recorded here as an Issue so that it can be considered by the FTF.)

Under "time scale has granularity" in clause 8.2, add a new Necessity:

Necessity: The scale of the time scale is the granularity of the time scale if and only if the granularity of the time scale is a precise time unit.
In Annex E.3:

• rename the glossary entry "granularity" to "scale granularity"
• rename the glossary entry "scale has granularity" to "scale has scale granularity"
• reword the Necessity under " scale has scale granularity" to read:

Necessity: Each scale has at most one scale granularity.
• Add 1 note and 2 examples:
Note: Time scales are kinds of scales, but time scales of nominal time units (which are not true measurement units) do not have true scale granularities (which are always measurement units).
Example: The Gregorian years scale has a granularity of 'year'. This granularity is the scale granularity of the scale.
Example: The Gregorian months scale has a granularity of 'month'. This scale does not have a scale granularity because 'month' is a nominal time unit, not a precise time unit.

The start of clause 7 has a set of SBVR terms for referenced vocabularies. The following are missing from this list:

IKL
Definition: The proposal of the IKRIS Interoperability Group, entitled IKL Specification Document, available at http://www.ihmc.us/users/phayes/IKL/SPEC/SPEC.html
Inter Gravissimas
Definition: The papal bull issued by Pope Gregory XIII, 24 February 1582. Prepared in English, Latin, and French by R.T.Crowley for ISO TC154 on 27 December 2002.
ISO 18026
Definition: The standard of the International Standards Organization (ISO), number 18026, Information technology — Spatial Reference Model (SRM), 2009
ISO 80000-3
Definition: The standard of the International Standards Organization (ISO), number 80000-3, named: Quantities and units – Part 3: Space and time, 2006
OCL
Definition: The specification of the Object Management Group (OMG) named: Object Constraint Language, version 2.0, May 2006

Merged into Issue 16659

The specification should contain a list of the SBVR terms and verb wordings that are referenced in the document, in order to make it clear where these terms come from.

Proposed text for clause 4 "Terms and Definitions":
__________________________________________________
SBVR Meaning and Representation Vocabulary
General Concept: vocabulary
Language: English
___________________________________________________
concept
concept1 specializes concept2
concept type
fact type
fact type has fact type role
fact type role
integer
instance
meaning
meaning corresponds to thing
meaning has representation
name
non-negative integer
noun concept
number
proposition
representation
representation uses expression
role
set
statement
statement expresses proposition
term
text
thing
thing has name
thing is in set
Synonymous Form: set includes thing
Synonymous Form: set has element
thing1 is thing2
verb concept
__________________________________________________
__________________________________________________

__________________________________________________
Vocabulary for Describing Business Vocabularies
General Concept: vocabulary
Language: English
___________________________________________________
categorization type
res
terminological dictionary
vocabulary
vocabulary namespace

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

The specification should contain a formal list of all the SBVR vocabularies defined by the specification. An example of such a list is given in SBVR clause 7. The list is needed by software that converts the specification text to XMI.

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

Summary:
These two ‘year of weeks scale’ and ‘year of weekdays scale’ are defined using the ‘time scale subdivides time point’ verb concept. That verb concept assumes that the start of the time point coincides with the start of the scale, but this is not true for these two scales because calendar weeks are not coherent with calendar years. A special verb concept needs to be used to relate weeks and weekdays to calendar years.

The issue is correct: subdivides does not characterize the year of weeks or the year of weekdays scales. These time scales are finite sequences that map directly to the weeks calendar and year of days calendar respectively

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

Accepted. The UML diagram will be changed. Other minor improvements are also made to the diagram.

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.

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

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.

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

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.

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

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

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

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

No Data Available

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

The entire document was scanned, and every example examined. Updates are made as necessary to avoid this confusion.

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

This issue duplicates issue 18167, which is merged with Issue 17425.

Revised Text:
See Issue 17425.

Disposition: Duplicate

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

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.

Clause 7.2.2 has several CLIF axioms that reference 'D0' but fail to quantify that variable. They should each existentially quantify 'D0'.

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.

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.

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.

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.

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

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

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

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

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.

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.

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.

The missing ‘atomic time coordinate has index’ is added and the diagram is corrected to match the text.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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?

Resolved by issue 17540 and 16993.

Revised Text:
Disposition: Duplicate or Merged

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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

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"

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

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.

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

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.

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

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

This issue is addressed by the resolution of issue 17425.
Revised Text:
Disposition: Merged

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

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

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.

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

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

The requested Note is added to the text

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

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.

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)

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.

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’

Clause 11.8 is updated to refer to ‘Gregorian month of year’ rather than ‘Gregorian month’.

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

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

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.

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.

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.

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

Disposition: Duplicate

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.

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

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.

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.

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

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

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.

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