Re: An approach to xsd:dateTime

To explain a bit more for my objection to the proposal at the F2F3:

"PROPOSAL: datetime literals with missing timezones are not in the
syntax; tools MAY insert a timezone, but SHOULD produce a warning if
they do so"

The part I object is that missing timezone should be disallowed from
the syntax. In many cases, a time zone is a default context, and as
default contexts typically behave, it may be omitted from a
description from this context. Tools may or may not be able to
rediscover a missing zone. The burden should not be on users to always
provide such information.

My proposal is that treating missing timezone as partially specified
datetime value. For example, "July 28, 2008" may mean a datetime value
that is within a local time in the date of July 28, 2008 on any
timezone on the earth. Its interpretation could be an interval of all
such values in UTC, i.e., July 28, 2008 0:00:00 GMT-12 to July 28
23:59:59 GMT+12.

When we compare two datetime, if their interpretation does not
overlap, like "July 28, 2008" and "June 28, 2008", it is deterministic
to say which one is earlier. If there is an overlap, e.g. "July 28,
2008" and "July 29, 2008", we may not for sure which one is earlier. A
reasoner may provide a warning in this case.

I agree with Boris' proposal on time-on-timeline interpretation of
times. If we have intervals for integer values, we can effectively
transform datatime values into integer values, and intervals of time
into intervals of integers.

Other partially specified datetime value may be handled similarly as intervals.


On Mon, Jul 28, 2008 at 11:25 AM, Evan Wallace <> wrote:
> 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 18:03:21 UTC