Re: I've implemented the changes to xsd:dateTimeStamp

Boris Motik wrote:
> To understand how xsd:dateTime works, you need to consider the issues of
> identity and the issue of ordering separately.
>
> 1. Identity
>
> Two date-times are identical only if their time zones are identical (and,
> consequently, if day, month, ..., hour, minute, ... are identical as well). This
> basically affects only number restrictions, and it does so in a way that I've
> outlined in the document.
>
>   

For folks who haven't read xsd 1.1:
xsd 1.1 [1] talks of identity, equality, and ordering. xsd 1 normalized 
dateTime values
with timezone offsets to UTC and placed them all on a single time line. 
Values
identifying the same instant on the timeline were considered both 
identical and
equal. In 1.1, the timezone offset value distinguishes identities of 
values for
the same instant on the UTC timeline. They are still considered equal, 
but not identical.

The first example in section 4.7 [2] of the Syntax document illustrates 
that this notion of
value identity will be used for testing cardinality constraints. Thus 
functional properties
will be considered violated if two values are found for the same 
individual denoting the
same instant but using different timezone offsets to do so. Since the 
whole point of the
dateTime format with offset is that it can be very simply normalized to 
UTC, I consider
these to be different lexical forms for the same value. Thus, from a 
user point of view, I
have a problem with this new interpretation. I prefer how we previously 
handled it.

BTW - I found two editorial problems with section 4.7:

(1) - The first sentence reads:
The OWL 2 datatype map provides the following XML Schema datatypes [XML 
Schema Datatypes] for the representation of binary data:
but should read:
The OWL 2 datatype map provides the following XML Schema datatype [XML 
Schema Datatypes] for the representation of time instants:

(2) - the timezoneFrag in xsd:dateTime isn't used to indicate the timezone
but to capture a local time offset from UTC. The name of the property
for this in the Seven-property Model has been changed to timezoneOffset
to make this clear. While one can compute a timezone offset from a 
timezone,
one can't necessarily determine a single timezone from a timezone 
offset. Thus
the -05:00 in "1956-06-25T04:00:00-05:00"^^xsd:dateTimeStamp corresponds
to two different timezones (EST and CDT). Since XSD 1.1 has cleaned up
its terminology in this area, I suggest that the example describe time
instants with different timezoneOffsets instead of time zones.

***

Back on the subject of OWL2 supporting dateTimes generally (i.e. 
including those
without timezone offsets):
> 2. Comparison
>
> Comparison becomes important only in the definition of facets, and there time
> zones are not important. That is, a data range constructed by a facet of the
> form "all instants after 1st of May 2009, at 10am GMT (inclusive)" will contain
> the time instant " 1st of May 2009, at 11am CET". This is as expected: if you
> use facets to define data ranges, time zone difference does not matter.
>   

The values in the data range are relative to the facet value. Since this 
relation is dependent
on the ordering and ordering requires comparability and some values 
without timezoneOffsets
will be incomparable, reasoners will have to determine comparable values 
(or at least determine
which comparable values are inside and outside the range). xsd explains 
how to do this:

> *Note:* Since the order of a dateTime 
> <http://www.w3.org/TR/xmlschema11-2/#dateTime> value having a 
> /·timezoneOffset·/ 
> <http://www.w3.org/TR/xmlschema11-2/#vp-dt-timezone> relative to 
> another value whose /·timezoneOffset·/ 
> <http://www.w3.org/TR/xmlschema11-2/#vp-dt-timezone> is */absent/* is 
> determined by imputing time zone offsets of both +14:00 and −14:00 to 
> the value with no time zone offset, many such combinations will be 
> ·incomparable· <http://www.w3.org/TR/xmlschema11-2/#dt-incomparable> 
> because the two imputed time zone offsets yield different orders.

While that shouldn't be hard to implement, it certainly does matter. 
Also, what does a reasoner do
with an ABox with values for datarange that *are* incomparable to the 
facet value? Given the xsd
definition for these things, mixing xsd:dateTimeStamps with 
xsd:dateTimes without timezoneOffsets
is fine, but determining consistency in the presence of these 
incomparable values is impossible.

> That's it! I really don't see any problem with it, from implementation or the
> user point of view.
>
> Regards,
>
>  Boris
I clearly disagree.

-Evan

[1] http://www.w3.org/TR/xmlschema11-2/#identity
[2] http://www.w3.org/2007/OWL/wiki/Syntax#Time_Instants

Received on Tuesday, 31 March 2009 15:44:13 UTC