SUO: Almost-Final Ballot Questions
At 08:00 2003-05-18 -0400, jim.s3@juno.com wrote:
>
> SUO Working Group,
>
> 1. This is not yet the actual ballot, so please don't vote yet.
>
> 2. Below are the latest versions of the motions by Adam Pease and John
> Sowa.
>
> 3. If you have additional suggested changes that will impact your vote,
> please submit them to the list or to Adam or John.
>
> 4. If both motions are ready about the same time, I will include them in
> a single email ballot, but you'll vote on each independently.
>
> 5. As stated previously, each motion will pass if YES-votes > No-votes.
> ABSTAINs are recorded but not factored into whether the motion passes.
>
> 6. The ballot, when released, will be open for 14 days.
>
> 7. The ballots will be posted to this list and also mailed directly to
> all voting members.
>
> Jim Schoening
Jim (and other SUO members)-
Sorry for my late response, but I've been trying to read through the mail.
My first comment concerns "building the hierarchy":
- As I mentioned in the past, we should use a registry-based approach for building SUO, SUOs, micro-SUOs, whatever over time. In that registry, we would store theories, micro-theories, classification schemes, blah, blah, blah. This is consistent with Matthew West's and John Velman's notion of a "posh dictionary" (see my E-mail on 2001-10-17 and followup discussion).
- Several SUO participants were at the Open Forum in 2003-01 in Santa Fe. In short, ISO/IEC 11179 (ISO Metadata Registries) could be used as an off-the-shelf technique for registering the kind of information discussed. The ISO/IEC standard is freely available -- I've put a copy at: http://farance.com/metadata/iso_iec_11179-3_2003.pdf
- Several features of 11179-3 may be used: "definition" portion (e.g., terminology-like things), "data elements", "value domains" (e.g., enumerated and non-enumerated sets of value-meaning pairs), "classification schemes" (e.g., general "relationship" facility), and so on.
- There has been some discussion on how to "name" these thingies. From an IT perspective, one should distinguish between navigation (the path to locating the thingy) and identification (distinguishing among thingies). One can easily devise hierarchical and non-hierarchical conventions for navigation. For identification, this is a different topic. To put it in a programmers framework, if I'm navigating a potentially cyclic structure, I need to know when I've returned to the "same" spot -- i.e., same identifier means "same spot".
- For identification, there are several well known schemes. I would suggest that we use the "object identifiers" of ASN.1 -- virtually everyone is under the "master hierarchy" of these identifiers (again, "identifier" does not necessarily equate to "navigation path"). This master hierarchy includes everything from IP addresses to bank accounts to phone numbers and so on. FYI, the format is something along the lines of "0.1.2.3.4....". The use of GUIDs (or, more properly, UUIDs) can be incorporated at lower levels it people want (GUIDs/UUIDs have their own uniqueness problems, but that's a story for another day).
My next set of comments concern the nature of the standard itself. What kind of standard are we talking about? Based on the motions below and the referenced documents, it is hard for me to tell. I'm using terminology of ISO/IEC Guide 2 ("Standardization and related activities -- General vocabulary") below.
Fundamentally, a standard is composed of "provisions":
7.1 provision: expression in the content of a normative document, that takes the form of a statement, an instruction, a recommendation or a requirement. NOTE -- These types of provision are distinguished by the form of wording they employ; e.g. instructions are expressed in the imperative mood, recommendations by the use of the auxiliary "should" and requirements by the use of the auxiliary "shall".
And standards come in a variety of types (not mutually exclusive; non-exhaustive list):
5.1 basic standard: standard that has a wide-ranging coverage or contains general provisions for one particular field. NOTE -- A basic standard may function as a standard for direct application or as a basis for other standards.
5.2 terminology standard: standard that is concerned with terms, usually accompanied by their definitions, and sometimes by explanatory notes, illustrations, examples, etc..
5.3 testing standard: standard that is concerned with test methods, sometimes supplemented with other provisions related to testing, such as sampling, use of statistical methods, sequence of tests.
5.4 product standard: standard that specifies requirements to be fulfilled by a product or a group of products, to establish its fitness for purpose. NOTE 1 -- A product standard may include in addition to the fitness for purpose requirements, directly or by reference, aspects such as terminology, sampling, testing, packaging and labelling and, sometimes, processing requirements. NOTE 2 -- A product standard can be either complete or not, according to whether it specifies all or only a part of the necessary requirements. In this respect, one may differentiate between standards such as dimensional, material, and technical delivery standards.
5.5 process standard: standard that specifies requirements to be fulfilled by a process, to establish its fitness for purpose.
5.6 service standard: standard that specifies requirements to be fulfilled by a service, to establish its fitness for purpose. NOTE -- Service standards may be prepared in fields such as laundering, hotel-keeping, transport, car-servicing, telecommunications, insurance, banking, trading.
5.7 interface standard: standard that specifies requirements concerned with the compatibility of products or systems at their points of interconnection.
5.8 standard on data to be provided: standard that contains a list of characteristics for which values or other data are to be stated for specifying the product, process or service. NOTE -- Some standards, typically, provide for data to be stated by suppliers, others by purchasers.
As mentioned above, these categories aren't mutually exclusive and aren't exhaustive. However, it is important for us to have some idea where our work fits in. If it doesn't fit in any of these categories then, from an industry perspective, it may be more difficult to understand how our work *is* a standard because it is less recognizable as a standard when compared with other standards.
Using the above categories, I'd guess that we *are not* developing a testing, process, or service standard. Let's look at the others:
- terminology standard: In short, terminology standards are about (1) designations, (2) tied to concepts, (3) organized in some structure, (4) for some field of study. Frank's Hunch: This kind of standard would apply to the SUO work.
- interface standard: Most familiar ICT standards are in this category -- codings, APIs, protocols, languages, databases, operating systems, etc.. Frank's Hunch: While this sounds exciting, I don't believe the computational *interface* has been defined enough to call this an interface standard. At the 2003-01 Open Forum, I was asking questions in one of the discussions (was it Chris Menzel making the presentation, and John Sowa and Pat Hayes responding to my questions?). In short, I believe it was Pat who was stating that, concerning my questions about CL (common logic), I was asking my questions via a computational framework. My questions concerned a more fundamental issue that I was probing: are we developing an "interface standard". Without specifying the computational "connection", it will be difficult to "[specify] requirements concerned with the compatibility of products or systems at their points of interconnection". Thus, I don't believe we are specifyi!
ng an interface standard -- I could be wrong.
- basic standard: At first glance, this has some nice appeal, but these kind of standards are difficult to write because one should have a whole framework of standards that are developed from the core module. Sure, this sounds like SUO, but it isn't clear to me: (1) what the basic provisions will be, and (2) what kind of system/thing will conform to the standard. So while one may have some "information contained in a document", what kind of systems/things will conform to this document? If one can't answer the "conformance" question (i.e., "what kind of systems/things conform"), then the document isn't really a standard, but a technical report (TR). A TR is OK, but we should be clear that we are developing a TR (if that is what is desired).
- product standard: Like the interface standard and the basic standard, it is not yet clear to me what system/thing will conform to the standard.
- standard on data provided: This kind of standard tells us what kind of data is required. In some areas, this might be called a "metadata standard". A couple years ago on this list, I said that we should define the "metadata" (i.e., descriptive information) about ontologies. This "ontology metadata standard", I believe, would be very useful -- even if we can't get agreement on a particular ontology, we should be able to get agreement on "talking about ontologies" (i.e., descriptive information). While there has been discussion of classifications and relations among ontologies, this is not exactly the same as "descriptive information" about ontologies. Frank's Hunch: This kind of standard (1) would be most useful, (2) would have immediate impact, (3) would have quick industry "uptake", and (4) would be a foundation for further technical activity (e.g., mappings, search, etc.).
> ------------------------------------------
>
> Ballot Question #1 (Latest Draft from Adam Pease):
>
> "Should the IEEE P1600.1 Standard Upper Ontology Working Group
> commence work on the Suggested Upper Merged Ontology (SUMO) version 1.51
> [April 11, 2003] posted at:
> http://ontology.teknowledge.com/cgi-bin/cvsweb.cgi/~checkout~/SUO/Merge.t
> xt?rev=1.49&content-type=text/plain with the intent of developing it into
> a final SUO document."
I can't support this motion because I don't understand (yet) what kind of standard this will be. I can't tell "what conforms" to this kind of document.
> ------------------------------------------
>
> Ballot Question #2 (Latest Draft from John Sowa):
>
> "Should the IEEE P1600.1 Standard Upper Ontology
> Working Group commence work on a project to develop
> a standard based on three starting candidates,
> IFF, OpenCyc, and SUMO, and continuing as follows:
I can't support this motion either for the same reason: it is not clear "what conforms" to this kind of merged document.
> (1) The development process shall include a
> collaboration of members of all three groups
> and other SUO participants to determine how each
> of the three starting candidates can complement
> and support the contributions of the others.
This describes how people get along. :-)
> (2) The results shall include a library of modules
> derived from OpenCyc, SUMO, and/or other sources.
> Each module shall consist of closely related
> axioms and definitions for some aspect of a
> standard upper ontology.
This says that we'll all tell our own stories and we'll share nicely. :-)
> (3) The standard shall include the specification
> of a methodology for testing the modules for
> consistency, relating them to one another in
> a generalization/specialization hierarchy,
> and combining two or more modules to derive a
> new module that is larger and more specialized
> than the modules from which it was derived."
This says that we'll make sure our stories don't have conflicting morals. :-)
OK, but we have no standard in the end: what will conform to this merged document?
In conclusion, while happy people, shared stories, and harmonized morals might make for a happy playground (or good cooperative research), they don't specifically address the end goal of developing a standard -- what will conform to this document? I can't support either approach until there is some discussion of how we specify conformance. If we can't specify conformance, then we should agree that this work should become a technical report or guideline.
-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 Information/Communication Technologies