- From: Jerry Hobbs <hobbs@ISI.EDU>
- Date: Wed, 04 Jan 2006 14:31:51 -0800
- To: John McClure <jmcclure@hypergrove.com>
- CC: public-swbp-wg@w3.org, pan@ISI.EDU
John,
> <time:Instant rdf:ID="departureDate">
> <time:inCalendarClockDataType rdf:datatype="&xsd;dateTime">
> 2005-03-10</time:inCalendarClockDataType>
> </time:Instant>
>
> 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".
Departure date is also an instant -- the time point where one actually
departs. The date is just the granularity for describing the instant.
> 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.
> Is this acceptable coding for the XML and RDF/A worlds?
We don't see why not?
> Wouldn't DepartureDate be a class defined somewhere?
> Isn't THIS coding infinitely better:
> <xxx:Date rdf:ID="myDepartureDate" date='2005-03-10'/>
We think it's sufficient to define it as an instance for this
example. Defining a concept as a class or an instance is really an
application-dependent decision. Our time ontology provides a core
vocabulary of time, and an application developer can easily extend it
to incorporate intuitive concepts for the application users.
For example, 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>
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.
> I urge you to take another crack at creating a time ontology that can
> be easilly understood. One simply echoing academic research with
> little regard for practice-minded communities, is short-sighted.
Obviously what we'd like to do is produce something that takes
"academic research" into account, since that is a good way to avoid
problems down the road due to design flaws, and also something that is
usable by "practice-minded communities". The latter goal is why we
find critiques like yours so valuable.
> 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.
-- Feng Pan and Jerry Hobbs
Received on Wednesday, 4 January 2006 22:32:38 UTC