comments on Time Ontology document

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

comments on Time Ontology document

C. M. Sperberg-McQueen

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.



Reply | Threaded
Open this post in threaded view
|

Re: comments on Time Ontology document

Jerry Hobbs

Dr. Sperberg-McQueen,

Thank you very much for your detailed comments on the OWL-Time
ontology.  Your observations deserve a detailed response.  However,
project deadlines and travel schedules preclude that right now.
I will get back to you with a full reply in August.

-- Jerry Hobbs