Re: SUO: Almost-Final Ballot Questions
Frank,
I agree with a great deal of what you say.
In particular, I assume that the library of modules
"should use a registry-based approach". If you believe
that it is important to state that point in the motion,
I would be happy to add it.
> 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).
I completely support the idea of using ISO/IEC 11179.
If you believe it would be important to say that in
the motion, I would also be happy to add that point.
And thanks for posting the URL for 11179.
> 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
I also agree with the following point, but that gets into
more detail than I believe is necessary for the motion.
The question of what features of 11179 are used would
be specified in the standard, but not in the motion to
develop the standard.
> Several features of 11179-3 may be used: ....
But I believe it is important to clarify the following
point:
> 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.
The hierarchical structure of the library could, of course, be
used for navigation, but it is much more fundamental than
just a navigational mechanism. It is a *generalization*,
hierarchy, which indicates which modules have been proved
to be consistent with any given module, which ones are more
general than any given module, and which ones are more
specialized than any given module. This information is
essential to the way that the library is used for designing,
developing, and using ontologies.
> For identification, there are several well known schemes.
> I would suggest that we use the "object identifiers" of ASN.1...
That is a useful suggestion, but the URIs of the W3C have also
been suggested. The standard must specify some such scheme,
but I don't believe that it is necessary to make a commitment
to a particular scheme in the motion to begin the project.
According to the ISO/IEC guidelines, the library of modules
would be an interface standard, as in 5.7:
> And standards come in a variety of types...
> 5.7 interface standard: standard that specifies requirements
> concerned with the compatibility of products or systems
> at their points of interconnection.
The standard for a libraries of modules would specify
1. the required formats for each module in the library,
following the guidelines of ISO/IEC 11179,
2. the required consistency tests each module must pass,
3. the requirement that the network of links among modules
would specify the position of each module relative to
other modules, which are its immediate generalizations
and specializations, and
4. the requirement that following the immediate generalization
and specialization links would enable a program to find
every indirect generalization or specialization of any
particular module in the library.
>... 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".
The standard will indeed specify a "computational connection",
including the methods for testing and determining the consistency
of any particular module and its place in the generalization
hierarchy relative to other modules. The four points above
(which I would be happy to add to the motion) determine the
kind of computation that is necessary.
>> Ballot Question #1 (Latest Draft from Adam Pease)...
> I can't support this motion because I don't understand (yet)
> what kind of standard this will be.
I believe this is essentially the same motion that you voted
for two years ago. But I'll let Adam respond to your question.
>> Ballot Question #2 (Latest Draft from John Sowa)...
> I can't support this motion either for the same reason:
> it is not clear "what conforms" to this kind of merged document.
As I said above, this is a proposal to develop an interface
standard of type 5.7. What would conform to it would be content
modules (derived from SUMO, OpenCyc, or other sources) that
observed the requirements on formatting, consistency, and
placement in the generalization hierarchy.
>> (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. :-)
Making them get along (or even talk to one another) is no
small achievement. But I would be happy to replace this
clause with a statement saying that the SUMO, OpenCyc,
and IFF are resources from which the formats and some of
the content to be cast in those formats are to be derived.
>> (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. :-)
I am primarily concerned about the interface stadard.
The SUMO and OpenCyc groups are concerned about populating
the modules with content derived from their projects.
>> (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. :-)
The "methodology" is the specification of how conformance
to the interface standard is determined by the computational
methods of testing consistency and generalization/specialization
relative to other modules in the library. I would be happy
to replace the word "methodology" with the phrase "methods for
testing conformance according to the following criteria...".
Let me know whether you would be satisfied with additional
clauses added to the motion along the lines mentioned above.
John Sowa