Re: SUO: The lattice of theories
Strangely enough, I found myself in agreement with most of what you say in:
> About a month ago (2002-05-12 E-mail to SUO list), I had suggested some ideas for organizing the SUO work, which is consistent with your "lattice" or "library of theories" approach. There were three kinds of standards that were necessary (I've slightly edited my words of 2002-05-12):
> - Type #1 (the registry): A registry of general concepts where there is common agreement. The goal would be to build consensus around a bunch of concepts and, hopefully, these general concepts could be used as a foundation for developing other concepts. Note 1: I believe that SUMO, some portion of IFF, and OpenCyc might be this kind of standard. Note 2: We might want to relax the constraint of "common agreement". Note 3: This kind of standard usually produces two separate standards: the registry (i.e., the "table" of entries -- the technical part), and the registration authority process (i.e., how we agree to include entries in the table -- the administrative part).
Right, there should be a *minimal* core of general concepts that should be blessed
with "common agreement" and used as a foundation for developing other concepts.
My take on this is only slightly more precise, in that the number of such concepts
SHOULD be kept to a minimum, *and*, even more imperatively still be left open as
the content or definition of such concepts is concerned. For instance it might be
that the concept of 'mass' is recognised as one which NEED a common agreement, but
at any given time the *definition* of this concept should be left open.
That is, the *characteristic* attributes (properties... whatever one like to name
them, be easy on the formalism during design debates...) should be replaceable
and amendable thru consensual debate but with a *linear* ordering of the successive
commonly endorsed definitions. And this is where *some* unique registration authority
is needed, but just to record the evolution of the consensus, NOT to define it.
> - Type #2 (the relationships/mappings): A technique for mapping one set of concepts to another. Why do we care about mappings? Because, e.g., that's all the market wants, or maybe it's impossible to get to common agreement on all the entries in Type #1. So this kind of standard would specify we describe, in general, mapping one set of concepts to another. Note: I believe that some portion of IFF might be this kind of standard.
This is fine too, but I would not use the word "mapping" because in most cases it is
NOT possible to represent exactly a concept from a given language (environment, jargon,
culture, whatever...) with concepts from another language or even with concepts from
a different theoretical setting for the same field.
Of course a coarse mapping is a minimum, like with the well known reduced color set
of some american indians (tit, lak, tulak for green/blue, red, orange/yellow/brown)
with which any translation will loose information but nevertheless give some
idea of what the color looks like.
A more satisfactory solution would be to spread the awareness of this difficulty
among users and application designers, so that they don't naively assume that a
simple minded "translation " will do and that they make provision for a more
sophisticated treatement of foreign concepts and ideas. The first step for this
being at least to tag the translated concepts with some information about their
original source. But this is a long term evangelisation process.
> - Type #3: We specify the necessary attributes to describe a concept. In other words, we wouldn't be specifying the concepts themselves, but we'd specify the required descriptive attributes when describing a concept. Note: Someone had mentioned something "metadata for ontologies" <-- an example of a Type #3 standard.
YES, rules about rules, this is *obviously* needed. But given that mathematics should
not be excluded from the realm of ontologies, does not this mean that some *high order*
statements should be expressible in the ontology language used to define constraints?
> These types of standards could be further partitioned or combined ... other types are possible, too. And once we've settled on the types of standards we want, we'll probably need to specify how to use this kind of information from an IT perspective, e.g., codings (file formats, XML, KIF, etc.), APIs (objects/interfaces with convenient paradigms in C/C++, Java, LISP, etc.), protocols (ontology exchange, storage/retrieval, etc.), and so on. <-- But most of this stuff is lower level engineering (also known as "bindings") because we really need to decide what kind of standard we want: Type #1, ..., Type #N, or some combination.
That would be REAL GREAT to have something to sort out the mess in software APIs!!!
> JS> Furthermore, you can start your library with as many or as few theories
> > as you want. A single monolithic theory, such as SUMO, is simply a
> > lattice with just one element. If you break SUMO into modules, you can
> > still keep SUMO in the lattice as one complete whole, with each of its
> > submodules as different generalizations.
> As I had mentioned in my E-mail of 2002-05-12, I suggested that the approach would be to
> "grow" the registry over time ... add entries, as appropriate/as approved. I don't know
> how many entries SUMO would require ... and there might be more than one "modular"
> representation/decompisition of SUMO if we used Type #1 and Type #2 standards.
> Once the registry were large, it would have the usual issues concerning searching,
> indexing, tagging, etc.. This is why I suggested that we also look into a Type #3 standard
> ("metadata for ontologies") to support the larger structures when they become available.
I could not state it better.
This is a kind of "bootstrapping" process, as the usefulness of the ontological
framework improves, it will also be usable to improve it's own structure.
> > MU> Any UNIMPORTANT differences among representations for the same
> > > concepts should be eliminated. To some extent it will be arbitrary
> > > deciding which one to choose. Where there are important differences
> > > these should be at attempt to keep them to a minimum and as you say,
> > > document them carefully so users can choose.
> > That is the beauty of having a library of theories instead of one big
> > lump. Each separate theory can be reviewed, studied, and evaluated
> > on its own merits and on its merits in comparison to its neighbors.
> One reason for keeping slightly different representations is to deal with "drift"
> over time ("terminology drift", "concept drift", etc.). It might be useful to have
> the 1970-timeframe thinking available, even though (presuably) the 2002-thinking would
> be more up-to-date. For practical reasons, both would need to be available.
For practical reasons, *many* variants of the same concept should be kept available
such that, whenever you read/hear about some concept as stated by *some* source,
be it an author, a standard body, a lexicon etc... you can figure out what *they*
mean and not assume that *this* occurence of the concept has the *standard* meaning.
Once a mechanism would have been agreed upon to provide with such multiple meanings
qualified by their source it will be able to deal with EVERY such case, including
revision levels of concepts from the same author.
Ultimately, and except for concepts from the "registry" (as defined at the beginning
of your message), there will be no such thing as a "standard meaning".
And even there, there will be "gravity" as of Newton's era, "gravity" as before 1905,
"gravity" as after 1905, "gravity" as of today, etc...
-- Jean-Luc Delatre
"Nothing is more annoying in the ordinary intercourse of life than this irritable
patriotism of the Americans. A foreigner will gladly agree to praise much in their
country, but he would like to be allowed to criticize something, and that he is
absolutely refused." - Alexis de Tocqueville, Democracy in America (1831).
http://perso.club-internet.fr/jld/ -- GSM: +33 6 11 24 06 29