Re: required timezone xsd dateTime datatype (ISSUE-138)

> Although this is certainly good, it does not solve all of the problems regard
> ing the naming of owl:dateTime. In particular, the
> identity of owl:dateTime values is different from the identity of xsd:dateTim
> e values. Consider the following two dates that
> represent the same time instant but have different time zones:
> 
> (1) 2008-10-01T08:00:00+01:00
> (2) 2008-10-01T07:00:00+00:00
> 
> In owl:dateTime, these two instants are identical (this was decided at the la
> st F2F), which is not the case in the XML Schema
> Datatypes 1.1 version of xsd:dateTime (according to http://www.w3.org/TR/xmls
> chema11-2/#dateTime).
> 
> This has important consequences on the semantics of OWL 2. The following onto
> logy is consistent: it uses owl:dateTime so the two
> instants are identical, and the functionality restriction is not violated.
> 
> (2) FunctionalProperty( a:time )
> (3) PropertyAssertion( a:time a:i "2008-10-01T08:00:00+01:00"^^owl:dateTime )
> (4) PropertyAssertion( a:time a:i "2008-10-01T07:00:00+00:00"^^owl:dateTime )
> 
> In contrast, the following ontology is inconsistent: it uses xsd:dateTime so 
> the two instants are distinct, which causes a violation
> of the functionality restriction: 
> 
> (5) FunctionalProperty( a:time )
> (6) PropertyAssertion( a:time a:i "2008-10-01T08:00:00+01:00"^^xsd:dateTime )
> (7) PropertyAssertion( a:time a:i "2008-10-01T07:00:00+00:00"^^xsd:dateTime )
> 
> Essentially, xsd:dateTime has a separate time line for each time zone. Becaus
> e of that, I believe we should not call our datatype
> xsd:dateTime even if the XML Schema WG introduces the change Peter mentioned.
> 
> 
> In my opinion, if we were to use xsd:dateTime, then we should revise the deci
> sion from the last F2F and define the datatype such
> that (1) and (2) are different instants. If we were to do that, I don't see t
> hen why we should focus only on dates with a time zone:
> the XML Schema 1.1 specification provides a clear model for timestamps withou
> t time zones and we could just use it.
> 
> Regards,
> 
> 	Boris

This design seems to me to be more of the same thinking as we saw in
float and decimal being disjoint ("the value spaces of all primitive
datatypes are disjoint (they do not share any values)").  It's a bizarre
design from OWL's (formal logic) point of view, but makes perfect sense
from the point of view of most popular programming languages (where the
integer 0 might compare equal to the float 0.0, but it's still a
different thing internally).  I wonder if we should be approaching this
question with them in a more explicit manner.....    

     -- Sandro

Received on Tuesday, 30 September 2008 15:35:48 UTC