Re: draft of LC comment to XML Schema WG

Here is my revised LC comment.  I've also put it on a Wiki page
http://www.w3.org/2007/OWL/wiki/DateTime

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 LC document puts these values on a
single separate totally-ordered timeline that is only 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. 

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 LC document, however, makes these values all
equal, as they are identical.

Our proposed suggestion to handling such ontologies is to put off the
task of determining "missing" timezones to tools, with roughly the
wording that dateTime literals that are missing timezones are
syntactically illegal, but that tools MAY accept such dateTime values by
determining what the "local" timezone is for the value and SHOULD
produce a warning if they do so.

This treatment of dateTime values appears to violate the equality of
dateTime values from the LC document, as different dateTime values that
compare equal according to the LC 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 equality of dateTime values.


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).

Received on Wednesday, 6 August 2008 17:40:48 UTC