Re: SUO: Almost-Final Ballot Questions
Frank,
One comment about "Is a UML model an ontology?". There are a range of
possible formalisms in which to state an ontology. A simple taxonomy
(class/sublcass structure) is an ontology. However, such an ontology lacks
the full definitions that a formal ontology such as SUMO provides. A
simple taxonomy is much like a dictionary that just has words,
prononciation, and synonym information, but lacks the definitions. UML is
getting more expressive, with the addition of OCL. My understanding though
is that OCL is not a widely used component of the language.
So, the short answer is "yes, but only in a very simple sense."
Adam
At 06:41 AM 5/20/2003 -0400, Frank Farance wrote:
>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