Comments below...
From: Eric Armstrong <eric.armstrong@eng.sun.com>
<snippage>
> At the moment, I continue to reserve the term "DKR" for
> future developments. Jack and Howard are constructing
> the ontology for the OHS, and we need that. But later on
> they are going to want to build bigger and better
> ontologies to solve even deeper problems (yes?).
>
Yes. But, let me put it a slightly different way. Ontologies are social
constructs. Jack and Howard will NOT be building the larger ontology, the
community of users will. Jack and Howard will be involved in the design of
knowledge structures that are, at once, mutable, and robust enough to give
us a solid foundation on which the ontologies can grow. Jack and Howard are
already engaged in the design of an ontology (meta ontology, perhaps) for
the system itself. That is perhaps best viewed as an engineering effort,
not suited for social evolution, though it, too, must evolve as the system
is used.
> I know that the OHS as currently envisioned will solve
> a lot of problems, and provide us with the ability to
> carry on intelligent, far-ranging discussions that can
> eventually "coalesce" to reach one or more conclusions.
>
> I'm not yet convinced, however, that it will give Jack
> and Howard *all* the tools they need to play with
> bigger and better ontologies -- to construct them,
> operate on them, and use them to deal with information
> in meaningful ways. Much as I want to see the capability
> come into existence, it is not all clear to me that the
> current design will be capable of doing that.
>
It is my deepest hope that as the OHS evolves, it will do so in a fashion
robust enough to allow for plug-in engines of various kinds. That is why I
favor my OntoCentric (tm) approach. <note>I use OntoCentric in a trademark
fashion because I want it to mean one, and only one particular thing</note>.
By that, I am saying that our use cases, design requirements, market
surveys, and so forth, all should contribute, first, to the meta ontology
that yields the product in all its gory details: software architectures and
source code, database schema, business rules, IDL, and so forth. Keep in
mind that a software implementation is just an expression of an ontology.
That notion remains my lone contribution to the OO design community. I
recall my first experiences with OO design did involve a *glossary* so
everybody would "stay on the same page." I have simply formalized that to
say that a glossary on steroids, including axioms, relations, states, and
all the rest, were, in fact, the most lucid design spec possible. Of
course, you cannot get it right the first time (in most cases), so the
process remains iterative. The life-cycle of an OntoCentric design is,
perhaps, infinite in length.
> So I tend to use DKR for that still-nebulous thing we
> hope to get to sometime downstream. In many ways, it
> is a label for my ignorance -- for all the things I
> have to understand about what we need, and about how
> to provide them. (The difficulty I have in following
> ontology-related discussions convinces me that the
> system I understand (the OHS) is unlikely to qualify
> as a DKR.)
>
In my view, a DKR is built when the knowledge it represents is, in fact,
dynamic, always evolving.
I am aware that Doug was always interested in the notion of knowledge
representation (KR). He had met Mary Keeler, who told him about Peirce,
Conceptual Graphs, John Sowa, and so forth. When I first met him and spoke,
myself, of these same ideas, he made it clear that these ideas needed to be
incorporated into the system. Thus, he invited me to talk at the last Unrev
II session. I have remained on the scene ever since, if for no other reason
than to kibutz everyone else into seeing the need for KR. It remains a
tough job, but, hey, somebody's got to do it ;-)
I would like everyone to understand my view: there does not exist any
computer that serves as a repository for knowledge. Knowledge resides
solely in that 3.5 pound universe of meatspace we call our brains.
<note>Here, I am ignoring that whole mind-brain thing</note>. The only
thing a computer can ever contain is a collection of representations of
knowledge. We, as humans, are awfully guilty of confusing the Map for the
Territory. The Territory is what our brains make of things. Maps are
representations that help our brains by providing a variety of stimuli,
nothing more than that. Steven Newcomb, one of the "fathers" of Topic Maps
and HyTime often refers to this issue with a discussion of a *chasm*. On
the left is all the representations we can imagine (Maps). On the right is
all the Platonic forms, (Territory). The brain resides in the chasm between
the two sides. The Maps are there to help the brain select the correct
objects out in the Territory. An OHS, in all its richness, is just a Map
and its engines of creation, management, and application.
My ideas are not original. I cannot think of ever having had an original
thought. Rather, I tend to synthesize from the ideas of others. I am deeply
indebted to Mary Keeler, Kathleen Fisher, Steven Newcomb, Michel Biezunski,
Howard Liu, Doug Engelbart, and others for helping me to formulate my views.
That my views may stray from reality (as viewed by others) remains with the
quirky ways in which I perform synthesis.
May the force be with us
Jack
============================================================================
This message is intended only for the use of the Addressee(s) and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
the intended recipient, dissemination of this communication is prohibited.
If you have received this communication in error, please erase all copies
of the message and its attachments and notify postmaster@verticalnet.com
immediately.
============================================================================
-------------------------- eGroups Sponsor -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/2/_/444287/_/974476223/
---------------------------------------------------------------------_->
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Fri Nov 17 2000 - 08:00:36 PST