[OEP] Time Ontology Note Review

I have reviewed the note about the proposed Time Ontology
(http://www.isi.edu/~pan/SWBP/time-ontology-note/time-ontology-note.html and
http://www.isi.edu/~pan/damltime/time.owl). With due respect for the substantial
work that's gone into this already, I believe signficant refinement is
necessary.

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.

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".

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.

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.

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

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.

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.

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.

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

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'/>.

Received on Wednesday, 16 November 2005 23:54:09 UTC