A Last Call comment about the seamtnics of xsd:dateTimeStamp in OWL 2 (caused by the yesterday's decision about numerics)

Hello,

At the yesterday's teleconf, we have decided to follow strictly XML Schema in
the design of numeric and binary data datatypes. We are now left with only one
datatype that does not comply with XML Schema, and that is xsd:dateTime(Stamp).
I believe that, for consistency, we should change the definition of that
datatype as well. Below are answers to some questions I expect people will ask.

Q. Why did I cause the stir with changing XML Schema datatypes in the first
place?
A. Initially, we were working off of XML Schema 1.0, which was not sufficiently
precise for our purpose. Therefore, I felt we needed to fix the definitions so
that they can be implemented in OWL 2. In the meanwhile, the developments in the
XML Schema 1.1 specification have rendered many of my initial concerns moot.


Q. Why bother?
A. I believe that we should have a consistent set of design principles across
the board. Following different guidelines for different datatypes makes us look
schizophrenic :-), and is just likely to raise questions with the readers.


Q. Our behaviour was sanctioned by the XML Schema WG, so why bother?
A. The same was true for the numerics: the XML Schema WG explicitly said that
they don't see a problem with us using equality as identity. Despite their
approval, we changed the numeric datatypes to follow XML Schema; well then, I
believe we should apply the same principles across the board.


Q. What will change technically?
A. Consider the following ontology:

(1) FunctionalDataProperty( a:P )
(2) DataPropertyAssertion( a:I a:P "12/03/2009, 2am CET"^^xsd:dateTime)
(3) DataPropertyAssertion( a:I a:P "12/03/2009, 1am GMT"^^xsd:dateTime)

Although the dates "12/03/2009, 2am CET" and "12/03/2009, 1am GMT" have a
different time zone, they are currently interpreted as the identical point on
the time line. Hence, the individual a:I has exactly one value of the property
a:P, so the axiom (1) is not violated.

In XML Schema, however, "12/03/2009, 2am CET" and "12/03/2009, 1am GMT" are
mapped to *distinct* objects. Hence, although the two objects represent the same
time instant, there are two values of a:P for a:I, so the ontology would be
inconsistent under the XML Schema semantics.

Note that this is *exactly* the same problem as the one we have with xsd:decimal
and xsd:double; hence, I consider it really strange to use one solution for
numerics but a completely different one for dates.


Q. What are other, more general benefits to the spec?
A. I can see several benefits:

- The spec gets simpler. We can point to XML Schema for all definitions, and I
would just add a couple of examples that highlight various tricky consequences
of these definitions.

- We can support xsd:dateTime, and not just xsd:dateTimeStamp. (That is, we can
support dates without a time zone.) We cannot do this now because we need the
time zone to map the date-time literals onto the time line. XML Schema, however,
provides a different time line for each time zone, and one more time line
without the time zone. This makes xsd:dateTime perfectly supportable under the
XML Semantics.

- Nobody (such as RIF) can scorn us for going our way: we can always point to
XML Schema and say "Here is the holy bible!"


Regards,

	Boris

Received on Thursday, 12 March 2009 12:08:43 UTC