- From: Guus Schreiber <schreiber@cs.vu.nl>
- Date: Fri, 12 May 2006 17:24:56 +0200
- To: Jerry Hobbs <hobbs@ISI.EDU>
- CC: Feng Pan <pan@ISI.EDU>, SWBPD list <public-swbp-wg@w3.org>
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