Re: An approach to xsd:dateTime

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 Tuesday, 29 July 2008 14:34:44 UTC