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

Correct the wording of 11.4 to describe named time points

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

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

Move clause 10.5 to clause 13 and address DTV13-105

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

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

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

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

In 14.1, remove the sentence about time dissemination

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

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

Correct the definitions of standard time and local time

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

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

Merge to Issue DTV13-101

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

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

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

Clarify UML operations construction in 5.3

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

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

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

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

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

Improve wording for Allen relations

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

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

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

Editorial repair.

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.

Issue does not reflect revision of Annex C

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

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

Repair paragraph tags in D.3.2

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

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

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

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

Clarify the "Nth member" concepts in D.2.6

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

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

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

Delete all 'Gregorian week elements from the UML model

See attached file DTV13-69.docx

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

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

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

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

Replace the synonymous forms for 'overlaps' with necessities.

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

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

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

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

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

• In clause 10.4, in the entry for finite time scale subdivides time point kind', the Note refers to 'day of week', which should be 'ISO day of week'.

• In the introduction to clause 10.6, the example 'week 41 day 6' should be 'ISO week of year 41 ISO day of week 6' (really?, this wording has no business use).

• In 10.6.3, under atomic time coordinate, the example "calendar week 53" should probably be "ISO week of year 53".

• In 10.6.3, under 'atomic time coordinate uses index', the references to 'week of year' and 'day of week' should use "ISO".

• In clause 10.7 (Time sets), the introduction twice refers to 'week of year' and 'weekday of year', which should use "ISO"

• Clause 10.10 makes several references to the "year of weeks" and "week-based year", which should use "ISO"

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

Correct references to 'week' terms in Clause 10

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

Specification: Date Time Vocabulary

Version: v1.2

Title: missing OCL

Summary:

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

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

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

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

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

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

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

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

Note: This is a follow-on to Issue 19462

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

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

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

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

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

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

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

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

time point2 follows time point1

time point2 is next after time point1

time point starts time interval

time point ends time interval

time scale of calendar

time scale on calendar

Repair the formatting of the cited entries

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

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

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

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

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

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

Revise 11.2: replace ISO 8601 with the Convention du Metre

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

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

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

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

· Gregorian year has Gregorian day of year

· Gregorian year has Gregorian month of year

· Gregorian month of year has Gregorian day of month

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

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

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

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

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

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

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

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

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

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

common year

leap year

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

week of days scale

day of hours scale

day of minutes scale

day of seconds scale

hour of minutes scale

minute of seconds scale

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

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

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

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

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

Add missing necessities for unique results

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

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

• Date

• DateTime

• TimeStamp

• Duration

Revise clause 18 to define datatypes

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

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

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

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

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

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.

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

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

OMG Specification: Date Time Vocabulary

Version: 1.0

Title: Unusual use of 'that' in definitions

Summary:

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

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

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

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

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

or

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

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

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

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

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

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

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

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

Defer for resolution of SBVR issue

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

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

Merging OCL into the UML model should be automated

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