- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Tue, 29 Jul 2008 12:15:18 -0400 (EDT)
- To: public-owl-wg@w3.org
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 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, 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. 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. 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. 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 Tuesday, 29 July 2008 16:16:02 UTC