W3C home > Mailing lists > Public > public-owl-wg@w3.org > July 2008

draft of LC comment to XML Schema WG

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Tue, 29 Jul 2008 12:15:18 -0400 (EDT)
Message-Id: <20080729.121518.01620678.pfps@research.bell-labs.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 July 2008 16:16:03 GMT