SUO: Almost-Final Ballot Questions
At 09:06 2003-05-20 +0100, West, Matthew R SITI-ITPSIE wrote:
> Dear Frank,
>
> Some relevant and thought provoking comments. See my responses below.
Matthew-
I agree with all your points and I have a question about one of them.
> ...
> >
> > 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.
I can tell you in advance that one feature that is "missing" from 11179-3 is *specific* relationship types. For example, even using 11179-3 for terminology registration, some basic relationship types (e.g., broader, narrower, etc.) are not "built-in". Typically, the relationship types get added to the standard that incorporates the registry (e.g., "standard X specifies relationship types R1, R2, ..., Rn (via normative wording), and uses a registry for the remainder of the standard). In other cases, the relationship types themselves are part of the registry (i.e., there is a registry of relationship types, so one is not limited to a fixed set).
> > - 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.
I believe the definition portion is more terminology-like, and the classification schemes can be used for classifications and taxonomies. My guess is that FOL theories, concepts, and constraints could make use of the definitions portion of 11179-3. There is no "right answer" in this regard, which is much like programming langauges -- in order to calculate N multiplied by 4, I have several choices, such as using the * operation (multiplication), the + operator (repetitive addition), the << operator (a couple of bit shifts).
Also, at the Open Forum in a room full of terminology and ontology folks (including people on this list), I asked the question "what are the essential and delimiting characteristics of an ontology" -- in short, how would I know if an ontology hit me over the head? -- and with terminologists in the room to help, I was certain to have a precise definition of "ontology".
For those who are not familiar with terminology standards speak, here's some excerpts from ISO 704 (Terminology work -- Principles and methods):
5.3.3 Essential vs. non-essential characteristics
Not all characteristics are equally important. For practical purposes, the essential characteristics of the intension shall be the focal point of any analysis and may differ according to specific fields. Characteristics are considered essential if they are indispensable for the understanding of the concept in a particular field of knowledge; the absence of an essential characteristic fundamentally changes the concept. The absence of an essential characteristic in the course of an analysis will lead to poor or even erroneous understanding of the concept. In the example of the 'lead pencil', if the characteristic graphite core encased in wood were removed, the concept would be radically changed. It would represent a different concept corresponding to a different set of objects. Therefore, this is an essential characteristic. On the other hand, if the characteristic one end is sharpened to a point were removed, the concept would not be altered. Although a lead p!
encil must be sharpened in order to write, it still qualifies as a lead pencil, even if it has not been sharpened. Therefore, this characteristic is not essential to the understanding of the concept of 'lead pencil'. The essential characteristics of a concept, such as 'lead pencil', shall be identified. It is not always necessary to categorize the characteristics explicitly as in example 3, only in cases where the concept in question is highly complex.
Example 3:
level of abstraction|1. concreteness |essential
composition |2. made of a long, thin piece of graphite|essential
composition |3. graphite is encased in wood |essential
colour |4. casing may be coloured |non-essential
composition |5. one end may have an eraser |non-essential
shape |6. one end may be sharpened to a point |non-essential
usage |7. must be sharpened for usage |essential
medium |8. graphite is the writing medium |essential
function |9. used for writing or making marks |essential
It must be noted that the same property of a given object may be abstracted as an essential characteristic of a concept in one subject field but may be non-essential in another.
5.3.4 Delimiting characteristics
After identifying the essential characteristics that make up the intension of a concept, the terminological analysis shall be taken a step further. Each essential characteristic of the concept under study shall be analyzed in relation to the related concepts in the concept system. Common or shared characteristics indicate similarities between concepts; delimiting characteristics signal differences which set a concept apart (see examples 7 and 8). A delimiting characteristic is an essential characteristic that distinguishes one concept from another. However, delimiting and common are relative terms. The same essential characteristic may be delimiting in relation to one concept but common in relation to another related concept. Analysing the similarities and differences between concepts will result in the unique set of characteristics that typify a given concept. This unique combination of characteristics will situate the concept within a network of related conc!
epts with similar or different characteristics. The relations between the concepts shall be used to determine the basic structure of the concept system. Understanding the characteristics used to develop the concept system simplifies the task of defining a concept.
So in the context of the Open Forum meeting, the ontology folks did not produce a list of essential and delimiting characteristics of the concept of an "ontology". This was especially confusing because at some point in the meeting, someone gave a presentation that used an illustration of an ontology for wine-making (Pat, Chris, John: do you remember?). As far as I could tell, the ontology was no different than a UML model. So I asked: "What's the difference between an ontology and a UML model?". The answer was: well, they are about the same -- ontologies can be UML models and vice versa. Now I didn't have confidence in that particular answer, but it appears that for some people, UML models are ontologies -- which means that the so-called "data modeling" portions of 11179-3 (which you have identified) could be used for ontologies, too.
I'm not so sure about "ontologies" vs. "UML models". However, I am certain that I need to understand the essential and delimiting characteristics of "ontology" <-- in this regard, I don't have a crisp definition -- maybe someone can help with a definition.
> ...
> > 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.
OK.
> > ...
> > - 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).
OK, that makes sense.
> ...
> > > ------------------------------------------
> > >
> > > 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.
OK.
> > > ------------------------------------------
> > >
> > > 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.
OK.
> ...
Thanks for your comments.
-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