RE: [OEP] Time Ontology Note Review

Feng,

Beyond a few comments below, I'll wait till the next version of the note for
further discussion.

Best wishes for the new year,
John

>> ============================================
>> 1. Will people really think a departure date is an "Instant"?

>XSD:dateTime is based on ISO 8601 standard having a provision that allows
>"the omission of components representing smaller units (seconds, minutes),
>where such precision is not needed".
>(from http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html)

True for ISO, but the issue is what XSD says.
http://www.w3.org/TR/xmlschema-2/#dateTime makes no such provision.

	3.2.7.1 dateTime Lexical representation

	The .lexical space. of dateTime consists of finite-length
	sequences of characters of the form:
	'-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?

>> ============================================
>> 2. Will anyone have a clue what inCalendarClockDataType is?

>As we discussed in the note, our ontology provides more than that: it provides
>not only the properties that do use XSD datatypes (e.g., dateTime and
>duration), but also classes and properties which are more expressive, for
>example, "CalendarClockDescription" can represent more information than
>XSD:dateTime, such as "week", "day of week" and "day of year", and these
>extra information can be very useful for particular applications (e.g.,
military
>applications), and they also make it easier to extract values from any field
>of the class.
>
>Thus, it gives the users or application developers the freedom to
>choose either the more compact ones or the more expressive ones,
>depending on the needs of their applications.

Understood. In the Legal XHTML ontology, classes for each of the days of the
week are established, so that a date can be easily <rdf:type>'d as that
day-type. I think that approach is superior to having text strings or, heaven
forbid, index numbers for day-of-the-week. My hope in the next revision is that
you'll define classes for each day of the week in this manner.

Further, the Legal XHTML ontology defines a class "DateTime" (and its primary
property, "datetime") as a subclass of both CalendarDate and ClockTime -- this
is superior to the note's CalendarClockDescription construct because one can
specifically create instances (or subclasses) that are dates but not times, and
times that are not dates. It's also superior because people naturally understand
what a DateTime, a CalendarDate, and a ClockTime ARE, without having to read a
document to understand what is meant by CalendarClockDescription.

>> ============================================
>> 3. Is this acceptable coding for the XML and RDF/A worlds?

Well, I still stand by my claims that it's not good XML, and that as a best
practice, it should work in RDF/A coding environments.

>> ============================================
>> 4. Isn't THIS coding infinitely better:
>>   <xxx:Date rdf:ID="myDepartureDate" date='2005-03-10'/>

>I noticed that in your ontology you defined your "CalendarDate" as a subclass
>of "CalendarPeriod", so I think you can understand what
>"CalendarClockInterval" means in our ontology. The only difference is that
>we combine calendar and clock information together (similar to
>XSD:dateTime).

I think that creating separate classes for date and for time (each of which
accommodate their relevant XSD quantity) and then combining them together to
accommodate the XSD:dateTime is a superior approach.

Received on Friday, 6 January 2006 00:56:16 UTC