ontology-summit
[Top] [All Lists]

Re: [ontology-summit] INCOSE Ontology Action Group, onto SysML/UML

To: "'henson graves'" <henson.graves@xxxxxxxxxxx>, "'Anatoly Levenchuk'" <ailev@xxxxxxxxxxx>, "'Bock, Conrad'" <conrad.bock@xxxxxxxx>, <chris.paredis@xxxxxxxxxx>, "'David Price'" <dprice@xxxxxxxxxxxxxxx>, "'Fredrick A Steiner'" <fsteiner@xxxxxxxxxxxx>, "'Victor Agroskin'" <vic5784@xxxxxxxxx>, <Ron_C_Williamson@xxxxxxxxxxxx>, "'David Leal'" <david.leal@xxxxxxxxxxxxxxxxxxx>, "'Ontology Summit 2012 discussion'" <ontology-summit@xxxxxxxxxxxxxxxx>
Cc: 'Chris Partridge' <mail@xxxxxxxxxxxxxxxxxx>, 'Matthew West' <matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx>
From: "Chris Partridge" <partridge.csj@xxxxxxxxx>
Date: Thu, 1 Mar 2012 21:11:40 -0000
Message-id: <016e01ccf7ef$e6a21c90$b3e655b0$@gmail.com>
Hi Henson,    (01)

It sounds as if you have had a lively discussion, and my comments might not
be to the point as I was not involved.
I guess this is an apology in advance.    (02)

Chris    (03)

> -----Original Message-----
> From: henson graves [mailto:henson.graves@xxxxxxxxxxx]
> Sent: 01 March 2012 20:51
> 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'; 'Chris Partridge'
> Subject: RE: INCOSE Ontology Action Group, onto SysML/UML
> 
> 
> 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.
> 
> 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.    (04)

I guess I am with Anatoly here. My view is that UML (as per its
specification) belongs in the same camp as COBOL - that is not to condemn
it, merely to classify it.
My question would be whether UML (or add your candidate here) has
demonstrated any ability to clearly show its ontological commitments. 
I guess Cory would have made the same point about UMLs shortcomings as this
has been discussed extensively in his workgroup.
BTW That is not to say that one cannot use UML diagramming to do (for
example) ISO 15926 modelling. We also use UML diagrams for IDEAS. I guess a
lot of people do the same thing.    (05)

> 
> Where to begin:  It is always easy to say throw out the old and bring the
new.    (06)

My motto is a bit different - it is to try and salvage all that is good in
the old and migrate it to the new.    (07)

> 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.     (08)

Agreed - absolutely. I have two projects where we are doing exactly that wrt
UML.    (09)

>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.      (010)

logic-based semantics? What had you in mind? And how do you get from there
to the intended interpretation?    (011)

>There are other factors that have to do with
> success such as acceptance factors.
> 
> 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.     (012)

I'd be very surprised if you were able to point to anything to do with
ontology that contributed to UML success (which its predecessor did not
have) - and enjoy being surprised. I'd be merely interested in the
mathematical points.    (013)

>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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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
> 
> Dear Henson,
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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".
> 
> 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.
> 
> There are many other examples of "formal semantics for bad language = bad
> results", e.g. OWL. But this is another story :-)
> 
> Best regards,
> Anatoly
> 
> >  -----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
>     (014)



_________________________________________________________________
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/     (015)
<Prev in Thread] Current Thread [Next in Thread>