ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Past, Present, and Future of Ontology

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Patrick Cassidy" <pat@xxxxxxxxx>
Date: Thu, 28 May 2009 12:51:23 -0400
Message-id: <03ef01c9dfb4$88cb4520$9a61cf60$@com>
John Sowa has done us all a service by presenting a good summary of the
issues that should be dealt with in designing ontologies in general and
foundation ontologies in particular:
    http://ontolog.cim3.net/forum/ontolog-forum/2009-05/msg00133.html    (01)

 . . .  for which I am grateful.    (02)

I would like to point out that the suggestion I have made for a large
collaborative development of a foundation ontology is designed precisely to
avoid the pitfalls that John has enumerated via quotes from previous
discussions.  I find little to argue with in those quotes, with one
exception: the question of semantic primitives.  JS quotes Lenat:    (03)

> In note #62, Doug Lenat and R. V. Guha made the following comments about
the search for a set of "primitives":
DL&RVG >> The problems... are (a) there is no small set, and (b) it's  >
almost impossible to nail down the meaning of most interesting terms,  >
because of the inherent ambiguity in whatever set of terms are "primitive."    (04)

This remark seems to be directed at "primitive terms" used in language.  The
kind of semantic primitives in an ontology are not ambiguous, of course, so
Lenat here is talking about human language.  When I spoke to him last year
about the issue of ontological primitives, he indicated to me that he
thought there might be as many as 15,000 primitive concepts that need
representation in an ontology, particularly because of the nuances of
meaning in relations.  But in fact Cyc has never pursued the tactic of
finding an inventory of conceptual primitives, so Lenat's guess is still
only a guess.  My suggestions was that, rather than guess, we actually
conduct a proper study to determine whether there is a finite inventory of
conceptual primitives and if so what the number is.  In fact, even with
respect to language he misses an important point: the senses of words that
are "primitive" and used by, e.g. Longman in their definitions are only a
small subset of the senses of those words.  That experiment was done by Guo
and he concluded that the Longman grounds out on 1433 words (a subset of the
published defining vocabulary) representing 3280 senses.  This not
surprising to me, because the particular "language game" that is played in
creating dictionary definitions (in Longman, at least) is to be as
**unambiguous as possible** in a non-interactive context.  That entails the
use of word *senses* that are common and easily recognizable in their
context of use.  In practice, this means that the average ambiguity of the
words used is less than 3.  John has noted that some of the definitions in
Longman are simple and do not go into detail. Yes, but when I try to create
more detailed definitions that include all of the necessary conditions I
would want in an ontological specification, I find that I can accomplish
that using the same set of words.  I think this is relevant a priori
evidence for a finite set of semantic primitives that cannot be dismissed
without some other experimental testing.    (05)

The notion of "semantic primitive" has been discussed mostly in the context
of human language, so its meaning is a little fuzzy because we don't have
detailed access to the workings of the brain. In the context of a
computational ontology, there can be a more precise way of viewing what it
means for a concept representations to be "primitive".  The view I currently
favor depends on viewing the ultimate goal of ontological representation to
be the ability to interpret and act on information with the depth of
understanding that a human can achieve.  I agree with Woods (and others)
that to achieve that, a machine must be able to recognize objects that are
picturable, and either perform actions or at least recognize when they have
been performed ("procedural semantics").  This means that human-level
understanding depends on sensory and motor capabilities that provide the
"grounding" in reality to give unambiguous meaning to the symbols used in
information exchange.  As a consequence, there is a requirement for
*procedural code* to properly interpret any assertion at the human level.
Using this basic assumption, the "primitive" elements in an ontology will be
those that depend directly on procedural code for their proper use.  These
are the elements that need to be included in a common Foundation Ontology
and for which there must be agreement among the users who want their systems
to interoperate accurately at the semantic level.  Any elements that can be
constructed as combinations of the primitive elements will not themselves be
primitive, though they also ultimately ground out on the procedural code of
the primitive elements.    (06)

Of course, at present and for the near future we will not have any agreement
on many of the sensory or motor processes that provide this kind of
grounding for primitive elements.  But there are some processes that are in
practice used now that can be viewed as primitives in this sense.  One
example is the computable functions used for arithmetic operations.  Though
arithmetic operations can in theory be represented as just a lookup in some
list of instances in  a table of infinite size, in practice they are
calculated procedurally.  So to achieve semantic interoperability where
arithmetic is concerned, there has to be agreement on how those calculations
are performed (e.g., specifying precision and how rounding is performed).
Another kind of "primitive" is input-output, and importantly, access to the
internet, which are the main links to the external world for most of our
computers.  These procedures need to be standardized so that when there is a
rule in the FO of the kind "if condition, then action" the action is the
same for all computer systems using that rule.  This view of primitives
versus non-primitives in an ontology classifies ontology elements into those
whose intended meaning can be represented solely with FOL rules, and those
that need procedural code; the latter are representations of the semantic
primitives.  The number may be fixed, or may have to increase as new
applications are added that want to interoperate.  For any given set of
applications that are interoperating, having all the procedures that
interpret data confined to the semantic primitives of the FO will allow all
systems to arrive at the same inferences from the same data, even if they
use locally created extensions to the FO for their local applications.  To
interoperate semantically, they have to share the definitions of ontology
elements not already present in the FO and its public extensions, if those
locally defined ontology elements are required for interpretation of the
shared data.    (07)

For the near future, in the absence of actual procedural code to represent
sensory and motor functions and concepts directly dependent on those,
agreement on the intended meaning of ontology elements that are primitive
will mostly depend on carefully written documentation that specifies how
particular ontology elements should be interpreted and used.  What this
means in practice is that, if any procedural code is used locally for data
interpretation, that code must not violate the description of the meanings
in the documentation of primitive elements.  If possible, the data
manipulations (other than input-output or reversible format transformation)
should be performed with FOL reasoning that is used in common with other
systems communicating the information.  But if a programmer feels s/he
"must* use procedural code, s/he needs to understand the intended meaning of
the primitive ontology elements on which the meanings of the data elements
depend.    (08)


> From note #16 by Bill Mark,
BM >> My belief is that we *can* have lots of knowledge to share, but
   >> only if we start building it to be sharable.      (09)

Yes, yes!  One point of the FO project is to create a Foundation Ontology
that is designed specifically to have the capability to translate among the
alternative representations that different groups may want to use.  Then any
knowledge represented using that FO will be sharable.    (010)

The point was also made in that 1991 discussion that we can't start with a
"standard" ontology at this time, a standard has to be based on experience
of use of ontologies in different applications; I have made that same
argument myself.  The problem is that to *evolve* an ontology to the point
where it may be suitable to recommend as a standard requires that there be a
substantial community that uses and tests that one ontology.  It is quite
impossible to test one ontology by using another.  So in order to have any
hope of evolving a common ontology it seems necessary to fund the activity
of some community of significant size that can build and test and evolve
some common FO.  If there is more than one such community, that is fine too,
as long as these communities are large enough to provide proper experimental
testing.    (011)

The main purpose of the FO project I have suggested is to create such a
community of users with varied interests who can evolve an FO that suits all
of their purposes and serves to support accurate interoperability; and to
sustain them for several years so as to properly test that FO.  This will
provide us with a publicly accessible FO that has actual open-source
applications that illustrate its use, something we don't have now.    (012)


Pat    (013)

Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx    (014)



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (015)

<Prev in Thread] Current Thread [Next in Thread>