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

Re: An approach to xsd:dateTime

From: Evan Wallace <ewallace@cme.nist.gov>
Date: Mon, 28 Jul 2008 11:25:51 -0400
Message-ID: <488DE4FF.8080600@cme.nist.gov>
To: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
CC: Bijan Parsia <bparsia@cs.man.ac.uk>, "Deborah L. McGuinness" <dlm@ksl.stanford.edu>, public-owl-wg Group WG <public-owl-wg@w3.org>

Ian Horrocks wrote:
> 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).

I would prefer that we not silently convert Local Time of Day to UTC of 
Day.  Complain to the user if you encounter it.

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

Sounds good.

>> - 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 Monday, 28 July 2008 15:26:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:05 UTC