Goals

The document appears to lack any description of its goals.

Armed only with the title, a reader might expect an effort to develop a philosophically sound account of time, working from first principles — perhaps a little discussion of Augustine's reflections on time in the , maybe some Bergson, maybe some Heidegger. Or perhaps a more empiricist account, in which Carnap and Popper might figure. Other readers may expect an attempt to give a systematic, coherent, semantically meaningful account of date and time information in daily life, something along the lines of an abstract data type. It is hard to imagine a single document satisfying both sets of expectation.

The introduction of the document needs to set the reader's expectations more clearly.

The section on suggests that one important goal is to provide a definition in OWL of date and time information adequate for date and time data as commonly encountered on the Web and in data processing more generally. But the document fails to address a number of obvious and important questions. What requirements must such a definition meet? What possible or imaginable requirements does it NOT need to meet? Is it a goal to be able to distinguish between well-formed and ill-formed date/time descriptions? or a non-goal? Is it a goal to provide well-formulated accounts of all the essential operations on date/time data? Or is that to be left for later work? What must be done in order to provide a useful semantic account of the classes you define? What is the division of labor between this document (or more precisely: the ontology defined here) and potential users of it?

In these comments, we assume that any formal ontology of time concepts will make itself useful by identifying a core set of primitive notions relating those notions informally to real-world information by means of natural-language descriptions, so as to enable an informed reader to understand what a class instance using only those primitive notions 'means', and to formulate an appropriate class instance to capture a given intended 'meaning'; it may or may not be a goal to make the meaning and rules of interpretation clear not only to humans who have read the documentation but also to properly constructed software identifying a set of derived notions which can be constructed from, and defined in terms of, the primitive notions showing how to interpret the derived notions in terms of the primitive notions showing how to distinguish well-formed instances of the class from ill-formed instances, or (depending on how things are formulated) how to distinguish members of the class from other things, or both. That is, if some asks what is the difference between an instance of class DateTimeDescription and this block of wood? we expect the reader of the document to be able to find the answer. showing how to interpret / assign meaning to all well-formed instances of the class; it may or may not be a goal to avoid rules of interpretation that assign meanings to ill-formed instances Other goals may also be important; this list claims no exclusivity.

We believe the document currently does not meet all of these expectations and thus has opportunities for improvement. If the items listed above are not in fact goals, then the document should probably identity them explicitly as non-goals, to avoid having the reader believe in error that the authors tried to satisfy them but failed. Readers might then cavil with the choice of goals for the work, but at least then the authors and the reader can argue about the same thing.

Engagement with earlier work

There is a great deal of earlier work relevant to the topic of this paper; without going at all far afield, we mention ISO 8601 , in the editions of 1988-06-15 and 2000-12-15, on which the date/time types of XML Schema are based the document , by Misha Wolf and Charles Wickstead, submitted to W3C by Reuters in 1997 (http://www.w3.org/TR/NOTE-datetime), which proposes a profile of ISO 8601 the date/time datatypes of XML Schema 1.0 (http://www.w3.org/TR/xmlschema-1/) and 1.1 (http://www.w3.org/TR/xmlschema11-2/); these are mentioned in the document, but the document provides no bibliographic reference to the relevant specifications the library of functions and operators on date/time values defined by (http://www.w3.org/TR/xpath-functions/) the library of functions for formatting date and time information provided in section 16.5 of XSLT 2.0 (http://www.w3.org/TR/2007/REC-xslt20-20070123/#format-date) The document should, we believe, refer to this related work.

More important, the document needs to engage with that other relevant work. The document's comments about the XML Schema types do not seem to reflect any real understanding of those types, their design, or the requirements of conventional information processing systems. And ISO 8601 has a great deal to teach anyone interested in working with date and time information in practice.

Notation

Some readers of English may be unfamiliar with the notation used to describe RDF graphs in this document; we recommend that a pointer to documentation for the notation be provided, and that each expression in the formal notation be accompanied by an English paraphrase of its meaning. (This practice introduces a certain amount of redundancy, which is useful for people who understand the formalism but don't read English well, or vice versa, and makes it easier to find typos, errors, and discrepancies.)

Documentation

None of the fields appear to have any documentation saying what the expected, well-formed, and/or semantically correct values of the field are, or how the values relate to time concepts.

It's possible that we are simply missing something that anyone fluent in N3 would see at once. If so, then you may have an editorial issue: unless your intended readership consists only of people conversant in N3, it would be useful to describe the contents of the N3 in English as well as in N3. If not, then you have another editorial issue: you should probably explain why the fields have no documentation and nothing to say what their values are expected to be.

Would :meetingStartDescription a :DateTimeDescription ; :unitType Typus ; :minute Minute ; :hour Stunde ; :day Tag ; :dayOfWeek Wochentag ; :dayOfYear Jahrestag ; :week Woche ; :month Monat ; :year Jahr . be a legitimate representation of a DateTimeDescription? If not, why not, and how should a reader of the Time Ontology document know? If so, then what is its interpretation: what instant in time does it describe?

Possible ambiguity

This year, in Massachusetts, Nov. 4, 2007, 01:01 EDT will be followed by Nov. 4, 2007, 01:00 EST, which will be followed by Nov. 4, 2007, 01:01 EST. The following value appears to be ambiguous: :example a DateTimeDescription; :unitType unitMinute; :minute 1; :hour 1; :day 4; :month 11; :year 2007; :timeZone EST.

Given that EST appears to denote the geographic time zone, and not in itself the offset from UTC, this appears to denote two distinct moments, one on winter time and one in summer time.

Which calendar?

The document doesn't seem to describe anywhere how to specify what calendar is in use in a particular DateTime description. Can it be inferred from this that all correct DateTime descriptions use the same calendar?

If so, then which calendar do they use? Some indications suggest that the proleptic Gregorian calendar is used (for example, the parallel between the xsdDateTime and inXSDDateTime relations, which have xsd:dateTime as their ranges, and the other relations with DateTime descriptions as their ranges). But the document goes on to say Someone doing a genealogical search may want to specify that the birthdate of a person is between 15 and 45 years before a known marriage date, for which the XML Schema datatype isn't directly usable.

Which time? Leap seconds?

Which system of time is used in dateTime descriptions? UTC, UT1, UT0, mean solar time, actual solar time, international atomic time, ephemerides time, ... ?

Does it vary between descriptions? If so, where does a description inform the user which system of time is in use? If not, where does the ontology tell the user which system is to be used to interpret dateTime descriptions?

If UTC is intended, then what policy is adopted by the ontology regarding leap seconds? Are they included? excluded? If included, then how can valid descriptions for times in the future be distinguished from meaningless constructs which denote no point or interval in time?

The XML Schema specification answers these questions for the dateTime type, but nothing in the ontology says explicitly that those answers apply to dateTime descriptions.

Section 4, Topological Temporal Relations

Interval relations such as intervalEquals, intervalBefore, etc are mentioned. That a month sometimes has 28, 29, 30, or 31 days is not mentioned. It is not known whether an interval starting now with duration 30 days and an interval starting now with a duration of 1 month are equal.

XML Query derives by restriction from xs:duration the types xs:yearMonthDuration and xs:dayTimeDuration. A less than operator is not defined between xs:duration and one of these two types, or between xs:yearMonthDuration and xs:dayTimeDuration.

Section 5, Duration Description

The ranges of the years .. seconds properties is specified in Appendix A as xsd:decimal. We would have expected all but the seconds property to be xs:integer. Specifically, we are surprised by the comment so that you can say duration of 2.5 years. We would expect that a duration of 2 years and 6 months could be defined, but not a duration of 2.5 years.

Section 5, Duration Description

Even if fractional duration units were better specified, we believe that it would be better to align the practice of the ontology with that of the existing duration types in XML Schema, and require integral values for all components of the duration except seconds.

Section 6 Time Zones 1st paragraph:

The document says in section 6:

What hour of the day an instant is in is relative to the time zone. This is also true of minutes, since there are regions in the world, e.g., central Australia, where the hours are not aligned with UTC hours, but are, e.g., offset half an hour. Seconds are not relative to the time zone.

The last sentence is incorrect for e.g. solar time that was used in Saudi Arabia until 1950. When noon is calculated by solar observation, the beginning of the second will in fact vary from time zone to time zone.

Is the ontology not intended to apply to date and time information used in the past? There is no statement in the document that such a severe limitation of scope is intended.

Section 7 "DateTime Description" 1st paragraph:

A datetime description has the following properties/fields: unitType, year, month, week, day, dayOfWeek, dayOfYear, hour, minute, second, and timeZone.

Since the "week" (week number) is culture specific it seems a bad choice to include it in the "canonical" description without additional properties/fields to disambiguate this.

Section 7, DateTime Description

Limits on the values of the DateTimeDescription properties should be specified (e.g. seconds between 0 inclusive and 60 [or 61] exclusive).

XML Schema defines 2007-03-21T24:00:00-04:00 and 20070-03-22T00:00:00-04:00 as two representations of the same time. Is 24:00 hours allowed in a DateTimeDescription? What does it mean?

Section 7, DateTime Description

A requirement should be added, saying that the properties of dayOfWeek, dayOfYear, and week must be consistent with the values of the other properties.

Section 7 DateTime Description

Consider the example from the section "DateTime Description": :meetingStartDescription a :DateTimeDescription ; :unitType :unitMinute ; :minute 30 ; :hour 10 ; :day 1 ; :dayOfWeek :Sunday ; :dayOfYear 1 ; :week 1 ; :month 1 ; :timeZone tz-us:EST ; :year 2006 .

Would this still be valid if the value of :minute were 73?

What does :week 1 mean here? Judging from the prose (we can also know that 01/01/2006 is Sunday, on the first day of the year, and in the first week of the year) the reader may guess that it's intended to mean that the instant being described is during week 1 of 2006.

But what does week 1 mean? What is a week, and how are weeks numbered? Do weeks begin on Sunday? Monday? On the first day of a month? On the first day of a year?

Information content (section 7)

Section 7 says in part: ... the advantage of using DateTimeDescription is that it can express more information than dateTime, such as week, day of week and day of year, so in the above example, we can also know that 01/01/2006 is Sunday, on the first day of the year, and in the first week of the year.

The problem with this proposition is that the day of the week, and the week number, do not constitute additional information; the nature of the Gregorian calendar and any systematic week-numbering system is such that if the date is known, then the day of the week and the week number are necessarily also known, and can be calculated algorithmically. So the claim that a dateTime description can express more information than the XSD dateTime type seems to be simply false, unless the nature of dateTime descriptions is such that they are not tied to a particular calendar, in which case it is not clear that they are usable for conventional date/time information.

Week numbering (Section 7)

Section 7 says that Sunday 1 January 2006 is the first day of the first week of 2006. Is it? Or is it the last day of the first week of 2006? Perhaps the most widely known system now in use for numbering weeks is that of ISO 8601 (and of other ISO specifications before it); in that system, Sunday 1 January 2006 is not the first day of the first week of 2006, but the last day of week 52 of 2005.

What scheme of week numbering is being used in the example in section 7? How is a consumer of a DateTimeDescription to know? Can it vary from instance to instance, or is it constant for all DateTime descriptions?

Gregorian and Julian calendars (Section 7 DateTime Description)

Consider :meetingStartDescription a :DateTimeDescription ; :unitType :unitMinute ; :minute 30 ; :hour 10 ; :day 1 ; :dayOfWeek :Saturday ; :dayOfYear 1 ; :week 1 ; :month 1 ; :timeZone tz-us:EST ; :year 2006 . This is the same as the example in section "DateTime Description" except that the day of the week changed from Sunday to Saturday.

Does it describe an instant in time? Is there a typo in the dayOfWeek field? According to the calendar, 1 January 2006 was a Sunday, not a Saturday. Or does the description denote Saturday, 1 January 2006 in the Julian (Old Style) calendar, which is Saturday 14 January 2006 in the Gregorian calendar?

Consider :meetingStartDescription a :DateTimeDescription ; :unitType :unitMinute ; :minute 30 ; :hour 10 ; :day 1 ; :dayOfWeek :Friday ; :dayOfYear 1 ; :week 1 ; :month 1 ; :timeZone tz-us:EST ; :year 2106 . This is the same as the example in section "DateTime Description" except that the year has been changed from 2006 to 2106 and the day of the week changed from Sunday to Friday.

What period of time is denoted by this description? The description seems to make sense in more than one way. Friday 1 January 2106 is a day in the Gregorian calendar; it is also a day in the Julian (or Old Style) calendar.

Example (section 8.2)

deliverySelectFedEx2-3day is an inappropriate example for a W3C spec — please use one that does not mention a specific company.

Appendix A, Summary of Classes and Properties in the Time Ontology

The QName ranges should use colons, not semicolons (so xsd:decimal not xsd;decimal). A cut-and-paste or global-change error?

Appendix B, Time Zone Resource in OWL

Time zones as legal entities are subject to change over time. The U.S. changed the dates it transitions to and from daylight savings time in 2007 (Energy Policy Act of 2005). DaylightSavingsPolicy does not seem to be able to represent this complexity.

Appendix B "Time Zone Resource in OWL" 1st paragraph:

We have developed a time zone resource [15] in OWL for not only the US but also the entire world, including three parts: the time zone ontology file [16], the US time zone instance file [17], and the world time zone instance file [18].

Including support for the entire world is a good thing. The resource seems, however, to lack support for parts of the world. The list is long, but this is what struck us off the cuff:

solar time that was used (just ONE example) in Saudi Arabia until 1950.

support for different calendars, many of which are not "aligned" with the "ISO" one. Note also that things like the start of the year has changed over time even in the same calendar. [This comment though is not time zone specific.]

Appendix B, subsection "Time Zone Ontology" 4th bullet:

observesDaylightSavingsTime: true if the region goes on daylight savings time, false otherwise.

This "boolean" is unfortunately time-dependent! Take the example of Sweden:

Daylight savings time was introduced on a trial basis in 1916, but following protests from the farmers it was not repeated the following year. It was re-introduced in 1980. The start and end date has also varied considerably with time, which does not seem to be expressable.

Using the time zone ontology (Appendix B)

It is not clear how one would use the time zone ontology given, "The expected input to the ontology is a location, e.g. a city, and the output will be its current time offset, say -6 hours, from the Greenwich Mean Time (GMT)." in genealogical research, where one would presumably want the timezone for an historical date (to calculate astrological charts?) For this to work you'd need also to specify a year -- e.g. there was a double DST in effect during WWII, and in most countries summer time was not used at all before WW I.

GMT Offset (Appendix B.1)

The offset GMToffset: an XML Schema duration between -12 and +14 hours. appears to be sufficient to hold any actual timezone in current use, although it's not clear whether it takes DST into account. But the range of actual time zones has changed somewhat in recent years, and there is little likelihood that such changes will cease in the foreseeable future.