SUO: RE: Almost-Final Ballot Questions
Dear Frank,
Some relevant and thought provoking comments. See my responses below.
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
<snip>
>
> 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).
MW: I agree a Registry is an appropriate mechanism.
> - 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
MW: I am skeptical that this will prove suitable. For ISO15926
we have not found that "off the shelf" registries would work,
and what we are trying here is more complex than that. However,
I say this before reading your reference, which I will take
a look at. I am confident that even if we do not use an
existing Registry standard, we can learn from existing ones.
> - 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.
MW: These terms suggest they are looking at storing data models
rather than FOL theories, concepts and constraints. We would
need rather different capabilities.
> - 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).
MW: Well ASN.1 is out there and is better than inventing
something new. In ISO TC184/SC4 we define ASN.1 identifiers for
all our documents. Can't say I recall them ever being used
after being defined though.
MW: My assumption is that the SUO concepts will have different
identifiers for different purposes, and the key thing is to be
able to support this. It is however convenient to have an
arbitrary "primary" identifier. The only really important thing
about that is to manage its uniqueness across the SUO.
>
> 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.
MW: I rather see the motions below as "Preliminary Work Items"
which might themselves result in proposals for specific standards
in the areas they identify.
>
> 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.
MW: I agree, this certainly applies to some of the work proposed,
but perhaps more formally than is usually envisaged.
>
> - 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.
MW: This might come later, if we get to specifying implementation
methods for SUO stuff. At some level SUO-KIF could itself be seen
as an interface standard.
>
> - 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).
MW: I suspect that IFF falls into this category. It provides
a framework and specification for implementing a lattice of
theories that would determine the structure of a Register
(amongst other things).
>
> - 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.).
MW: I agree that it would be useful to work out what data we
need to hold about the concepts and axioms we develop.
>
> > ------------------------------------------
> >
> > 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.
MW: I think there are two things that this standard does:
1. It is a statement of fact, which you can hopefully find answers
to questions in.
2. It is a terminology specification. You conform by using the
terms with the specified meaning.
>
> > ------------------------------------------
> >
> > 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.
MW: I guess OpenCyc is much the same as SUMO. IFF, as well as being
a statement of fact is a basic standard.
>
> > (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. :-)
MW: This is about process, and it is fine to have such material
in a motion. Al motions (or parts of motions) do not have to
lead to standards.
>
> OK, but we have no standard in the end: what will conform to
> this merged document?
MW: This is really the big umbrella that will lead to a
specfication of a Register, and say how content will be added to
it so that it behaves like a lattice of theories. But it is still
a PWI type motion.
>
> 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.
MW: I think you are right that the motions do not specify adequately
particular standards, and it is good to note that. However, I
think they do identify areas of work where we wish to make
progress and develop standards. I also think you are right that
looking at what it means to conform is the key to making the
next step.
>
> -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
>
>
>