|
At 3:23 PM +0200 1/23/08, Christopher Spottiswoode wrote:
Ed,
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? :-)
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?
Your rhetorical question has no answer, as you do not say what
you mean by 'contexts'. But in general, to move from speaking of times
(which are relatively well-understood and thoroughly investigated) to
'contexts' is a retrograde step.
It's as in
colloquially-familiar
and meaningful statements such as "The precise meaning of the
time statements is dependent on their context."
which means (literally) nothing, until one says what is meant by
'context'
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.
Bear in mind that the entire point of this whole community is to
focus on ontological engineering. Now, if ontologies have anything in
common, they are all intended to be used repeatedly, to be archivable
for re-use, and usually transmittable from place to place on a network
for re-use. Moreover, the agents doing the transmission and re-use are
usually mechanical systems rather than human 'parties', and they
cannot be relied upon to use human-level sophistication or awareness
of such things as contexts of use. All of which means that ontologies,
in notable contrast to human utterances in conversations and
discussions, must be written so that their context of use is remote
from, and usually unknown to, the context in which they are composed.
Any contextual or indexical sensitivity which is liable to change the
intended meaning, therefore, is likely to be a serious problem; and
indeed this does sometimes occur, and it is indeed a serious problem.
The ideal ontology framework is one in which all contextual
sensitivity has been eliminated as far as possible. We know how
to do this, in broad methodological outline: one imports into the
ontology itself an explicit marker or markers of what would normally
be considered the 'context'. In tensed terms, one does not speak of
'now', or use tenses whose meaning depends on the time of utterance,
but rather puts explicit date and time markers on (or in) assertions,
using a recognized and hopefully internationally ratified standard
notation for indicating these times. If there is any risk of
misunderstanding of the notation in a different context, one includes
an explicit reference to the standard itself as part of the temporal
reference, and so on. The general process is called
'decontextualizing',and in various forms it has been a hallmark of
ontology engineering and indeed of KR work more generally since the
beginning of the subject.
The result is often tediously pedantic and redundant to human
eyes, but ontologies are not primarily intended for human eyes. For
example, to refer to the number three in RDF requires this:
"3"^^http://www.w3.org/2001/XMLSchema#number
Can we really do without some formal recognition and
representation of 'context', all in a context-dependent way, of
course?
Yes, we can. Indeed, we must.
And surely, there is no need to
eschew the word!
But there is a need to define it: that is, your particular
use of it. For example, your understanding of what the word means,
though never specified, seems to be completely remote from John Sowa's
admirably clear sense of what he means by a context.
Pat Hayes
Christopher
----- 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
John Sowa wrote:
>> 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).
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)?
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.
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.
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.*
Matt West says:
> 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.
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:
> 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.
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.
-Ed
*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.
--
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
"The opinions expressed above do not reflect consensus of
NIST,
and have not been reviewed by any Government
authority."
_________________________________________________________________
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
_________________________________________________________________
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
--
---------------------------------------------------------------------
IHMC
(850)434 8903 or (650)494 3973 home
40 South Alcaniz St.
(850)202 4416 office
Pensacola
(850)202 4440 fax
FL 32502
(850)291 0667 cell
phayesAT-SIGNihmc.us
http://www.ihmc.us/users/phayes
_________________________________________________________________
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 (01)
|