RE: [OEP] Time Ontology Note Review

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

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

>This example is very similar to the "CreditCardExpirationDate" example
>we show in the time ontology note, where it was also defined as an
>instant, "because the expiration date is actually an instant -- the
>midnight of the day the credit card expires".

Actually, "expiration date" refers to invalid charges occurring AFTER the
subject date, so the 'time' at which the expiration implicitly occurs is
23:59:59 on the date, not 00:00 on the date, or better yet, is 00:00 on the date
FOLLOWING the so-called expiration date. Further for credit cards, the
expiration 'date' is often a month-year combination, so the card expires at
midnight on the day FOLLOWING the last day of the month in the year of the
"expiration date".

But more to the point is that if an 'instant' is desired to be communicated, the
proper way is to establish a CreditCardExpirationDateTime property or class. It
would be mighty odd in the application world to say that an instant is a date,
or a date is an instant; the note presently implies such an equivalence which,
in my opinion, is not only NOT a best practice but also NOT true.

>Departure date is also an instant -- the time point where one actually
>departs. The date is just the granularity for describing the instant.

Again, it should be called "DepartureDateTime" if the desire is to communicate
the instant that someone actually departs, or is scheduled to depart. Again, a
date is not an instant in time but is a set of instants in time -- pretending
they're the same thing obfuscates what is being communicated.

I'm also noticing that rdf:datatype="&xsd;dateTime" while the value is
2005-03-10 -- I think it is poor practice, and I suspect that XSD supports me on
this, to allow a dateTime value to be missing a time quantity.

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

>In our last email, we asked for feedback regarding an alternative
>name, "inXSDDateTime", which may be more intuitive.

I think BOTH property names are uncommunicative and unwise. I vastly prefer that
best practice be to establish classes and or properties that coincide with each
of the XSD datatypes, as I have done in the Legal XHTML ontology [1].

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

>We don't see why not?

XML: applications want intuitively clear and simple elements and attributes. The
note requires that the rdf:datatype attribute on the "inCalendarClockDataType"
always be specified -- this contradicts that need for simplicity.  It is also
intuitively unclear what the property is meant to convey.

RDF/A: The 'rdf:datatype' attribute canNOT be specified in an RDF/A coding. The
date itself would presumably be encoded something like

   <span rdfa:property='time:inCalendarClockDataType'>
      2005-03-10</span>

So therefore the 'time:inCalendarClockDataType' property is also a poor fit with
RDF/A best practice.

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

>... in order to specify a departure date in the way you did,
>we can define a "Date" class as a subclass of "CalendarClockInterval",
>and a "date" property whose range is XSD:date:
>
>   <owl:Class rdf:ID="Date">
>     <rdfs:subClassOf rdf:resource="#CalendarClockInterval"/>
>   </owl:Class>
>
>   <owl:DatatypeProperty rdf:ID="date">
>     <rdfs:domain rdf:resource="#Date" />
>     <rdfs:range  rdf:resource="&xsd;date" />
>   </owl:DatatypeProperty>

Interesting.... this is how I define the 'date' property in the Legal XHTML
ontology for time [1] (see the class named "CalendarDate"). The Legal XHTML
ontology also defines a DatatypeProperty for each one of the time-related XSD
datatypes, something I think the note should do also.

But more relevant I suppose is that the class "CalendarClockInterval' is poor at
least because it is artificial -- a creature of some research paper's
imagination that is ungrounded with respect to everyday discourse. To
re-emphasize, I have no intuitive sense what a 'CalendarClockInterval' IS, and I
haven't heard anyone say otherwise.

>However, in the way you define the departure date, you will have to
>define all the classes for different granularities, whereas in our
>representation, different granularities can be represented using only
>one class ("CalendarClockDescription") with a different value of the
>"unitType" property.

It's hard to evaluate your 'unitType' property since unitSecond,  ..., unitYear
have not been formally defined in your note or your ontology. FYI, in the Legal
XHTML time ontology there is a similar property, 'TimeUnit' whose domain is the
"Time" class (the base class for all time concepts, like your
"CalendarClockDescription"). Note that the values of Legal XHTML's TimeUnit
property coincide with the time quantities established by the International
Bureau of Weights and Measures... and please note that Legal XHTML's 'TimeUnit'
maps to the "Time-Unit" definition in http://ksl.stanford.edu/ontologies/time,
which is cited as fundamental to [3]. As an aside, why the need in your note to
rename TimeUnit to TemporalUnit, in light of your claim that the note follows
naming established by the literature?

============================================
5. Missing (Gregorian) Classes and properties

> > For instance, you say that Year, CalendarYear, January, and Sunday can all
> > be defined as subclasses ..... yet you don't do it -- why not? Surely
> > you can appreciate that definition of THESE TERMS is both critical and
> > mandatory.
>
>Our aim was to produce something that was adequate but also compact.
>But you have convinced us to add a section to the note defining the
>common everyday terms in the obvious way.
>

Great to hear. I do understand that one goal of the note was to define a small
number of classes and to let others 'fill in the blanks' so I appreciate your
reconsideration of the impact of doing so.

The Legal XHTML ontology for time [1] defines around 75 classes and 375
properties (which includes classes that act as properties, those which I call
"Direct Object" classes). It will be interesting to see the extent to which the
note will have the capacity to define a resource representing a normal
calendar.... such as the Legal XHTML calendar [2] that I shared with you
earlier. You see, it is my opinion that the note definitely needs to be able to
represent a normal wall-calendar so that (as I said earlier) one can say not
only

   <xxx:Date rdf:ID="myDepartureDate" date='2005-03-10'/>

but also

   <xxx:Date rdf:ID="myDepartureDate" rdf:about='{aCalendar}/20050310'/>

It is in THAT RESOURCE, '{aCalendar}/20050310', that one finds the name of the
day, its status as a holiday or workday, its preceding and following days, and
any and all other information that the resource creator deems important. Futher,
I believe that it is only by having such a calendar published by the W3C, can
the global community hope to avoid having to inventory and to process
innumerable 'owl:sameAs' relationships across resource repositories with regard
to dates.... gee all this was covered in my original review of the time note.

[1] http://www.hypergrove.com/OWL/ISO/Calendar2005.rdf
[2] http://www.hypergrove.com/OWL/ISO/ISO.owl.
>[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

Incidentally, please note that the link you provided for your [4] is the same as
it is for your [3], so I was unable to review it.
>
>[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

Cheers,
John

PS I have not reviewed the timezone constructs in the note in any depth,
focusing first on the date/calendar related issues.

Received on Thursday, 5 January 2006 02:27:36 UTC