Re: SUO: RE: OpenCyc problems
In response to Dietrich Fischer's comments (appended):
Thanks for your note and the reference to your paper.
The use of metaclasses is certainly common and has benefits
for certain aspects of ontology development. I use them myself,
and I expect that most people who get at all serious about
building an ontology will understand what they are. I sure
hope I didn't give the impression that I think metaclasses
aren't useful. They may be better than alternatives for
expressing disjointness and perhaps for classifying
predicates.
My specific concern related to the fact that
the way Cyc seems to distinguish substances from other
physical objects is through the metaclass-instance relation of
substance classes to "Stuff" metaclasses. Likewise, the
main distinction of processes from Events is by a "Stuff"
metaclass relation.
Working from the instances to their properties as
expressed through metaclasses at best requires an additional
inference step. For most of us humans I think this has
to be less perspicuous than having instance properties
right out in the open with the classes themselves, wherever
possible. Pierluigi apparently finds metaclasses congenial,
so I suppose there are some who are not too lazy to do
(or even enjoy doing?) the extra inference step. At worst,
the use of metaclasses may unnecessarily obscure what can
be otherwise quite transparent.
The problem of CYC substances is something like this:
(1) The "stuff" metaclass documentation talks about divisibility
but the OpenCyc predicates relating to this concept are hard to
find. True, as Dietrich points out, there is a predicate that
specifies that instances of a class of "Stuff" type will have
parts also of a "Stuff" type:
>
> 4. With respect to your question: "Where are the rules for the water
> example?"
> I would point to
> Mt : NaivePhysicsMt
> salientAssertions : M(relationAllInstance membershipMaintainedUnder
> ExistingStuffType physicalParts)
> M(relationAllInstance membershipMaintainedUnder ExistingStuffType
> physicalPortions)
>
. . . but I haven't yet found (in axioms or predicates, not in the
documentation) what being of a "Stuff" type entails for the instances.
(2)
The above predicates in fact entail the classical "sorites"
paradox, that one can divide a "Stuff" indefinitely down to some
ridiculous and completely non-physical level. So in the
documentation, it is also mentioned that there is a "grain" below
which the division rule doesn't apply. Very good. Where are
the predicates that tell the "Stuff" rule when to stop?
(3) Well, one can specify the grain size with the predicate:
#$granuleOfSpatialStuff. From the documentation:
"(#$granuleOfSpatialStuff STUFFTYPE OBJTYPE) means that the
collection STUFFTYPE has as its spatial granules (or granularity
level) the collection OBJTYPE. If some collection is spatially
stuff-like, that means that the instances of that collection can be
divided spatially, and the physical portions remaining will still be
instances of that collection; e.g., a physical portion of some
instance of #$SandMob is still sand (cf. #$ExistingStuffType). Such
division cannot go on indefinitely in this way, however: eventually,
division of something spatially stuff-like will result in the
object-like 'granules' out of which the stuff-like thing is composed
. . . "
That's OK, now how is it applied? I can't find an example of where
that predicate is actually used in OpenCyc. And I can't find where
the Granule, whatever it is, puts a limit on the subdivisibility
of an instance of a class whose metaclass is "StuffType". IF it is
there in OpenCyc, I hope that a Cyclist can point it out.
(4) But the bigger point is: why do we have to go on a hunting
expedition to find out what the logical properties of a Substance
are? There are straightforward ways to specify that in the
inheritable necessary properties of instances of Substances.
These properties are really important and should be obvious
at the highest level in the list of necessary properties of the
Substance class instances. To my mind, this is vastly preferable
because it is easier to understand and to use (even for a computer
I suspect).
Perhaps the clarifying axioms were just inadvertently left
out, even for these important concepts. As Dietrich points
out:
>
> Opencyc 0.7 is a torso and the extraction aims and principles and
> the quality of their execution from "Full Cyc" we are not informed
? of, are we? There are two fora related to the use of OpenCyc at
> https://sourceforge.net/forum/?group_id=27274
>
Sure, extracting part of a large interwoven fabric is bound to
leave some loose ends. But the fundamental treatment of Process and
Substance are to my mind seriously flawed, and the difficulty of
making sense of Substances in the OpenCyc just suggest that
they were never taken seriously at Cycorp.
===============================
(5.a)
To provide a concrete example (no, it's not "concrete" the
substance):
Consider #$StoneStuff which is a subclass of #$Soil-Generic:
#$Soil-Generic
An instance of #$ExistingStuffType, and a specialization of
#$EarthStuff. Each instance of #$Soil-Generic is a portion of earth in
which one can (usually) grow plants. Instances of #$Soil-Generic
include soils that are part of the top layer of the ground, as well as
soils that are processed and sold at lawn and gardening stores.
#$StoneStuff
"A specialization of (SolidFn #$RockyPlanetaryStuff). Each instance of
StoneStuff is a piece or portion of rock or stone. Stone is widely
used as a material for the construction of buildings, walls,
monuments, and sculptures."
Now is Stone actually a subtype of Soil?? It's true that stone
is often a **component** of soil, but one can't grow anything on
stone, even pebble-sized stone. Things grow in the soil under stones.
Was this subclass really intended? Well, the documentation hedges
about growing things by saying one can "usually" grow plants. But
wouldn't it be more reasonable to distinguish, say RockySoil from
StoneStuff? Do you think of the stones in the Parthenon as a type of
Soil?
More reasonably, a Soil should be a mixture of which one component
may be Stone-Stuff. But in OpenCyc Soil is not a mixture, though it
is an instance of "Stuff" type.
PS. As it turns out, "Concrete" the material isn't a mixture either,
though the documentation says that it is.
=====================================
I have said before and I say again that there are lots of useful
things in OpenCyc. I think that over 90% is reusable, and a lot of
that is well-thought out and non-obvious. But it appears to me that
they made some poor choices for representation of Process and
Substance. For a standard ontology that is intended to be widely
used, these fundamental classes should be specified as clearly
as possible, both in their documentation and in their transparent
logical properties.
So I recommend that, as we build the Merged Ontology that will be
one of the candidates or components of the SUO, we try to find
a different representation of Substance than that in OpenCyc.
I am, in a different thread, trying to find some agreement on
how we can represent Event and the related concept Process.
Pat
=============================================
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
=============================================
From Dietrich Fischer:
> Some remarks in response to Patrick Cassidy concerning metaclasses and
> OpenCyc:
>
> 1. People using and populating thesauri or even ontotologies create them,
> often not being aware, that a metaconcept's instances are not the
> metaconcept's subconcepts.
> In thesauri this does not cause harm because the single superordination
> relation
> there is the fuzzy "is a broader topic than".
> But people who claim to build ontologies should learn the distinction
> at least between a first order concept and a second order concept.
> The thesaurus people also invented "guide terms" and generally they can
> be interpreted as second order concepts. (see e.g. the Art &
> Architecture Thesaurus)
>
> 2. Metaconcepts are a place to describe properties of all their instances
> without using explicit quantification, using e.g. "rule macro-predicates",
> a Cyc method to implement special rules specially.
>
> 3. The prominent use of metaconcepts in OpenCyc obviously pertains to
> describing the range constraint (of the type argIsa) for arguments of
> predicates or functions,
> which have to be concepts and not e.g. individuals. If you ask e.g.
> (and
> (arg1Isa ?PRED ?COLL2)
> (isa ?PRED BinaryPredicate)
> (isa ?COLL2 SecondOrderCollection))
> you get 64 answers, and if you ask the same with arg2Isa you get 109.
>
> The metaconcept can say that its instances form a partition, a covering
> or are mutually disjoint,
> see predicates facets-Partition, facets-Covering, and facets-Strict.
> See also e.g. SiblingDisjointCollectionType and the the following
> inference justification
> from the OpenCyc 0.7 interface, asking wether Nurse and Dentist are
> disjoint:
>
> Strength : Default Module : DISJOINTWITH
> Mt : InferencePSC
> HL Formula :
> (disjointWith Nurse Dentist)
> Justification :
> (isa Nurse MedicalSpecialtyType) in HumanSocialLifeMt
> (isa Dentist MedicalSpecialtyType) in HumanSocialLifeMt
> (isa MedicalSpecialtyType SiblingDisjointCollectionType) in
> HumanSocialLifeMt
>
> By this method you need for n instances of the metaconcept (here
> MedicalSpecialtyType)
> n+1 isa-assertions to express their mutual disjointness, where otherwise
> woud need
> (n * (n-1)) / 2 assertions.
>
> 4. With respect to your question: "Where are the rules for the water
> example?"
> I would point to
> Mt : NaivePhysicsMt
> salientAssertions : M(relationAllInstance membershipMaintainedUnder
> ExistingStuffType physicalParts)
> M(relationAllInstance membershipMaintainedUnder ExistingStuffType
> physicalPortions)
>
> Unfortuantely, with an example I could not make this work; I guess that
> there are
> missing rules or "modules" for the predicates relationAllInstance and/or
> membershipMaintainedUnder.
>
> Opencyc 0.7 is a torso and the extraction aims and principles and the
> quality of their execution from "Full Cyc" we are not informed of, are we?
> There are two fora related to the use of OpenCyc at
> https://sourceforge.net/forum/?group_id=27274
>
> 5. I further guess that memberships in metaclasses mostly have been /
> have to be handcoded.
> I saw only very few rules which determind automatically this membership,
> such as
> Mt : BaseKB
> Direction : Forward
> (implies (and (genls ?TYPE SomethingExisting) (termOfUnit ?MOBFN (MobFn
> ?TYPE))) (isa ?MOBFN ExistingStuffType))
>
> or this problematic one:
>
> Mt : HumanSocialLifeMt
> Direction : Forward
> (implies (ist BaseKB (genls ?X Artist)) (isa ?X PersonTypeByActivity)),
> which says that in the HumansocialLife-Microtheory the following rule holds
> as a forward rule:
> "If in the root microtheory (BaseKB) it has been stated that ?X is a
> subconcept of Artist,
> then ?X is an instance of PersonTypeByActivity."
>
> Regards
> Dietrich
>
> P.S. If somebody can read German and is interested in more
> OpenCyc-related tutorial details of this kind (not only affirmative),
> see my working papers at
> ipsi.fraunhofer.de/~fischer/Metaconcepts.pdf
> and
> ipsi.fraunhofer.de/~fischer/CycPersonTypes.pdf
>
>
>