Re: SUO: single vs. multiple ontology standard: modularization?
In this line, the term "modularization" has
been used, but I am unclear as to its intention.
In programming, modules in general are not
inconsistent with each other. One simply doesn't
have to use all of them. Certainly the SUO
can have "modules" that can be used or ignored at
will, even though *none* are inconsistent with
any other. A manufacturing ontology won't
usually need the biochemistry or medical "module",
and if they are sufficiently independent, they may
be excluded from a working manufacturing ontology
and then added later if they are needed, without
causing any inconsistencies. This will still
give us the interoperability that is one of
the prime goals of having any standard. I think
that Adam's point about CYC can also be
interpreted as meaning that the "microtheories"
are mostly "modules" in this sense.
We will also need some mechanism to handle
inconsistent theories, possible worlds, fictional
contexts, etc. But this is very different
from the usual use of "modules" in programming.
A "lattice of theories" seems to be the more
appropriate term for this mechanism.
Are we all using the same terminology?
Pat Cassidy
=========================
John.Velman@HSC.com wrote:
>
> John,
>
> See my note following quoted stuff -
>
> John Sowa wrote:
>
>>Pat,
>>
>>Perhaps that is a good reason for reconsidering the vote on SUMO.
>>
>>Pat Hayes wrote:
>>
>>JS>Bottom line: There is simply no reason to separate the two
>>
>>>>efforts, as Adam has suggested. The best approach is to
>>>>combine them.
>>>>
>>PH> Well, there *is* a reason, though it is managerial rather than
>>
>>>technical. Adam is in control of the SUMO effort, this being done at
>>>Teknowledge under his direct management; and Adam is quite unwilling
>>>to either adopt any other methodology or to work in cooperation with
>>>anyone who is using one. He is also, it seems, incapable of
>>>understanding the issues that motivate those who are inclined towards
>>>a modular approach, which does not inspire a great deal of confidence
>>>in anyone who might be inclined to work with him. Taken together,
>>>these seems to me to amount to an insurmountable barrier to a
>>>combined effort, as indeed Adam has himself suggested.
>>>
>>Since you and I both voted against making SUMO a candidate for an
>>SUO standard, we seem to be disqualified from submitting a motion
>>to reconsider the vote on SUMO.
>>
>>However, I voted in favor of IFF. Perhaps if somebody who voted
>>in favor of SUMO as a candidate standard wanted to submit a motion
>>to reconsider SUMO, I would be willing to submit a motion to
>>reconsider IFF. Then we could jointly propose a new candidate
>>project along the following lines:
>>
>>1. Adopt the current SUMO ontology as a resource.
>>
>>2. Adopt whatever Cycorp decides to contribute as a resource
>> (provided that Cycorp releases it under a license that is
>> appropriate to the bylaws of the IEEE procedures for standards).
>>
>>3. Adopt IFF as a resource.
>>
>>4. Modularize whatever is appropriate from #1 and #2 into a
>> collection of starting modules and adopt whatever is
>> appropriate from #3 as a basis for developing a methodology
>> for organizing and combining modules along the lines that
>> have been discussed on SUO list.
>>
>>John Sowa
>>
>
> I don't qualify, since I abstained on SUMO (and voted for IFF).
>
> But,
>
> As I understand the rules of the game, those of us who believe in
> modularization could work on this plan without overturning anything. SUMO
> as of the ballot edition is already a resource for SUO, as is IFF, as of
> it's ballot edition.
>
> This sounds like a good approach. What it needs is a leader and a little
> (understatement!) planning. I think it could garner a group of workers.
>
> --
> A true story that may not be relevant, but is a parallel in some respects.
> Stop reading now if you want.
>
> Once many years ago I had the job of calculating a bunch of parameters
> based on certain geographic location (relative to the Clarke ellipsoid
> of 1866 -- it wasn't that long ago, but that was the earth model we used).
> I filled a notebook with calculations using a Friden calculator and a book
> of 8 place trig tables.
>
> Just after I finished, the project moved the primary geographic reference
> spot. So I swore I'd never calculate with a desk calculator again. I got a
> Fortran II manual and wrote a massive program following exactly the same
> steps I had used in the previous calculations. This turned out to be
> impossible (for me) to get running and validated.
>
> So, I modularized. I wrote lots of little programs (and their inverses,
> which helped with the validation). This took less time and was successful.
> Not only that, it was easy to add capabilities when other requirements
> changed.
>
> ---
>
> Best,
>
> John V.
>
>
>
--
=============================================
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
=============================================