RE: Time Ontology in OWL (OWL-Time)

Hello Roger -

Thanks for these suggestions. In particular, thanks for making them very concrete and implementable!

As mentioned by Scott, any changes to the document has to also respect the W3C process.
'Revision' of a normative document (e.g. a W3C 'Recommendation') can only be done through a formal working group and would be a 2-3 year process.
'Errata' can be processed more quickly, by consent of the SDWIG, and with the assistance of the W3C staff contact (Francois Daoust).

Even though they are tiny and non-normative, your suggestions look more like the former than the latter.
They are essentially to update the references to the OGC inputs to refer to definitions in a document that had not been published at the time that OWL-Time was prepared.
Thus, while I see benefits in making the changes you propose, I am not sure I see a path to achieving them.

Francois - do you see a pathway here?

Simon

From: Roger Lott [mailto:rogerlott@btinternet.com]
Sent: Wednesday, 9 January, 2019 10:10
To: public-sdwig@w3.org
Cc: 'Scott Simmons' <ssimmons@opengeospatial.org>
Subject: Time Ontology in OWL (OWL-Time)

The attached comments on Time Ontology in OWL (OWL-Time) were made in response to the Open Geospatial Consortium request prior to OGC adoption of the specification. I have been asked to repeat them to the W3C forum.

Issue:
Terminology surrounding (temporal) coordinate system and (temporal) coordinate reference system.

Background:
OGC Abstract Specification Topic 2 = ISO 19111, Referencing by coordinates, defines the terms 'coordinate system' (CS) and 'coordinate reference system' (CRS). The data model includes a high level construct in which a CRS is composed of a CS and a 'datum' which defines the relationship of that CS to an object (usually but not necessarily the Earth).


The latest revision of OGC Abstract Specification Topic 2 (awaiting formal publication but text available at OGC 18-005r3<https://portal.opengeospatial.org/files/?artifact_id=81118&version=1>) = ISO 19111:2019 (also awaiting formal publication, expected January 2019), has added detail to the elements defining a temporal coordinate reference system[1]. The same structure is used for temporal CRS as for other subtypes of (spatial) CRS, that is the high level construct is a temporal coordinate reference system which is composed of a temporal coordinate system and a temporal datum. A Topic 2/19111 Coordinate Reference System maps to the concept in 19108 called Coordinate System. This is confusing because of the different uses of the term 'coordinate system'. But leaving that ambiguity aside, see OGC 18-005r3<https://portal.opengeospatial.org/files/?artifact_id=81118&version=1> Annex D.1 for an overview of Topic 2 discussion of Temporal CRS.

[1] Historical note. During the revision of Topic 2 that led to 19111:2007, this detail was understood to be added to a proposed future revision of ISO 19108:2002. ISO 19111:2007 included a temporal CRS class as a stub but with no detail, just a reference to 19108. That revision of 19108 has never happened. As a consequence the missing detail was added to the recent 19111/Topic 2 revision, and is being included in the ongoing CRS WKT revision (ISO 19162).

Suggestions:
Before being adopted as an OGC specification, the Owl-Time documentation should be updated to acknowledge OGC Abstract Specification Topic 2 and mention the concept of a Temporal CRS. The following edits are suggested:

i) In 3.2 (Temporal reference systems, clocks, calendars), paragraph 6 add reference to ISO 19111 (OGC Topic 2) temporal reference system: " ... using a representation of temporal position in a temporal coordinate system [iso19108<http://www.w3.org/TR/owl-time/#bib-iso19108>] or temporal coordinate reference system [iso19111], [OGC Abstract specification Topic 2], i.e. ..."

ii) In 4.1.18, Temporal reference system class definition, change 'temporal coordinate system' to 'temporal coordinate reference system'.

iii) in 4.1.18, Temporal reference system, NOTE, add "ISO 19111:2019 (OGC Abstract Specification Topic 2) provides a data model structure for temporal coordinate reference systems, conceptually equivalent to the temporal coordinate system of ISO 19108, in which the offset may be expressed as a dateTime, an integer or a real number. Annex D provides examples of definitive and ambiguous calendar arithmetic".

iv) In Annex G.2, Informative references, add [iso19111] ISO 19111:2019 Geographic information - Referencing by coordinates, 2019. (URL will be available January 2019).



v) In Annex G.2, Informative references, add [ogcTOPIC2] OGC Abstract Specification Topic 2, 2019 - Geographic information - Referencing by coordinates, 2019. (URL will be available January 2019).



I also attach below Annex D from OGC Abstract Specification Topic 2 (2018/2019 version), in which 'this document' means OGC Abstract Specification Topic 2, Referencing by coordinates.


Annex D (informative)

Temporal referencing by coordinates - Context for modelling

D.1 General
ISO 19108[3] describes three forms of temporal reference system:
-           calendars;
-           ordinal scales;
-           temporal coordinate systems.
Calendars have a variety of complex internal structures defined through a set of rules for composing the calendar date and time. Ordinal scales provide a basis for measuring only the relative position of temporal objects, for example geological eras. Calendars and ordinal scales are out of scope of this document.
NOTE      This document and ISO 19108:2002 use the term temporal coordinate system to describe different concepts. A 19108:2002 temporal coordinate system maps to this document's temporal coordinate reference system.

In this document a temporal coordinate reference system is a temporal coordinate system which is related to the Earth through a temporal datum. The datum defines the origin of the temporal coordinate system with respect to a calendar. In this document the only calendar supported is the Gregorian calendar with its Proleptic extension, as defined in ISO 8601. However the Calendar class codelist allows implementations to extend to alternatives not supported by this document, for example providing the name of a calendar for Mars.

This document describes three options for temporal coordinate systems:

a)      dateTime;

1)     a value expressed as a DateTime in conformance with ISO 8601.

b)     temporal count;

1)     discrete temporal quantity, expressed as an integer. A unit of measure is included;

2)     the time axis is with respect to the calendar defined in the temporal datum.

c)      temporal measure;

1)     a continuous temporal quantity, expressed as a real value. A unit of measure is included;

2)     the time axis is with respect to the calendar defined in the temporal datum.
This document recognises both temporal count and temporal measure because for temporal count unambiguous conversion to dateTime is usually (but not always) possible whereas for temporal measure unambiguous conversion to dateTime generally is not possible; see the following sections of this Annex. Knowledge of this distinction a priori may be useful for implementation.

See E.4 for examples of TemporalCRS instances.

D.2 Temporal Units of Measure
Axis unit uses the datatype of UnitOfMeasure. This is defined in ISO 19103. The class includes a note "conversion ToISOstandardUnit is not null only if the conversion is a simple scale". For many temporal cases, the unit is not a simple scale, as the size of a month, a day or an hour vary at different locations in the calendar due to corrections factors and alterations such as leap seconds, leap years, and seasonal time zone changes. Conversion of a temporal quantity (unit of measure) to the SI base unit for time, the second, therefore may or may not be ambiguous when compared to a calendar definition of that quantity. Consequently, UnitOfMeasure instances for temporal counts and temporal measures may be defined with no relation to the second.

NOTE      In ISO 8601 the terms 'calendar day', 'calendar month' and 'calendar year' are used, with the note: often referred to as 'day',  'month' and  'year' respectively.

In the DateTimeTemporalCS case only, axis unit is prohibited. The dateTime syntax is a representation of a compound string including multiple units. Its components are defined in ISO 8601. This requirement prohibition is modelled through the DateTimeTemporalCS class.

POSIX time is commonly used in software. It is dimensioned in seconds, but leap seconds are ignored (not applied)[13]. A unit of measure "second" may be used to represent this, but it is required to be defined independent of the SI second, not as a specific number of SI seconds. It may be thought of as a "calendar second".

D.3 Reduced Precision
ISO 8601 defines syntax for dateTime instances with reduced precision. A temporal datum may use reduced precision to define its origin. For example a datum used in a temporal CRS for decimal years in the common era may choose to define its datum origin as 0000, a representation with precision reduced to only years.

Individual dateTime coordinate values may also use reduced precision.

D.4 Calendar Arithmetic

D.4.1 General
Calendar Arithmetic is the process of adding or subtracting a temporal quantity, an offset from a DateTime, to calculate a new DateTime, whilst taking account of all of the calendar corrections.

Calendars define time through periodic and quasi-periodic quantities, together with corrections to particular instances of those quantities at specified points in the calendar.  Leap seconds, leap years and seasonal time adjustments are all examples of corrections.

The definition of calendar arithmetic and the standardisation of results is not part of this document.  Implementations of this standard may implement calendar arithmetic to enable the conversion of dimensioned offsets to dateTimes, but the results from different implementations in a variety of  cases may differ (examples below).

Conversions between dateTimes and temporal quantities that are real values (temporal measures) are complicated, as context specific calculations and approximations for decimal remainders are generally required. This document does not support conversions to recalculate coordinate values using a different temporal measure unit or convert temporal measures to an ISO 8601 dateTime string.

Conversions between dateTimes and integer temporal counts can make use of integer arithmetic, reducing the complication significantly. In general integer calendar arithmetic returns consistent results and implementations may reasonably expect to agree on results. However there remain areas where some calculations are ambiguous or not well defined and caution is required. In such cases implementations may choose to return null results or raise exceptions.

To assist with implementation, some examples of definitive calendar arithmetic with integers are provided in D.4.2. Examples of ambiguous arithmetic, with integers and real values, are provided in D.4.3. These examples are illustrative, other interpretations of the ambiguous cases may also be plausible.



D.4.2 Definitive Calendar Arithmetic
Examples of unambiguous calendar arithmetic are:

a)       A DateTime offset by 25 months from a datum origin of 2012-01

(3/4)      2014-02

b)       A DateTime offset by 25 days from a datum origin of 2000-12-01T00:00Z

(3/4)      2000-12-25T00:00Z

c)       A DateTime offset by 31536000 hours from a datum origin of 1900-01-01T00Z

(3/4)      2006-04-01T00Z

d)       A DateTime offset by 1483228815 SI seconds from a datum origin of 1970-01-01T00:00:00Z

(3/4)      2016-12-31T23:59:48Z

e)       A DateTime offset by 1483228815 calendar seconds from a datum origin of
1970-01-01T00:00:00Z

(3/4)      2017-01-01T00:00:15Z (derived from POSIX formula[13])

f)        A DateTime offset by 5351236450450 SI microseconds from a datum origin of
2016-12-01T00:00:00.000000Z

(3/4)      2017-01-31T22:27:15.450450Z

g)       A DateTime offset by 5351236450450 calendar microseconds from a datum origin of
2016-12-01T00:00:00.000000Z

(3/4)      2017-01-31T22:27:16.450450Z (derived from POSIX formula[13])
Note the comparison between each of the last two pairs of examples.


D.4.3 Ambiguous Calendar Arithmetic

Examples of ambiguous calendar arithmetic are:


a)       A DateTime offset by 1 month from a datum origin of 2016-01-30

(3/4)      The accuracy of the datum origin is day, whilst the unit of the offset is month.  The day number is greater than the minimum. It is not clear how to interpret 1 month on from the 30th of January in any year, and a further complication is that the year may be a leap year. Plausible interpretations include:

(3/4)      2016-02-29 (the largest allowed value but still less than 30)

(3/4)      2016-02-28 (the largest allowed value -1, the last but one day of the month)


b)       An offset of 25.1 months as a dateTime from a datum origin of 2012-01-01

(3/4)      The interpretation of 0.1 of a month within the calendar is open to interpretation, as is the level of accuracy to which the result should be given. Plausible interpretations include:

(3/4)      2014-02-02 (25 months + the floor of 0.1 of a month of 28 days in days)

(3/4)      2014-02-03 (25 months + the round of 0.1 of a month of 28 days in days)

(3/4)      2014-02-02T19:12 (25 months + a time estimation based on the remainder)


c)       An offset of 31536000.146 hours from a datum origin of 1900-01-01T00:00:0Z

(3/4)      The interpretation of 0.146 hours within the calendar is open to interpretation, as is the resolution to which the result should be given. Plausible interpretations include:

(3/4)      2006-04-01T00:08:45.6 (all hours the same size, conversion to decimal seconds)

(3/4)      2006-04-01T00:08:45 (all hours the same size, floor conversion to integer seconds)

(3/4)      2006-04-01T00:08:46 (all hours the same size, round conversion to integer seconds)

(3/4)      2006-04-01T00:09:45.6 (northern seasonal time adjustment 1 hour forward)


d)       A temporal duration in hours from 0 hours to 24 hours from a datum origin of
2017-11-05T12:00:00

(3/4)      The time zone is not quoted, so the assumption in ISO 8601 is that this is local time, but the locale is not provided.  In New York, USA, there was a seasonal clock change, adding an hour, so the elapsed time is 25 hours. In Wellington, New Zealand, there was also a seasonal clock change skipping an hour, so the elapsed time is 23 hours. In London, UK, there was no seasonal clock change on this date, so the elapsed time is 24 hours.

e)       A temporal duration from 2011.163 years to 2012.163 years, from a datum origin of
0000-01-01T00:00, to be expressed as a dateTime

(3/4)      0.163 years within the calendar is open to interpretation. Plausible interpretations include:

(3/4)       (2011-02-28T12:00, 2012-02-28T12:00)

(3/4)       (2011-03-01T00:00, 2012-02-29T00:00)

f)        367 days [nameStandardUnit=second, scaleToStandardUnit=86400.0] from a datum origin of 2016-01-01T00:00:00Z, as a dateTime

(3/4)       It is unclear whether to use the integer days as a count, or whether to convert the days to seconds, as per the definition of the unit of measure, and count using these. 2016 was a leap year, and there was a leap second at the beginning of 2017 so using days as a count will result in a different day from using days converted to seconds, which will not count the leap second.

Roger Lott
OGC CRS SWG co-chair
epsg.rl@btinternet.com<mailto:epsg.rl@btinternet.com>

________________________________

________________________________

[1] Historical note. During the revision of Topic 2 that led to 19111:2007, this detail was understood to be added to a future revision of ISO 19108. 19111:2007 included a temporal CRS class as a stub but with no detail, just a reference to 19108. That revision of 19108 never happened. As a consequence the detail was added to the recent 19111/Topic 2 revision, and is being included in the ongoing CRS WKT revision.