- From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
- Date: Wed, 30 Jul 2008 13:14:18 +0100
- To: Jie Bao <baojie@cs.rpi.edu>
- Cc: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, bparsia@cs.man.ac.uk, public-owl-wg@w3.org
Jie, Any application can take recovery action, including those that produce OWL (e.g., a data mining tool), those that consume it (e.g., a reasoner), and those that do both (e.g., an editor). I expect that reasonable applications will have settings that allow users to control their behaviour. What the spec will say is that an application that consumes OWL *may* choose to perform some recovery action in case the ontology includes values with no time zone, and in this case it *should* issue a warning. Exactly what recovery action is taken is up to the application. Applications that produce OWL can do something similar, although the OWL standard has less to say about that (provided what they produce is valid OWL, they can produce it in any way they please). Annotations could be used to indicate the provenance of such defaults, but this is again not something that can or should be legislated for in the spec. Ian On 29 Jul 2008, at 15:34, Jie Bao wrote: > Ian > > I support the idea. There is still a point I'm not quite clear. When > we say "tool", does it mean an ontology editor or reasoner? If it is > an editor, it may mean in the syntax of the language timezone is > always required and an editor will require a missing one. If it is a > reasoner, it may mean that we still allow missing timezone to be > legal, but a reasoner will try to give it an interpretation (e.g., > adding a timezone or interpreting it as an interval depending on > user's intruction). > > Jie > > On Mon, Jul 28, 2008 at 10:17 PM, Ian Horrocks > <ian.horrocks@comlab.ox.ac.uk> wrote: >> Everyone seems to agree that dealing with literals with missing >> timezones is >> a problem because we don't know how to map them onto the timeline. >> Everyone >> also seems to agree that there is no one "recovery" strategy that is >> appropriate in all cases -- default time zones and intervals both >> have >> serious problems in some contexts. Therefore, we can't *specify* the >> recovery strategy because then we will be *forcing* compliant >> tools to do >> the wrong thing in some situations. The only remaining choice is >> whether we >> make it mandatory or optional to take *some* recovery action. It >> would seem >> strange to me to *demand* that tools perform some recovery action >> without >> specifying what it is. By a process of elimination, this does seem >> to lead >> us back to the formulation mentioned by Peter below, i.e., tools >> *may* try >> to recover. We can argue as to whether they *should* issue a >> warning, but >> this is normally the case when some recovery action is taken. >> >> Ian >> >> >> On 28 Jul 2008, at 19:56, Peter F. Patel-Schneider wrote: >> >>> >>> From: "Jie Bao" <baojie@cs.rpi.edu> >>> Subject: Re: An approach to xsd:dateTime >>> Date: Mon, 28 Jul 2008 14:45:09 -0400 >>> >>>> >>>> On Mon, Jul 28, 2008 at 2:17 PM, Bijan Parsia >>>> <bparsia@cs.man.ac.uk> >>>> wrote: >>>>> >>>>> On 28 Jul 2008, at 19:02, Jie Bao wrote: >>>>>> >>>>>> To explain a bit more for my objection to the proposal at the >>>>>> F2F3: >>>>>> >>>>>> "PROPOSAL: datetime literals with missing timezones are not in >>>>>> the >>>>>> syntax; tools MAY insert a timezone, but SHOULD produce a >>>>>> warning if >>>>>> they do so" >>>>>> >>>>>> The part I object is that missing timezone should be >>>>>> disallowed from >>>>>> the syntax. In many cases, a time zone is a default context, >>>>>> and as >>>>>> default contexts typically behave, it may be omitted from a >>>>>> description from this context. Tools may or may not be able to >>>>>> rediscover a missing zone. >>>>> >>>>> Yes. That's part of the point. We can't guess reasoanble ones. >>>>> >>>>>> The burden should not be on users to always >>>>>> provide such information. >>>>> >>>>> Who else? >>>> >>>> Tools may help in two ways: if such information can be >>>> rediscovered, >>>> then add it. If there is no way to find it precisely, then give >>>> it a >>>> *reasonable* interpretation. >>> >>> This seems to me to be precisely the proposal that was voted on just >>> before lunch. Tools MAY recover the information, if there is any >>> doubt >>> they provide a warning, but MAY also put in a reasonable answer, in >>> which case they SHOULD provide a warning. >>> >>> peter >>> >> >>
Received on Wednesday, 30 July 2008 12:15:27 UTC