Re: [OEP] Review o Time Ontology editor's draft 18 April 2006

Feng Pan wrote:
> Hi Guus,
> 
> Thank you very much for your comments on the new edition of the time 
> ontology note! Please see our reply below.

Feng,

Thanks for your prompt response. Comments inline.

> 
>> Review o Time Ontology editor's draft 18 April 2006
>> http://www.w3.org/2001/sw/BestPractices/OEP/Time-Ontology
>>
>> I enjoyed reading this document; clear and well-written. I
>> have a number of comments that I hope will help improve it.
> 
> Thank you.
> 
>> 1. begins/ends
>>
>> [[
>> begins and ends are relations between instants and temporal
>> entities, and the beginnings and ends of temporal entities,
>> if they exist, are unique. In some approach to infinite
>> intervals, a positively infinite interval has no end, and a
>> negatively infinite interval has no beginning. Hence, we use
>> the relations begins and ends in the ontology, rather than
>> defining functions beginningOf and endOf, since the
>> functions would not be total. begins, for example, can be
>> specified as:
>>
>> :begins
>>      a       owl:ObjectProperty ;
>>      rdfs:domain :TemporalEntity ;
>>      rdfs:range :Instant .
>> ]]
>>
>> It seems that domain and range should be reversed. An
>> Instant begins a TemporalEntity, right? I do not understand
>> the sentence about "beginningOf". Do you mean "hasBegin"
>> (domain=TemporalEntity, range=Instant)? I would then
>> understand your objection wrt some intervals not having a
>> begin/end.
> 
> The point of the sentence about "beginningOf" is that we can't use 
> functions; we have to use predicates. However, if this were a function, 
> TemporalEntity would be the domain and Instant (the beginning point) 
> would be the range.

My point was that

   TemporalEntity begins Instant

sounds counterintuitive to me. The name "begins" suggests to me that the 
domain should be Instant, e.g. Instant X begins Interval Y. Am I 
misinterpreting something?

> 
>> 2. DurationDescription
>>
>> The name "Duration" would be more natural for me, but I
>> guess this is a matter of style. Same holds for
>> DateTime/DateTimeDescription.
> 
> An interval can have multiple duration descriptions (e.g., 2 days, 48 
> hours), but can only have one duration.

OK. It would be useful to include this explanation in the note.

> 
>> 3. seconds/second property names
>>
>> For DurationDescription you use properties called "seconds"
>> "minutes", etc. For DateTimeDescription you use the singular
>> form ("second","minute"). Do you really need to use two
>> different sets of properties? I see no reason why you
>> couldn't use the same property with different local
>> restrictions for DurationDescription and
>> DateTimeDescription.
> 
> We use two different sets of properties because their ranges are 
> different. For example, "year" (in DateTimeDescription) has a range of 
> xsd:gYear, while "years" (in DurationDescription) has a range of 
> xsd:decimal so that you can say duration of 2.5 years.

Yes, I see. It helps to give the info on the different datatypes; please 
include it. I would also propose that you discuss the difference between 
"year" and "years" in the text.

You could still use one property name and employ local restrictions 
instead of global ranges, but given the semantic differences you pointed 
out above I agree it makes sense to have two set of properties.

> 
>> 4. use of xsd:duration
>>
>> Why do you not discuss the use of the datatype xsd:duration,
>> in similar fashion as later for the datatype xsd:dateTime?
>> It seems to be part of the OWL file though.
>>
>> I recall a problem with the semantics of xsd:duration, but
>> I'm not sure what the status is of this issue.
> 
> That's per Jeremy Carroll's comments [1,2]. We had suggested adding a 
> warning to point out the issue of the semantics of xsd:duration, but 
> Jeremy thought a warning would not be sufficient and suggested that it 
> should not occur in the document. So we have removed those from the note.

Hmm, not sure I agree with Jeremy. It is an obvious question to ask for 
a reader who knows the XML Schema datatypes. But I can live with it for 
now and wait and see what the comments from outsiders will be.

> 
>> 5. Specification of ":Year"
>>
>> Suggest to add a note why you prefer to use "maxCardinality
>> = 0" instead of restricting the values of days, etc. to
>> 0. This might be insightful for the readers.
> 
> Good point! A note will be added. The reason is that using 
> "maxCardinality = 0" means all those properties/fields (days, etc.) 
> should not be specified (i.e., the granularity is "year"), while 
> restricting all those values to 0 means they all have a fixed value of 0 
> (i.e., x years 0 months 0 days ...) and the granularity is actually 
> "second", which is not the correct semantics of "year".
> 
>> 6. DateTimeDescriptionOf
>>
>> Why is the domain DateTimeInterval (undefined in the
>> document, btw), where you use TemporalEntity in the
>> comparable property DurationDescriptionOf?
> 
> Any TemporalEntity has a duration, but only DateTimeInterval can have 
> DateTimeDescriptions (e.g., May 8 has a DateTimeDescription, but the 
> interval from 1:30pm, May 8, to 1:30pm, May 9, does not. Both have a 
> duration of a day.

Again, include this explanation in the document.

> 
> DateTimeInterval is a subclass of ProperInterval. We will add this into 
> the note.

I would be good to explain more clearly in the document, that a 
DateTimeDescription is always a description of an interval and not of an 
Instant (as readers might intuitively think). You can relate this to the 
point you make about 6:00pm being actually the interval 6:00-6:01,

> 
>> 7. properties DayOfWeek and DayOfYear
>>
>> One could argue this is redundant information (as it can be
>> computed). I assume you add it for convenience, but in that
>> case I would argue for a range of values such as "Monday",
>> "Tuesday" (with the possibility to use rdfs:label for other
>> languages).
>>
>> The argument of redundancy also holds for DayOfYear.
> 
> Yes, we add those for convenience (e.g., military applications use "day 
> of year" very often). Using a range of values such as "Monday", 
> "Tuesday" is a very good suggestion! We will update this in the note.
> 
>> 8.
>>
>> [[
>> :January
>>      a       owl:Class ;
>>      rdfs:subClassOf :DateTimeDescription ;
>>      rdfs:subClassOf
>>              [ a       owl:Restriction ;
>>                owl:onProperty :unitType
>>                owl:allValuesFrom :unitMonth
>>              ] ;
>>     rdfs:subClassOf
>>              [ a       owl:Restriction ;
>>                owl:onProperty :month
>>                owl:hasValue 1 ;
>>              ] .
>> ]]
>>
>> "owl:allValuesFrom :unitMonth"
>>  should be
>> "owl:hasValue :unitMonth".
> 
> Thanks! This will be corrected.
> 
>> 9. Discrepancies with OWL file
>> http://www.isi.edu/~pan/damltime/time-entry.owl
>>
>> There are many discrepancies between the examples in the
>> document and the OWL time ontology file. To mention a few:
>>
>> - different names;  e.g. DateTimeDescription is called
>>  CalendarTimeDescription
>> - specification of datatypes
>> - use of InstantThing instead of Instant (and variants of
>>  this scheme).
>> - intervalOverlaps vs. intOverlaps
> 
> The OWL file linked from the W3C note ("OWL code for the time ontology
> [RDF/XML]" -- right before the section of "Use Cases for Web Services") 
> is http://www.isi.edu/~pan/damltime/time.owl
> whereas the OWL file in
> http://www.isi.edu/~pan/damltime/time-entry.owl
> is an entry sub-ontology of the time ontology we developed, as described 
> in the note, that allows temporal predicates to apply directly to 
> events, but in the W3C note we restrict our treatment to temporal entities.

I now see what the problem is. Your reference [6]:

   [6] OWL code of the time ontology.
   http://www.isi.edu/~pan/damltime/time.owl

has a hyperlink to the wrong file: time-entry.owl.

> 
>> In general, the OWL file covers more than described by the
>> document. The document should at least be consistent with
>> the OWL file and preferably cover the full OWL specification
>> (possibly in appendices).
> 
> The OWL file in http://www.isi.edu/~pan/damltime/time.owl as linked from 
> the note is consistent with the content and the coverage of the note.
> 

I found a few update errors in the inverseOf slots (e.g. intBefore),

Thanks, again.

Best,
Guus

>> I would also like to have an overview table in (an appendix
>> of) the document summarizing all the time-related classes
>> and properties.
> 
> Good suggestion! This will be added.
> 
>> 10. Consistent naming
>>
>> I would prefer a consistent naming scheme, e.g. starting
>> classes with a capital (UnitSecond) and properties with a
>> lowercase letter (durationDescriptionOf).
> 
> Yes, we also follow that naming scheme, but "unitSecond" is an instance 
> (of TemporalUnit class), not a class, so it starts with a lowercase letter.
> 
> We have just double-checked the names, and found two inconsistent 
> property names:
> 
> - DateTimeDescriptionOf: a typo, will be corrected to dateTimeDescriptionOf
> 
> - XSDDateTime: we consistently use XSD in names, but it can be changed 
> to xsdDateTime unless you think it's a bad idea.
> 
> Thanks again for your very helpful comments!
> 
> -- Feng Pan and Jerry Hobbs
> 
> [1] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0083.html
> [2] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0104.html
> 
> -- 
> Feng Pan, Ph.D. Candidate
> USC Information Sciences Institute (ISI)
> Email: pan@isi.edu
> Web: http://www.isi.edu/~pan/

-- 
Vrije Universiteit Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
T: +31 20 598 7739/7718; F: +31 84 712 1446
Home page: http://www.cs.vu.nl/~guus/

Received on Wednesday, 10 May 2006 15:38:06 UTC