Re: SUO: Re: SUO Ballot with 2 Questions
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