John, (01)
We have a major failure to communicate, and I think that failure is important
to this Forum. (02)
You wrote: (03)
> I said that the software for any and every useful application is based on
> some ontology about the application domain. (04)
With any definition of "ontology" that I understand, even a philosophical one,
that is patently false. The software for every useful application is based on
some reasonably accurate understanding of the domain of the application and the
purpose of the application, and thus of some corresponding viewpoint on that
domain. None of those is an "ontology". (05)
> Then I summarized four ways
> that the software is related to the ontology. Following is a slightly clearer
> specification of those four ways:
>
> 1. Informal & implicit: The ontology is informal and not stated in
> any document. The fact that the implicit ontology is in the head
> of the programmer who wrote the code can be determined by asking
> him or her. (See Plato for the method of inquiry.) With suitable
> software, the implicit ontology can often be discovered by
> analyzing the programs and the kinds of data they process. (06)
This is the crux of my issue, and why I simplified what you said. It is my
position, and I hope that of the knowledge engineering community generally,
that there is no such thing as an "implicit ontology". An "ontology", in the
knowledge engineering sense, is an ENCODED body of knowledge, and specifically
a body of knowledge that is encoded in a language that supports inference.
There are no "implicit ontologies", because there are no "implicit encodings"
-- an oxymoron. The nature of an encoding of knowledge is to be explicit. (07)
> 2. Informal & explicit: The ontology is stated informally but
> explicitly in some natural language text, such as manuals,
> requirements documents, or comments in the code and the data
> definitions. (08)
I would argue that encoding the knowledge in natural language text is not an
"ontology", either, precisely because it argues that "knowledge engineering" is
an empty discipline. One can argue that part of the engineering exercise is
getting the domain experts to express their knowledge at all, but a major part
of knowledge engineering is to produce a formal logical model from the body of
natural language expression that is available from published resources or
extracted from the experts. That product of the knowledge engineering activity
is what we mean by an "ontology". The production of ontologies requires
specialized skills, not just the ability to read natural language and technical
jargon. (09)
> 3. Formal & implicit: The ontology is formal, but the formal
> statements have been lost, discarded, or otherwise disconnected
> from the code and the data. (010)
Once you have a formal logical model, you have an ontology. If you lose it,
you don't have an ontology any more. (011)
That it is "disconnected from the data" has nothing to do with its being
"implicit". What you mean is that the trace from the knowledge engineering (of
the problem space and the requirements) to the products of (later) software
engineering tasks is missing. That is a very important problem when it occurs.
It creates a requirement for a different engineering task: the re-creation of
the trace -- the "semantic mapping" between the operational software elements
and the problem space ontology. (012)
I would also point out that it is now becoming a practice to make formal
ontologies of an application domain after the fact of the application
development, e.g., for an integration or enhancement process. And that results
in a situation that is John's "formal & implicit ontology" -- a "disconnected
ontology". If your purpose is to upgrade and replace the legacy application,
you may not need to connect the ontology to the application-as-is, but if your
purpose is integration or enhancement, you need to develop the "semantic
mapping", at least in those areas that affect the extension of the application. (013)
This whole area has given rise to two related areas of academic and industrial
research:
- how to extract (reverse engineer) an ontology from software artifacts and
supporting documentation
- how to formalize the relationships between software artifacts and a
"reference ontology" for the application domain (014)
After an increasing body of work over the last roughly 10 years, neither of
these problems is solved. There is a handful of competing "methods" and tools
to support the human knowledge engineer in extracting a formal ontology from
software and defining the relationships. These are knowledge engineering
activities that we have not been able to automate and are the subject of
research with potentially very high return. (015)
> 4. Formal & explicit: The ontology is formal, and it is explicitly
> linked to the code and the data.
>
> > Now, John may believe that there are 'ontologies' written in COBOL,
>
> I cited the legacy re-engineering project. Arun Majumdar and Andre LeClerc
> used a version of the VivoMind software to analyze the COBOL code and the
> SQL definitions to determine the structure of the programs, the structure of
> the data, and what the programs did with the data. ... (016)
And there is the OMG Knowledge Definition Metamodel, implemented by
half-a-dozen vendors who sell software analysis tools. And there are a dozen
"ontology-based software analysis" product development activities being funded
by US, EU and Japanese government research programs, in order to produce
"software assurance" -- the knowledge that the software does what was intended
an nothing else. And OBTW, my division at NIST is on its 5th and 6th "semantic
mapping" projects to extract ontologies from existing formal artifacts like
competing standards for industry information exchange. (017)
The very smart VivoMind guys were needed, precisely because the "ontology" and
the "semantic mapping" they built were NOT THERE when they started. Saying
that there is an "implicit ontology" in a bunch of COBOL and SQL schemas is
like saying there is an implicit NASCAR championship vehicle in a junkyard. It
takes a skilled engineer to turn the mice and pumpkins into a coach and four.
The VivoMind guys were not the first, and they won't be the last. Yes, some of
us know how to do the knowledge engineering involved. But the ontology and the
mappings are the products of skilled engineering, not just latent in the raw
material. (018)
-Ed (019)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Systems Integration Division
100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800 (020)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (021)
_________________________________________________________________
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 (022)
|