- From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
- Date: Mon, 4 Aug 2008 17:33:46 +0100
- To: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Cc: public-owl-wg@w3.org
On 29 Jul 2008, at 17:15, Peter F. Patel-Schneider wrote: > > Here is my proposed LC comment to the XML Schema WG concerning > datetime. > I have some comments in []. I did not "ask" for changes to dateTime > itself, aside from a new derived datatype, but instead put forward > what > I think are our concerns. > > peter Looks good. I did have a few comments/suggestions though -- they are in line below. Thanks, Ian > > > > > The W3C OWL WG is determining how to use XML Schema dateTime values > from > the last call working draft http://www.w3.org/TR/xmlschema11-2/ in OWL > ontologies. The main problem we face concerns dealing with dateTime > values that do not have a timezone. The document puts these values > on a > single separate timeline that is partially ordered with respect to the > absolute timeline. > > For the purposes of reasoning in OWL, it is much easier to deal with > dateTime values where the timezone is present. Such values can be > converted to single time points (using timeOnTimeline) and a complete > order determined from the time points. We would thus like to have a > derived XML Schema datatype for dateTime with a required timezone. [I > added this last sentence based on some evidence but the WG should > confirm.] > > There are already OWL ontologies that contain dateTime values where > the > timezone is absent. Such dateTime values may come from different > documents, and that really have a different notion of what their local > (unspecified) time is. The document, You refer to "the document" several times. I assume this is http:// www.w3.org/TR/xmlschema11-2/. Wouldn't it be clearer to cite this in the usual way: [1] http://www.w3.org/TR/xmlschema11-2/ and use "[1]" instead of "the document"? > however, makes these values all > equal. > > Our proposed solution to handling such ontologies is to put off the > task > of determining "missing" timezones to tools, with roughly the wording > that tools MAY accept dateTime values with an absent timezone by > determining what the "local" timezone is for the value and SHOULD > produce a warning if they do so; otherwise dateTime values with > missing > timezone are syntax errors. I liked Sandro's suggested refinement here. > > This treatment of dateTime values appears to violate the document, as > different dateTime values that compare equal according to the document > are turned into dateTime values that do not compare equal. The WG > would > appreciate guidance on how to do this processing in a compliant > manner. I don't really see how this violates [1] any more than it violates the OWL spec -- tools may change time values in an ontology in a way that could be interpreted as being in violation of [1], but from an OWL point of view we *only* compare values with a timezone in a way that is compliant with [1]. > > There are other potential solutions to reasoning with such dateTime > values (such as treating them as true intervals). However, these > solutions also appear to violate the document. I'm not sure if we need this either (for the same reason) -- what are we suggesting/asking? > > > We also do not find a justification for having the range of > timezone be > -840 to +840. The range of timezones currently in use ranges from > UTC-12 to UTC+14 (http://en.wikipedia.org/wiki/List_of_time_zones). > [This last is also an extrapolation from some evidence at the F2F.] >
Received on Monday, 4 August 2008 16:34:22 UTC