From OWL
Revision as of 16:10, 4 September 2008 by IanHorrocks (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Draft of LC comment to XML Schema datatypes

The W3C OWL WG is planning on using datatypes from XML Schema 1.1 Datatypes, currently in last call [2]. The WG views most of the changes made for XML Schema 1.1 Datatypes to be beneficial, and thus supports the transition of the last call specification towards recommendation, which a few exceptions, detailed below.

1/ Time instants

1.1/ Derived type for time instants with a required timezone

The W3C OWL WG is determining how to use XML Schema dateTime values from the last call working draft [2] in OWL ontologies. The main problem the WG faces concerns dealing with dateTime values that do not have a timezone. The LC draft puts these values on a single separate totally-ordered timeline that is only partially ordered with respect to the absolute timeline.

For the purposes of reasoning in OWL, it is much easier to deal with dateTime values where the timezone is present. Such values can be converted to single time points (using timeOnTimeline) and a complete order determined from the time points.

The WG requests that a derived XML Schema datatype for dateTime with a required timezone be added to the XML Schema datatypes spec.

1.2/ Handling "time instants" without a timezone

There are already OWL ontologies that contain dateTime values where the timezone is absent. Such dateTime values may come from different documents, and that really have a different notion of what their local (unspecified) time is. The LC draft [2], however, makes these values all equal, as they are identical.

The OWL WG is proceeding along a path to require timezones in dateTime values, i.e., dateTime values without a timezone will be syntactically illegal. However, tools may attempt to recover, for example by using the local time zone for the data source, but if they do so, they SHOULD produce a warning. Since such recovery may produce incorrect results, it should be done with caution, and data providers would be strongly encouraged to provide timezone information for all dateTime values.

Adding in missing timezone values appears to violate the equality of dateTime values from the LC draft, as dateTime values without timezone information that compare equal according to the LC draft can be turned into dateTime values that do not compare equal.

The WG requests that dateTime values missing a timezone that are otherwise equal do not compare as equal. The WG requests that dateTime values missing a timezone be instead *independently* treated as if they had one of the possible timezone values.

1.3/ Value space for time instants

The WG will be using a value space for time instants that consists of a single timeline.

The WG believes that this is compatible with the treatment of time instants in the LC draft.

1.4/ Range of possible timezone values

The WG does not find a justification for having the range of timezone be -840 to +840. The range of timezones currently in use ranges from UTC-12 to UTC+14 (, i.e., -720 to +840.

The WG suggests that the range of timezones be limited to those actually in use to tighten comparisons between dateTime values with and without timezones.

2/ Partial implementation limits for infinite datatypes

2.1/ Incorrect treatment of decimal

The OWL WG also noticed what appears to be a problem with partial implementation limits for the infinite datatypes [1].

The LC draft says

 All minimally conforming processors must support decimal values
 whose absolute value is less than 10^16 (i.e., those expressible with
 sixteen total digits). 

but decimals can have fractional parts, so the non-parenthetical part appears to require infinite-precision decimals. Perhaps what was meant was to require support of only those decimal values that can be written using at most 16 decimal digits, i.e., to require support of 12.34567890123456 but not 12.3456789012345678901234567890123456789

The WG strongly suggests that this change be made to the LC draft. Otherwise the WG will not be requiring minimal conformance that is less stringent that the minimal conformance in the LC draft.

2.2/ Difficult to discern relationship to datatypes

The section of the draft related to partial implementation of infinite datatypes [1] does not mention dateTime. Only a careful examination of the entire LC draft shows that year and second in this section probably refer to the year and second that appear as parts of dateTime (and other datatypes).

The WG suggests as an editorial change that the relationship between year and second and the actual datatypes be made more clear in this section of the LC draft.

[1] [2]