- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Thu, 19 Jun 2008 12:26:06 -0400
- To: Evan Wallace <ewallace@cme.nist.gov>
- Cc: "'OWL Working Group WG'" <public-owl-wg@w3.org>
I was looking into xsd date types, as (all things being equal) I would think we would want to support them. One of the things that surprised me was that dates are not a total order. http://www.w3.org/TR/xmlschema-2/#dateTime-order Basically, if one of the dates to be compared has a time zone and the other does not, and the dates without considering the timezone are less than 14 hours apart, then the dates are incomparable wrt order. I'm not sure how much this complicates implementations, but note that it would mean that the union of date > x and complementof(date >x) is not all dates. If this poses a problem, and we think date ranges are important, we may need to specialize the xsd dates (and related date types, such as gYearMonth) into those which require a timezone, and those that require there not be one, and then only offer facets on these subtypes. The xsd spec alludes to such a strategy http://www.w3.org/TR/xmlschema-2/#totally-ordered-instants though still says that the min and max facets are available for dateTime, despite the incomparables. I'm also not sure what complications leap year calculations bring in to the picture. Following Boris' example, suppose you have gMonthDay is Feb 29 and x < gYear < y, then this is only satisfiable for some values of x and y and you need to do the leap year calculation to be able to tell. In this case timezone doesn't matter, but what about Feb 28 6PM 20xx < dateTime < March 1 6AM 20yy. Now, depending on whether Feb 29, x, and y have timezone specified, and the specific years, you might have a situation where you just can't say if it is satisfiable, as the facet values can't be compared. What strategy are you using for handling such oddities in your date and time vocabulary? How important is the ability to make date range data ranges? -Alan On Jun 19, 2008, at 11:47 AM, Evan Wallace wrote: > The OWL 1 rendering of OWL Time makes use of xsd types for a number > of things > including identifying a year and month for a time interval > associated with a > DateTimeDescription. It also carefully uses integer for datatype > properties using > ordinal numbers to identify say a day of the week or a week in a > WeekYear calendar, > while still using xsd decimal for seconds in a date-time. While it > would probably be > a good thing to change OWL Time, in any case, to make use of new > constructs in OWL 2, > we really need to understand what datatypes to use for these things > if support for integer > and xsd date types is discouraged. > > -Evan > > Evan K. Wallace > Manufacturing Systems Integration Division > NIST > >
Received on Thursday, 19 June 2008 16:26:57 UTC