Dear Anatoly,
You say that a plan future (for engineering modeling languages) on a base of
current "de facto" legacy is not good even if we label it as a pragmatic
argument. To suggest that my argument for building on UML is equivalent to
arguing for building on COBOL is nonsense; you either misconstrue or
misunderstand what I am saying. (01)
I am saying the UML family satisfies specific criteria that enable one to
evolve it rather than starting over with something new. If COBOL had the
demonstrated capability to be used to design a submarine by a multinational
enterprise, had good graphics notation, had scalable tools, and had a formal
logic-based semantics then COBOL would meet the criteria that we both appear
to believe necessary. I would be the first one to suggest be used as the
basis for the future. (02)
Where to begin: It is always easy to say throw out the old and bring the
new. Indeed sometimes this is the way to go. For this to make sense one
should articulate where the old is insufficient, what is better, and why the
old cannot be evolved to the new. People always use tools (which include
languages) on the one hand as a magic bullet, and on the other hand as
something to blame when things go badly. You state that one needs a good
notation, a formal semantics and a logic paradigm and a fair amount of
ontology commitments. I agree, but to be clear when I say formal semantics I
mean logic-based semantics. There are other factors that have to do with
success such as acceptance factors. (03)
Language and Notation: As I am sure that you would agree language details
matter a great deal in establishing the necessary conditions for a language
to be successful, but they are not sufficient. I believe that you noted
that your proposed candidate ISO 15926 did not have a good notation. There
are deep reasons that have to do with foundations of mathematics and
ontology why UML is successful where its predecessors where not. Its
superiority over its successors has been validated empirically by its
success in building large systems. This is not to say that it doesn't need
improvement. It is to say that one wants to build on its success, which of
course means you have to understand why it is successful. (04)
Formal Semantics: You say Formal semantic for such a language is
prerequisite, but there are many languages with formal semantics. Which to
choose? Which one do you choose and why? The choice of language is a
serious business, not an academic one. There are perfectly good languages
with formal (logical) semantics that have been around for a long time that
conceivably have sufficient expressivity for engineering applications. Yet
they are not in common use in engineering. One might ask why. The reason is
an "engineering problem".
Integration of Ontology with modeling languages: You note that Conrad Bock
at al. had papers where they argue for more substantial integration of
ontology into product modeling languages and suggest an approach which is to
capture patterns such as "Product Model" or "System" as meta-classes at the
M2 Level in the MOF architecture. This makes good sense to me and I agree
with this viewpoint. However, this view is perfectly consistent with the
building on UML argument. One still needs a language which is or is embedded
as the language of a logic. The meta-classes which describe the ontological
patterns such as Product Model are simply specializations of the meta-class
for model at the M2 level. (05)
Ontological Commitment: We all want ontological commitment, but to what?
Without a pretty firm understanding of the logic requirements, ontology
commitments can hardly go beyond terminology. Even terminology seems to be
difficult. Incorrect ontological commitment (in the sense of Nicola) is very
dangerous. In my opinion it is better to have a language with weak
ontological commitment with a facility to make the ontological commitment
extensible. As we are aware UML has only very slight ontological commitment
beyond basic class and property language constructions. It does at least
have a concept of "part" which represents an ontological commitment.
Conrad's approach to integration of ontology with modeling languages using
the OMG MOF framework allows us to start with a modeling language family
(UML) and add ontology patterns as they become sufficiently stable. Conrad
points out that UML as spec'd has open semantics, even though many interpret
it as closed. To me the ability to specify meta-level semantics for use in
building models is the essence of a language's openness. I do not know for
sure if this is the way that Conrad is using the term. As noted UML's
ontological commitment is weak, this is a good thing for getting things
right in the future. (06)
Modeling-in-the large: You note that one needs a language for architecting
and modeling-in-the-large, where one assembles architectural work of many
people. I certainly agree. As I have stated before my opinion is that
solving the in-the-large problem is more a methodology issue than a language
defect. Conrad also points out that a language with open semantics is
important for assembling work of many people; in that sense a language with
open semantics is better suited for "in the large" than others. I have a
lot of direct experience with UML and SysML both failing and succeeding on
large multi-company and multi-national product development programs. It is
not really too hard to understand what caused the failures, but they were
not primarily defect with the modeling language, even though they have
defects. Specifically I have used UML to represent the design for an
information system that federated multiple large legacy systems. The UML
model contained both a user level ontology and the transformations between
that and the legacy system's interface. Many legacy systems have a
web-services interface which enables interface without any code on the
legacy systems being changed. (07)
Acceptance Factors: Large enterprises almost always correctly make fairly
conservative choices regarding tools and methodology. They correctly do not
want to add to whatever risk they already incur. This is one place where I
agree with the sentiment that sociology and politics, and global warming or
its absence all plays a part in the success or failure of engineering
efforts. I do not believe, however that these aspects are necessary for a
specification which tells what to build as opposed to why one wants to build
something. (08)
Your Proposed Solution: You propose JSO 15926 as a candidate. Can you
explain what its formal logic-based semantics is and its ontology
commitments are, and what kind of usage and tool support it has, what
submarines and nuclear reactors have been built with it? Is it sufficient to
build autopoietic systems?
Regards,
Henson
-----Original Message-----
From: Anatoly Levenchuk [mailto:ailev@xxxxxxxxxxx]
Sent: Friday, February 24, 2012 12:00 PM
To: 'henson graves'; 'Bock, Conrad'; chris.paredis@xxxxxxxxxx; 'David
Price'; 'Fredrick A Steiner'; 'Victor Agroskin';
Ron_C_Williamson@xxxxxxxxxxxx; 'David Leal'; 'Ontology Summit 2012
discussion'
Cc: 'Matthew West'; Chris Partridge
Subject: RE: INCOSE Ontology Action Group, onto SysML/UML (09)
Dear Henson, (010)
Argument about huge legacy as a reason to plan future on a base of current
"de facto" legacy is not good even if we can label it with "pragmatic".
According this thinking we should bring formal semantics to COBOL and stay
with this COBOL FORMAL to eternity due to many years of status of COBOL as
de facto standard of programming. (011)
There are programming-in-the-small (one team, one computer) and
programming-in-the-large (web programming),
http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the
_small. There are different language patterns in these different kinds of
programming-in-the-*. I regard programming, modeling and ontologizing as
different facets of one discipline. Architectural modeling (with languages
like SysML or ArchiMate) is simply subdiscipline of this general discipline.
As a systems engineer I need language for arhcitecturing that support
modeling-in-the-large, where I every day assemble architectural work of many
people. Formal semantic for such a language is prerequisite, but there are
many languages with formal semantics. Which to choose? (012)
Most detailed answer I found in a book of Chris Partridge "Business Objects:
Re-Engineering for Re-Use"
http://www.borosolutions.co.uk/research/content/files/books/BusObj-Printed-2
0050531-with-watermark.pdf/at_download/file (while this book has no
references to UML or ISO 15926 or any other language or software or
standard). To have scalable for eco-system architecture (or any other)
description I need abandon substance paradigm (that is very intuitive!) to
logic paradigm (that is not intuitive at all, this is counterintuitive). In
another word I need architectural description not in objects-with-attribute
(object-oriented, like UML/SysML) languages but in objects-with-relations
(fact-oriented, like ArchiMate or ISO 15926) languages. (013)
We have difficulties when tried to introduce ISO 15926 in Russia: nobody
understand why they need something new in this Big Systems game (namely
Nuclear Power Plants and Shipbuilding industries). Now we start our "crash
course" of PLM integration with introducing of "Business Objects:
Re-Engineering for Re-Use". After this our clients knows names of
integration (in-the-large) problems they have and knows what can be
solutions (logic paradigm, not formal semantics for substance paradigm) to
their problems. Then ISO 15926 study is very easy: people understand what
theory behind ISO 15926 counterintuitiveness and why we need it. (014)
I consider that we need not only "good notation" and "formal semantics", and
"logic paradigm" but also a fair amount of documented ontology commitments
in an architectural language. I follow intuition of Conrad Bock et al. for
embedding ontology into architectural language. Also I am not rely on UML
approach to language (multiple diagrams, attributes) and follow intuition of
ArchiMate (http://www.opengroup.org/archimate/doc/ts_archimate/) in
architectural language definition. By the way, one of three intended
audiences of ArchiMate is "The academic community, on which we rely for
amending and improving the language based on state-of-the-art research
results in the architecture field". (015)
Why ISO 15926? It has a notion of system right out of the box. While SysML
have no notion of a system, sorry. I support position of Matthew West in
discussion about system component. There are many nuances about it in ISO
15926 community but all this nuances support engineering intuitions while
position of ontologists-non-engineers not supporting it. ArchiMate support
notion of system indirectly, via Services and Interfaces. I need more. (016)
There are many other examples of "formal semantics for bad language = bad
results", e.g. OWL. But this is another story :-) (017)
Best regards,
Anatoly (018)
> -----Original Message-----
> From: henson graves [mailto:henson.graves@xxxxxxxxxxx]
> Sent: Friday, February 24, 2012 7:30 AM
> To: 'Anatoly Levenchuk'; 'Bock, Conrad'; chris.paredis@xxxxxxxxxx;
> 'David Price'; 'Fredrick A Steiner'; 'Victor Agroskin';
> Ron_C_Williamson@xxxxxxxxxxxx; 'David Leal'; 'Ontology Summit 2012
> discussion'
> Cc: 'Matthew West'
> Subject: RE: INCOSE Ontology Action Group, onto SysML/UML
>
> Dear Anatoly,
> As I understand it you suggesting is that given the deficiencies of
> the
UML
> family languages regarding scaling to business eco-systems one should
start
> over. I have to disagree with you; the disagreement is pragmatic.
> What I see is that UML and SysML while needing improvement have
> become defacto standards in many engineering domains. This family of
> languages
is
> slowly getting a formal semantics, they have good tool support, and
> they
are
> being used on a wide scale. Further, OMG the keeper of these
> language specifications recognizes that the standards need
> improvement and are beginning to recognize that the languages need a
> formal semantics. There are several RFPs from OMG related to this.
> One of them is called
something
> like a" precise semantics for composite structure"
> The difficulty with scaling to eco-systems is not in my opinion a
language of
> UML or any other language; is a system engineering methodology defect.
> One has to develop and enforce some common terminology (ontology?)
> and some interoperability standards to expect to get consistent
> integrated architecture. this commonality currently exists in the CAD
> world and many multinational companies collaborate. Developing some
> commonality at least where things interface can work for use of UML in an
eco-system.
The
> lack of this kind of hygiene is also responsible for even small
> projects
failing.
>
> Regards
> - Henson
>
> -----Original Message-----
> From: Anatoly Levenchuk [mailto:ailev@xxxxxxxxxxx]
> Sent: Thursday, February 23, 2012 2:45 PM
> To: 'Bock, Conrad'; 'henson graves'; chris.paredis@xxxxxxxxxx; 'David
Price';
> 'Fredrick A Steiner'; 'Victor Agroskin';
> Ron_C_Williamson@xxxxxxxxxxxx; 'David Leal'
> Cc: Matthew West
> Subject: RE: INCOSE Ontology Action Group, onto SysML/UML
>
> Conrad,
> Thank you for pointing me to the right links for your works.
>
> I appreciate your ideas about adding ontology to product, behavior
> and project descriptions languages, especially architecture languages.
>
> I know that UML 2 and MOF are a big leap to formal semantics in MDA
> world.
> But for me this is not enough to enable UML family languages scaling
> to business eco-systems (beyond one enterprise). What is an object in
> one project appears as an attribute in another and vice versa
> (lessons
learned
> from work of EPISTLE consortium). There was extended discussion in
> ISO
> 15926 community that build on EPISTLE experience.
>
> I carefully see development of ArchiMate as a very successful
fact-oriented
> architectural language. There are no attributes in ArchiMate, and
> still
they
> have no formal semantics. Sure, they have almost no ontology
> features. I think that eventually they will have 1) formal semantics,
> will add 2)
ontology
> features (the two things that you provided with UML and OPML) and
> continue be 3) fact-oriented. I am wonder how many years 1) and 2)
> will
take
> (I guess no less that this was taken by UML).
>
> Personally I try to use ISO 15926 as an engineering ontology, but it
> is
not a
> language because has no good notations. My team is thinking about
> language workbench (http://www.languageworkbenches.net) supporting
> multiple engineering DSL on a base of ISO 15926 representation of
system-of-
> interest, systems in operational environment and enabling systems.
> Sure, most of this DSL will be established languages for specialty
> engineering
but
> we still need a good architectural language. Your work on OPML give
> us inspiration to continue think about fact-oriented variant of such
> a
language
> with strong ontology flavor and still usable by engineers.
>
> Best regards,
> Anatoly
>
> > -----Original Message-----
> > From: Bock, Conrad [mailto:conrad.bock@xxxxxxxx] > Sent:
> Thursday, February 23, 2012 12:46 AM > To: Anatoly Levenchuk;
> 'henson graves'; chris.paredis@xxxxxxxxxx; > 'David Price';
> 'Fredrick A Steiner'; 'Victor Agroskin'; >
> Ron_C_Williamson@xxxxxxxxxxxx; 'David Leal'
> > Subject: RE: INCOSE Ontology Action Group, onto SysML/UML > >
> Anatoly, >
> > > Conrad Bock at al. had papers where they urge for "more ontology
> > > in product modeling languages" and suggest alternatives like
> OPML > > (Ontological Product Modeling Language, > >
> http://www.cesames.net/fichier.php?id=370) that go beyond UML while >
> > still not fact-oriented.
> >
> > Thanks for referring to this, but the link goes to a paper that >
> should not be > distributed (see its header), are you able to take
> it down? The distributable > paper is at >
> http://www.nist.gov/manuscript-publication-search.cfm?pub_id=822748
> > and slides at
> >
> http://conradbock.org/ontological-product-modeling-short-slides.pdf
> >
> > > We found that SysML is not as good to be a basement of overall
> > MBSE > initiative. We consider many other alternatives that more
> > fond of > ontology.
> >
> > UML 2 introduced significant logical interpretations that are
> carried over to > SysML. The above paper uses UML. A similar
> paper on onto behavior > modeling also uses UML
> (http://dx.doi.org/10.5381/jot.2011.10.1.a3).
> >
> > Conrad (019)
_________________________________________________________________
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/ (020)
|