Re: SUO: Vote on Merged Ontology as a 'Base Document' for SUO WG
Teh suggestions by Frank McCabe, below, are excellent. I'm especially
in favor of collecting use-case scenarios. It may be equally difficult
to reach consensus on which one or more scenarios to start with -- but
I think this will serve to ground the exercise.
Some may object that if we design the SUO with specific use-cases in
mind, it may be too purpose-specific, and not general. This may be true
to some extent, but must be balanced against building an SUO that is not
useful for ANY purpose.
Mike
----
From owner-standard-upper-ontology@ieee.org Fri Jan 19 10:02:28 2001
Date: Fri, 19 Jan 2001 09:59:00 -0800
From: "Francis G. McCabe" <fgm@fla.fujitsu.com>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17 i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: "Schoening, James R CECOM DCSC4I" <James.Schoening@mail1.monmouth.army.mil>
CC: "Standard-Upper-Ontology (E-mail)" <standard-upper-ontology@ieee.org>
Subject: Re: SUO: Vote on Merged Ontology as a 'Base Document' for SUO WG
Content-Transfer-Encoding: 7bit
X-Resent-To: Multiple Recipients <standard-upper-ontology@majordomo.ieee.org>
X-Listname: standard-upper-ontology
X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org
X-Moderator-Address: standard-upper-ontology-approval@majordomo.ieee.org
I vote NO
Nothwithstanding some of the rather ad-hominem attacks about this matter, I feel
that I must also vote no on this question. Below are some of my reasons:
1. Without following all of Pat's arguments, I agree with the gist of them.
2. Ignoring the logical foundations, the engineering issues do not come close to
being resolved either. By this I mean primarily the issues of scale and
componentization. A document that is already >1000 lines long, which is not
properly structured with well defined interfaces is simply not going to survive
when we need 100K lines.
3. The process by which an agreed specification arises does NOT need to follow
the route of a `piece of grit' from which oysters come; otherwise known as
`programming by debugging the null program'. There are alternatives.
To quote some techniques that I have used:
1. develop use case scenarios
2. develop and focus on key abstractions; to be followed by a reification later
3. brainstorm + gradual crystalization of consensus.
4. At this time I would argue for (a) more concern about engineering issues, (b)
less focus on the concrete and more on the key abstractions. (This is NOT a
contradiction)
However, it is clear that direction is sorely needed: we dont have time for
another 3K years of philosophical debate.
Frank McCabe