RE: [OEP] Time Ontology Note Review

John,

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

As we showed in the last email, should the application developer desires, a 
date class or property can be straightforwardly defined from our core ontology.

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

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)

> ============================================
> 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].

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.

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

OWL-Time is coded in OWL. Since OWL is a higher level ontology language based 
on RDF/S, while RDF/A is an effort to embed RDF in HTML, it's possible that 
some properties in OWL can not directly be expressed in RDF/A.

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

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

>> 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?

All the temporal units have been defined in our ontology:
http://www.isi.edu/~pan/damltime/time.owl

Please note that the base class for all time concepts in our ontology is NOT 
"CalendarClockDescription". "TemporalEntity" is the most general temporal 
concept in our ontology.

> ============================================
> 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

Here is the link to [4]:
http://www.isi.edu/~pan/time/pub/hobbs-pan-TALIP04.pdf

-- Feng Pan and Jerry Hobbs

Received on Thursday, 5 January 2006 22:47:48 UTC