Re: SUO: Re: nature of organisation
Chris --
Thanks much for the clarification. As you may suspect,
my familiarity with set theory is de minimis, but my
confusion has a little more basis than just some
confusing terminology in the Ontolingua Frame Ontology.
I was concerned with how the SUMO would align with CYC,
and in CYC the concepts in the hierarchy are called
"Collections", whereas in SUMO they are called "Classes".
I have suspected that these two terms were intended to have
the same definition -- but your comments suggest
otherwise.
In CYC, a #$Collection is described as:
;;; #$Collection
(#$isa #$Collection #$SetOrCollection)
(#$isa #$Collection #$Collection)
(#$genls #$Collection #$SetOrCollection)
(#$comment #$Collection "The collection of all Cyc collections. Cyc
collections are natural kinds or classes, as opposed to mathematical
sets; their elements have some common attribute(s). Each Cyc collection
is like a set in so far as it may have elements, subsets, and supersets,
and may not have parts or spatial or temporal properties. Sets,
however, differ from collections in that a mathematical set may be an
arbitrary set of things which have nothing in common (see
#$Set-Mathematical). In contrast, the elements of a collection will all
have in common some feature(s), some `intensional' qualities. In
addition, two instances of #$Collection can be co-extensional (i.e.,
have all the same elements) without being identical, whereas if two
arbitrary sets had the same elements, they would be considered equal.
As with any Cyc constant, an instance of #$Collection should be created
only if it is expected to have some purpose or utility. Moreover, the
`best' collections to create are the ones which are impossible to define
precisely, yet about which there are rules and other things to say.
E.g., `WhiteCat' is not a good element of #$Collection to create,
because it's easy to define with other Cyc concepts, and there's not
much to say about the collection of white cats; but `WhiteCollarWorker'
could be a good element of #$Collection, because it is hard to define
exactly, yet there are many things to say about it.")
. . . the operative point (for me) is the phrase: "their elements have
some common attribute(s)"
As I understand your response, there is no concept
in SUMO of an aggregation of Entities that necessarily have
*some* common attribute, therefore a Class in SUMO is not a
concept identical to a #$Collection in CYC. If this is correct,
I am curious to know why such a concept is not defined?
Do the creators feel that this is not a useful concept?
That is one thing I am curious about.
On the question of which Set Theory is being used, I confess
that I *was* totally snookered by my naive conclusion that
it was Zermelo-Frankel. One logician I spoke to a while back
told me that the most commonly used Set theory was ZF, and in the
absence of any disclaimer (plus some other clues) my suspicion
was that SUMO also used it. Your contradictory assertion -- that
"the most prominent theory" was VNBG -- was enlightening. Then:
> Well, yes, but you have been misled because the Frame Ontology inherited
> the quirky vocabulary of the first versions of KIF -- call it KIF-1.
> KIF-1 in fact incorporated all of VNBG set theory, but for some dark and
> mysterious reason decided to use the term "Set" to refer to VNBG
> classes. This has been -- and apparently remains -- a source of untold
> confusion.
This helps clarify some of the questions I had, but questions
remain. In one of the pitiful few texts I own on Set Theory (Stoll's
"Set Theory and Logic") I noticed that he mentions von Neumann theory
only in passing, to distinguish it from Z-F, which is the main
axiomatization
that he describes. He mentions that a VN "Class" which is *not* a Set
cannnot have another class as a member. But I ran into SUMO axioms like
this:
(<=>
(instance ?ENTITY (GeneralizedUnionFn ?SUPERCLASS))
(exists (?CLASS)
(and
(instance ?CLASS ?SUPERCLASS)
(instance ?ENTITY ?CLASS))))
<=>
(instance ?ENTITY (GeneralizedIntersectionFn ?SUPERCLASS))
(forall (?CLASS)
(=>
(instance ?CLASS ?SUPERCLASS)
(instance ?ENTITY ?CLASS))))
(=>
(instance ?SUPERCLASS PairwiseDisjointClass)
(forall (?CLASS1 ?CLASS2)
(=>
(and
(instance ?CLASS1 ?SUPERCLASS)
(instance ?CLASS2 ?SUPERCLASS))
(or
(equal ?CLASS1 ?CLASS2)
(disjoint ?CLASS1 ?CLASS2)))))
. . . from which I concluded that metaclasses were permitted in
SUMO, and VN Set theory "Class" was not what was intended
by "Class". (Are these classes intended to be Sets? or
should these "instance" predicates have been "subclass"?)
Also, I could not find any mention of von Neumann in
the file, nor any reference to metaclasses,
nor any axiom forbidding classes to be instances of
other classes.
In addition, Stoll mentions that "classes in the von Neumann
theory play the same role that formulas do in the
Zermelo-Fraenkel theory."
So I was truly snookered, but now I still don't know
quite what a Class is in SUMO. It doesn't seem to be a
von Neumann "class" -- or have I misread the explanation?
If it can be intensionally defined like a CYC #$Collection,
but also be a Set, is there also a third subclass of Class that is
neither a Set nor defined by some Formula (necessary condition)?
If there are only the two possibilities, then it would seem
to be similar to the CYC $%SetOrCollection (is this supposed to
be a VN "Class?). Is that the intention?
Perhaps one problem is that there is not a single Class that
is defined as "All classes that are not Sets". Then it is not
clear whether a particular Class is or is not a Set.
> Actually, nothing in SUMO *requires* a class to have an associated
> membership condition as far as I can see. It is a common way of
> thinking about classes, granted, but there's nothing in SUMO that
> prevents you from simply asserting "(Class FOO)". Presto, FOO is a
> class, ex nihilo, no definition.
>
This is one of the possibilities that I think it would be a good
idea to avoid. Since most classes will be subclasses of some other
class, the only truly vacuous classes with no attributes would have
to be at the top of an ontology, as sisters to "Entity" -- truly
useless things. More to the point, it should be illegal to
define a class unless it has some predicates or axioms added to
those of the parents. It can be useful to define vacuous classes while
developing an ontology, to help understand the intention of
class definitions by providing subclasses with suggestive
natural-language names. But if such vacuous classes persisted into
a working ontology, such classes would be essentially indistinguishable
from their parents logically. If we had the requirement that a
class *must* have some defining predicate or axiom in addition to
those of the parent, vacuous classes could be detected by
a consistency-checker before the ontology was fielded.
Perhaps if I had a deeper understanding of all the nuamces of
set theory, the description of "Class" in SUMO would be
crystal-clear, but then isn't it possible that there are some
programmers who might use the SUO who would be similarly
misled? Among other questions, does SUMO permit classes to
be instances of "Class"? Is there a specific reason why
Classes in SUMO are not required to be intensionally defined,
as #$Collections are in CYC? IS a "Class" actually intended
to be a VNGB "Class"?
Pat Cassidy
=========================
============================================
Chris Menzel wrote:
>
> On Sat, 25 Aug 2001, Patrick Cassidy wrote:
> > (3) Question:
> > Set vs. Class
> >
> > A related question I have asked and do not yet know the answer to is
> > why a "Set" in SUMO is a subclass of "Class" when in most theories the
> > opposite is true.
>
> No, in fact, in all theories I know of, and notably in the most prominent
> theory VNBG (for "von Neumann - Godel - Bernays), all sets are classes,
> but not vice versa. (Though it wouldn't be quite right to say that SET is
> a subclass of CLASS, as there is in VNBG no class of all classes, unlike
> SUMO.) I think you have been snookered by the quirky terminology of the
> Frame Ontology -- see below.
>
> > The definitions below say that a Set, "unlike &%Classes generally",
> > does not have "an associated condition"
>
> Better, it *needn't* have an associated condition, i.e., a definable
> condition A such that all and only members of the set satisfy A.
>
> > (i.e. the standard interpretation of Class),
>
> I am not familiar with this standard interpretation.
>
> > but if Classes all had "an associated condition", then with the
> > subclass relation in SUMO this would appear to violate the principle
> > of inheritance of attributes; ...
>
> You lost me. Can you make this argument explicit?
>
> > whereas, if the subclass/set order were reversed, the comment would be
> > correct, but then Class would no longer be a generalization of Set.
>
> Ditto here.
>
> > This would not be a contradiction if in fact Classes generally were
> > not *required* to have an associated memership condition,
>
> Actually, nothing in SUMO *requires* a class to have an associated
> membership condition as far as I can see. It is a common way of
> thinking about classes, granted, but there's nothing in SUMO that
> prevents you from simply asserting "(Class FOO)". Presto, FOO is a
> class, ex nihilo, no definition.
>
> > but this would then differ from the usual interpretation of "Class" as
> > it is used in ontologies
>
> I don't think so.
>
> > (e.g. in the Ontolingua Frame Ontology, a Class is a subclass of Set;
>
> Well, yes, but you have been misled because the Frame Ontology inherited
> the quirky vocabulary of the first versions of KIF -- call it KIF-1.
> KIF-1 in fact incorporated all of VNBG set theory, but for some dark and
> mysterious reason decided to use the term "Set" to refer to VNBG
> classes. This has been -- and apparently remains -- a source of untold
> confusion.
>
> Classes in the Frame Ontology are in fact just a special class of
> Relation -- they are relations of arity (or "valence", in SUMO-speak) 1.
> Being extensional and all, a relation in the Frame Ontology is just a
> set of n-tuples, i.e., in the Frame Ontology, a *list*. Thus, a Frame
> Ontology class is just a set of 1-tuples -- which is a further major
> quirk of usage.
>
> In more standard terminology, then, SET in the Frame Ontology = CLASS in
> standard class theories, and CLASS in the Frame Ontology = SET OF
> 1-TUPLES in the Frame Ontology = CLASS OF 1-TUPLES in standard class
> theories. So you can see why, in the Frame Ontology, CLASS is a
> subclass of SET. In SUMO-speak, this just means that CLASS-OF-1-TUPLES
> is a subclass of CLASS. No disparity there.
>
> > a Class is distinguished from a unary predicate only by a second-order
> > predicate.)
>
> I find the Frame Ontology documentation that I believe you are drawing
> upon here incoherent. Help us out if you think you can translate.
>
> > I can understand why one might want to define a "generalization" of
> > Set so that it is not extensional, but I could not find defining
> > axioms for "Set" or "Class" (except the extensionality axiom for
> > &%Set), and from the definitions below I am not sure whether these two
> > concepts actually serve their intended pupose.
>
> And what purpose is that, exactly? Currently, the axioms say that sets
> are classes, and are extensional. There are also axioms that ensure
> that classes form a boolean algebra. Currently these axioms appear to
> be all that is needed for sets and classes to do the work for which they
> are intended in the SUMO. So either you think the current axioms are
> inadequate for purposes of the SUMO -- in which case chapter and verse
> would be helpful -- or you think there are other purposes relative to
> which the current axioms are inadequate. In that case, state those
> purposes. Telling us you're not sure about the axioms is interesting
> autobiography perhaps (or not), but that's about it.
>
> > In the documentation, a distinction is drawn between Class and
> > Collection that a collection can change members without changing
> > the identity of the collection (a typical criterion for
> > *intensional* definiton):
> >
> > "Collections have &%members like &%Classes, but, unlike &%Classes,
> > they have a position in space-time and &%members can be added and
> > subtracted without thereby changing the identity of the &%Collection."
> >
> > . . . but the documentation for &%Class specifically says that
> > Classes are *not* defined extensionally, which is also what is
> > implied for &%Collection by the documentation for &%Collection.
> > Can you clarify this?
>
> It is not explicitly declared in the SUMO that classes are not
> extensional, it is just not assumed, whereas it appears that collections
> are assumed to be nonextensional. Furthermore, collections exist in
> space-time, classes do not.
>
> > Question: Is it *required* that a Class have an assocated
> > membership condition (predicate)?
>
> No. That is, if I understand you, it needn't be the case for every
> class c that there is some definable condition A in our language such
> that c consists of all and only those things that satisfy A.
>
> > If not, is there any concept that serves as an intensionally defined
> > Set, like the "Class" of the Ontolingua Frame Ontology?
>
> You lost me.
>
> > If a &%Collection retains its idenity in spite of membership changes,
> > does this not mean it is *necessarily* defined intensionally (by a
> > defining predicate)?
>
> No, it would simply mean that it *is* an intensional entity, whether
> definable or not.
>
> > I think it's a good idea that the highest levels of the ontology
> > should have the clearest and least ambiguous definitions.
>
> Hear hear! Let's have a look.
>
> > -------------------- From SUMO 1.17 (subclass Set Class)
> > (documentation Set "A &%Class that satisfies extensionality as well as
> > other conditions specified by some choice of set theory. Unlike
> > &%Classes generally, &%Sets need not have an associated condition that
> > determines their membership. Rather, they are thought of
> > metaphorically as `built up' from some initial stock of objects by
> > means of certain constructive operations (such as the pairing or power
> > set operations). Note that extensionality alone is not sufficient for
> > identifying &%Classes with &%Sets, since some &%Classes (e.g.
> > &%Entity) cannot be assumed to be &%Sets without contradiction.")
>
> I agree that the second sentence above seems to imply that classes
> *must* have an associated condition that determines their membership.
> That is currently false, and I would suspect will remain so -- one can
> simply declare a thing to be a class, as noted above. *Typically*,
> however, one introduces a class by providing some sort of condition that
> states necessary and sufficient conditions for being in the class.
> Moreover, operations that are legitimate for constucting new sets from
> given sets -- power set, notably -- will not in general hold for
> classes. Seems to me the above documentation can be fixed just by
> replacing "Unlike &%Classes generally" in the second sentence above with
> something like "Unlike typical &%Classes".
>
> > (subclass Class Abstract) (documentation Class "&%Class generalizes
> > that &%Set. &%Classes, like &%Sets, are collections of things.
> > Accordingly, the notion of membership is generalized as well - a
> > member of a &%Class is an &%instance the &%Class. &%Classes can
> > differ from &%Sets in two important respects. First, &%Classes that
> > are not explicitly identified as &%Sets are not assumed to be
> > extensional. That is, distinct &%Classes might well have exactly the
> > same instances. Second, &%Classes typically have an associated
> > `condition' that determines the instances of the &%Class. So, for
> > example, the condition `human' determines the &%Class of &%Humans.
> > Note that some &%Classes might satisfy their own condition (e.g., the
> > &%Class of &%Abstract things is &%Abstract) and hence be instances of
> > themselves.")
>
> No problem here as far as I can see.
>
> Cheer!
>
> -chris
>
> --
>
> Christopher Menzel # web: philebus.tamu.edu/~cmenzel
> Philosophy, Texas A&M University # net: chris.menzel@tamu.edu
> College Station, TX 77843-4237 # vox: (979) 845-8764
--
=============================================
Patrick Cassidy
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax)
internet: cassidy@micra.com
=============================================