Re: An approach to xsd:dateTime

I can live with applications - any of them - editors, reasoners, 
application specific programs, etc - that augment their representation 
to increase the granularity.
two resistance points that i expect are:
a - I am not sure though if there will be a way to represent if one was 
putting in UTC +0 if that is a default that the application put in or if 
that was actually the time zone that is explicitly known.
b - in some applications that know only coarse granularity information 
and have a very large amount of data, adding what is essentially default 
information that may not be used could make a difference in space 
for example, some applications like astronomy applications, generate 
very large amounts of data that is time stamped and as long as 
everything is in the same relative time frame, they would prefer not to 
add the extra encoding requirement.

Bijan Parsia wrote:
> 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?
> I mean user application. Editors and reasoners and acquisition tools 
> can do what makes sense.
> So, for example, I would expect Protege4 to flag these as problems and 
> offer different ways of repairing or ignoring them. But a text mining 
> application that generated OWL might choose to always resolve to UTC.
>> 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.
> Or to add an interval explicitly. (I think intervals can be a sensible 
> choice, just not a good default (at this time)).
>> 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).
> Indeed, flags could control what the reasoner did.
> Cheers,
> Bijan.

Received on Tuesday, 29 July 2008 15:44:37 UTC