RE: SUO: Re: SUO Ballot with 2 Questions
Dear Pierre,
See responses below.
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 16:36
> To: West, Matthew R SITI-ITPSIE
> Cc: standard-upper-ontology@ieee.org
> Subject: RE: SUO: Re: SUO Ballot with 2 Questions
>
>
> Dear Matthew,
>
> I snipped a lot, hope the comments still cover most of your
> questions.
> Pierre
>
> > > > Am I missing something?
> > >
> > > Yes, so it seems to me. The environment for managing the
> > > content should be
> > > informed by the content.
> >
> > MW: What do you mean here by "informed by the content"?
>
> A structure used to manage the content emerges from the
> content, it is tailored
> a posteriori.
MW: I'm surprised you think this can only be done a posteriori.
let us consider what can be done a priori.
1. The content of an ontology (or module) will be concepts and
axioms. The axioms may be further analyzed into functions and
arguments. Some arguments may be variables, and there may be
quantification. A suitable data model can be constructed for this
(a meta model for KIF or CL effectively - though you could also
hold KIF fragments).
2. For each concept/axiom we will want to be able to hold its origin,
author, date of inclusion, date of retirement and perhaps a number
of other pieces of essentially management/admin data.
3. We need to be able to hold grouping data that shows what sets of
concepts are part of what ontology, including dependencies.
This is what a register can do for you. You can of course do lots
of other things a posteriori, but I would see these as analysis of
content that would result in "modification" of register contents.
>
> > > We have to extract content (eventually from structured
> > > sources and we could use
> > > SUMO and OpneCyc browsers if that is an environment in your
> > > sense, but this is
> > > more or less anecdotal since proposers of canfidate standards
> > > are asked to
> > > produce flat files which to date are hardly structured).
> >
> > MW: Quite. Getting away from flat files as the medium in which
> > the ontologies are managed is one of the things I think a Registry
> > is about.
>
> This format has been requested by this group (Adam in any
> event requested that
> John D endure the same kind of dump-your-data-into-a-file
> exercise he had to go
> over himself). If you are not happy with this, then you
> change the behavior of
> this group and ask proposers to parse their files into the
> variety of topics
> which constitute the fundamental elements of a UO and this is
> more than enough.
> But then make the list first. That's partly what I'm asking for.
MW: When you say "fundamental elements" do you mean e.g. a CL
metamodel? If so, this is exactly what would be implied by adopting
a registry type solution.
> But in any event this would seem sort of strange to me. I'm
> leery about
> comparing modules which have been abstracted from the rest of
> the theory they
> are integral parts of.
MW: Me too. For me a module has dependencies on at least some other
modules, and cannot just be taken in isolation, but may also be
independent of some other modules.
>
> > > The content we will care for will have to be structured in an
> > > environment
> > > eventually.
> >
> > MW: Why only when we have some content we decide we like? Why not
> > use structured methods to help us sort the alternatives and compare
> > them?
>
> Motion two proposes to turn possible means to reach the goal
> of this group
> (based on methods supported by a portion of this group) into
> its new goal.
MW: Only a goal, or even subgoal.
>
> > Does that have to be made harder than is necessary?
>
> This is a question I asked in the first place. Why would we
> have to spend
> months if not longer dissecting and re-gluing two legacy
> ontologies before we
> start wondering about their merits? How will that make the job easier?
MW: Well that is like asking whether you would rather dig a large hole
with spades or a JCB. I believe we have a large task in front of us, and
that it is not practical without good tools. If that means we have to
spend some time investing in tools, then so be it. We will get there
faster in the end.
>
> > MW: The difference between us seems to be the start point. I would
> > argue for a start point that includes assessing and comparing the
> > source material (or authoring it for that matter). You seem to want
> > to restrict things to that which is "blessed".
>
> First sentence might be part of the truth. Second sentence
> express something we
> have in common. Forget about third, unless by blessing you
> mean voting (why are
> we voting otherwise?).
MW: I did mean voting.
>
> In my understanding, our divergence comes from the fact that
> I consider the
> sources as supports and raw material candidates for re-use.
> The main starting
> point in my opinion is philosophical analysis.
MW: I would always want to leave room for this.
>
> It seems to me that the order of importance is reversed in
> your approach. You
> (and John Sowa) seem to say: we start from legacy ontologies
> and we will surely
> be able to come up with something better but which benefits
> from the years of
> experience of these bright people who have created these things.
MW: This is also important. A problem with many new computer
systems is that they do well what the old system did not do at
all, but do not do well what the old system did do well. Or to
put it another way, we want to avoid throwing out the baby with
the bathwater.
>
> OpenCyc might have started in the heroic way John Sowa
> describes in another
> email. To me anything which attempts to make me believe that
> OpenCyc is better
> than anything else based on whatever heroic history it has is
> marketing and
> bullshit. Cyc has been more shaped by idiomatic intuitions
> and implementation
> constraints than anything else. Maybe this didn't prevent it
> from being
> successful, not sure it is a good piece of UO. SUMO is the
> refined product of a
> garbage collection and frenetic merging. Maybe the recycling
> process was
> efficient, I don't know for sure.
MW: I think both these ontologies have architectural problems
that arise from the way they have been developed, and would
benefit from re-working. I think the best way to achieve this
is to place them in an environment where the architectual
deficiencies become clear, rather than expecting the authors
to just take my word for it.
>
> I don't like the prospect of refining refined product which
> have been polutted
> over the years by the contingency of the moment. And you
> don't need to take a
> look at OpenCyc and SUMO to know that there is a potential
> conflict between 3d
> and 4d. It is interesting to look at OpenCyc and SUMO to see how these
> conflicts can be resolved and if they were. You may get
> valuable information
> from Cyc on how we could get both things living together
> assuming a modular
> structure for instance, but even this is a stretch. The truth
> is that legacy
> ontologies will give you few more than dipshit insight in
> what you need for a
> UO and mostly negatively (through their inconsistencies). If
> you add to that
> that you will need to add to your registry any this or that
> ontology in order
> to imporve the diversity and the breadth of your horizon, you
> end up with an
> endless toying in the mud.
> teil1
>
MW: Well I certainly think that since these are amongst the best
ontologies we have available today, it says somthing of how far
we have to go ... But this is just another reason for girding
our loins to do the job properly.