Re: draft of LC comment to XML Schema WG

Fine for me.

Ian


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