Re: EIIF draft needs unified person, rigorous when/where, criteria towards common ontology, use of phases

Pardon the detail, but it would be really great if the standard was good enough to pass not just W3 but IETF muster.
Anyone familiar with IETF RFCs knows they are full of such identification of side cases and loopholes and how these are to be closed.  the price of ijnteroperability... and anyone who's been in on RFC creation knows IETFers are picky.

>> "Some local" is nowhere near acceptable for the purposes we are talking about.  Especially not as relief efforts
>>begin to span global communications networks.   With the "Z" suffix that specifies that the time is in UTC it's fine for
>>points in time - only.  But ISO 8601  has nothing to say about how to specify spans of time / intervals, floating 
>>durations,etc.

>
>ISO8601 is perfectly capable of reflecting time zones by using +1300 to represent NZDT for example.

Obviously.  But "is perfectly capable of" is not the same as "requires all compliant implementations to".

The difference is very significant.  What I'm saying, and what OWL-Time and W3 itself is saying, is that EIIF should require all compliant implementations to behave in a certain way when it encounters any date/time without a time zone and should encourage modules that must actually do temporal calculations to use a robust already-accepted approach and not apply ad hoc algorithms to possibly-ambiguous data.  Certainly not if medical supplies will be routed by these.

>I think it is important to recognise that ISO8601 is primarily an atomic standard, in that it generally defines an atomic
>datetime unit (as you rightly point out). It is then up to standards that build upon ISO8601 to implement more complex 
>functionality such as you suggest e.g. ranges, intervals etc.

W3 has already specified a terminology for this in OWL-Time.  Whether using OWL-Time or even using XML or RDF or any other mechanism, the intervals and durations should be called exactly what they are called in OWL-Time because W3 has already approved this semantics.

In practice programmers will probably use APIs but again these should name the objects exactly as OWL-Time does and adopt the same semantics.  At least where time math and scheduling are actually being done by the module.  It would be a serious mistake to trust programmers to invent robust time models and do time math in their own modules.  This literally never works - the programmer would have to have studied temporal algebra, and very few have done so.  If W3 has names for time concepts, and they do, the only APIs that should be used for these should reflect those names.

>>ISO 8601 apparently allows one to express the non-existent concept of a date/time without being fixed in any one 
>>time zone.  This is a plain semantic error, to allow the expression of something that seems to exist but in fact is
>>ambiguous.
>
>I would suggest this is a programmers error - in that users don't generally enter datetimes in ISO8601 format, rather 
>the programme saves it as such. Therefore, it is a design error on behalf of the programmer that they store it as local 
>time rather than fully specifying the UTC offset. Plain lazy development. Of course, closing that loophole in the
>standard may improve lazy development practices ;)

I would say the standard is at fault because it does not specifically require the programmers to discover the timezone or assume one or even to say it's ambiguous explicitly.  The programmer is within his or her rights not to disambiguate the timezone because the standard actually allows this with the unwise/ambiguous "some local" qualifier.  If I can save this non-existent non-data as "some local" and stay within the standard, what's assumed is that the writer and reader of it will be either in, or referring to, the same time zone.  Standards aren't supposed to load programmers with requirements to know about and work around plain semantic errors, they're supposed to discover and pre-empt this kind of error.  

A designer or architect would be in error for selecting ISO 8601 without explicitly specifying how to close this possibility but I wouldn't blame the programmer for errors in supervision.

We agree however that the loophole must be closed.  We can encourage that best by pointing it out, resolving it in a responsible fashion that won't lead to possibly-fatal data integrity problems in the field, and reverting to the robust W3-approved OWL-Time approach to do anything sensitive.  Because the OWL-Time authors actually understood this.

>Cheers Gav

Received on Wednesday, 26 November 2008 01:04:30 UTC