SUO: Modularity and standards administration
At 12:03 2001-09-30 +0100, Austin Tate wrote:
>
> Frank, I take the main points of your e-mail and agree that modularity can
> be more of a problem where boundary issues can take more time than just
> getting with it. I do hope though that the time will be right eventually
> to break up the whole SUO into parts which can be adopted.
>
> At 10:04 29/09/01 -0400, Frank Farance wrote:
> >In the context of ICSs (implementation conformance statements), how would
> >this work with uses of the SUO standard: what standard(s) would they claim
> >conformance to?
>
> A conformance statement would be to the specific parts which are used and
> their respective "editions" (I have corrected my parlance here;-). So long
> as the engineering aspects are mot lost at this stage, putting everything
> in to a single bag may be okay. But where clear "real upper" ontology
> elements can be established we should separate them from all the
> refinements and instance I can see in the SUO to date - many of which I
> treat as outer and irrelevant to many applications - but not of course to
> those that need those specific items.
Austin-
You statement:
A conformance statement would be to the specific parts which are used and their respective "editions"
is exactly right. OK, so now lets look at some of the problems associated with this.
Let's say that we have a standard IEEE Std 2345-2001 (<-- "Std" means "approved standard", "2345" is the standard number, and "2001" is the edition). Let's say that this standard is organized as:
IEEE Std 2345-2001
Clause 1, Scope and Purpose (<-- wording comes from PAR)
Clause 2, Normative References
Clause 3, Definitions
Clause 4, Conformance
Clause 5, Topic #1 (<-- e.g., architecture/conceptual model)
Clause 6, Topic #2 (<-- e.g., some foundational, normative wording)
Clause 7, Topic #3
Clause 8, Topic #4
... and so on
Annex A, Bibliography
Annex B, Topic #A1 (<-- e.g., informative annex on "Rationale")
Annex C, Topic #A2 (<-- e.g., normative annex on Binding #1)
Annex D, Topic #A3 (<-- e.g., normative annex on Binding #2)
Annex E, Topic #A4 (<-- e.g., informative annex on "Examples")
... and so on
FYI, "normative wording" contains the requirements of the standard (e.g., "assertions") and "informative wording" is helpful text, such as notes, footnotes, and annexes (some annexes may be normative, some may be informative).
As you can see, the document organization above is familiar and easy to use. One way of incorporating updates might be:
IEEE Std 2345-2001 (<-- original standard)
IEEE Std 2345A-2002 (<-- amendment in early 2002)
IEEE Std 2345B-2002 (<-- amendment in late 2002)
IEEE Std 2345C-2003 (<-- ammedment in 2003)
IEEE Std 2345D-2004 (<-- ammedment in early 2004)
IEEE Std 2345E-2004 (<-- ammedment in late 2004)
IEEE Std 2345-2005 (<-- next revision in 2005)
This would allow reasonably frequent updates, e.g., adding in more axioms as they became standardized. Note that my timeline above is arbitrary -- just for illustration purposes.
Some advantages to using amendments:
- When you "purchase" (read: download) the standard from IEEE, you get all the amendments.
- This makes referencing and using the standard easy:
- "IEEE Std 2345, latest edition" <-- refers to all the amendments
- "IEEE Std 2345-2001" <-- refers to the original standard
- "IEEE Std 2345C-2003" <-- refers to original and A-C amendments
- "IEEE Std 2345C" <-- same as above, assuming no later edition
- This kind of referencing reflects many engineering and business realities: knowing that your implementation conforms/conformed to a particular edition of the standard (including certain amendments).
In case it wasn't clear from my previous E-mail, this kind of statement "Conforms to IEEE Std 2345-2001" when attached to an "implementation" (of a standard, e.g., a system) is known as an "Implementation Conformance Statement" (ICS). For users, vendors, institutions, etc., it is important to write thes ICSs precisely.
So amendments and revisions are well-used, well-understood techniques for rolling out new/improved standards wordking, as it becomes stable.
Amendments also have the advantage of prioritizing our work: completing work that is ready now.
Another organizational technique is "multipart" standards. In the example above, we might choose to break the standard into several "parts" ("part" is a standards term):
IEEE Std 2345.1-2001
Clause 1, Scope and Purpose (<-- wording comes from PAR for 2345.1)
Clause 2, Normative References
Clause 3, Definitions
Clause 4, Conformance
Clause 5, Topic #1 (<-- e.g., architecture/conceptual model)
IEEE Std 2345.2-2001
Clause 1, Scope and Purpose (<-- wording comes from PAR for 2345.2)
Clause 2, Normative References
Clause 3, Definitions
Clause 4, Conformance
Clause 5, Topic #2 (<-- e.g., some foundational, normative wording)
IEEE Std 2345.3-2001
Clause 1, Scope and Purpose (<-- wording comes from PAR for 2345.3)
Clause 2, Normative References
Clause 3, Definitions
Clause 4, Conformance
Clause 5, Topic #3
IEEE Std 2345.4-2001
Clause 1, Scope and Purpose (<-- wording comes from PAR for 2345.4)
Clause 2, Normative References
Clause 3, Definitions
Clause 4, Conformance
Clause 5, Topic #4
IEEE Std 2345.5-2001
Clause 1, Scope and Purpose (<-- wording comes from PAR for 2345.5)
Clause 2, Normative References
Clause 3, Definitions
Clause 4, Conformance
Annex A, Bibliography
Annex B, Topic #A1 (<-- e.g., informative annex on "Rationale")
Annex C, Topic #A2 (<-- e.g., normative annex on Binding #1)
Annex D, Topic #A3 (<-- e.g., normative annex on Binding #2)
Annex E, Topic #A4 (<-- e.g., informative annex on "Examples")
... and so on
As you can see, this adds a lot of work. Multipart standards **can** be very useful (Matthew West can tell you about his experience in TC184/SC4; I've developed many multipart standards).
However, anyone who has worked with multipart standards will tell you that the work requires much much careful coordination and planning. In other words, multipart standards are created/grow because there is a higher-level design/vision/architecture that is well-understood by participants (e.g., written down and agreed upon).
From an IEEE perspective (not too different than other standards development organizations), you'll need to create the following "adminstrative features":
- A separate PAR would need to be created for each part
- A separate ballot group is required for each part
- The new PARs would need to check the box on "coordination required" ... this means that although the work can proceed in parallel, the drafts and changes must be carefully coordinated in terms of edits and ballots
The last bullet ("coordination required") is a real schedule killer.
And from the perspective of users, vendors, institutions, etc., their ICSs will look like:
Conforms to IEEE Std 2345.1-2001, IEEE Std 2345.2-2002, IEEE Std 2345.5-2001, ...
Which can be error-prone and confusing. However, the real downside to multipart standards is the "administrative features" above. Without any clear sense of partitioning (that we can all agree upon), I see no reason to take on more administrative work.
In conclusion, any of these structures could be used: single part, single part with amendments, multipart. The multipart is the hardest to administer.
I firmly believe that it is too early to be making decisions on multipart standards or amendments. We should make more progress on the work (SUMO, IFF, and future documents) before we create new administrative structures.
Regarding "modularity", the real problem seems to be consistency and coherency ... "modularity" (as described by John Sowa) is just an approach to solving that problem. As I've said, I believe a "criteria" paper and a "conformance clause" would be a better approach towards consistency and coherency problems.
-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