W3C home > Mailing lists > Public > public-swbp-wg@w3.org > December 2005

Re: [OEP] Time Ontology Note Review

From: Jerry Hobbs <hobbs@ISI.EDU>
Date: Fri, 23 Dec 2005 15:26:30 -0800
Message-ID: <43AC87A6.9070703@isi.edu>
To: John McClure <jmcclure@hypergrove.com>
CC: public-swbp-wg@w3.org, hobbs@ISI.EDU, pan@ISI.EDU

John,

Thanks again for your critique of our proposal for a temporal
ontology.  Sorry for the delay in responding, but it took some time to
mull over your comments, plus the usual excuses.

Here are some of our thoughts on your comments.

 > 1. Poor Class Names: The names of seven of the nine classes (Instant
 > and InstantPair, Interval and ProperInterval, TemporalEntity and
 > TemporalUnit, DurationDescription, CalendarClockDescription, and
 > CalendarClockInterval) are each wholly artificial. Noone speaks of a
 > "temporal unit" nor certainly of a "duration description" -- these
 > names radically risk alienating those who want a simple RDF/OWL
 > solution that leverages the terms that they already know and use in
 > everyday language.

Most of the terms for basic concepts used in the note are consistent
with the literatures on time ontology and temporal logic (e.g., [1]
[2] [3]).  For example, what else would you call members of the set
{second, minute, hour, day, week, month, year} besides "temporal
unit"?  "Duration description" may not be a common phrase, but it's
compositional semantics is pretty obvious.  But we would be happy to
entertain other terminology if you have suggestions.

Concerning CalendarClock[Description/Interval] see below.

 > 2. Poor Property Names: A number of property names use an abbreviation
 > which are (or most certainly ought to be) verboten in a 'best
 > practice' document, eg intEquals, intBefore, intMeets, and so on. Some
 > of the names make little intuitive sense, eg inCalendarClockDataType.
 > And others should not have the meaningless suffix "Field".

We will remove the "Field" suffix. The reason we put it in there
originally was that without the suffix they would be confused with
some other properties we had defined. Since we have removed those
properties, it's now safe to remove the "Field" suffix.

For "inCalendarClock" (maps from instants to CalendarClockDuration) and
"inCalendarClockDataType" (maps from instants to xsd:dateTime), would
it be better to replace them by "inDateTime" and "inXSDDateTime"?
In general, we'd be happy to replace "CalendarClock" by "DateTime" in
all the names, if people think that would be helpful.

We'd also be happy to replace the names "intEquals" etc. with
"intervalEquals" etc.  Do other people think that would be a good
idea?

 > 3. Missing Fundamentals: No classes are defined for simple expressions
 > of a Second, Minute, Hour, Day, Week, Month, Year, Decade, or
 > Century. Yes these can be represented by a "DurationDescription" I
 > suppose but it is unquestionably odd to refer to some "Year" in this
 > manner.

Most of the time, when we talk about durations (including years or
mintues), there is an (implicit or explicit) associated interval with
its location on the time line, e.g., the 3rd month of the year
2005. Also durations can be described in many different equivalent
ways, e.g., 2 days vs. 48 hours.  This is the reason we have the
"DurationDescription" property for temporal entities.

Duration "Year" can be defined as a subclass of"DurationDescription"
with the restrictions that the "years" property is required (with
"cardinality" of 1) and all other properties (e.g., "hours", "months")
should not be present (with "cardinality" of 0):

:Year
       a       owl:Class ;
       rdfs:subClassOf :DurationDescription ;
       rdfs:subClassOf
               [ a       owl:Restriction ;
                 owl:cardinality "1"^^xsd:nonNegativeInteger ;
                 owl:onProperty :years
               ] ;
       rdfs:subClassOf
               [ a       owl:Restriction ;
                 owl:cardinality "0"^^xsd:nonNegativeInteger ;
                 owl:onProperty :months
               ] ;
       ...

       rdfs:subClassOf
               [ a       owl:Restriction ;
                 owl:cardinality "0"^^xsd:nonNegativeInteger ;
                 owl:onProperty :seconds
               ] .

It's worth pointing out that there is a distinction between a year as
a duration and a calendar year.  The year from December 22, 2004 to
December 21, 2005 is the former but not the latter.  The year 2005 is
both.  We take it that you were concerned with the durations, not the
calendar intervals, and that's what "year" should refer to?

 > 4. Inappropriate Assumption: The ontology assumes a gregorian
 > calendar, ignoring others such as an Arabic, Jewish, Julian, or
 > Chinese Calendar. Not to mention conversions between the calendars.

We assume you would not dispute that the people who use computers
overwhelmingly use the Gregorian calendar.  It would be nice to have
the other calendars in the ontology, but the Gregorian calendar was
obviously the highest priority.  We think that we have provided enough
of an example of how to build a calendar in [4] that it would be a
fairly straightforward technical exercise to construct the others,
modulo any astronomical knowledge that might be required, and we would
welcome such additions, although it is not our own highest priority
right now.

We also don't deal with years BCE or leap seconds in the current
ontology, for similar reasons.

 > 5. Missing Gregorian Classes: No classes are defined to represent
 > simple concepts like January, Tuesday, LeapDay, and LeapYear.

These can be specified using "CalendarClockDescription". For example,
"January" can be defined as a a subclass of "CalendarClockDescription"
with the restrictions that the "unitType" property has "allValuesFrom"
unitMonth and property "month" "hasValue" of 1:

:January
       a       owl:Class ;
       rdfs:subClassOf :CalendarClockDescription ;
       rdfs:subClassOf
               [ a       owl:Restriction ;
                 owl:onProperty :unitType
                 owl:allValuesFrom :unitMonth
               ] ;
      rdfs:subClassOf
               [ a       owl:Restriction ;
                 owl:onProperty :month
                 owl:hasValue "1"^^xsd:positiveInteger ;
               ] .

It would be straightforward to specify in OWL that LeapYear is a
subclass of CalendarYear.  The definition of "leap year" requires
first-order logic and arithmetic.  For that, please see [4].

 > 6. Missing Strawmen: It would be incomplete to publish a note about a
 > Time Ontology and not include a representation of a simple, everyday
 > calendar that uses its XML elements. As well, an RDF/A strawman is
 > critical to demonstrate use of these classes and properties in an
 > XHTML 2.0 or other framework.

Could you please clarify this a little bit more?  We're not sure what
you're asking for.

 > 7. Forgotten XML Schema Datatypes: Little guidance is provided how to
 > use the gregorian datatypes other than dateTime that are defined in
 > XML Schema, eg gDay, gMonth, gYear, gYearMonth, and gMonthDay.

This note is about an OWL representation of the ontology.  How to use
XML Schema datatypes is not the focus of the note.

 > 8. Missing Requirements: It would be reassuring to read specifically
 > what requirements apply to this ontology, what requirements are
 > satisfied, and what requirements have not (yet) been addressed.

At the beginning of the note, we describe what is covered by the
ontology, i.e., topological relations among instants and intervals,
durations, and clock and (Gregorian) calendar information.  We think
that the time ontology we developed satisfies all these requirements.
The first-order theory defines all the concepts (or at least
constrains their interpretations as much as possible).  In the OWL
version we expressed everything in the full theory that translates
naturally into OWL, including "declarations" for the complete
vocabulary of the full theory.

Please let us know if there is something you think is missing, other
than the things you have mentioned already.

 > 9. Missing Definitions: I cannot find any formal definitions for any
 > of the classes or any of the properties defined by the ontology.

The concepts in OWL-Time are explicated in [4].  There they are given
axiomatizations in first-order logic, and we feel these axioms pin
down their possible interpretations as much as is appropropriate.  In
some cases these are constrained enough to amount to definitions.  A
certain looseness is intended in some of the concepts, as described in
[4].

We refrained from including logical definitions in the note, for fear
of scaring off potential users.  We did put in prose descriptions of
the meanings of the terms.  If you think any of these are inadequate,
please let us know.

 > 10. Specific issue: The document says
 >
 >       We can see from this example that it's much more concise
 >       to use the XML Schema datatype dateTime. However, the
 >       advantage of using CalendarClockDescription 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/2003 is Wednesday, on the first
 >       day of the year, and in the first week of the year.
 >
 > Yes it's more concise to use dateTime.... all this other data is
 > located in a standard RDF calendar, not repeated constantly for each
 > date specified in every RDF file -- which is why it is SO IMPORTANT to
 > create a standalone calendar that uses the elements proposed by the
 > ontology, that provides this data. See, for instance,
 > http://www.hypergrove.com/OWL/ISO/Calendar2005.rdf, which eats the
 > tasty dogfood defined in http://www.hypergrove.com/OWL/ISO/ISO.owl. In
 > other words, the goal of a time ontology is encoding such as
 > <DepartureDate rdf:about='&legalxhtml;Time/D2005031'/> or, if
 > properties must be used, <departureDate
 > rdf:resource='&legalxhtml;Time/D2005031'/>.

Our representation doesn't preclude the simpler way of representing
date/times.  What we did was provide a more convenient and flexible
way for the user to explicitly specify more temporal information about
the date/times.

For example, our ontology has no problem representing a departure date
of March 10th, 2005 similarly:

<time:Instant  rdf:ID="departureDate">
   <time:inCalendarClockDataType rdf:datatype="&xsd;dateTime">2005-03-10
   </time:inCalendarClockDataType>
</time:Instant>

Thanks again for your valuable comments.  We are looking forward to
any further comments you have.

Feng Pan and Jerry Hobbs


[1] Allen, J. F. and Ferguson, G. 1997. Actions and events in interval
temporal logic. In Spatial and Temporal Reasoning. O. Stock, ed.,
Kluwer, Dordrecht, Netherlands, 205-245.

[2] Hayes, P. 1995. A Catalog of Temporal Theories. Tech report
UIUC-BI-AI-96-01, University of Illinois 1995.
    http://www.ihmc.us/users/phayes/TimeCatalog1.ps
    http://www.ihmc.us/users/phayes/TimeCatalog2.ps

[3] Zhou, Q. and Fikes, R. 2002. A Reusable Time Ontology. Proceeding
of the AAAI Workshop on Ontologies for the Semantic Web, 2002.
    http://www.ksl.stanford.edu/KSL_Abstracts/KSL-00-01.html

[4] Hobbs, J. R. and Pan, F. 2004. An Ontology of Time for the
Semantic Web. ACM Transactions on Asian Language Processing (TALIP):
Special issue on Temporal Information Processing, Vol. 3, No. 1,
pp. 66-85.
    http://www.ksl.stanford.edu/KSL_Abstracts/KSL-00-01.html
Received on Friday, 23 December 2005 23:27:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:15 UTC