RE: SUO: Re: SUO Ballot with 2 Questions
Dear Pierre,
So you think content is what is important, and it is so important
you are adamant that we should not use an environment to manage it?
Am I missing something?
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
> -----Original Message-----
> From: Pierre Grenon [mailto:pierre.grenon@ifomis.uni-leipzig.de]
> Sent: 05 June 2003 10:24
> To: John F. Sowa
> Cc: standard-upper-ontology@ieee.org
> Subject: 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á*
>