- From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
- Date: Mon, 4 Aug 2008 17:21:24 +0100
- To: Jie Bao <baojie@cs.rpi.edu>
- Cc: "Sandro Hawke" <sandro@w3.org>, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, public-owl-wg@w3.org
Jie, I would prefer not to add the text about "fuzzy" repair. This seems to me to be at the same time too detailed (we are not blessing any particular kind of repair, and so should say as little as possible about them) and too brief (the proposed repair mechanism isn't really understandable). Ian On 29 Jul 2008, at 17:53, Jie Bao wrote: > > On Tue, Jul 29, 2008 at 12:39 PM, Sandro Hawke <sandro@w3.org> wrote: >> >> >> ... >>> 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 document, however, makes these values >>> all >>> equal. >>> >>> Our proposed solution to handling such ontologies is to put off >>> the task >>> of determining "missing" timezones to tools, with roughly the >>> wording >>> that tools MAY accept dateTime values with an absent timezone by >>> determining what the "local" timezone is for the value and SHOULD >>> produce a warning if they do so; otherwise dateTime values with >>> missing >>> timezone are syntax errors. >> ... >> >> I find this unclear. My understand of what the WG is saying is >> this: >> >> It is a syntax error for an OWL 2 document to contain a dateTime >> value (literal) which is missing timezone information. >> >> Systems MAY attempt to recover from this error (such as by >> assuming the local time zone), but if they do so, they SHOULD at >> least notify the user. >> >> I would add: >> >> Such "recovery" will in many cases produce incorrect (unsound) >> results and should be done with caution, since OWL data may come >> from unexpected contexts. Data providers should be strongly >> encouraged to provide data with timezone information. >> >> -- Sandro >> > I would also suggest to mention the interval interpretation of time > without timezone as another possible way to recover (fuzzily). We > could add > > If the recover of a timezone is not possible or it likely to be > unsound, the tool may also adopt an interval-base interpretation of > datetime with missing timezone that includes all possible time values > that are compliant to the datetime value in question in any possible > timezones. A warning should be given in doing so. > > Jie >
Received on Monday, 4 August 2008 16:22:06 UTC