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

Action 695 argument

From: Changhai Ke <cke@ilog.fr>
Date: Fri, 23 Jan 2009 13:09:16 +0100
Message-ID: <3E5E1A634BBD5C4A94C4D4A6DE0852E702106644@parmbx02.ilog.biz>
To: "RIF WG" <public-rif-wg@w3.org>
Hello all,


Per my action http://www.w3.org/2005/rules/wg/track/actions/695, please
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 DTB,
because the former does not deal well with timezone (more precisely
timezone is optional). I was against this replacement and my argument is
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 have
a date without a timezone, you can easily represent it in xsd:dateTime.
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 type also supports order relations and date arithmetic. It is
defined in the specification how dates with and without timezones can be


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


3. There are also use cases where the timezone information is missing or
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.


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.


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



Received on Friday, 23 January 2009 12:10:03 UTC

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