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

Hello,

> -----Original Message-----
> From: Evan Wallace [mailto:ewallace@cme.nist.gov]
> Sent: 31 March 2009 16:43
> To: Boris Motik
> Cc: 'W3C OWL Working Group'
> Subject: 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.
> 

Thanks for pointing these two errors out. I've fixed both; for the second one,
instead of time zones, I now talk about time zone offsets. (In the example, I
still use CET and EST -- this, however, is used informally. Let me know if you
think this should be changed.)

> ***
> 
> 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.
> 

I agree that implementing comparisons with time zone offsets might not be as
easy (as I have thought initially). Nevertheless, I don't think that determining
consistency is impossible. What you need to implement is basically a check
whether a particular date-time value (with a particular time zone offset) is in
a particular range. If the date-time value is not comparable to, say, the lower
boundary of the range, then clearly the date-time value is not in the range.

Another way of thinking about is as follows: given a lower and an upper boundary
lb and up, you need to determine the set of date-time instants between them.
This set is defined like this:

{ di | lb < di and di < ub }

Thus, for di to be between lb and up, it must be comparable both to lb and up.
(You should think here about di as a tuple consisting of seven values as
specified in [1].) As long as the comparison criterion is clear, you should be
able to implement this. If nothing else, you can break up this set into n
disjoint subsets each with a consistent time zone offset. Here, n is large, but
finite (it is the number of different time zone offsets, which is finite in the
XSD spec); hence, this should be doable.

Now I do agree that this may be a bit more complicated than what one might
desire. Nevertheless, I see the following benefits of going with XSD:

- We'll be compatible with XSD and nobody can reproach us for that.

- The existing ontologies out there use xsd:dateTime, which increases the
usefulness of OWL 2.

Regards,

	Boris


> > 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 16:14:41 UTC