- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: Wed, 20 Jun 2007 13:25:37 -0600
- To: public-swbp-wg@w3.org
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
Over the winter and spring, the XML Schema, XSL, and XML Query
Working Groups reviewed the document "Time Ontology in OWL"
(W3C Working Draft 27 September 2006). I have just discovered
that after the Working Groups completed their review and
approved the comments, I seem to have let the matter drop and
failed actually to transmit the comments. My apologies for
the delay.
The Working Groups' comments are on the Web at
http://www.w3.org/XML/2007/qts-timeont-comments
(In some browsers, you may need to add .html to the end of that
URI, if the browser is not set up to display XML or does not
support XSLT, but nevertheless claims during content negotiation
to prefer XML to HTML.)
An ASCII version of the comments is appended, for the convenience
of those who prefer to have the full text of comments in the
mail archive.
We hope that our comments will be useful in any future revision
or re-issue of the time ontology document; please let us know
if you have any questions about them.
--C. M. Sperberg-McQueen
on behalf of the XML Schema, XSL, and XML Query Working Groups
[1]W3C [2]Architecture Domain [3]XML
[1] http://www.w3.org/
[2] http://www.w3.org/Architecture/
[3] http://www.w3.org/XML
Notes on Time Ontology
Anders Berglund
Andrew Eisenberg
Liam Quin
C. M. Sperberg-McQueen
17 April 2007, rev. 19 April 2007
_________________________________________________________
* 1. [4]Introduction
* 2. [5]General
+ 2.1. [6]Goals
+ 2.2. [7]Engagement with earlier work
+ 2.3. [8]Notation
+ 2.4. [9]Documentation
+ 2.5. [10]Possible ambiguity
+ 2.6. [11]Which calendar?
+ 2.7. [12]Which time? Leap seconds?
* 3. [13]Comments on specific sections
+ 3.1. [14]Section 4, Topological Temporal Relations
+ 3.2. [15]Section 5, Duration Description
+ 3.3. [16]Section 5, Duration Description
+ 3.4. [17]Section 6 “Time Zones” 1st paragraph:
+ 3.5. [18]Section 7 "DateTime Description" 1st paragraph:
+ 3.6. [19]Section 7, DateTime Description
+ 3.7. [20]Section 7, DateTime Description
+ 3.8. [21]Section 7 DateTime Description
+ 3.9. [22]Information content (section 7)
+ 3.10. [23]Week numbering (Section 7)
+ 3.11. [24]Gregorian and Julian calendars (Section 7
DateTime Description)
+ 3.12. [25]Example (section 8.2)
+ 3.13. [26]Appendix A, Summary of Classes and Properties in
the Time Ontology
+ 3.14. [27]Appendix B, Time Zone Resource in OWL
+ 3.15. [28]Appendix B "Time Zone Resource in OWL" 1st
paragraph:
+ 3.16. [29]Appendix B, subsection "Time Zone Ontology" 4th
bullet:
+ 3.17. [30]Using the time zone ontology (Appendix B)
+ 3.18. [31]GMT Offset (Appendix B.1)
_________________________________________________________
1. Introduction
This document contains comments on the document Time Ontology in
OWL, W3C Working Draft 27 September 2006, ed. Jerry R. Hobbs and
Feng Pan
(<URL:[32]http://www.w3.org/TR/2006/WD-owl-time-20060927/>), drafted
on behalf of the XML Schema, XSL, and XML Query Working Groups for
eventual transmission as comments on the working draft.
These comments are from the point of view of readers interested in
time, calendars, their representation in electronic form, and the
useful manipulation of those representations, but not readers
immersed in RDF or OWL. If the comments reflect some
misunderstanding of some details or of implications of the notation
used in the document, it may indicate that the document needs to
explain its notation and implications more clearly.
These comments have been drafted by the individuals named above on
behalf of the XML Schema, XSL, and XML Query Working Groups, and
have been approved by those Working Groups.
[32] http://www.w3.org/TR/2006/WD-owl-time-20060927/
2. General
2.1. 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 Confessions, 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 “General issues” 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.
2.2. 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 Representations of dates and times, in the editions of
1988-06-15 and 2000-12-15, on which the date/time types of XML
Schema are based
* the document Date and Time Formats, by Misha Wolf and Charles
Wickstead, submitted to W3C by Reuters in 1997
(<URL:[33]http://www.w3.org/TR/NOTE-datetime>), which proposes a
profile of ISO 8601
* the date/time datatypes of XML Schema 1.0
(<URL:[34]http://www.w3.org/TR/xmlschema-1/>) and 1.1
(<URL:[35]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 XQuery 1.0 and XPath 2.0 Functions and Operators
(<URL:[36]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
(<URL:[37]http://www.w3.org/TR/2007/REC-xslt20-20070123/#format-
date>)
[33] http://www.w3.org/TR/NOTE-datetime
[34] http://www.w3.org/TR/xmlschema-1/
[35] http://www.w3.org/TR/xmlschema11-2/
[36] http://www.w3.org/TR/xpath-functions/
[37] 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.
2.3. 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.)
2.4. 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?
2.5. 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.
2.6. 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.
2.7. 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.
3. Comments on specific sections
3.1. 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.
3.2. 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.
3.3. 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.
3.4. 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.
3.5. 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.
3.6. 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?
3.7. 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.
3.8. 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?
3.9. 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.
3.10. 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?
3.11. 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.
3.12. Example (section 8.2)
deliverySelectFedEx2-3day is an inappropriate example for a W3C spec
— please use one that does not mention a specific company.
3.13. 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?
3.14. 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.
3.15. Appendix B "Time Zone Resource in OWL" 1st paragraph:
We have developed a time zone resource [$1\47] in OWL for not only
the US but also the entire world, including three parts: the time
zone ontology file [$1\47], the US time zone instance file [$1\47],
and the world time zone instance file [$1\47].
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.]
3.16. 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.
3.17. 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.
3.18. 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.
Received on Wednesday, 20 June 2007 19:25:46 UTC