Re: [OEP] Time Ontology Note Review

John,

Thanks for your detailed critique and for your perspective.
Obviously, it will take us a while to mull all this over, but we'll
respond in a week or two.

-- Jerry

 > 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 Friday, 18 November 2005 04:06:27 UTC