Ali, Ryan, Duane, and Mike, (01)
As a reminder, I'll repeat the questions: (02)
JFS> Why do we need ontologies? How are current ontologies being used?
> What are the successes and failures of projects that use ontologies?
> How do they compare to the successes and failures of similar projects
> that do not use explicit ontologies? (03)
AH> Quick question: in your opinion, in the analogy, what's the box
> for ontologies? i.e., sun::ontology -- box:: ? (04)
As an example, I quoted the comment that nuclear fusion is like
building a sun in a box. The physicist who made that observation
said that everybody wants to do the scientific work of creating
the sun, but they neglect the engineering work of designing a box
that can contain the sun. (05)
For the analogy, the scientific work of creating the sun is like
creating new ontologies. The engineering work of designing the
box involves building tools and methodologies that use ontologies
to make software design and development easier and better. (06)
RK> Naturally, data-sharing would be much easier if we all agreed
> upon a single model to use. This would encourage us to understand
> Ontology as the study of making one model to replace them all,
> and ontologists as the people who do a lot of talking in order
> to reach agreement on this one model. (07)
That's the top-down approach. Ontologists start from "first
principles" derived from logic, philosophy, and science. But
they seldom look at the actual problems that people working
in the trenches have to solve. (08)
RK> A different approach to data-sharing would be to formalize as
> much of the semantics of a dataset as possible... In this way,
> ontologists do less talking and more writing as they translate
> natural-language definitions into a more formal variety. (09)
By the "semantics of the dataset", I assume you mean the documents
that specify the data that the software must process and the
requirements for processing it. That is a bottom-up approach
that focuses on the details. (010)
RK> The first strategy [top down] doesn't seem to scale particularly
> well, and ultimately seems to benefit more from people who train
> in facilitating meetings than people with a background in
> mathematics, computer science, linguistics, or philosophy. (011)
I think what you're saying is that people who aren't familiar with
the problem domain (mathematicians, computer scientists, linguists,
and philosophers) produce upper level ontologies that aren't useful. (012)
By "people who train in facilitating meetings", I think you mean
people who know how to elicit critical problem-oriented information
from the attendees. Those people used to be called systems analysts
and knowledge engineers: they would elicit relevant information
from the people who understood the subject matter; then they would
show how that information could be written in a formal notation. (013)
RK> I do think that a good reason for involving oneself in ontology
> is not to share data, but instead to formalize semantics. There
> seem to be quite a lot of prospects for data with formal semantics
> (data sharing being one), and many current uses for them as well
> (e.g. lighter user interfaces that can depend on the inferences
> explicit in an ontology and realized by some reasoner). (014)
What I think you're saying is that formalization is useful when
it's applied to the actual data that the software will process.
That is consistent with the lessons that Lenat and others have
emphasized: the most important reasoning is done with low-level
microtheories, not with the upper-level ontologies. (015)
DN> Why do we need ontologies?
>
> ... I usually find a winning statement with the following in
> the business world:
>
> 1. Business decisions are fueled/made based upon information!
>
> 2. Inference: bad or missing quality information increases the
> risk of poor quality business decisions!
> a. Areas where ontology work can help with information quality:
> b. Relevance - What process does the information support decisions in?
> c. Clarity - what does the information really mean?
> d. Consistency/compatibility - how do you get information from
> different parts of your organization to come together?
> e. Search how can you find the information you require? (016)
All these points address the domain-dependent or task-oriented
ontologies of the kind that are used in Cyc's microtheories.
They support Ryan's recommended approach of formalizing the
"semantics of the dataset" -- i.e., the actual data that the
system must process. (017)
MB> As I see it, there is a glaring hole in many systems application
> developments, whereby we need a technology neutral, business-
> reviewable model of the terms that systems, data models and
> message models are developed against. (018)
I agree. And to a large extent, the old systems analysts did
that, but they recorded their results in English and various
kinds of diagrams rather than a formal logic. (019)
MB> So ontologies have huge potential to plug the gap in technical
> development and quality assurance. This means developing a good
> technology development methodology, based on the Zachman Framework,
> in which the "Semantic model" section is fulfilled by an ontology. (020)
Mentioning Zachman is significant, since he is an old-time systems
analyst who filled the gap between the theorists and the implementers. (021)
MB> There are plenty of advanced and interesting things that can be
> done with ontology beyond this, but I would suggest that ontologies
> which deliver business meaning are more immediately relevant than
> all those cool things. We have the opportunity to plug a very
> serious gap which is pretty easy to plug. (022)
I agree. And by "business meaning" I think you mean the domain level
ontologies rather than the upper level. I'm not against using an
upper level as a general guideline, but the axioms for detailed
reasoning must be written in the lower levels. (023)
Some history: (024)
1. Long before computers became available (1920s to '50s), businesses
had "systems and procedures" analysts, who analyzed how a business
works and what information is used. They designed printed forms
that had columns and fields for all the information required,
and they mapped those forms to the fields of punched cards. The
"procedures" were executed by secretaries and file clerks, who
read forms, filled out other forms, and organized them in acres
of filing cabinets. (025)
2. In the 1960s and '70s, systems and procedures analysts became
systems analysts and database administrators. They specified
tables and columns of databases, computer programs, and I/O
devices. Their "procedures" included work for human clerks
and specifications that "coders" translated to programs. (026)
3. In the 1980s, the expert systems led to knowledge engineers who
elicited information from subject matter experts and formalized
it in a computable form. Some knowledge engineers were familiar
with the long tradition in systems analysis, but many of them
had no understanding of how expert systems could be integrated
with traditional data processing. That lack of integration
limited the expansion of expert systems to data processing. (027)
4. In the 1990s, the PC revolution empowered anybody who could
point and click. The professional DB administrators were
replaced by point-and-clickers who uploaded their spreadsheets
to a database. The object-oriented paradigm broke the long
tradition of systems analysis, but the three amigos who
developed UML preserved a lot of the old methodology and
made it acceptable to the O-O world. (028)
5. In the 2000s, the trendy WWW empowered anybody who could hack up
a web page. The old traditions were forgotten. There are very
few people left to do the systems analysis, database design, or
knowledge engineering. The ontology theorists don't understand
the applications, and the developers don't understand the theory. (029)
I believe that the major focus for ontology should be on developing
appropriate methodologies -- very much along the lines that the
systems analysts and knowledge engineers used to do. UML preserves
a great deal of the old traditions, and more work should be done
to integrate UML with ontology development and application. (030)
John Sowa (031)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (032)
|