Re: An approach to xsd:dateTime

On 26 Jul 2008, at 00:03, Evan Wallace wrote:

[snip]

I think we are converging on a reasonable proposal here. I only have  
a couple of comments/suggestions:

> Do we have one proposal to evaluate?  Boris made a suggestion but  
> there has been considerable discussion
> since.  So let me suggest some parameters of a small Date-Time  
> feature for OWL2:
>
> - the lexical space for OWL Date-Time values will be the subset of  
> the xsd:dateTime lexical space which
> includes the timezone component.

Seems to me that we could easily support non-timezoned constants by  
simply treating these as defaulting to a specific timezone,  
presumably UTC+zero. Defaulting to "local time" seems like a very bad  
idea as the semantics of an ontology would change depending on our  
idea of local -- or we would need an additional ontology property  
specifying "ontology location" or some such -- I prefer not to even  
think about it! It will be up to applications to specify a time zone  
where it is important (like the breakfast time examples).

>
> - time zone offsets will be used to normalize values to the  
> timezone associated with UTC and those values
> will then be mapped to a single timeline with a value space based  
> on the OWL2 equivalent of  xsd:decimal
> where integer values represent integral numbers of seconds.

I suggest using a clone of the relevant numeric value space rather  
than the actual numeric value space -- otherwise we could get strange  
and unintended equivalences between numbers and date-times. I also  
suggest using owl:number rather than xsd:decimal -- the difference  
shouldn't be detectable, but it will make implementation easier by  
allowing re-use of the owl-number implementation that all owl  
reasoners will already have.

>
> - the origin of this timeline will be stated in the OWL2  
> specification as corresponding to a particular date in
> the Gregorian calendar and a particular UTC time of day.  The  
> mapping of dateTime literals to values on this
> timeline does not take into account leap second adjustments  
> periodically made to UTC and thus will diverge
> from UTC by small amount for values further from its origin.

Sounds reasonable -- we just need to pick our origin. W.r.t. leap  
seconds, I'm not sure why the mapping should not take into account  
leap second adjustments -- is this to avoid subtle changes in meaning  
when such an adjustment is made (because the ontology may have been  
written without any knowledge of such events)? This substitutes one  
problem (divergence from UTC) for another (change in semantics) -- it  
isn't obvious to me which is the right way to go on this.

ian


>
> Evan
>
>
>

Received on Sunday, 27 July 2008 21:09:16 UTC