- From: Changhai Ke <cke@ilog.fr>
- Date: Fri, 23 Jan 2009 13:09:16 +0100
- To: "RIF WG" <public-rif-wg@w3.org>
- Message-ID: <3E5E1A634BBD5C4A94C4D4A6DE0852E702106644@parmbx02.ilog.biz>
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 compared. 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 closed. Changhai
Received on Friday, 23 January 2009 12:10:03 UTC