SBVR 1.4 RTF Avatar
  1. OMG Issue

SBVR14 — SBVR Issue: Mis-use of Date-Time Concepts

  • Key: SBVR14-34
  • Legacy Issue Number: 19015
  • Status: closed  
  • Source: General Electric ( Mark Linehan)
  • Summary:

    SBVR 1.2 beta annex G (EU Rent Example) adopts concepts from the Date-Time Vocabulary (DTV) but deliberately gives them names that are both inconsistent with DTV and in fact are confusingly similar to the names of other concepts that are defined in DTV. Although any business can use any vocabulary terms desired, an OMG standard should maintain consistency with other OMG vocabularies for reasons of quality and to avoid user confusion. Especially a portion of a standard that is specifically intended to "to provide an aid to help them understand the specification " (annex G.2).

    The Annex is also inconsistent in its own terminology with respect to dates and times. For example, "maximum rental period" (Annex G.6.6) is a kind of "duration" even though G.8.6 defines "period" as a kind of "time interval" and a "rental period" (G.6.8.3) is a kind of "period".

    This annex also defines its own concepts that relate states of affairs to time, and for quantities – rather than using the corresponding concepts defined by the Date-Time Vocabulary. It fails to give definitions for these concepts, which means they are subject to varying interpretations. The example would be stronger if it used the carefully worked-out concepts defined in the Date-Time Vocabulary.

    Specifically:

    • Annex G.8.4 specifies, but does not define, concepts such as "state of affairs at point in time". 'Point in time' is a synonym for Date-Time's 'time point', which is a time interval that is a single member of a time scale. The authors of this Annex apparently did not understand that the duration of a time point depends upon the granularity of the time scale that is used. Consider a time scale of years. What does it mean to say that a "state of affairs at [a year]? Is the state of affairs "at" throughout the year or just during some portion of the year. The Annex G concept is fundamentally ambiguous.
    • Annex G.8.5 defines concepts such as "period", "period1 overlaps period2", and many others, using the definitions from Date-Time's "time interval", "time interval1 overlaps time interval2", etc., but with its own terms. This is particularly confusing because Date-Time has other concepts with similar names, such as "time period". (I do not object to terms that are clearly business specific, such as "rental period".) Moreover, the Annex probably should be built on the DTV "time period" concept, rather than "time interval". The discussion of the "Rental Time Unit" makes it clear that EU-Rent is interested in periods that are based on calendars (i.e. DTV "time period") rather than arbitrary periods ("time interval"). Probably the authors of the Annex did not understand the difference.
    • Annex G.8.5 defines a concept "date-time1 is before date-time2" that is unnecessary in light of the fact that a "date-time" is a kind of "time coordinate", which is a representation of a "time interval". The existing "time interval1 precedes time interval2" is applicable to all time coordinates, in the same way that representations of quantities (e.g. "5") may be used in instance of the verb concept "quantity1 is less than quantity2".
    • Annex G.8.5 misquotes some definitions from the Date-Time Vocabulary. For example, the definition of "current day" is misquoted.
    • The concept "date time" is defined twice: in G8.5 and in G.8.9.5. Another concept "date-time" has almost the same spelling, but has a different definition – another likely source of user confusion. Plus the definition does not make sense.
    • The Annex mixes two distinct types of concepts: "time intervals" (spans of time) and "time coordinates" (representations of time intervals). It should use one or the other throughout. The confusion is particularly obvious in places like the definition of "rental is late", which talks about the "end date-time" of a "grace period".
  • Reported: SBVR 1.1 — Sat, 12 Oct 2013 04:00 GMT
  • Disposition: Deferred — SBVR 1.4b2
  • Disposition Summary:

    Deferred to SBVR v1.5 Revision Task Force because the SBVR v1.4 RTF was requested to close before it was finished so the SBVR RTF could be convert to JIRA.

  • Updated: Thu, 6 Apr 2017 13:51 GMT