Re: SUO: RE: OpenCyc problems
Just to follow up one point that Pierluigi raised:
Pierluigi Miraglia wrote:
> On Mon, Jun 23, 2003 at 04:55:42PM -0400, Patrick Cassidy wrote:
>
>
>> I don't know how these metaclass distinctions are
>>applied in CYC. I presume their applications find some
>>way around what appears to me at least clumsy and possibly
>>a logical inconsistency. The use of metaclasses to make
>>such distinctions is to me one of the serious weaknesses of
>>CYC as a standard. It is unnecessary and makes the structure
>
>
> I actually find metaclasses a very intuitive way to classify .... well,
> classes -- just as second-order properties seem to be useful in
> classifying properties. Why do you think that's obscure?
>
>
obscurity (1)
metaclasses can be useful and I think even necessary for
some situations, but since the logical properties that
are imparted by membership in a metaclass do not inherit
to subclasses, they cannot be considered as intrinsic
properties of all instances of the class. Sometimes that's
appropriate. But where it is possible to make distinctions
that are inheritable, i.e. to specify properties of instances
of a class rather than of the class itself, that is, to my
appreciation, much clearer in permitting an understanding of
what is intended as the meaning of the class -- just what does
it mean to be a member and how can one distinguish one
sort of entity from another. That makes it easier to use
and less prone to error.
It's admirable that Pierluigi finds classification of
classes by metaclasses to be "intuitive" but I rather
suspect that the average novice who is trying to learn
how to use a "standard" ontology will not be so familiar
with such a way of thinking. Try to find "metaclass" in
a dictionary (forget about a "collection of collections").
On the other hand, the use of "class" is standard (i.e. the
concept itself is pretty common)-- the first definition
in the Random House dictionary is:
Class. 1. number of persons or things regarded as forming a group by
reason of common attributes, characteristics, qualities, or traits;
kind; sort: a class of objects used in daily living.
The issue here is not whether, after years of getting used to
it, one can eventually find a particular usage to be easy --
the question for a *standard* is how easy will it be to get
an initiate to the point where s/he can use the standard with
an adequate level of technical proficiency. Putting properties
right in the classes where people are used to seeing them is
surely more intuitive for the average person. Hiding properties
in metaclasses is an additional barrier to learning distinctions
that could otherwise be simpler.
======================================
obscurity (2)
So just what does it mean for a class to be an instance of a
metaclass in Cyc? How do we determine the logical properties
of each metaclass? Take the "stuff" metaclasses as examples.
I want to know what the Cyc system does with instances of
substances, such as water. The necessary relations on "water" are
clear enough, though perhaps a bit eclectic: altitudeAboveSeaLevel,
duration, parts, temperatureOfObject, spatiallyRelated, hasAttributes.
That's easy to understand. Now, what do the metaclasses add to
these logical properties?
We see that the class #$Water has two metaclasses:
> (#$isa #$Water #$ChemicalSubstanceType)
> (#$isa #$Water #$TemporalStuffType)
A look at the metaclass hierarchy shows this subsumption sequence:
. . .
StuffType
TemporalStuffType
ExistingStuffType
TangibleStuffCompositionType
ChemicalSubstanceType
Question 1: why is #$Water an instance of both ChemicalSubstanceType
and TemporalStuffType? Doesn't the former imply the latter?
Or have I misinterpreted the meaning of the Type hierarchy?
The glosses for those metaclasses are reproduced below,
at the end of this note.
=====================
IF #$Water is an instance of StuffType, then the following should apply:
" More precisely, for a collection to be an instance of StuffType it
is sufficient that there be some spec-pred PARTPRED of parts (that is,
some predicate PARTPRED for which (genlPreds PARTPRED parts) holds),
such that if (isa OBJECT1 COL) and (PARTPRED OBJECT1 OBJECT2), then
(isa OBJECT2 COL)."
. . .
" Consider #$Water. Take any instance of #$Water -- say the water in
the Pacific Ocean. Now take any portion of that water -- say a handful
of it that a person scoops up near Honolulu, one of its
#$physicalPortions (a spec-pred of #$parts). That handful is itself an
instance of #$Water. Hence #$Water is a #$StuffType, in virtue of the
fact that all #$physicalPortions of all instances #$Water are
themselves instances of #$Water. "
. . .
and for an ExistingStuffType:
"Division in time or space does not destroy the stufflike quality of
the object (down to a certain granularity). "
==============
OK, so the gloss says that we can divide water and still get water --
down to a point (the individual molecule, I suppose). SO I looked
through the OpenCyc predicate lists for assertions or axioms
that say the same thing in logical form, and couldn't find any.
Question 2:
I suppose they are there somewhere, can any Cyclist point out
the axioms I can't find? Where does it say what the temporal or
spatial grain of water is? If this information isn't available
in OpenCyc, are the Type metaclasses of any use? Can't the
same information be included with the necessary relations
on instances of Water? Suppose I want to assert that the
spatial grain size for water is 3nm in each direction.
Where does that go? What happens when you subdivide a
piece of water that is just at the grain size? Does
the grain size depend on state -- solid/liquid/gas?
Does that have to be re-specified for each class?
=====================
Or more generally:
Where should we look to find the predicates that specify
the properties for instances of classes that are asserted
in the *documentation* to the metaclasses?
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
=============================================
StuffType
Mt : BaseKB
comment : [Def]"A collection of collections. Each instance of
StuffType is a collection that is stuff-like in at least one respect.
A collection COL is stuff-like just in case there is some sense of
'part' according to which every part of an instance of COL is itself
an instance of COL. More precisely, for a collection to be an instance
of StuffType it is sufficient that there be some spec-pred PARTPRED of
parts (that is, some predicate PARTPRED for which (genlPreds PARTPRED
parts) holds), such that if (isa OBJECT1 COL) and (PARTPRED OBJECT1
OBJECT2), then (isa OBJECT2 COL). Here are two examples. Consider
Breathing. Take an instance of that, say a ten minute long period in
which a person is breathing. Imagine some two minute snippet of that,
one of its timeSlices (a spec-pred of parts). That, too, is an
instance of Breathing. So Breathing is a StuffType, since all
timeSlices of an instance of Breathing are also instances of
Breathing. Consider Water. Take any instance of Water -- say the water
in the Pacific Ocean. Now take any portion of that water -- say a
handful of it that a person scoops up near Honolulu, one of its
physicalPortions (a spec-pred of parts). That handful is itself an
instance of Water. Hence Water is a StuffType, in virtue of the fact
that all physicalPortions of all instances Water are themselves
instances of Water. Other examples are: AbstractInformationalThing,
which is stuff-like with respect subInformation; CharacterString,
which is stuff-like with respect to #$subCharacterStrings; and List,
which is stuff-like with respect to subLists. These examples are
somewhat exceptional -- most StuffTypes are like the examples of
Breathing and Water. See ObjectType, for the contrasting notion of
being object-like."
TemporalStuffType
Mt : BaseKB
comment : [Def]"A specialization of StuffType (q.v.) whose instances
are all and only those collections that are temporally stuff-like. A
collection COL is temporally stuff-like just in case every time slice
(see timeSlices) of an instance of COL (at or above COL's temporal
graularity level; see granuleOfTemporalStuff) is itself an instance of
COL. More precisely, for a collection COL to be an instance of
TemporalStuffType it is sufficient that for any OBJ1 and OBJ2 (with
OBJ2 at or above COL's temporal granularity level), if (isa OBJ1 COL)
and (timeSlices OBJ1 OBJ2), then (isa OBJ2 COL). Consider
#$WalkingOnTwoLegs. Take an arbitrary instance WALK of this collection
(say Miss America 2000's victory walk down the runway and back); and
then take an arbitrary time-slice SUBWALK of WALK that subsumes at
least one instance of (the eOfTemporalStuff for #$WalkingOnTwoLegs)
#$TakingAStep (say her trip back from the end of the runway). SUBWALK
is itself an instance of #$WalkingOnTwoLegs. So #$WalkingOnTwoLegs is
an instance of TemporalStuffType. See TemporalObjectType for the
disjoint notion of being temporally object-like."
ExistingStuffType
Mt : BaseKB
comment : [Def]"A collection of collections, and a specialization of
TemporalStuffType. Each instance of ExistingStuffType is a collection
of things (including portions of things) which are both temporally and
spatially stufflike. Division in time or space does not destroy the
stufflike quality of the object (down to a certain granularity).
``STUFF is an instance of ExistingStuffType'' implies: a) for most
instances, OBJ, of STUFF, for any proper physical part (see the
predicate physicalParts) PART of OBJ, PART is also an instance of
STUFF. b) for all instances, OBJ, of STUFF, for most proper physical
parts PART of OBJ, PART is also an instance of STUFF. For example,
every piece of wood is temporally stufflike: if W-168 is a piece of
wood during 1996, then it's also a piece of wood for the one-minute
time-slice 9:05am 7/7/96. It's also spatially stufflike: if we take
that piece of wood W-168 and cut it in half, we have two things which
are both pieces of wood. Since every piece of wood is both temporally
and spatially stufflike, Wood is an instance of ExistingStuffType.
Other instances of ExistingStuffType include the collections
#$AppleJuice, #$IceCream, #$Diamond, #$WaxedPaper, and StriatedMuscle.
See the comment for StuffType to learn more about the distinctions
between, and the need for, these four collections: StuffType,
ObjectType, ExistingStuffType, and ExistingObjectType."
TangibleStuffCompositionType
Mt : NaivePhysicsMt
comment : [Def]"A collection of collections and a specialization of
ExistingStuffType. Instances are subcollections of PartiallyTangible
whose membership is based only on the physical and/or chemical
composition of their instances. TangibleStuffCompositionType does not
have as instances collections whose instances are determined _solely_
by the physical state they are in -- for that, see
TangibleStuffStateType. For example, the collection Water is an
instance of TangibleStuffCompositionType, as instances of Water are
all pieces of substance with the chemical composition H20. On the
other hand , the collection of all pieces of ice (i.e. (SolidFn
Water)) is not a TangibleStuffCompositionType, because membership in
that collection depends on the substance's composition _and_ on its
physical state. Further instances of TangibleStuffCompositionType are
#$Nylon, #$GasolineFuel, #$FattyTissue, #$TalcumPowder, #$Nitrogen,
and Glass. An important specialization of this collection is
#$ChemicalCompoundType."
ChemicalSubstanceType
Mt : BaseKB
comment : [Def]"A collection of collections and a specialization of
TangibleStuffCompositionType. Each instance of ChemicalSubstanceType
is a specialization of PartiallyTangible whose instances are defined
_only_ by their chemical composition -- not by their physical state or
any other property. Instances of ChemicalSubstanceType can be of two
varieties: (1) Collections whose instances are completely uniform with
each other in terms of chemical composition; this includes (a) the
chemical elements -- such as #$Carbon, #$Oxygen, and #$Hydrogen --
which are instances of ElementStuffTypeByNumberOfProtons (thus, the
latter is a specialization of ChemicalSubstanceType), and (b) chemical
compounds constituted of more than one substance chemically bonded,
e.g., Water, #$Caffeine, and #$IronOxide, which are instances of
#$ChemicalCompoundTypeByChemicalSpecies (2) Substances which have a
general chemical specification, that is, whose instances do not have
exactly the same chemical composition but fall within certain
specifications, e.g., #$DNAStuff. Note that collections that are _not_
instances of ChemicalSubstanceType include collections of substances
which have some component which is of overriding significance in some
context, so that in everyday language such substances are frequently
referred to by the name of their important component (e.g.,
"penicillin" applied to a tablet containing penicillin), but which
have significant admixtures of other substances. Thus, #$Penicillin is
an instance of ChemicalSubstanceType, but the collection of tablets
containing penicillin and including other ingredients is not. Also,
specializations of Mixture, such as #$Lemonade, are _not_ instances of
ChemicalSubstanceType, because mixtures are determined by their
physical state rather than solely by their chemical composition."