Re: SUO: Re: nature of organisation
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