RE: SUO: RE: OpenCyc problems
Dear Pat,
I might point out that EPISTLE makes extensive use of what
you call meta classes. (Just classes of classes).
This was based on pragmatic utility and necessity.
I could not imagine how we could achieve the same capability
without them. (e.g. strictly you can't have numbers).
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
> -----Original Message-----
> From: Patrick Cassidy [mailto:pcassidy@bellatlantic.net]
> Sent: 26 June 2003 16:10
> Cc: standard-upper-ontology@ieee.org
> Subject: 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
> >
> >
> >
>
>