RE: Time Ontology in OWL (OWL-Time)

Agreed. It is terminology/naming not formal semantics. 

There are 7 occurrences of 'temporal coordinate system' in the rec document, and 6 in the rdf document, several of them citing ISO 19108. Some are within normative text, though changing them would have no impact on users. But it would be messy to change them all. 

Are you proposing that adding your note to 4.1.18 would be sufficient to deal with all those mentions? That's probably OK (a 'Note:' is non-normative by definition). I would be less comfortable making changes a new references in a dozen other places.

Simon  

-----Original Message-----
From: rogerlott@btinternet.com [mailto:rogerlott@btinternet.com] 
Sent: Friday, 8 February, 2019 04:40
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-sdwig@w3.org; Francois Daoust <fd@w3.org>
Cc: ssimmons@opengeospatial.org; jeremy.tandy@metoffice.gov.uk; Gregory, Linda (A&F, Black Mountain) <Linda.Gregory@csiro.au>
Subject: RE: Time Ontology in OWL (OWL-Time)

In my view there are no normative changes in my suggestions.

Roger

--------------------------------------------
On Thu, 7/2/19, Francois Daoust <fd@w3.org> wrote:

 Subject: RE: Time Ontology in OWL (OWL-Time)
 To: Simon.Cox@csiro.au, rogerlott@btinternet.com, public-sdwig@w3.org
 Cc: ssimmons@opengeospatial.org, jeremy.tandy@metoffice.gov.uk, Linda.Gregory@csiro.au
 Date: Thursday, 7 February, 2019, 16:48
 
 Note the word “revision” has a
 broader meaning for us, encompassing both normative and  editorial changes. The IG can easily publish a revision of  the Time Ontology that includes editorial errata. What it  cannot do is publish a revision of the Time Ontology that  includes normative changes.
  That said, it may be possible to
 work around the definitions of “normative” and  “editorial” if the changes to incorporate clarify but do  not significantly alter the normative essence of the  statements. If you believe the proposed updates are useful  additions that essentially refine the definitions without  notably changing their meaning, I can certainly push  internally to have them published as  errata.
  Francois.
  
  
  
  From: Simon.Cox@csiro.au <Simon.Cox@csiro.au>
 Sent:
 Thursday, February 7, 2019 1:36 AM
 To:
 rogerlott@btinternet.com; public-sdwig@w3.org
 Cc:
 ssimmons@opengeospatial.org; fd@w3.org;  jeremy.tandy@metoffice.gov.uk; Linda.Gregory@csiro.au
 Subject: 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) = 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 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]  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
 modellingD.1
 GeneralISO
 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:dateTime;a  value expressed as a DateTime in conformance with ISO  8601.temporal count;discrete temporal quantity, expressed as an integer.
 A unit of measure is included;the
 time axis is with respect to the calendar defined in the  temporal datum.temporal measure;a  continuous temporal quantity, expressed as a real value. A  unit of measure is included;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 MeasureAxis 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
 PrecisionISO 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
 ArithmeticD.4.1
 GeneralCalendar 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 ArithmeticExamples of
 unambiguous calendar arithmetic are:a)  A DateTime offset by 25 months from a  datum origin of 2012-01¾
 2014-02b)
 A DateTime offset by 25 days from a
 datum origin of 2000-12-01T00:00Z¾
 2000-12-25T00:00Zc)
 A DateTime offset by 31536000 hours
 from a datum origin of 1900-01-01T00Z¾
 2006-04-01T00Zd)
 A DateTime offset by 1483228815 SI
 seconds from a datum origin of
 1970-01-01T00:00:00Z¾
 2016-12-31T23:59:48Ze)
 A DateTime offset by 1483228815
 calendar seconds from a datum origin of  1970-01-01T00:00:00Z¾  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¾
 2017-01-31T22:27:15.450450Zg)
 A DateTime offset by 5351236450450
 calendar microseconds from a datum origin of  2016-12-01T00:00:00.000000Z¾  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¾
 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:¾
 2016-02-29 (the largest allowed value
 but still less than 30)¾
 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 ¾  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:¾
 2014-02-02 (25 months + the floor of
 0.1 of a month of 28 days in days)¾
 2014-02-03 (25 months + the round of
 0.1 of a month of 28 days in days)¾
 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¾  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:¾
 2006-04-01T00:08:45.6 (all hours the
 same size, conversion to decimal
 seconds)¾
 2006-04-01T00:08:45 (all hours the
 same size, floor conversion to integer
 seconds)¾
 2006-04-01T00:08:46 (all hours the
 same size, round conversion to integer
 seconds)¾
 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¾  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¾
 0.163 years within the calendar is
 open to interpretation. Plausible interpretations  include:¾
  (2011-02-28T12:00,
 2012-02-28T12:00) ¾
  (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¾  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 LottOGC CRS SWG  co-chairepsg.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.

Received on Friday, 8 February 2019 03:25:03 UTC