- From: Evan Wallace <ewallace@cme.nist.gov>
- Date: Mon, 28 Jul 2008 11:25:51 -0400
- 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