Re: An approach to xsd:dateTime

On Jul 23, 2008, at 6:14 PM, Boris Motik wrote:

>
> Hello,
>
> The problem seems a bit more complicated. What do you do with the  
> time zone if it is present on some constant?
This is well defined in http://www.w3.org/TR/xmlschema11-2/#vp-dt-timeOnTimeline

The issue is really what to do about constants without time zone, as  
these don't have a specific location on the time line.
Or they have a position on a different time line (depends on your  
point of view)

> Another way forward would be to make the value space of dateTime the  
> (continuous) time line at Greenwich. Each number on the time
> line would correspond to the number of seconds elapsed from some  
> fixed point, such as the beginning of AD or something similar. (I
> am deliberately not using UTC -- I'll explain shortly.) In this way,  
> you have a unique time point for every event, and that time
> point is not dependent on the time zone or on effects such as  
> daylight saving. Furthermore, the value space is isomorphic to
> owl:number, which makes reasoning simpler.

This is effectively TimeOnTimeline. owl:number is a reasonable value  
space because the value space is otherwise decimal, and owl:number is  
what we use for decimal.

> Time zone, daylight saving, and leap seconds would be relevant only  
> for dateTime constants. For example, you might have a constant
> "midnight on 1/1/2008 in London", and this constant would be mapped  
> to the same time point as the constant "1am on 1/1/2008 in
> Berlin". Thus, the time zone, leap seconds, and daylight saving  
> would be relevant only when you want to refer to actual time points.
>
> Now I deliberately didn't want to say that the value space of  
> dateTime should be UTC because UTC time consists of a day, month,
> year, hour, minute, and second. As such, it is not just one number,  
> but six numbers, which makes reasoning more complicated.
> Furthermore, a minute in UTC can contain leap seconds, which is yet  
> another complication for reasoning.

The leap seconds is a separate issue, I think. The main issue is that  
leap seconds are defined only historically. So no matter what you  
can't account for them completely. In any case, the latest version of  
the spec explicitly says that it doesn't handle leap seconds.
http://www.w3.org/TR/xmlschema11-2/#d-t-values

> I believe that such a design would work. The main problem, however,  
> is that we don't have (or at least I don't know of) a standard
> that we can point to and that we could reuse. Specifying something  
> like this from scratch might require a lot of work; furthermore,
> I don't believe that this is the core competence of our WG.

I don't think we are designing from scratch - the XML Schema provides  
us what is needed to map to owl:number.

The biggest decision is what to do about the TZ specified versus TZ  
not specified values. If  each (with/without)  were placed on separate  
timelines, then the only thing we would lose is the ability to use a  
facet value of one kind with the value space of the other, unless   
someone has an idea of how to do something reasonable with areas where  
the two are incomparable (when they are with 24 hours of each,  
ignoring time zone).

-Alan

>
> Regards,
>
> 	Boris
>
>> -----Original Message-----
>> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org 
>> ] On Behalf Of Michael Smith
>> Sent: 23 July 2008 17:33
>> To: public-owl-wg
>> Subject: Re: An approach to xsd:dateTime
>>
>>
>> On Wed, 2008-07-23 at 14:49 -0400, Michael Smith wrote:
>>> As I read the XML Schema 1.1 description of dateTime [1], the  
>>> primary
>>> problem it presents as a datatype is that timezone is optional.   
>>> If OWL
>>> were to require the timezone property, all values map to a single  
>>> point
>>> on a discrete number line (see [2]), making implementation  
>>> equivalent to
>>> implementation of xsd:integer.
>>
>> Tracker, this was in reference to ISSUE-126.
>> --
>> Mike Smith
>>
>> Clark & Parsia
>>
>
>
>

Received on Thursday, 24 July 2008 10:09:14 UTC