Re: SUO: Re: SUO Ballot with 2 Questions
The problem comes from bringing in this ludicrous idea of a register for the
sake of it. If all we need is a catalog of existing ontologies, we take
Bateman's page or similar resources and we vote on taking whatever it names as
raw material sources.
But we need to know what actually is inside a system, not how they are
marketed. We will not need to parse each systems into modules and expect that a
structured hierarchy will emerge from clear water. The modular structure of Cyc
was not motivated for accomodating a variety of UOs. Cyc has one upper-level
ontology, not ten. With respect to the conetnt, the microtheories we shall find
there are not necessarily relevant to SUO.
You seem again to agree that we need to know what we are looking for. In the
mean time you don't seem to be able to leave on the side your love for the
lattice of theory (who knows that there would be a lattice anyway in the case
of SUO?) Building a lattice of theories is a decent goal when you want to build
a lattice of theories. It is nearly absurd to start with this intend when all
you want is to factor out material which will partake in the construction of a
SUO. That we will actually need a modular structure is a gratuitous claim, and
I think in the first place an implementation issue, irrelevant imho.
The problem again is methodological. You are putting the cart in front of the
ox.
0) don't confuse my theoretical leanings towards modularity with my views on
how a sound process should shape the construction of a SUO (whatever the form
it takes)
1) registry is ludicrous
2) registry is a baneful and not only a waste of time, it puts the issue of
content in the background, but content is the only thing which should drive the
SUO effort.
3) registry based on SUMO and Opencyc is dangerous for both of them taken
together are not representative.
4) yes, the issue is re-use. We need to know what kind of things we want and
come up with it. If some of the things we want are in the SUMO or OpenCyc, take
them from here. Otherwise take them from somewhere else, otherwise, do it
yourself.
I am agaisnt a SUO which would be ad hoc in its content because we had to:
1) make room for SUMO
2) make room for OpenCyc
and ad hoc in its structure because we had to:
3) use IFF
4) make your infinite lattice leitmotiv part of the catechism
I hope this gives a better idea of where is the problem.
Pierre
> Pierre,
>
> I have no idea what you are complaining about. Everything
> you are asking for is supported by motion #2 in very much
> the way you suggest it should be.
>
> > I find this move more reasonable but I still have some same grave reserves.
> > What bother me the most is that you take an a priori stance on the
modularity
> > and extensibility which I would fully support if the purpose was to create
an
> > organized lattice of ontologies.
>
> Why would anybody object to modularity and extensibility?
> Every large software system is modular, and the more modular
> they are, the easier they are to debug, test, maintain,
> and extend.
>
> And just look at Cyc. It was originally developed as
> a monolithic theory, but around 1991 -- seven years after
> the project began, they subdivided it into microtheories.
> That was necessary to simplify development, testing,
> debugging, and maintenance.
>
> And certainly, motion #2 supports an organized lattice.
> I did not include a requirement that every step of the
> development must be a lattice because the modules will be
> added one at a time, and the intermediate steps are not
> likely to preserve the full lattice operations at every
> stage. But in any case, IFF does support a full lattice.
>
> > Moreover, you make this claim when dealing
> > with two idiomatic bodies of theory but your claim remain theoretical and
never
> > rooted in the actual content of these bodies.
>
> What claim remains theoretical? Do you mean the claim
> that both SUMO and OpenCyc have modules? That is what
> they have said. There is some hierarchy in them,
> but I agree that it is not a full lattice. So what?
>
> > I think that we cannot start with
> > formal requirements before we have examined the raw materials. But also, I
> > think we should use the raw material to create another monster, not to
build a
> > niche for both of them.
>
> Of course, we must examine the raw materials.
> In order to get from A to B, you must create niches for
> A and B as well as the intermediate steps in between.
>
> And if there is old software using the old modules,
> you have to leave them in the library so that legacy
> systems can access them. That is common practice in
> operating systems (except for Windows, which creates
> "DLL hell" by deleting the old modules while older
> software still requires them).
>
> > We should do what this group once started:
> > -in the first place, isolate thematically all the components a formal
ontology
> > should present (mereology, group, agents, theory of properties, spatiality,
> > temporality, causality, and so on)
> > -and shoot for an ontology which meets our desiderata.
> > -see what happens when we have something which stands together.
>
> That's fine. That's a good way to populate the modules that
> are proposed in motion 2. It has exactly the right niches
> to support your proposal.
>
> > In this process we should be able to identify or expose all the alternative
we
> > collectively think are both incompatible and necessary and then maybe
motivate
> > modularity (this is likely to be a list of disagreement). If any such
> > incompatibility survives, this gives a rough idea of which module we should
> > consider.
>
> Yes, that's fine. That's consistent with the methodology
> supported by the IF framework.
>
> > I surmise that there will be a very small formal level and a not so broad
> > upper-level tree. Extensibility is not necessarily a matter of accomodating
> > alternative upper-level ontologies, the accomodation may be trivial in some
> > case. It is when arriving in more specific domain ontologies that we will
have
> > far reaching branching. But true enought there may be dense branching quite
> > early.
>
> This is an empirical issue to be determined by the methodology
> which motion 2 supports. Everything you want is there.
>
> > As for the legacy ontologies. Concerning their use, it is mostly a question
of
> > re-use. We will maybe not need to re-invent the wheel if we can gather
elements
> > which fit our predefined desiderata in existing ontologies. As concern the
> > integration or compliance, we will see how they fit and if they only
partially
> > fit. Having an embedding SUO will support the development of readily
tailored
> > modules.
>
> It is not just re-use. Supporting legacy software requires us
> to support methods for mapping older systems to newer systems
> for the entire period during which they continue to be used.
> And from looking at existing software, the period of co-existence
> for older software with newer software tends to be measured in
> decades. There is software in active use that is 40 years old.
>
> > To my knowledge, SUMO is good old fashion 3-d. It allows properties as
platonic
> > universals. Although I loose acquaintance with Cyc, Cyc is said to tend to
be
> > 4D, there's a shitload of 3d stuff (probably even in OpenCyc), however, and
the
> > microtheoretic stucture allows you to secure 3D anytime. It also used to be
> > platonic about properties. It has started to become nominalistic
> > (unfortunately). I am biased toward having a 3-d and a 4-d module. The
monsters
> > might fit under them in some way or another (might be tricky to make SUMO
fit
> > though, we will probably loose some of Cyc in trying to fit, unless maybe
we
> > make the microtheoretic structure part of the SUO). It is more difficult
with
> > properties, but for the least it seems that in any extension of a framework
> > which assumes a 3-d module (with some caveat) there should be a non
> > nominalistic treatment of properties. Nominalist ontologies will live
without
> > properties but OTOH some of the apparatus for similarity reasoning and
other
> > related stuff will have to be amended. And so on and so forth.
>
> Yes. These are issues that have to be considered,
> and motion #2 accommodates them.
>
> > Well, this is interesting but we will not come up with all relevant
> > distinctions by looking at SUMO and OpenCyc, and provided we make a lattice
of
> > these two theories we might simply not come up with something interesting
> > enought to stand as a SUO even in a modular form. Because some things will
be
> > too idiomatic, some of the common concepts will not be related in the same
ways
> > to other concepts, etc.
>
> Yes, I agree.
>
> > This is roughly what motivates my supporting independent vote on raw
material
> > and the refusal of putting everything at once in the same garbage can
hoping
> > that shaking long enough we will end up with a stable system of relations
> > between alleged modules about which we do not have a clear and reliable
> > knowledge nor even good intuition.
>
> I never said that we put everything in the same garbage can
> and shake. What I said is that we catalog the existing material
> and take inventory. Some modules we bless as good, and others
> we label "deprecated" or bad. But the system allows us to examine
> everything on its merits and on its ability to combine with
> everything else.
>
> > So my suggestion is indeed that you withdraw your motion (because I think
it
> > threatens the Western civilization). That you, if you want, formulate a
motion
> > which takes into account OpenCyc and SUMO, leave open the addition of
material
> > as subjected to future votes. I do not object to open the road formally to
> > modularity as a possible outcome, in the sense that I feel that this will
end
> > up modular. But on the other hand, I don't know which modules these would
be
> > and I don't even know for sure that we cannot find a good solution which
would
> > not be modular. So, I object to this notion being made a requirement for
the
> > future activity of this group.
>
> I agree with you that we don't yet know which modules would be
> used. Motion #2 proposes that we catalog what is available,
> examine what is good and not so good, determine how the pieces
> are related, and maintain an audit trail that shows how each
> of the new modules were derived from old modules or from theories
> that are documented in a reference book or research article.
>
> I cannot see anything in motion #2 that prevents you from doing
> what you say should be done, and I see a great deal that will
> help you achieve the goals you outlined.
>
> Where is the problem?
>
> John
>
>
AAAAAá*