Specification: DTV v1.1

Title: Occurrence does not specialize Situation Kind

Summary:

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

General Concept: situation kind occurs for time interval

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

Agreed. Delete the General Concept declaration.

Specification: DTV

Version: 1.1

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

Summary:

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

individual situation kind has occurrence interval

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

Necessity: The individual situation kind has exactly one occurrence

...

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

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

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

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

Specification: DTV v1.1

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

Summary:

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

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

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

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

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

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

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

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

The RTF agrees

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

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

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

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

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

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

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

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

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

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

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

Specification: DTV

Version: 1.1

Title: Different 'time period' concept in Annex C

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

Summary:

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

fixed period

Definition: time period that cannot be changed

...

variable period

Definition: time period that can be rescheduled

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In the beta-2 document, clause 10.8 defines a verb concept 'time point converts to time point sequence on time scale'. A typical use is 'Gregorian month converts to time point sequence on the Gregorian days scale', which is given as a specialization. The 'time scale' role is redundant in the main verb concept, and the use of individual concepts in the derived verb concepts is poor practice.

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

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

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

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

Spec: DTV

Version: 1.0 and 1.1

Source: Ed Barkmeyer, NIST

Summary:

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

(and

(sequence s)

(forall (sp1)

(if

(and

("sequence has sequence position" s sp1)

(exists (sp2)

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

(forall (x1 x2)

(if

(and

("sequence position has index" sp1 x1)

("sequence position has index" sp2 x2))

(= x2 (+ x1 1)) ))

)) )))

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

The correct formulation is:

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

(and

(sequence s)

(forall (sp1 sp2 x1 x2)

(if

(and

("sequence has sequence position" s sp1)

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

("sequence position has index" sp1 x1)

("sequence position has index" sp2 x2))

(= x2 (+ x1 1)) ))

)))

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

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

Accept the text correction

DTV 1.1 clause 4 has several errors:

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

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

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

4. The only definition given for each concept is “

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

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

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

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

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

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

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

The caption is supplied and the reference is corrected.

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

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

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

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

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

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

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

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

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

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

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

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

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

Specification: DTV v1.1

Title: DTV SBVR Profile is not formally applied

Source: Pete Rivett, Adaptive (for the AB)

Summary:

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

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

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

” has no semantics. Note that the symbol “

”.

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

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

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

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

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

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

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

The Note provides the underlying motivation:

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

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

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

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

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

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

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

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

Disposition: Merged (see Issue 19652)

Specification: Date Time Vocabulary v1.1

Title: what is the year of weekdays?

Summary:

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

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

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

The Necessity provides the real delimiting characteristic:

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

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

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

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

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

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

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

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

It then defines calendar week as follows:

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

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

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

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

Then in 12.4 we find this entry:

year week coordinate indicates time point sequence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· time interval1 begins time interval2

· time interval1 ends time interval2

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

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

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

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

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

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

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

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

(forall (t1 t2 t3)

(if

(or

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

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

(iff

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

(and

("time interval1 starts time interval2" t1 t3)

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

)))

It should be:

(forall (t1 t2 t3)

(if

(and

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

(or

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

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

(and

("time interval1 starts time interval2" t1 t3)

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

))

and similarly for the others.

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

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

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

CLIF Axiom:

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

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

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

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

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

(and

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

(forall (soq2)

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

(= soq2 soq) ))

)))

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

Replace the text as suggested. Add the OCL form.

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

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

The only OCL Constraint in DTV clause 8.2.1 reads:

context: _'time interval'

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

It should be:

context: _'time interval'

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

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

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

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

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

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

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

Specification: DTV v1.1

Title: misplaced Synonymous Forms on 'time set'

Summary:

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

Synonymous Form: time set1 equals time set2

Synonymous Form: time set1 = time set2

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

Agree. Editorial repair

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

Definition: time coordinate that combines more than one time coordinate

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

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

That makes them both circular. Prefer something like:

compound time coordinate

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

compound time coordinate combines atomic time coordinate

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

These definitions match the first Necessity under the verb concept.

The 'set' makes the second Necessity redundant.

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

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

Specification: DTV v1.1

Title: Starting week day is a number

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

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

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

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

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

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

Clause 8.7 includes two verb concepts:

time point1 through time point2 specifies time period

time point1 to time point2 specifies time period

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

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

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

By creating companion verb concepts:

time point1 through time point2 defines time point sequence

time point1 to time point2 defines time point sequence

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

E.g. for

time point1 through time point2 specifies time period

Definition: time point1 is the first time point of a time point sequence and time point2 is the last time point of the time point sequence and the time point sequence corresponds to the time period

the Definition is replaced by:

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

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

Specification: DTV v1.1

Title: Gregorian years before 1600 have no starting day

Summary:

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

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

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

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

Necessity: Each Gregorian year has exactly one calendar day.

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

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

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

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

Specification: DTV

Version: 1.1

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

Summary:

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

time interval1 starts during time interval2

or

occurrence starts during time interval

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

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

Specification: DTV v1.1

Title: Unspecified Relationship of OWL files to DTV

Source: Sridhar Iyengar, IBM (for the AB)

Summary:

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

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

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

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

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

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

Disposition: Merged (see Issue 19547)

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

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

Specification: DTV v1.1

Title: Missing and incorrect text in clause 10.6

Summary:

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

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

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

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

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

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

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

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