Time Ontology outstanding issues

Dear All,

I promised to summarise the outstanding issues in the Time Ontology, but was sidetracked to the OGC Technical Committee conference. I will follow Frank Knibbe's approach of starting an email thread for each issue that needs a decision and/or discussion and exploration. Here is the summary of the marked issues in the latest draft of the Time Ontology http://w3c.github.io/sdw/time/ .

I am not sure what to do about some notes. Many can be removed as the text as been incorporated appropriately into the body of the text. Some can disappear when an issue is resolved and removed, but others that apply to the text in general may need discussion and decision.

I will group the notes, and issues if appropriate before starting threads.

Chris
----------------
Section 2 Changes from previous versions

Issue 1 https://www.w3.org/2015/spatial/track/issues/64

Most of the properties defined in the original ontology have global constraints on the domain and range. If the rdfs:domain were left unspecified, the properties could be used more widely without undesirable entailments. Their use in the context of the classes in the ontology is adequately controlled through guarded restrictions (local cardinality constraints)

Issue 2 https://www.w3.org/2015/spatial/track/issues/65

The Time ontology is concerned only with formalizing temporal intervals and instants, and does not include any predicates to tie temporal objects to spatial entities or features, or other things. The editors note that predicates that concern temporal behaviour and properties will usually be part of an application or associated with a community of practice. Nevertheless, there may be some generic predicates that could be conveniently provided as part of the generic time ontology. Some may already exist in the ontology (before, after, hasEnd, hasBeginning) but their rdfs:domain is :TemporalEntity, so this would need to be generalized to avoid inappropriate entailments. Else predicates with similar names could be provided for linking to other entities.
Note The SDWWG requirement 5.56 Valid time relates to this.

Issue 3 https://www.w3.org/2015/spatial/track/issues/26

Temporal vagueness requirement. Extended Data/Time Format (EDTF) is a detailed proposal for how to encode temporal vagueness, and some other concerns, by extending the xsd:dateTime syntax. The editors consider that would be the wrong direction since it would make the encoding inconsistent with all XSD-based processors. On the other hand, specific RDF properties matching the ones proposed in EDTF could be used to make it amenable to RDF reasoning. However, we should consider doing this in a separate namespace. Note that some of the concerns in EDTF are already accommodated in OWL-Time (e.g. 'unspecified' appears to only require the timeUnit to be chosen appropriately).
Note The SDWWG requirement 5.49 Temporal vagueness relates to this.

Issue 4 https://www.w3.org/2015/spatial/track/issues/15

Past, present future - this appears to already be supported using capabilities in OWL-Time, but needs to be verified.

4. Principles and vocabulary overview
4.1 Topological Temporal Relations

Issue 5 [No link]
:durationOf was mentioned in the original draft, but not in the published ontology. It appears to have been replaced by :hasDuration.

4.3 Time position and time units
Note DateTimeDescription covers the case that was defined in the original note, and retains the original class name.
Note These classes address the 'date' and 'time' requirement from 5.7 Date, time and duration

4.4 Duration
Issue 6 https://www.w3.org/2015/spatial/track/issues/63

What is the best URI for the Gregorian calendar/clock system? http://dbpedia.org/resource/Gregorian_calendar or http://www.opengis.net/def/uom/ISO-8601/0/Gregorian .
Note DurationDescription covers the case that was in the original note, and retains the original class name.
Note These classes address the 'duration' requirement from 5.7 Date, time and duration

5. Vocabulary specification
Note The SDWWG requirement 5.25 Multilingual support relates to the documentation of the ontology.

5.4 Class: DateTimeInterval
Issue 7 [No link]
Verify that this satisfies the SDWWG requirement 5.53 Update datatypes in OWL Time

5.5 Class: Instant

Issue 8 [No link]
This property uses xsd:dateTime which was available in OWL v1. The datatype xsd:dateTimeStamp, which makes the timezone element mandatory instead of optional, was added in OWL2. Should anything be added to OWL-Time to allow for this? Need to balance backward compatibility concerns. See SDWWG requirement 5.53 Update datatypes in OWL Time


5.6 Class: TRS [Temporal Reference System]
Note A taxonomy of temporal reference systems is provided in ISO 19108:2002 [ISO-19108], including (a) calendar + clock systems; (b) temporal coordinate systems; (c) temporal ordinal reference systems.

Issue 9 https://www.w3.org/2015/spatial/track/issues/66

Should we define a vocabulary for the definition of the other temporal reference system types? (Calendar+clock, temporal coordinate reference system). Perhaps as an additional annex to this document, alongside the Time Zone resource?

Note This TRS support addresses the following requirements from the SDWWG: 5.9 Different time models, 5.48 Temporal reference system, 5.28 Nominal temporal references.

5.8 Class: GeneralDateTimeDescription
Issue 10 [No link]
The time zone ontology provided in the Annex is immature and incomplete. Use of a tzont:TimeZone from that ontology as the range of an ObjectProperty in OWL-Time creates an implied dependency which is not ideal. We propose adding a stub class time:TimeZone into the main namespace (i.e. no properties) which can then be a super-class or equivalent class to any time zone formalization.(Compare with time:TRS which is handled this way.)

5.9 Class: DayOfWeek
Note In this version of the ontology, membership of the class DayofWeek is open, to allow for alternative week lengths and different day names.

5.11 Class: TemporalUnit
Note In this version of the ontology, membership of the class TemporalUnit is open, to allow for additional temporal units used in some technical applications (e.g. millions of years, Baha'i month).

5.14 Class: DurationDescription
Issue 11 [No link]
:Year was in the original OWL-Time, but was the only specialization of :DurationDescription - suggest moving it to an 'example' namespace

5.16 Datatype: generalYear
Note While this pattern achieves the correct lexical form, the value-space is not defined, so a generic OWL2 processor cannot compute ordering relationships of values of this type.

5.17 Datatype: generalMonth
Note While this pattern achieves the correct lexical form, the value-space is not defined, so a generic OWL2 processor cannot compute ordering relationships of values of this type.

5.18 Datatype: generalDay
Note While this pattern achieves the correct lexical form, the value-space is not defined, so a generic OWL2 processor cannot compute ordering relationships of values of this type.

6. Examples
6.1 iCalendar
Note This example replaces the one from [OWL-T].

6.3 DateTimeDescription vs. dateTime
Note This example carried over from [OWL-T].

6.6 A Use Case for Scheduling
Note This example carried over from [OWL-T].

6.7 Web commerce applications
Note This example carried over from [OWL-T].

B. Time Zone Vocabulary
Note This section unaltered from [OWL-T].

Issue 12 [No link]
The time zone ontology and vocabularies is less mature than the time ontology. It includes a taxonomy of jurisdictions (Region, PoliticalRegion, Country, State, Reservation, County, City) which does not cover all international practice. It refers to GMT, rather than UTC. It has fixed dates for daylight savings start and end, else uses a time-sequence ontology which is not provided. Appears to need more work.
----------------
Chris Little
Co-Chair, OGC Meteorology & Oceanography Domain Working Group

IT Fellow - Operational Infrastructures
Met Office  FitzRoy Road  Exeter  Devon  EX1 3PB  United Kingdom
Tel: +44(0)1392 886278  Fax: +44(0)1392 885681  Mobile: +44(0)7753 880514
E-mail: chris.little@metoffice.gov.uk  http://www.metoffice.gov.uk


I am normally at work Tuesday, Wednesday and Thursday each week