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

Jerry Hobbs wrote:
> 
> Dan,
> 
>  > 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?
> 
> It should be read
> 
>    Instant begins TemporalEntity
> 
> It very often happens that the value of a function appears in the
> subject of the sentence and the argument in the object.
> 
>    "3 is the square root of 9" for sqrt(9)=3
> 
> Is there an OWL convention to read domain as subject and range as
> object?

Jerry,

Yes, the convention in the RDF/OWL world is to read it from left to 
right: subject predicate object. So, from that perspective "hasBegin" 
and "hasEnd" are the appropriate terms.

> 
> We noted in the OWL OWL Web Ontology Language Guide
> 
>    http://www.w3.org/TR/owl-guide/
> 
> the following example:
> 
> <owl:ObjectProperty rdf:ID="course">
>   <rdfs:domain rdf:resource="#Meal" />
>   <rdfs:range rdf:resource="#MealCourse" />
> </owl:ObjectProperty>
> 
> The most natural way of saying this would be
> 
>    MealCourse is course of Meal
> 

This one must have slipped through. I'm sure the intended reading of the 
property is "hasCourse" and not "isCourseOf". See for example the 
properties names in the OWL Reference [1], which all have the 
left-to-right reading.

A naming suggestion from you that follows this convention would be very 
much appreciated.

> Wrt your other comments, we adding the explanations you recommended
> and making the corrections you suggested.

OK.

Guus

[1] http://www.w3.org/TR/owl-ref/

> 
> Thanks again for the close reading.
> 
> -- Jerry
> 
> -------------------------------------------------------------------
> 
> 
> 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
> 

-- 
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 Friday, 12 May 2006 15:25:08 UTC