I work with engineers who have a day job and recognize that they need
ontologies to do their work. [I have a lot of experience with being in their
shoes.] The ontologies are needed to model, i.e., describe and specify systems
and their operations in the real world. The models are used to design and
analyze vehicles, aircraft, etc. The recognition of the need for ontology is
that the operating environment descriptions need to be much more complex and are
much more changeable than they were 50 years ago. The use of ontology also
increasingly applies to some of the systems being built. They use ontologies to
process the enormous volume of data that they ingest at operation time, and use
some inference to take actions. The software of some of these systems
contains a model of the system as well as its environment which it uses at
runtime for flight control and threat avoidance.
To be of any use the ontologies have to be imported into the development
tools which they use. The mostly UML based tools (including SysML) are now
robust, ordinary engineers can and do use them to develop large complex systems.
By and large these folks cannot or will not use traditional logic syntax. Also
there are not commercial grade tools that have been proven in the industrial
context. This doesn’t mean that these language don’t need a formal semantics,
and need extensions to handle the applications that they are being used for.
They do. I have been arguing for a long time that the formal methods folks
should focus on retrofitting and evolving these tools, rather than attempting to
develop new ones.
As a practical note, I believe that the SysML community is more receptive
to something such as William Frank advocates than the UML community. The reason
being that sociologically the engineering community has to deal with a much
broader scope of applications than the UML community. If the battery fire on a
commercial aircraft causes a crash then the manufacturer will certainly be sued
and will be asked to produce the analysis and test results that were used to
declare the aircraft safe to fly. If these results are not compelling the
manufacture is in big trouble. Engineers are beginning to get this.
As a comment on Ron Wheeler’s comment the ontologies I see in the big data
world if they deserve the name ontologies, are currently much simpler than the
kind of ontologies mentioned here. However, if these systems are to be used for
medical diagnosis, and drug design and analysis then they will have to have the
complexity of the ones I am talking about.
I do not know of anywhere within a university context material relevant to
this discussion is being taught. There presently doesn’t even seem to be any
traditional departments willing to pick this up, in my limited experience.
By the way, I am passing along John’s slides to a group I am working with
which is in desperate need of an upper ontology.
Sent: Tuesday, February 18, 2014 9:15 AM
Subject: Re: [ontolog-forum] Good ontologies without good tools are
UML based on a many-sorted higher order predicate calculus
with Henkin semantics, and a simple upper ontology represented by the
this is what we (Joauquin Miller, Kevin Tyson, and
I) proposed for UML 2, in Clear, Clean, Concise (3C) UML
Communications of the ACM, Nov 2002, volume 45, no. 11 pages 79 -
"The Clear, Clean, Concise (3C) UML2 proposal makes the
easier to understand and enables it to describe a broader
of systems, from Web agents and services to entire
This was never going to happen, at that
point. The agenda was set by Oracle and IBM, with no regard for the
benefits to the long term future of systems engineering. Also, I
misunderstood people so much that instead of referencing the science, I simply
explained the BENEFITS, and showed how simple
it was to use this
language, so I now suspect they thought this was some new off-the-wall approach
invented by us three.
I agree with all you say below,
John, but add that an equally important feature integrated into a cosistent set
of of UML models, along with the 4 you list, are state - transition models, the
backbone, in my opinion, for precise behavior specifications.
Myself, I find UML diagrams, with my OWN simple simple common logic semantics,
the most effective way to ensure a system consistency, because of all these
Community Wiki: http://ontolog.cim3.net/wiki/