W3C home > Mailing lists > Public > public-rif-wg@w3.org > February 2009

RE: Action 695 argument

From: Changhai Ke <cke@ilog.fr>
Date: Tue, 3 Feb 2009 16:14:31 +0100
Message-ID: <3E5E1A634BBD5C4A94C4D4A6DE0852E7021A1C7A@parmbx02.ilog.biz>
To: "Dave Reynolds" <der@hplb.hpl.hp.com>
Cc: "RIF WG" <public-rif-wg@w3.org>

Some comments below.


-----Original Message-----
From: Dave Reynolds [mailto:der@hplb.hpl.hp.com] 
Sent: Tuesday, February 03, 2009 3:10 PM
To: Changhai Ke
Subject: Re: Action 695 argument

Changhai Ke wrote:
> Hello all,
> Per my action http://www.w3.org/2005/rules/wg/track/actions/695,
> read below my answer.
> During the F2F 12, it was proposed to replace xsd:dateTime 
> (http://www.w3.org/TR/xmlschema-2/#dateTime) by owl:dateTime in RIF
> because the former does not deal well with timezone (more precisely 
> timezone is optional). I was against this replacement and my argument
> the following. (Acknowledgement: I'm not an expert of date 
> representation. Please correct if something is wrong).
> 1. Xsd:dateTime allows representing dates with or without a timezone. 
> The timezone in xsd:dateTime is necessarily UTC. Initially, if you
> a date without a timezone, you can easily represent it in
> If you have a date with a timezone, you can (must) convert it into UTC

> and store it in xsd:dateTime. So in terms of information preservation,

> this type does not have any weakness.

The issue is that some applications, such as the examples given by Gary,

treat a dateTime without a timezone as if it were a dateTime within the 
timezone of the current Locale. This different from xsd:dateTime. If you

converted such a dateTime-in-local-timezone to either an 
xsd:dateTime-in-UTC or xsd:dateTime-without-timezone then you are 
changing the semantics.

[Changhai] This is also my examples, see below. And when a date has no
timezone, the timezone is just undefined, we don't have to assume that
the timezone will be the local one. We just don't care, the running
engine will define the time zone, which will become the timezone for the
dateTime. As an interchange, we only care to restore on the other the
same date, always without a timezone.

> The type also supports order relations and date arithmetic. It is 
> defined in the specification how dates with and without timezones can
> compared.


> 2. In general, it is simpler and straighter to keep XML types without 
> replacement. With the widespread of the web services, there are
> numerous utilities to manipulate xsd:dateTime. Moreover, W3C Schema 
> group may fix this issue, and we'll benefit from it. Owl:dateTime
> is also at risk (see: http://www.w3.org/TR/owl2-syntax/, search for 
> "**Feature At Risk #3: /owl:dateTime/ name").**

First, adopting a fixed xsd:dateTime-with-required-timezone would indeed

be preferable. The issue is one of timescale, do you propose postponing 
adoption of dateTime in RIF until XML Schema has been changed and 
reversing our decision to use XML Schema 1.0?

[Changhai] Not sure what you mean. For my part, I meant that we should
leave xsd:dateTime in RIF and not try to fix it. W3C will fix this (will
or will not, whatever), and OWL says that owl:dateTime is not
guaranteed. Double reason to wait for fixes from W3C and not to
anticipate unnecessarily.

Second, if you are happy to adopt the fixed 
xsd:dateTime-with-required-timezone and if we agree that that is 
precisely what owl:dateTime is then what is the problem with adopting 

[Changhai] My point is precisely that dateTime without timezone have its
application. I thought that I expressed my point clearly.

> 3. There are also use cases where the timezone information is missing
> is irrelevant. For example, when you want to write a birth date (eg: 
> "12/20/1970"), you write it without a timezone. I don't know how this 
> can be represented in owl:dateTime, but it is straight to represent it

> in xsd:dateTime.

Actually that is an xsd:date not an xsd:dateTime, they are different 
primitive types. At the moment RIF is not proposing to adopt xsd:date, 
xsd:time, xsd:gYear etc.

[Changhai] I don't understand your point. How do you represent
"12/20/1970" without a timezone? If xsd:date is not in RIF, then I
should represent it with xsd:dateTime, right? Precisely if I use
owl:dateTime, I will be thinking hard what will be the timezone, while
initially there is no timezone concept. (A person born somewhere can
change timezone and have birthday locally).

> If I write this production rule: "For any restaurant booking in 12/31 
> between 5:00pm and 9:00pm, give a 10% discount". My rule does not have

> any timezone, it is intrinsic and can be applied to all the locations.

> Of course, the executing environment needs to be well set (for example

> there will be a rule engine for the east coast timezone, while another

> one will be for the central Europe), but the rule content itself does 
> not need to refer to any timezone.

That is precisely the case I outlined above. You cannot use xsd:dateTime

for that because you are assuming that a non-timelined xsd:dateTime 
corresponds to the current Locale timezone which it doesn't. If your 
application assumes this convention, but sends the RIF rules to a 
different application which does not make this assumption you will get 
incompatible results.

[Changhai] We have a misunderstanding here. A date may not have a
timezone, and we don't have to care about it, at least from a production
rule point of view. We make sure that the same date is restored on the
other side, this is the role of the interchange. After this it will
happen what will happen.

In particular a correct implementation will only fire that rule if the 
current time (which would be in UTC) is 14 hours after 5:00pm and 14 
hours before 9:00pm, i.e. never.

> I hope this is clearer. Maybe someone can explain why it is important
> replace xsd:dateTime by owl:dateTime, or we consider this topic as

I hope the above has clarified the problems.

As I see it we have several options:

(1) Remove the ambiguity by enforcing all dateTimes to have timezones. 
This means either adopting owl:dateTime or waiting until there is an XML

Schema change.

(2) Adopt xsd:dateTime but reduce the ambiguity, for example by adding 
an explicit specification that xsd:dateTime values without a timezone 
should be treated as in the timezone of the Locale of the running rule 

(3) Adopt xsd:dateTime, leave it ambiguous, and put an explicit warning 
in the text that the sort of assumption made in your restaurant rule is 
not safe and that different RIF implementations may act in different

My preference is (1) on grounds of simplicity, lack of ambiguity and OWL

compatibility. However, I don't think I'd formally object to any 
solution, I just want us to be clear what we are choosing.

Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Tuesday, 3 February 2009 15:18:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:53 UTC