Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: SUO: Re: SUO Ballot with 2 Questions




John,

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. 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. 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. 

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.

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. 

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.

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. 

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.

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. 

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. 

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. 

Best,
Pierre

> Eric,
> 
> If we could really get everyone to agree, I would be
> willing to withdraw motion #2 in favor of a new motion.
> Following are my major concerns:
> 
>   1. Modularity and extensibility are essential.
> 
>   2. A methodology of the kind that IFF provides
>      (but not necessary the full IFF theory) must
>      be available to relate and combine the modules.
> 
>   3. SUMO and OpenCyc are partners on an equal
>      footing (i.e., no special motion for SUMO
>      that makes it different from OpenCyc).
> 
>   4. Other projects, such as the ones on Bateman's
>      list, should be able to join the coaltion if
>      and when they wish to do so.
> 
>   5. A privileged upper ontology as a "reference
>      model" could be admitted as a desirable goal,
>      but the framework should accommodate legacy
>      systems and pragmatic alternatives that are
>      not 100% compatible with the reference model.
> 
>   6. I find Matthew West's arguments in favor of
>      a registry compelling.  I cannot see any
>      reason for not having a registry or something
>      like it.  But if the word "registry" is an
>      obstacle to agreement, I would be happy to call
>      it anything else -- provided it supports the
>      functions that Matthew believes it should.
> 
> As far as I can see, these six points are compatible
> with the current wording of motion #2, but if anybody
> finds it important to adopt different names for the
> same functions, I don't really care.
> 
> John
> 
> 
1(