John's principles and their application summarize the issue well for those
who think that formal semantics, and formal ontology have great benefits for
better models, improved collaboration, well-defined standards, and
incorporating reasoning. (01)
My experience in this arena has been that adoption of modeling languages is
to retrofit what engineers or other modelers find works for them. In doing
so one can generally sell improvement and extensions which bring language
and practice in line with what has been learned and built on from formal
systems. Of course sometimes things go in the other direction. For example
the apparently non-sense notation and practice of physics eventually had a
strong impact on mathematics. My opinion is that Matthew West's example
should serve the same role for formal foundations. But back to Bradley's
issue. (02)
I have witnessed the success of the kind of strategy in at least three
cases. I mention the UML situation as it seems topical. First I watched the
adoption of UML/SysML as the standard practice in an aerospace company. This
took about 10 years. Initially there was immense resistance from engineers,
system engineers couldn't see the need for anything beyond PowerPoint and
Excel, and software engineers only wanted to do code. Managers came on board
even more slowly as PowerPoint was the only thing they understood. They ways
were the transition went wrong and what caused it to eventually work are
very interesting but would take too long to spell out here. I only mention
that COBOL and FORTRAN would not have sufficed for this role. The question
of why previous generation of graphical design tools didn't work is very
interesting and has to do with confusions about instances and classes and
part and roles. To address SysML buy in from manager we use SysML to
generate simulation models, both high and low fidelity models. We can
generate better PowerPoint for the managers and customers. Not only do they
explain things well the simulations are tied intrinsically to the design. As
many of you know PowerPoint design generally does not correspond to what the
design actually is. This has obvious advantages. (03)
So what is the path ahead? Do they need anything better, and how will tech
transition be achieved. Well two things. Here is where I see a practical
problem of interest to engineers which requires a solution that they don't
currently have. Currently design models do not generally contain
assumptions under which a component of a design is valid. This leads to
inconsistent designs. In engineering terms they make decisions without being
aware of the consequences until units are build and tested. Then the
problems are found and sometimes result in significant cost and schedule
overrun, e.g., several years and hundreds of millions of dollars. One can
by extending UML with some DL class constructions represent these
assumptions and use automated inference to continually track evolving design
consistency. I think there is good reason to believe that engineers will buy
into this. (04)
- Henson (05)
-----Original Message-----
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Wednesday, March 07, 2012 8:05 AM
To: ontology-summit@xxxxxxxxxxxxxxxx
Subject: Re: [ontology-summit] INCOSE Ontology Action Group, onto SysML/UML (06)
On 3/7/2012 7:48 AM, Bradley Shoebottom wrote:
> Since our information is created in OASIS DITA XML, RDF and OWL seem
> to be attractive mechanisms. The difficulty is that we can create
> knowledge models suitable for publishing information, but the system
> engineers are not using this toolset. Getting them on-board is our
> missing link. (07)
Fundamental principle #1: Nobody who is traveling on a ship at sea will
voluntarily leave their boat to get on board your boat. (08)
Fundamental principle #2: Your religion may bless your method as the more
virtuous, but other people believe in other religions. (09)
Fundamental principle #3: The simplest way to make people virtuous is to
make virtue the path of least resistance. (010)
> One of questions is do we extend OWL right to the engineers, or let
> them use their current modelling tools and try to map to OWL.
>
> We do not have a complete answer, but a decade for user adoption
> phase-in is a bit disheartening. (011)
I certainly agree with the last sentence. My suggestion is to apply the
three principles above to derive an answer to your question: (012)
1. As you have noted, the engineers show little or no interest
in leaving their boat to get on yours. (013)
2. The engineers have their own religion(s), which probably do not
include your religious rites among their perceived virtues. (014)
3. Instead of trying to get them to abandon their current virtues
in order to follow your path to salvation, I suggest that you
build a clear, smooth branch from their current path to yours. (015)
Note the methods used by successful missionaries to make converts to a new
religion: don't stop them from doing what they have always been doing.
Instead, study their practices and adapt them to your religion in a way that
enhances what they are going to do anyway. (016)
Show them that they can get new benefits with a minimal amount of additional
effort. Better yet, show that they can actually reduce the total amount of
effort by adopting the revised methods. (017)
I realize that you probably don't have enough resources to build their
methods into your tools. But you may find a few engineers who are already
sympathetic to your approach. Instead of bringing them on board your ship,
join them on *their* ship and work with them to add the tools that make
their practices work successfully with yours. (018)
Fundamental principle #4: Instead of making people abandon their religion
in favor of yours, help them adapt their religion to yours. (019)
John (020)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
Community Portal: http://ontolog.cim3.net/wiki/ (021)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
Community Portal: http://ontolog.cim3.net/wiki/ (022)
|