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

Re: draft of LC comment to XML Schema WG

From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
Date: Thu, 7 Aug 2008 14:16:14 +0100
Message-Id: <675EFA9B-92CF-426C-BC88-9F31866A63CA@comlab.ox.ac.uk>
Cc: public-owl-wg@w3.org
To: Peter F. Patel-Schneider <pfps@research.bell-labs.com>

Fine for me.


On 6 Aug 2008, at 18:40, Peter F. Patel-Schneider wrote:

> 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 Thursday, 7 August 2008 13:16:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:41:50 UTC