Issues for Mailing list of the Date-Time (DTV) Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 16662: Date-Time Issue - OCL Corrections
Issue 16664: Date-Time Issue: Propositions, Situation Models, and Occurrences
Issue 16668: time scale1 differs from time scale2 by time offset
Issue 16669: Date-Time Issue - local time
Issue 16670: Date-Time Issue - week of year
Issue 16671: Date Time Issue - time set2 is duration after time set1
Issue 16672: Date-Time Issue - time of day
Issue 16673: Date-Time Issue - missing arithmetic on time point sequences
Issue 16674: Date-Time Issue - Atomic Quantity Value Conversion
Issue 16678: Date-Time Issue - states of affairs and situation models
Issue 16679: Date-Time Issue - Examples Related to Timezones
Issue 16682: Date-Time Issue: Time Zones
Issue 16689: D0 Should be Quantified
Issue 16690: CLIF Logic Errors
Issue 16714: Date Time Issue: quotation in OCL of UML symbols that include blanks
Issue 16715: Date-Time Issue: CLIF file should include metadata
Issue 16717: Date-Time Issue: now is not synonymous with current
Issue 16719: Date Time Issue - compound quantity value cardinality mismatch
Issue 16768: Relating time to states of affairs
Issue 16870: Relationship of UML model to SBVR is undocumented
Issue 16872: Annex D should be Normative
Issue 16874: Clause 5.2 depicts the UML model as informative
Issue 16944: Weekday definitions are inadequate
Issue 16949: DTV Editorial issue: Figures 9-5 and 9-7 should be reversed
Issue 16951: Time point subdivision is out of place twice
Issue 16992: Corollaries to Axiom D.4 in 8.2.3 are misstated
Issue 16993: no syntax for indefinite time periods
Issue 16997: forever is misdefined
Issue 17128: UML Model Should be Vendor-Independent
Issue 17129: Need Profile for UML Stereotypes
Issue 17225: DTV Issue: inaccurate formulation of definitions in CLIF
Issue 17232: DTV time-of-day time point definitions are inaccurate
Issue 17367: DTV Issue: There is no smallest time interval
Issue 17404: Quantity Kind is a categorization type
Issue 17425: rename 'calendar date'
Issue 17426: UML vs. text inconsistencies in clause 12
Issue 17427: Confusing text for Gregorian calendar
Issue 17428: basic time coordinate concepts are badly described
Issue 17429: Definition of Calendar Date
Issue 17446: DTV Issue: A calendar day is not a time period
Issue 17465: Duration vs. Duration Value
Issue 17540: Need to support infinite and indefinite time constructs
Issue 17541: Inconsistent Use of ‘Concept Type’
Issue 17555: 'Gregorian Month' Confused with 'Gregorian Month of Year'
Issue 17556: 10pm to 2am does not specified a time period
Issue 17573: time-of-day time point definitions are inaccurate
Issue 17593: Reference to 'conceptual schema'
Issue 17594: Next Sequence Position
Issue 17595: 'Time Span' is defined twice
Issue 17597: repair heading structure of Clause 16
Issue 18130: Conflicting models of 'leap second'
Issue 18167: ‘Time of Day’ misused
Issue 18173: Adopt ‘occurrence’ and ‘what-happens state of affairs’ from SBVR
Issue 18187: Definition of 'time interval is current'
Issue 18189: invalid indexical time references
Issue 18191: time point1 shares common time scale with time point2
Issue 18283: Atomic Time Coordinate has Index
Issue 18284: UML Profile is Specifically for DTV, not for SBVR in General
Issue 18803: In Annex D.3.2, in the entry for "base unit", the first caption should be "Definition" instead of "Concept Type".
Issue 18804: The "SBVR-DTV Vocabulary" in clause 4 has no namespace URI. That means it cannot be referenced across a network

Issue 16662: Date-Time Issue - OCL Corrections (date-time-ftf)

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"

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

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.

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

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

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

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.

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

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

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

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.

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

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.

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.

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

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 proposed by the Issue Authors:
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 continuing 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’.
Resolution of the DTV FTF-2:
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.

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.

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.

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

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.

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.

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.

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.

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?

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

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.

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.

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

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

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.

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.

It is not clear what list the text bullets following the diagram in 12.3.1 are members of, and they are not sentences.  Further, they have the pattern:  "Gregorian year coordinate composed of a Gregorian year, for example 2010", but coordinates are defined to 'indicate' time points.  They are not "composed of" time points in any sense.  On the other hand, a 'G. year month coordinate' is composed of two time coordinates, but not two time points.


The definition of 'Gregorian year coordinate' is: "absolute atomic time coordinate that indicates a Gregorian year that has the index equal to the index of the Gregorian year coordinate".  The term 'Gregorian year coordinate' is being used in its own definition.  The definition should read:  "absolute atomic time coordinate that indicates a Gregorian year".  (There are no other time coordinates that indicate Gregorian year time points.)  There is a related Necessity: Each Gregorian year coordinate indicates the Gregorian year that has an index that is equal to the index of the Gregorian year coordinate.  This pattern also applies to G. day of month, G. day of year coordinates, and hour, minute, second coordinates.  It applies to numeric 'Gregorian month coordinates', but the time coordinate "January" does not have an index, per se.  "January" is a term for the time point, but not an index (integer).  The UML model (Figure 12.3) makes 'atomic time coordinate has index' a derived relationship, but that is false, given the intent:  the index of the time coordinate is used to identify the time point, not taken from the identified time point.  And in that case, the non-derived 'index' property is 0..1.



The definition of 'Gregorian year month coordinate' misuses the verb concept 'compound time coordinate combines atomic time coordinate':  "Definition: absolute compound time coordinate that combines the set of {a Gregorian year coordinate, a Gregorian month coordinate} and indicates the Gregorian month that..." A 'set' is not an 'atomic time coordinate' and cannot play that role.  What is intended is:  
"Definition: absolute compound time coordinate that combines a Gregorian year coordinate and that combines a Gregorian month coordinate and that indicates a Gregorian month."  That is sufficiently delimiting.  The structural rule that determines which month it indicates can be stated as a separate Necessity.  This "combines the set of" pattern is used in every compound time coordinate definition in 12.3.


Note also that the formal statement of these definitions/necessities suffers from the lack of a basic arithmetic vocabulary (in Annex D?).  Elsewhere DTV just says the arithmetic expressions are described in English or mathematical notations.  If the arithmetic expressions are removed from the definitions, it becomes easier to do that.  The mathematical formulations can be stated in CLIF and OCL.

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

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

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

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

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’

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.

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.

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.

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

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.

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.

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

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

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

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



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



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

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

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


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


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


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



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

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


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

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

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

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

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

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

Recommendation: delete 'atomic time coordinate has index'.

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

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

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

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

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