[Top] [All Lists]

Re: [ontolog-forum] Ontology Project Organization:

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Jawit Kien <jawit.kien@xxxxxxxxx>
Date: Tue, 12 May 2009 10:17:18 -0500
Message-id: <9f9644bb0905120817q29efd953i2ea20fb6fff9c5c7@xxxxxxxxxxxxxx>
On Mon, May 11, 2009 at 8:03 PM, John F. Sowa <sowa@xxxxxxxxxxx> wrote:
> Pat,
> That is a hypothesis that many people have asserted, but without
> a single shred of evidence:
> PC> No, one single foundation ontology is **absolutely essential**
>  > in order to support *accurate* semantic interoperability.  Without
>  > a common standard of meaning, ambiguity and misinterpretation are
>  > inevitable.
> I agree with the second sentence, but not the first.  There is no
> implication relation of the first to the second or vice versa.
> On the contrary, there is overwhelming evidence that people manage
> to collaborate very well without anything remotely resembling a
> universal upper ontology. Interoperability is *always* task related,
> and the standards that support successful interoperability are
> always at the domain level, not the upper levels.
> Not only have people been interoperating for millennia without any
> common upper ontology, but computer systems have been interoperating
> very well since the first networks of the late 1960s and early '70s.
> Furthermore, whenever people start with an upper level, they eventually
> discard it, ignore it, or relegate it to a rarely used guideline, not
> as something central.  The evidence is overwhelming:
>  1. For Cyc, Lenat started with an upper level, but within the first
>     five years or so, he came to realize that the most important work
>     is in the microtheories, and the upper levels are of minor value.
>  2. For OntologyWorks, Bill Andersen & Co. started with an upper
>     level based on Dolce, but they discarded it in favor of special
>     domain-dependent ontologies.  And most of the current contracts
>     are coming from companies that need to make independently
>     developed databases and knowledge bases *interoperate*.
>  3. At VivoMind, we use a lot of ontologies, but we use the upper
>     levels (along the lines of my KR ontology) primarily as a set
>     of design guidelines.  All the serious inferences are in the
>     low-level contexts or microtheories.  We do use *lexical*
>     resources very strongly for relating the vocabulary:  WordNet,
>     Roget's Thesaurus, VerbNet, and several other resources.
> This list can be repeated endlessly, but all of the real work
> comes from the low-level domains.  The upper levels can be
> thrown away or ignored with almost *zero* influence on any
> practical problems.
> John    (01)

as you have said before, I think when talking about Functional
Conceptual Analysis, the distinctions that you make can be used
to induce a lattice/hierarchy.  I hope that you made an assumption,
when you said that the upper levels of an ontology can be thown away.    (02)

It seems to me, that the essence of a upper level should be that the
distinctions that are made (which implicitly define the upper level
are distinctions that must be made for almost all elements of your domain.
As I understand these distinctions, these boil down to questions that when
answered, put the element of the domain in a particular (I expect disjoint)
subset of the domain.    (03)

Saying that the upper levels can be thrown away cannot mean that the
distinctions that are made do not matter, so I assume that you mean that
these upper level distinctions can't be used as the sole antecedents
for very many inferences.    (04)

To get a feel for whether this is true, I did some research on three ontologies
available on the net, (Sowa's,  SUMO, and Cyc) and have included
the results later in this e-mail. In looking over what I found, I
think my assumption
is well founded.  Either you can't draw many conclusions from the upper
most distinctions, or you end up with a LOT of distinctions, and an unknown
number of inferences which can be made.    (05)

When I look over the distinctions, like Physical versus Abstract, I
can only come
up with a small number of inferences, and certainly nothing that I
would pay good
money to have a person answer.  It may be true that I can't touch a mathematical
formula, and that I can touch a doll accessory, but I'm not going to pay anyone
to make that specific inference on my behalf. This distinction is one I agree
the computer can record, but it can't make the distinction. And just who would
pay someone to go classify all of creation SOLELY for that distinction
so the computer can use it in inferences ?    (06)

I think very small upper-level ontologies might be useful for helping us think
about things, but not too very useful if you are expecting that they will enable
very many useful inferences by a computer.    (07)

JK    (08)

Research follows:    (09)

according to http://www.jfsowa.com/ontology/toplevel.htm
there are twelve top level  primitive categories in the Ontology that
you propose
that are the result of the distinctions you list:
1) Independent, Relative, or Mediating;
2) Physical or Abstract;
3) Continuant or Occurrent.    (010)

According to http://www.ontologyportal.org/ there is a link to the uppermost
hierarchy (at http://virtual.cvut.cz/kifb/en/toc/229.html )    (011)

1) Physical vs Abstract
1.2) Within Physical: Object vs
1.3) Within Physical: Process
2) Within Abstract:
2.1) Quantity,
2.2) Attribute,
2.3) Set or Class,
2.4) Relation
2.5) Proposition
2.6) Graph
2.7) Graph Element    (012)

This hierarchy seems to be only partially supported by the SUMO
ontology itself, as listed at
http://sigmakee.cvs.sourceforge.net/*checkout*/sigmakee/KBs/Merge.kif    (013)

I did find the top-most distinction
(partition Entity Physical Abstract)
(partition Physical Object Process)    (014)

I could not find a (partition Abstract ...) statement at all.
I don't know why partition is used for one level of the hierarchy and
then not used
for Abstract.    (015)

I did find a (disjointDecomposition Abstract Quantity Attribute
SetOrClass Relation Proposition)
and a (subclass Graph Abstract) and a (subclass GraphElement
Abstract), but no "partition"
According to the notes, I found that a partition is a disjoint
decomposition that also covers the
set, i.e.:    (016)

"A &%disjointDecomposition of a &%Class C is a set of subclasses of C
that are mutually &%disjoint."    (017)

and    (018)

"A &%partition of a class C is a set of  mutually &%disjoint classes
(a subclass partition) which covers C.  Every instance of C is an
instance of exactly one of the subclasses in the partition."    (019)

Finally, looking at Cyc,    (020)

I found a real simple drawing at
http://www.cyc.com/doc/tut/ppoint/TopLevelCollections_files/v3_document.htm    (021)

that seemed to say #$Thing is broken up into
#$Individual and #$Intangible,
and #$TemporalThing under #$Individual,
and #$Event under both #$Intangible and #$TemporalThing
and #$SetOrCollection only under #$intangible    (022)

with #$Collection, #$PartiallyTangible, #$ExistingStuffType,
and #$ExistingObjectType related in some other ways.    (023)

Looking for more detail I found:
which has the statement:
#$Thing is the universal collection : the collection which, by
definition, contains everything there is.    (024)

The "next level" under thing, I would assume is the direct
specializations of #$Thing.
I found there:    (025)

direct generalization of:
 1) #$PartiallyTangible
 2) #$Collection
 3) #$AttributeValue
 4) #$LogicalTruthUnionConstant
 5) #$CoreUnionConstant
 6) #$CoreImplementationConstant
 7) #$DirectedAcyclicPathSystem
 8) #$DirectedPathSystem
 9) #$BidirectedPathSystem
10) #$Tree-PathSystem
11) #$SimplePathSystem
12) #$ConnectedPathSystem
13) #$Semi-DirectedPathSystem
14) #$PointFinitePathSystem
15) #$PathSystem
16) #$IndeterminateTerm
17) #$TheTerm
18) #$PartiallyIntangible
19) #$HLIndexedTerm
20) #$ELNonAtomicTerm-Assertible
21) #$CycLClosedAtomicTerm
22) #$PublicConstant-DefinitionalGAFsOK
23) #$CycLNonAtomicTerm-Assertible
24) #$SubLListOfStrings
25) #$SubLSymbol
26) #$LogicalTruthImplementationConstant
27) #$CycLAtomicTerm
28) #$SubLTemplate
29) #$ELNonAtomicTerm-Askable
30) #$ProgramCondition
31) #$LogicalTruthConstant
32) #$HLVariable
33) #$SubLExpression
34) #$CycELVariableList
35) #$CycLNonAtomicTerm-Askable
36) #$Path-Generic
37) #$CycLVariable
38) #$SkolemTerm
39) #$SubLNonVariableSymbol
40) #$CycLConstant
41) #$ProposedPublicConstant-DefinitionalGAFsOK
42) #$SubLCharacter
43) #$CoreConstant
44) #$PublicConstant
45) #$ProposedPublicConstant
46) #$ProposedPublicConstant-CommentOK
47) #$SubLAtomicTerm
48) #$CycLReifiableNonAtomicTerm
49) #$ReformulationDirectionSpecification
50) #$NLTerm
51) #$SetOrCollection
52) #$CycLRepresentedTerm
53) #$ReformulatorTemplate
54) #$CycSubjectClump
55) #$MathematicalThing
56) #$PublicConstant-CommentOK
57) #$CycLRepresentedAtomicTerm
58) #$Path-Cyclic
59) #$SubLListOrAtom
60) #$CycLReifiedDenotationalTerm
61) #$SubLList
62) #$ELVariable
63) #$ReformulatorHighlyRelevantFORT
64) #$ELReifiableDenotationalTerm
65) #$CycLClosedDenotationalTerm
66) #$SkolemConstant
67) #$SubLAtom
68) #$ProposedPublicConstant-NL
69) #$CycLNonAtomicTerm-ClosedFunctor
70) #$ELNonAtomicTerm
71) #$CycLOpenDenotationalTerm
72) #$HLNonAtomicReifiedTerm
73) #$DocumentationConstant
74) #$CycLDenotationalTerm
75) #$CycLNonAtomicTerm
76) #$HLReifiedDenotationalTerm
77) #$HLExpression
78) #$CycLIndexedTerm
79) #$CycLFormula
80) #$IndexicalConcept
81) #$TestingConstant
82) #$ReformulatorIrrelevantFORT
83) #$ELExpression
84) #$CycLOpenExpression
85) #$CycLTerm
86) #$CycLExpression
87) #$CycLClosedExpression
88) #$IDObject
89) #$Intangible
90) #$SubLVariable
91) #$CycLUnreifiedReifiableNonAtomicTerm
92) #$CycLGenericRelationFormula
93) #$ProbabilisticCycLConstant
94) #$Individual
95) #$SimpleSegmentOfPath
96) #$ELFormula
97) #$HLReifiedFormula
98) #$CustomaryPathCycLConstant
99) #$TermPhrasesConstraint
100) #$CycLClosedFormula
101) #$PathSystemCycLConstant
102) #$SubLKeyword
103) #$MathematicalOrComputationalThing
104) #$CycLOpenFormula
105) #$ELTemplate
106) #$ELExpression-Assertible
107) #$CycLReifiableDenotationalTerm
108) #$CycLNonAtomicReifiedTerm
109) #$UniqueID
110) #$CycLExpression-Assertible
111) #$SubLAtomWithValue
112) #$CycLClosedNonAtomicTerm
113) #$ELExpression-Askable
114) #$NLMorphologyTerm
115) #$CycLOpenNonAtomicTerm
116) #$CycLExpression-Askable    (026)

So, unless I missed count, there are 116 different ways to
sub-classify the universal class in Cyc.
Presumably these aren't actually disjoint, but the Last Update on the
document was 12/13/02,
so I wouldn't be surprised if this has changed in the last 7 years.
I did find http://sw.opencyc.org/2009/04/07/concept/en/Thing
which seemed to have a list of "Subtypes" including doll accessories,
and double bonds, so while it claims it was updated on April 20th, I
have less confidence that it represents any kind of definitive list.    (027)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (028)

<Prev in Thread] Current Thread [Next in Thread>