SUO: Opposition to Motion
[Sorry for the somewhat long respnse. I decided to add to general comments on the standards development process, which I hope you find useful. -FF]
At 02:17 2001-07-22 -0700, Robert Grayson Spillers wrote:
>
> As you know Jim Schoening has proposed a motion to accept the document called SUMO ( Standard Upper Merged Ontology?) as an official document of the SUO Working Group with the stated intent that this document will be developed into the final SUO document.
Actually, Jim is "stating the question" according to RONR (Robert's Rules of Order Newly Revised), not making the motion. I believe the motion was proposed by Ian Niles and seconded by Robert Bordogna. Also, the E-mail letter ballot contains other information, such as the ballot close date, etc., which are not part of the motion.
> I oppose this motion for a variety of reasons among them that this is a seriously flawed intellectual approach and is unsuited for most commercial purposes. It also duplicates a currently available commercial implementation that uses a similar approach, and has similar problems, but the commercial product is much better engineered. (It is available without fee but with restrictions that will cause many potential users to decline.) Neither the commercial product, Cyc, nor Teknowledge's SUMO is suitable for a standard. I will recap these reasons in a separate note but they were discussed extensively when TeKnowledge last offered this motion.
FYI, I am not addressing the technical content of the motion, I am only commenting on your response.
On 2001-07-06 in the SUO P&P committee, which you chair, I reminded the committee (if they didn't know already) that standards participation is considered "work for hire" under the Copyright Act, i.e., IEEE owns the copyright of our work. So this contribution, if adopted, will belong to SUO WG and not its original submitters. In other words, whether or not Cyc, Teknowledge, etc., charge fees for their products is of no consequence to IEEE: if SUO WG adopts this work, then the contribution is controlled/developed by the SUO WG (operating under the Computer Society and IEEE Standards Association).
We are all individuals in the IEEE, so our company affiliations (from an IEEE P&P) aren't significant, i.e., Teknowledge can't make a motion, but an individual can (who has no requirements to represent their employer/organization).
> This motion creates a privileged position for a particular work in progress that is inappropriate and unnecessary. For reasons that are very murky, Teknowledge wishes to have exclusivity. This is not just one of many approaches that might in the future be developed into something more acceptable than its current status. I quote from Jim's motion
> ...
This is not "exclusivity". Simply put, it is volunteers (Robert Kent, Ian Niles, anyone else) putting forward work in a volunteer organization (IEEE Standards Association, Computer Society) for the purposes a making a technical contribution for the development of a technical standard (that's what we do in IEEE Standards Association). If the document is accepted by our SUO WG, then it belongs to the SUO WG and the SUO WG is responsible for editing, improving, merging, aligning, harmonizing, etc., with other documents and proposals from the SUO WG. This topic has all be discussed previously in the SUO P&P committee.
Regarding the "murkiness" of intent, I think you need to check yourself: it is normal in standard committees for volunteers to make contributions of for further development of the committee's work (otherwise, where would the standards come from?). So the real "murkiness" might be: why do you question activity that is normal in a standards committee? I can see that you have technical objections, but your comments should focus on these technical objections (and possibly convincing others of your position).
-------------
[On a related point of contributions and editing ...]
At some point, we (SUO WG) will need a Technical Editor to manage the editing tasks. In the SUO P&P committee, there was discussion about the role of Technical Editor and whether or not one was required for each "base document" (i.e., what Ian is proposing now). The following are the highlights from that discussion in the SUO P&P committee (around 2001-07-03):
- We only need one official Technical Editor because the SUO WG will produce only one "document" (standard) because we only have one project outstanding, as defined in the IEEE PAR (Project Authorization Request). Currently the SUO WG believes, for the time being, that this is all that is necessary, although additional PARs may be proposed. Of course, the Technical Editor may have as many helpers as necessary to complete the editing work.
- There may be submission of multiple base documents, refinements, additional wordings, etc., which may proceed as independent tasks. For example, there will be a Definitions Clause (usually Clause 3) that is comprised of terms and definitions that are important to the normative wording (i.e., technical requirements; in contrast to informative wording) of the standard. We may receive several base documents: some on terminology alone (i.e., only adds to Definitions Clause) and some with terminology and other standards wording (i.e., adds to Definitions Clause and other Clauses/Annexes).
- Looking at this from the perspective of these base documents: some participants may be involved in the refinement/wording polish, and some participants may only be involved for a short time ... and more importantly, that might be all that is necessary for the editing tasks. In a typical standards committees that meet face-to-face, if the committee adopts several base documents X, Y, and Z, then they give the three documents to the Technical Editor for incorporation into the standard that is being developed (normal standards committee operation). I mention face-to-face meetings only because the physical gesture of handing documents to the Technical Editor makes the editing process fairly obvious -- in contrast to a electronic-only forum like our E-mail reflector and web site where these kind of gestures may be harder to convey to those participants who are new to standards development.
- Depending upon the size and nature of the contributions, the Technical Editor (who is directed by the WG and also is the "default owner" of action items relating to the draft itself) may request some editing help to smoothly incorporate/integrate these new contributions. Also, many times participants with a particular interest in these newly adopted contributions may offer editing help to the technical editor.
- IMPORTANT: As participants, we really need to support the Technical Editor when he/she requests our assistance.
- The adoption and incorporation of a base document becomes an action item for a Technical Editor, not a longstanding committee/group -- and not an action item for the original submitters.
- [In the SUO P&P, it was proposed that base document contributions have a "five-person minimum", but this is not required because adopted work now belongs to the SUO WG, not the original submitter. This comment is relative to that discussion.] We should not impose a five-person minimum on every action item for the Technical Editor. In many cases, 1-2 people may only be interested in participation (e.g., locating specific ISO or IEEE terminology for a Definitions Clause), but that level of volunteer help may be all that is necessary ... mandating a minimum of 5 people for a task that only requires 1-2 doesn't help anyone. Some wording, such as the Conformance Clause, is likely to be contentious and involve/require almost all SUO participants.
- Regardless, the SUO WG reviews and approves the document ... there are enough checks and balances within the system to make it efficient (e.g., not every task requires the whole SUO WG to participate ... a subset as small as one individual may handle tasks) and to make it representative of the SUO WG consensus (e.g., the standards wording requires SUO WG approval regardless of how many or how few handle tasks).
> "Should the IEEE P1600.1 Standard Upper Ontology Working Group commence work on the Suggested Upper merged Ontology (SUMO) version 1.15 [June 22, 2001] posted at http://suo.ieee.org/Merge.txt, with the intent of
> developing it into the final SUO document?
> Note 1: See background information below for more details.
> Note 2: This may be one of several candidate documents to be combined and aligned into the final SUO document via the consensus building process."
> The SUMO is to be the exclusive approach that might accept other contributions if they are able to be merged with it. Consensus is left undefined. However the IEEE does not leave it undefined.
Bob, this is one of the places where the SUO P&P committee worked on suggested refinements, so I'm puzzled why you are objecting to this wording. The above note:
This may be one of several candidate documents to be combined and aligned into the final SUO document via the consensus building process.
was a direct result of suggestions, compromise, and refinement within the SUO P&P committee.
> "Consensus means agreement among the majority. It does not mean unanimity. A balloting group does not need to achieve 100% approval, or even 95% or 90%. According to the IEEE rules, consensus is defined as a minimum 75% return of ballots from the balloting group, and a 75% approval rate from that 75% return group. If this is reached, then consensus has been achieved according to the IEEE definition."
Here you are missing the distinction between "consensus" (which you've accurately described) and the "consensus-building process". The "consensus-building process", also known as "standards development" or the "standards development process", is how we (SUO WG) work towards our final goal of "consensus". Each committee has their own "consensus-building" (development) strategies, which may vary from technology to technology, and may vary over time. There are a good number of "best practices" for standards committees. We're using several of them now:
- A strategy for standards development: developing initial (base) documents; incremental improvement through refinements/proposals; do Workding Draft ballots within the WG (not formal sponsor ballots) to build more consensus; submit for sponsor ballot after significant consensus (60-80%) around the Working Draft ballots.
- Another strategy for standards development: expect contributions from multiple sources; liaise with related activities; may help more stakeholders approve documents.
- Yet another strategy for standards development: write a rationale that explains some of the major decisions; this saves time in the future so newcomers don't have to revisit old arguments.
The "consensus-building process" or "standards development" in its minimalist form is the IEEE, IEEE-SA, CS SAB, etc., P&Ps (processes and procedures). Comparing two hypothetical standards committees:
Committee to develop a standard glossary:
- Process and Procedure: IEEE, IEEE-SA, CS SAB
- Development strategies: the three listed above
- Additional domain-specific development strategies
- On document development: multiple submissions, each consisting of a few terms
- On establishing incremental approval: voting on a few terms at a time
Committee to develop a standard network protocol:
- Process and Procedure: IEEE, IEEE-SA, CS SAB
- Development strategies: the three listed above
- Additional domain-specific development strategies
- On document development: separation into layering, functionality, services, etc.
- On establishing incremental approval: voting on complete protocol specifications with increasingly more functionality
In other words, we already are using some "best practices" for the consensus-building process and we will use more as the SUO WG work progresses.
The discussion recently between John Sowa and Adam Pease is along these lines of consensus-building strategies.
> In addition to achieving consensus the IEEE advises:
> "Lesson Learned: Just because you have over 75% approval doesn't mean you should automatically submit a standard for approval. Making sure the technical comments have been addressed is the most important issue, not just achieving 75% approval. "
Yes, I agree. I believe Jim Schoening did an excellent job of processing (asking the committee to address) all the technical comments in recent ballots. This process is known as "ballot resolution" and it helps build consensus.
> ...
> In the motion Jim states
>
> "The wording of this ballot was developed and reviewed by the SUO Policies & Procedures Subgroup."
>
> Individual members of the P&P did contribute to the wording of the motion. No vote was taken and no formal approval sought or given. Sub-committees may not make or approve motions. Sub-committees may only make reports and recommendations. No report or recommendation of any type was voted or adopted.
Jim (the chair of SUO WG, and SUO WG is the parent of the SUO P&P committee) suggested that the SUO P&P committee review a potential motion for the SUO WG. The purpose of Jim's request was to have P&P discussion in the SUO P&P committee and to not take up E-mail "bandwidth" on the main SUO WG E-mail reflector.
The wording was developed and reviewed by the SUO P&P committee. We all made compromises and suggested improvements to Jim, who passed them on to Ian Niles and/or Robert Kent, the proposer of the motion. Although the SUO P&P committee did not *approve* the motion per se, no approval was required: it is Ian that is making the motion and he and Robert sought advice on how to properly present the motion to the SUO WG. Ian and/or Robert contacted Jim and asked for advice (as reported by Jim). Jim, on behalf of Ian and/or Robert, asked the SUO P&P committee for advice on the proper wording. You (Bob) chaired the committee and I think all of us contributed to the advice to Ian and/or Robert.
So I believe Jim's statement still stands:
The wording of this ballot was developed [yes, we (P&P) improved it] and reviewed [yes, reviewed, but we did not take a vote on appoval] by the SUO P&P Subgroup
-FF
-----------------------------------------------------------------------
Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605
mailto:frank@farance.com http://farance.com
Standards, products, services for the Global Information Infrastructure