Re: SUO: Procedural question (long-ish response)
Frank,
I agree with your message, and maybe most importantly your "flame",
(which seems quite mild), about most ontology work being conceptual instead
of real implementation. Your three types of standards frame well our
current situation. I suspect we'll need all three, and part of the
conflict in this group probably stems from different people only being
interested in one type or another instead of type 1, which is how I
interpret our current PAR.
To address one of your main points of the need for a specific example of
ontology use and benefit, I would cite our work on the HPKB project
(reference below - Cohen et al 1998), in which we built on top of the Cyc
upper ontology, and added a great deal of domain specific content for a
particular problem (reasoning about Army battle planning). We needed an
expressive language because the concepts involved (such as preventing
classes of activities, the goals of agents and groups etc), were much more
easily and generally stated in such a language (yes, anything can get
stated in an RDBMS, OO, bits etc. but we don't code in assembly anymore
either). We showed quantitatively in (Cohen et al, 1999) how we reused
upper ontology content in solving problems.
Further, in that task, we created a domain-specific English grammar that
allowed us to translate pseudo-English into logic statements. The same
ontology was the output of visual battle specification tools (and in fact
we had two of these that conformed to the same ontology). The same
ontology was the input to three different battle plan critiquing tools.
So, all this is to say that we have both concrete anecdotal evidence as
to the value of using large ontologies for systems integration, and
quantitative scientific evidence for the degree of support that upper
ontologies lend to an application.
Cohen, P., Chaudhri, V., Pease A., and Schrag, R. (1999), Does Prior
Knowledge Facilitate the Development of Knowledge Based Systems, In
Proceedings of the Sixteenth National Conference on Artificial Intelligence
(AAAI-1999). Menlo Park, Calif.: AAAI Press.
Cohen, P., Schrag, R., Jones, E., Pease, A., Lin, A., Starr, B., Gunning,
D., and Burke, M. (1998), The DARPA High Performance Knowledge Bases
Project, AI Magazine, Vol. 19 No.4, Winter.
Adam
At 06:55 AM 5/12/2002 -0400, Frank Farance wrote:
>At 15:42 2002-05-09 +0200, Jean-Luc Delatre wrote:
> > Hi Frank,
> >
> > ...
> > IEEE "blessing" is one thing, real usefulness and use another.
>
>Agreed.
>
> > > However, your W3C vs. IEEE comparison is apples and oranges. In your
> URL regarding W3C and >its Semantic Web (I largely agree with those
> points on Slashdot), it discusses (1) the >feasibility of the technology
> with respect to (paraphrasing) "all the pages on the web", and >(2) the
> adoption of this technology for a significant portion of the web.
> >
> > I am glad you "largely agree" with the points on Slashdot.
> >
> > > The SUO work doesn't frame itself in addressing all the needs of the
> web (it audience is >probably different) and the SUO work doesn't set
> itself out to be adopted (large scale) by >the web.
> >
> > I never meant to suggest that SUO will have to be adopted for any use
> on the web.
> > The "points on Slashdot" are just to highlight the difficulties of
> having a standard
> > (whether official or "de facto") really adopted by a significant
> segment of the
> > intended user community.
> >
> > To remind of one of my previous metaphors, yes, ADA is in use, but by
> how much
> > of the originally intended audience?
>
>Ada is a good example of standards activity the didn't result in
>significant adoption, Pascal is another, and the problems with C++
>standardization has caused several vendors to create new languages (e.g.,
>Java, C#). I'm sure we can find many more examples of standards they have
>had problems. The standards process is a "best practice", but doesn't
>guarantee good results (just like any methodology).
>
>I don't yet know how successful SUO will be. In fact, success/failure is
>determined (typically) 2-5 years after the completion of the standard
>(that's just the way it is).
>
> > > So it's not the IEEE is more "powerful", per se, than W3C ... it's
> that W3C has a different >audience and different kind of expectation
> (with respect to adoption, etc.) than IEEE SUO.
> >
> > If you DO have a more precise idea of what the "intended audience" for
> SUO is,
> > I would very much like to know this.
> > The SUO Scope & Purpose is so broad that it *does* in fact
> > cover "E-commerce applications" a.k.a. the web!
>
>I agree with the a good number of points in the Slashdot article. For
>example, I believe that a good number of web page developers will have
>little motivation to improve upon tagging of web pages (whatever that
>might be). So for web pages, while it would be useful, the lack of
>adoption is not an indication of the quality of the standard ... many
>times, it is an indication of cost. For example, we might state that
>Dublin Core tagging is a Good Thing, and the proper use of HTML META tags
>is a Good Thing, but there is little motivation to add this kind of
>tagging because the purpose of the web pages (as intended by their
>authors) might be to distribution information ... and untagged web pages
>are good enough ... additional tagging is simply an extra cost with little
>rationale (i.e., good engineering principles would leave out these tagging
>features).
>
>So adoption by the web isn't a good metric. Adoption of a standard by its
>marketplace (i.e., people that have a potential interest in using the
>standard) is a better metric. So for the group of people who want to use
>ontologies, let's see how much they want to adopt the standards work.
>
>Even with the tagging of web pages, the "semantic content" (whatever that
>is :-)) might not easily mapped/embedded/tagged .
>
> > If you have some "niche market" in which you can make good business
> with SUO,
> > so far, so good, for you...
>
>Note: I just came back from a week of conferences, where there were some
>talks on ontologies and the recent ACM papers on ontologies were
>distributed. So the discussion below is fresh with questions inspired by
>those presentations/papers. I know that some of the questions/issues
>below may sound basic, but I've found myself in need to explain this stuff
>in really basic terms ... the kind of terms that convince software
>engineers to incorporate technologies into applications (i.e., I'm not
>interested in PowerPoint engineering). So I'm asking for your help.
>
>Disclaimer: I'm going to try to minimize the use of jargon because (1) I
>believe we need to talk about our work in simple, lay terms (an important
>feature for general adoptions), and (2) it's easy to get to some
>misunderstandings by using certain jargon. Please pardon the plain language.
>
>While I'm doing work where I might be interested in the results of SUO,
>I'm not exactly sure we (the Working Group) are all in agreement regarding
>the problem to solve. For example, here's three different kind of
>standards that are possible (others are possible, too):
>
> - Type #1: A registry of general concepts where there is common
> agreement. The goal would be to build consensus around a bunch of
> concepts and, hopefully, these general concepts could be used as a
> foundation for developing other concepts. (Note: I believe that SUMO
> might be this kind of standard.)
>
> - Type #2: A technique for mapping one set of concepts to
> another. In this case, we have decided that we only care about mappings
> (why do we only care about mappings? because, e.g., that's all the market
> wants, or maybe it's impossible to get to common agreement on Type
> #1). So the standard would specify we describe, in general, mapping one
> set of concepts to another. (Note: I believe that IFF might be this kind
> of standard.)
>
> - Type #3: We specify the necessary attributes to describe a
> concept. In other words, we wouldn't be specifying the concepts
> themselves, but we'd specify the required descriptive attributes
> when describing a concept. (Note: Someone had mentioned something
> "metadata for ontologies" <-- an example of a Type #3 standard).
>
>Of course, these types of standards could be further partitioned or
>combined ... other types are possible, too. And once we've settled on the
>types of standards we want, we'll probably need to specify how to use this
>kind of information from an IT perspective, e.g., codings (file formats,
>XML, KIF, etc.), APIs (objects/interfaces with convenient paradigms in
>C/C++, Java, LISP, etc.), protocols (ontology exchange, storage/retrieval,
>etc.), and so on. <-- But most of this stuff is lower level engineering
>(also known as "bindings") because we really need to decide what kind of
>standard we want: Type #1, ..., Type #N, or some combination.
>
>OK, so what kind of standard do we want? I tried exploring this issue a
>bunch of months ago when I asked "What does it mean to "conform" to the
>SUO standard?" (jargon: "conformance" means an "implementation" (whatever
>that is) satisfies the requirements of the standard). We had some lively
>discussion, but not much resolution. In my experience in standards work,
>I've found that answering this question is especially helpful for
>discovering the nature of our intent. For example, if we knew what
>conformance meant, then we'd know what kind of standard we're doing. And
>a standard without a clear understanding of conformance is largely worthless.
>
>A while ago, the conformance discussion digressed into worry over using
>all or some of SUO (assuming that SUO would be a standard of Type #1
>variety). This all/partial use can be easily addressed through the use of
>"implementation conformance statements" (ISO/IEC jargon for "describing
>what features of the standard(s) you've implemented and any potential
>limitations"). So the all/partial use of a registry of concepts is a
>straightforward problem to solve in standards wording.
>
>Another thing that would help would be identifying the prototypical
>applications of the standard. For example, in the programming language C,
>there were three prototypical applications that helped clarify the
>development of the standard:
>
> (1) the programming language C needed to be able to compile a
> compiler for C
> (2) the programming language C needed to be able to compile an
> operating system, such as UNIX
> (3) the programming language C needed to be able to support the
> development and compilation of a text editor (e.g., ED, VI, EMACS) so
> that programs could be written in C
>
>Those prototypical applications really helped focus things. I think we
>need those prototypical applications for our work ... it's not clear to me
>what those prototypical applications are.
>
>--------
>
>[Disclaimer: The following paragraph is a bit of a flame/whine, please
>excuse ...]
>
>[Flame On] I the past year, I've seen over 100 presentations/articles
>from people who are doing ontology work (using it, creating it, reviewing
>it, procuring it, etc.). Largely, they (1) quote some "reference"
>definition of ontology, (2) have some nice diagrams, (3) promise that
>ontologies help us do "smarter" things, and (4) conclude with "if
>everything were scaled up, we be doing smarter things in a bigger way; and
>if everybody agreed on ontologies, we'd all understand what we mean". To
>me, that's all a bunch of hype. Some people have some small
>problems/solutions, but they don't scale up (the authors acknowledge this
>limitation). Some people have some general problems/solutions, but it's
>not clear how they apply to common applications (whatever that is ... if
>we had prototypical applications, we know what common application
>are). Some people worry about the feasibility of getting agreement on
>general concepts since everyone has they own (valid) opinion. Some people!
> t!
>hink that "adding ontologies" would produce "semantic interoperability"
>among systems. [Flame Off]
>
>So I guess what I'm asking for is "show me the code for a prototypical
>application". This would mean that we'd need to know what a prototypical
>application. Here's my idea of a sample prototypical application:
>
> A person managing a train routing system has several choices of
> routing trains, e.g., routes R1, R2, ..., RN. A train T has cargo
> C. Based on the news of a forest fire at some particular area near route
> Rx, the decisions could be made on the routing of train T: say the fire
> were within 100 meters of route Rx (with still wind), we might permit
> trains with one kind of flammable material (e.g., wood) but not permit
> trains with others (e.g., propane).
>
>In this application, there would be no specialized programming for forest
>fires or propane, but a general set of concepts (e.g., the SUO work),
>specialized concepts (derived from the SUO work or derived independently),
>and some general strategy statements (Want Good Things to happen (e.g.,
>fuel efficiency), Want to avoid Bad Things (e.g.,
>damage/destruction/delay), etc.).
>
>For the design feasibility,
>
> (1) we'd need some text-to-Something translation (e.g., newswire
> feed, weather reports)
> (2) we'd transform the Something into SomethingBetter
> (potentially more useful for our application that's about to use "ontologies")
> (3) we'd need to use some kind of tool that takes the general
> nature of our application (general concepts, specialized concepts, etc.)
> combine them with our strategy statements (Want Good, Avoid Bad) and turn
> them into action items
> (4) the action items would be transformed into actions (via
> human, machine, etc.) and, hopefully, there would be some rationale for
> these actions
>
>Item #1 seems feasible: there's a variety of ways to transform natural
>language text into Something ... what that Something is is up for debate,
>but for argument's sake I'll say that Item #1 is feasible.
>
>Item #2 seems interesting: what is the target of our transformation to
>SomethingElse? Is it a representation of concepts, a set of queries, a
>state machine, an agent, etc.? In a good number of presentations I've
>seen, the transformation to SomethingElse is application-specific. In our
>application, that transformation might have some bias towards the
>Want-Good/Avoid-Bad strategy; maybe we wouldn't want that bias.
>
>Item #3 seems somewhat difficult: generically, it's the classic AI
>chess-playing problem except that the rules/constraints are
>generalized/different.
>
>Item #4 is a straightforward engineering problem.
>
>So if we're going to explain the utility of ontologies and to gather
>widespread adoption of our work, we're going to have to reduce these
>problems into tractable engineering problems that a competent engineer
>(possibly with some training) could solve. In almost all the
>presentations I've seen, the nature of the application is like this
>"smart" train routing system, except that Item #1 might not be text (it
>might be a database) and the nature of the application and strategy
>statements are different.
>
>In many of the presentations I've seen, there's much handwaving on Item #3
>("you see, you use the inferencing engine and the results come out here").
>
>I'm sure a good number of you have straightforward answers/suggestions for
>Items #1, #2, and #3, so pointing to publicly available code to handle
>these pieces/portions would be great. I'm sure many of you have better
>ideas for prototypical applications, so let me know.
>
>Of course, when I said "reduce these problem to tractable engineering
>problems", I didn't expect that solutions would appear overnight, but I
>did expect that solutions were possible with competent engineers (if they
>require additional specialized skills, we need to know what these skills are).
>
>And if there are better illustrations of general problems/solutions using
>ontologies (and I'm talking about real code, too), then please let us know.
>
>If we can explain this application of ontologies and the
>engineering/programming paradigms to incorporate ontologies (in general),
>then we can get to broader adoption of our work. Right now, presentations
>seem to suggest that one "bolts on ontologies" and applications/systems
>become smarter. I'd like to know what kind of paradigms are useful for
>integration of ontologies (i.e., "bolting on").
>
>As an analogy, Dublin Core metadata provides descriptive information for
>media. Previously, when opening a file, I might have had to know the file
>by name or navigate the file system. However, if my media is tagged with
>Dublin Core metadata, I might be able to open up files based on certain
>criteria. I might add this feature to the "open file" user interface by
>(1) allowing the user to specify criteria in terms of keywords, (2)
>scanning a database or scanning the tags of the files directly and
>matching keywords to my criteria (say, a simple string-matching
>algorithm), (3) presenting a list of "matches" to the user, and (4)
>allowing the user to select from the match list.
>
>What's Good about this analogy is:
>
> (1) the data (actually metadata and criteria) and its operations
> are well-defined
> (2) the data is accessible (via database or tags extracted from
> the files)
> (3) the new user-interface features (i.e., adding a list of
> matches to "open file") are relatively easy to integrate into the
> *existing* application framework
>
>So it seems plausible to "bolt on" some "Dublin Core functionality" to
>common applications. My question is: what's the common application
>integration paradigm for ontologies, e.g., what's a common technique for
>integrating these features into existing systems?
>
>FYI, one integration technique that I've seen in presentations is: using
>ontologies to disambiguate terms, e.g., it is "tank" the military
>vehicle?, it is "tank" that holds water and fish?, or it is "tank" as what
>a stock price does after bad news? This all seems like terminology
>management to me (certainly, a related field). Regardless, if this is the
>prototypical application, then I don't think it will get much industry
>attention because recognizing tank vs. tank vs. tank isn't a common
>problem that everyone needs to solve ... reminds me of the early sales
>pitches on why home users should buy a PC: "you can store your recipes on
>it; you can write a program to ask you to make sure you've checked all the
>locks before you leave" ... these home applications were better solved
>with low-tech solutions, such as index cards and paper checklists ... the
>PC was overkill and there was little rationale to buy a home PC based on
>those applications (e.g., storing recipes).
>
>So what's a good reason to incorporate ontologies into one's applications
>and what's the paradigm for integration?
>
>--------
>
>One more topic: On the possibility of getting to a common upper
>ontology. It's easy to demonstrate that a common upper ontology is
>impossible: simply ask everyone to disagree with any standards wording
>(and don't suggest any better wording) and it's easy to get to
>disagreement. So part of the problem with agreement is the potential ease
>of disagreement (possibly, a "people" problem :-)). I credit Nancy Lawler
>with the following observation: some people's research projects' funding
>are biased towards developing "unique" solutions (so, there might be a
>business rationale for disagreement/differing solutions). And, of course,
>there are legitimate differences of opinion.
>
>So I was wondering: is it possible to get any agreement at all? For
>example, is it possible to get agreement on at least *one* concept? And
>if we can agree on *one* concept, can we get agreement on *two*
>concepts? Because if it possible to get agreement on at least one
>concept, then it's merely a matter of how big we can grow the list of
>agreed-upon concepts. Right?
>
>OK, so let me try for a couple. Does everyone agree upon the meaning of
>"milli-", "kilo-", and "micro-", as in prefixes for quantities? My guess
>is that we'd be likely to get agreement on this. Furthermore, there's a
>multi-part ISO standard (ISO 31-*, Quantities and Units) on this, which
>include things like: SI units, Space and Time, Mechanics, Heat,
>Electricity and Magnetism, and so on. Not only is this an international
>standard, it has been translated to many languages (national editions),
>it's in use in science, industry, and trade, and it's consistent with the
>lay understandings of these kind of things.
>
>I'm sure a bunch of other things in ISO/IEC/ITU standards would be good
>candidates ... we'll be able to take advantage of a good number of things
>that many knowledgeable specialists have come to (international) consensus
>upon.
>
>Of course, not everything in ISO/IEC/ITU is "right" ... some ISO/IEC/ITU
>things are useful in certain contexts and not in others. Not a surprise:
>we have specialized terminology, each useful within its own context. For
>example, the term "object" has at least 7 related meanings (the
>lay/dictionary meaning, the IT meaning, the object-oriented meeting, the
>programming language meaning, the language-independent datatypes meaning,
>the C meaning, and the C++ meaning), all of them relevant, when discussing
>data interchange between C and C++. So maybe the ISO/IEC/ITU concepts
>aren't always right for every context, but they'd certainly be useful and
>should be considered.
>
>Maybe we'll need all three kinds of standards:
>
> - We'll need a Type #1 standard that serves as a registry of
> these concepts (e.g., the ISO/IEC/ITU concepts, other widely agreed-upon
> concepts, and, possibly, portions of natural language dictionaries).
> - We'll need a Type #3 standard to tell us all the important
> information that we'll need to record in the registry when making entries
> in the Type #1 registry.
> - We'll need a Type #2 standard to describe the mappings
> (relations) among registry entries of the Type #1 standard and other
> specialized registries (e.g., the 7 related meanings of "object" in the
> illustration above).
>
>Sorry for the long-winded E-mail! :-)
>
>-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 the Global Information Infrastructure
Adam Pease
Teknowledge
(650) 424-0500 x571