Ed, (01)
I support everything you said here (below). But - in the light
(or darkness...) of a long-running recent discussion on this
forum - are you carefully steering clear of the word "context" on
purpose? :-) (02)
Is this not a prime example of where contexts - and conversions
or translations or mappings (often lossy) between them - are used
by everybody with no problem? It's as in colloquially-familiar
and meaningful statements such as "The precise meaning of the
time statements is dependent on their context." (03)
Other classic aspects of context are communities' comfortable
commitments to them, the dependency - as in all the time examples
in this thread - of statements upon the proper but natural
awareness by the various parties concerned of the respective
contexts, and their easy accommodation to the frequent need for
contexts to shift as conversations or tasks or even transactions
unfold. (04)
Can we really do without some formal recognition and
representation of 'context', all in a context-dependent way, of
course? And surely, there is no need to eschew the word! (05)
Christopher (06)
----- Original Message -----
From: "Ed Barkmeyer" <edbark@xxxxxxxx>
To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Sent: Tuesday, January 22, 2008 7:02 PM
Subject: Re: [ontolog-forum] Time representation (07)
John Sowa wrote: (08)
>> There are so many hard problems, it's hard to say which are
>> harder.
>> But the idea of taking the least significant digit as the
>> criterion
>> for implicit granularity is fairly common for experimental
>> data
>> (unless some explicit margin of error is stated). (09)
With my NIST hat firmly on, I would say that in John's
parenthetical
addendum he hit on a critical issue. Most identifications of
"points in
time" are inaccurate, and the stated precision probably isn't the
intended accuracy. For example, is 21 January 2008 at midnight
really
accurate to the second, just because it was captured as:
"20080121T000000 +0500" (ISO 8601 form)? (010)
Certain carefully stated scientific measures of time, e.g.
astronomical
observations or standard time dissemination, are intended to be
accurate
and have a stated accuracy (margin of error/uncertainty), because
they
need to be compared with times observed for other events by other
unknown observers. But most times are intended to be used only
in
comparison with other events observed by some particular
community of
observers. (011)
Computer clocks, in particular, may give precision to
milliseconds and
still be minutes off the standard time. If my laptop computer
timestamps an event with the time given above, that is probably
plus or
minus 3 minutes from Eastern Standard Time as disseminated by
NIST, or
5:00 A.M. as disseminated by the Greenwich Observatory. (Now, as
it
happens, my desktop computer time is synchronized once a day with
the
disseminated standard time, but even so, it is probably wrong 8
hours
later, even if only by a second or two.) The computer timestamps
are
still valid for precise comparisons between times of events on
that
computer, but they are not necessarily valid for comparison with
events
timed by some other computer. (012)
So when we talk about converting between time granularities, we
have to
talk about the intent of the conversion relative to the
communities
involved. If you take two times out of the context of use, you
are
comparing apples and oranges. You can get away with it, as long
as the
interpreted timestamps don't have overlapping domains of
uncertainty,
but since you don't know what those are, you are using some kind
of
seat-of-the-pants statistics to judge the probable value of the
comparison. To use a particularly apt metaphor, it is a lousy
way to
run a railroad.* (013)
Matt West says: (014)
> And what they really are, i.e. in this case an interval or
> period. Now
> there is, in my mind, nothing wrong with naming an interval
> 14th Jan
> 2008, but it needs to be understood that it has a start time of
> midnight
> at the start of the day, and an end time of midnight at the end
> of the
> day, and that it is not in any sense a point in time. (015)
The problem is that it is the designation for a precise "point in
time"
in some frame of reference, and a rough designation for an
"interval" in
another frame of reference. And because it is a rough
designation (your
midnight and my midnight are not necessarily the same UTC
instant), any
comparison that is close to the interval boundary, which is a
nominally
more accurate point in time, has some margin for error within
which the
relative time relationship is *indeterminate*. As Matt says: (016)
> All this for me is independent of whether time is ultimately
> granular
> or continuous. Ultimately this only means at what point we can
> not longer
> tell whether one event happened before another. (017)
Exactly. But the problem is that we don't know what the intended
accuracy of most timestamps is. If we leave it to software, or
lawyers
(or logicians, if this thread is any indication), we will get
hard-and-fast uneducated decisions near the boundaries. IMO, one
cannot
compare timestamps from different sources without understanding
the
overall margin of error in the clocks, and one cannot compare
timestamps
with different granularities without understanding the intent of
the
comparison. (018)
-Ed (019)
*The original motivation for standard time in the United States
was to
get railroad schedules to make sense. Theretofore, time at a
place was
referenced to a particular clock that was adjusted to "sun time"
at that
place every noon. (020)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (021)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (022)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (023)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (024)
|