Re: An approach to xsd:dateTime

Hi,

the 'easy' support for time that I was advocating yesterday seems to  
fit in nicely with this:

- absence of a time zone (so I guess we would only support a  
*restriction* of xsd:dateTime, but this should be ok)
- the value space is continuous (since seconds are decimals between 0  
and 60, according to my reading of Mike's [1]) and therefor, from an  
algorithms perspective, isomorphic to owl:number and thus it shouldn't  
be too much of a burden on the implementors.

Cheers, Uli

On 24 Jul 2008, at 11:56, Boris Motik wrote:

>
> Hello,
>
> Having only one time line (without the time zone) is rather usual in  
> programming languages. For example, this is how java.util.Date
> works: it is internally implemented to store the number of  
> milliseconds elapsed from January 1, 1970, 00:00:00 GMT. This value is
> always in GMT.
>
> When you want to put this value onto the Gregorian calendar, then  
> you need to specify a time zone, and you get back an the 8-tuple
> (day, month, year, hour, minute, second, millisecond, time zone).  
> You are also free to use calendars other than the Gregorian.
>
> Windows Win32 API works in a similar way and, if my memory serves me  
> right, UNIX has something similar as well.
>
> Form an implementor's perspective, such a design is beneficial  
> because reasoning with dates is really easy: it is the same as with
> owl:number. The only complicated machinery is in reading the  
> constants and converting them into the number of milliseconds.
>
> Regards,
>
> 	Boris
>
>> -----Original Message-----
>> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
>> Sent: 24 July 2008 06:09
>> To: Boris Motik
>> Cc: 'Michael Smith'; public-owl-wg@w3.org
>> Subject: 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 11:26:47 UTC