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>
From: "Matthew West" <matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 2 Mar 2012 07:36:53 -0000
Message-id: <000001ccf847$3f60d9a0$be228ce0$@west@informationjunction.co.uk>
Dear Henson,    (01)

> I am sure that there are more than a few things that I have misunderstood
> about ISO 15926. In what you say there is only one place where I think you
and
> others are glossing  over something very important, that is the issue of
> formal (logic-) based semantics.
> 
> MW: ISO 15926 Part 2 is written in EXPRESS, a data modelling language of
> roughly the same capabilities as the UML static modelling language. As you
> say, you have to start somewhere. But what we effectively did, was to
build a
> new language with it. The key thing you cannot do with UML or any data
> modelling language is go through multiple levels of abstraction (instance
> of) within a single model space. We needed to do that in ISO 15926, and
the
> result is very powerful.
> 
> HG: Of course 1SO 15926 builds on a rich base of practice. I understand
> calling UML a modeling language, but I don't understand calling it a data
> modeling language. That usage seems incorrect to me. I use UML to model
things
> like molecules and the human heart. The model itself is data as is any
model,
> but the thing modeled is not data.    (02)

MW: Formally, the UML static modelling language defines data structures for
programs. There is nothing to stop you using that language to model the
things the data represents, just as there is nothing to stop you taking that
model of things and use it to hold data.
> 
> MW: In fact we have created a graphical notation around this, which has
been
> very useful for working out details, but is a bit like assembler, you need
> quite a lot to do something simple.
> 
> HG: the thing worth noting about having a good graphical syntax is that
with a
> good graphical syntax mere mortals can build models. I am using "model" in
the
> engineer's sense. In practice good graphics has an enormous impact on user
> acceptance.
> 
> MW: Strictly, I think it is better to have a language layer that is
> ontologically neutral, and then a layer that is your ontological
commitments,
> and then a layer that is your domain model(s) but they do not have to be
in
> different meta spaces. Yes. Your base language should have as few
ontological
> commitments as possible.  The commitment that UML makes is the separation
> between classes and instances, and that is unfortunate in my view.
> 
> HG: agreed about placing the ontological commitments in the meta-space.
> This is the way that Conrad Bock and I are using the MOF layers to provide
> ontology to UML.  See comments on separation below.
> MW: The result for ISO 15926 is that there is no separation into these
levels,
> but we did include the ontological commitments at this stage.
> 
> HG: I am a bit unclear what you mean by separation of levels and what you
mean
> when you say that the separation of instances and classes. I don't think
that
> you mean that there is no difference between an individual and a class, or
> type. In mathematics 3 is an individual which is an instance of
> some number type.   What I think you are saying is that UML does not have
> hierarchies of the form  a:U, and U:X where you have U being both an
instance
> and a type. If this is what you are saying then I agree with you,     (03)

MW: Yes that is what I am saying. The consequence is that what in UML needs
to be held at a number of meta layers can be held in different parts of one
model.    (04)

> but from my
> viewpoint this makes it even more important that there be a logic based
> semantics, or there will be tears in the long run.    (05)

MW: At the moment ISO 15926 is light on formal semantics. The only formal
semantics are in the cardinality constraints on relationships. These have a
very straight forward translation into any form of logic.
> 
> MW: Its foundations are in EXPRESS (strictly a subset of EXPRESS) from
which
> it gets its logic based semantics.
> 
> HG: This puzzles me a lot and even frightens me. I am unaware that EXPRESS
has
> a logic based semantics. What is it? By logic-based semantics I mean FOL,
DL,
> type theory, HOL, or something with a real inferfence system and a model
> theory. I am using model theory in the logician's sense. And I would hope
that
> the logic system has the requisite soundness and completeness results.    (06)

MW: As a whole, EXPRESS does not, but as I said above, the only parts we use
rely on cardinality constraints that are quite straight forward.
> 
> MW: The ontological commitments are the standard 4D ones with an
extensional
> basis for identity of individuals and classes, together with possible
worlds
> to deal with semantics. For example, it contains all you need to model the
> pump example we have been discussing.
> 
> HG: that seems ok if you really have a formal semantics, and you can
really
> specify the semantics of the ontological commitments in a precise way,
> otherwise you just have a terminology, not an ontology.    (07)

MW: The most formal representation of ISO 15926 are the OWL translations
from EXPRESS. However, OWL is not really satisfactory for our needs. It
suffers from the same problems as UML with regard to classification.    (08)

MW: That is work to be done. It is available in English of course, and there
are standard axiomatisations of things like mereotopology and set theory
which are the backbone of the semantics we need, but with the emphasis on
data integration, reasoning is not that high a priority. I expect this to
come over the next few years. At the moment I would be inclined to use CL
for this. It can handle all our requirements, including the multiple levels
of classification.    (09)

MW: What we will not do is develop axioms "because they are there". We will
develop the axioms we need for the tasks in hand. So for example, at the
moment it looks like it would be useful to develop axioms that say that two
different ordinary physical objects at the same level of reality are not
coincident, because this means that when you are updating a database, if you
have found one object that is in the right place, you know it's the one you
wanted, and you don't have to consider others. However, what we are not
concerned about are axioms that would allow us to do general reasoning over
the model. At the moment we do not have requirements to do that. It's just
not where the financial priorities are.
> 
> MW: There are only limited tools to support its use, but I would not
expect
> many - it is not after all like UML. It is not in use in the defence
industry
> so I would not expect submarines to be built with it, but offshore oil
rigs
> and undersea installations have used it, and the main CAD systems used in
the
> process industry claim to support it. The nuclear industry is considering
it.
> 
> HG: To get wide acceptance across aerospace, and automobiles, and many
other
> industries is unlikely to happen unless there are good, scalable tools
with a
> usage track record.    (010)

MW: For the most part, ISO 15926 is supposed to be part of the plumbing,
rather than something that engineers see and use on a daily basis. If
engineering software systems are just able to communicate without apparent
effort to the users of those systems, we will have done our job and no one
will even notice. Engineers will be using the software systems they have
always used.    (011)

Regards    (012)

Matthew West                            
Information  Junction
Tel: +44 1489 880185
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
http://www.matthew-west.org.uk/    (013)

This email originates from Information Junction Ltd. Registered in England
and Wales No. 6632177.
Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
Hertfordshire, SG6 3JE.    (014)


> 
> Regards
> -     Henson
> 
> 
> -----Original Message-----
> From: Matthew West [mailto:matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, March 01, 2012 4:34 PM
> To: 'henson graves'; '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: 'Chris Partridge'
> Subject: RE: INCOSE Ontology Action Group, onto SysML/UML
> 
> Dear Henson,
> 
> There are a few things that you seem to have misunderstood about ISO
15926.
> 
> <snip>
> >
> > 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.
> 
> MW: ISO 15926 Part 2 is written in EXPRESS, a data modelling language of
> roughly the same capabilities as the UML static modelling language. As you
> say, you have to start somewhere. But what we effectively did, was to
build a
> new language with it. The key thing you cannot do with UML or any data
> modelling language is go through multiple levels of abstraction (instance
> of) within a single model space. We needed to do that in ISO 15926, and
the
> result is very powerful.
> 
> MW: In fact we have created a graphical notation around this, which has
been
> very useful for working out details, but is a bit like assembler, you need
> quite a lot to do something simple.
> >
> > 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.
> 
> MW: The result for ISO 15926 is that there is no separation into these
levels,
> but we did include the ontological commitments at this stage.
> 
> MW: Strictly, I think it is better to have a language layer that is
> ontologically neutral, and then a layer that is your ontological
commitments,
> and then a layer that is your domain model(s) but they do not have to be
in
> different meta spaces.
> >
> > Ontological Commitment:
> <snip>
> >  As noted UML's
> > ontological commitment is weak, this is a good thing for getting
> > things
> right
> > in the future.
> 
> MW: Yes. Your base language should have as few ontological commitments as
> possible. The commitment that UML makes is the separation between classes
and
> instances, and that is unfortunate in my view.
> 
> <snip>
> 
> > 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?
> 
> MW: Its foundations are in EXPRESS (strictly a subset of EXPRESS) from
which
> it gets its logic based semantics.
> The ontological commitments are the standard 4D ones with an extensional
basis
> for identity of individuals and classes, together with possible worlds to
deal
> with semantics. For example, it contains all you need to model the pump
> example we have been discussing.
> There are only limited tools to support its use, but I would not expect
many
> - it is not after all like UML.
> It is not in use in the defence industry so I would not expect submarines
to
> be built with it, but offshore oil rigs and undersea installations have
used
> it, and the main CAD systems used in the process industry claim to support
it.
> The nuclear industry is considering it.
> It certainly won't build autopoietic systems for you, so it is certainly
not
> sufficient, however, it contains nothing that would prevent you from using
it
> to build them either.
> 
> Regards
> 
> Matthew West
> Information  Junction
> Tel: +44 1489 880185
> Mobile: +44 750 3385279
> Skype: dr.matthew.west
> matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> http://www.informationjunction.co.uk/
> http://www.matthew-west.org.uk/
> 
> This email originates from Information Junction Ltd. Registered in England
and
> Wales No. 6632177.
> Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
> Hertfordshire, SG6 3JE.
> 
> 
> > 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
> >
> >
> 
> 
>     (015)




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