Dear Henson,
There was a lot of a discussion that goes to "formal semantics' direction. I
confirm that formal semantics is a "must" requirement to any language that
we can discuss here. There can be only choice of particular life cycle model
for a language: formal semantics is the first and "success" is the second;
or "success" is the first and formal semantics should be developed for
survivals "successful" languages only. (01)
Many arguments were answered by Chris, Matthew, David, John etc., thank you
very much. Let's return to not touched yet arguments of the discussion. (02)
I consider 3 generations of systems engineering:
-- "alchemic" (sketches and informal descriptions)
-- contemporary (diagrams and drawings without formal semantics)
-- model-based (MBSE) that means formal semantic (and no more). (03)
Thus UML/SysML or ISO 15926 (AADL, or even P&ID, etc.) discussion about
theirs formal semantics sure relate to MBSE. I urge for not privatizing of
all MBSE only by one language of past (substance, 2000 years old) paradigm.
There are alternatives here. (04)
> I am saying the UML family satisfies specific criteria that enable one to
> evolve it rather than starting over with something new. (05)
I completely agree of need for the language to be evolvable to a multiple
DSL for different engineering specialties. It should be not "closed"
language but convenient basis for a bunch of higher level specialization
languages. In programming many of the languages provides now such a
possibility. Even Fortran had procedures and common blocks that was a
rudimentary way to lift language level. Ancient Forth was permitting
redefine language on the fly and use not only new semantic but also
syntactic structures in it. There was POL in those times, not DSL
(problem-oriented languages, not domain-specific languages). Ideal onto
language should be as well flexible to support DSLs on it base. UML is
extendable with stereotypes, it is good. It will add years of prosperity to
it. We will see UML 2015 as we saw Fortran 77, 90, 95, 2003, 2008
(international standard adopted at 2010 -- ISO/IEC 1539-1:2010,
http://en.wikipedia.org/wiki/Fortran). Long live Fortran and UML! But,
please, live not with me. There exist another paradigm languages. (06)
Let get specific criteria list for an engineering language of choice: (07)
1. Formal semantics. This is necessary but not sufficient. This is machine
codes, only to most brave people in the world create on this level, Titans
and Heroes. (08)
2. Low level language to integrate all (like Assembler: it has low
expressivity but multiple paradigm languages compiled to this language). ISO
15926 is not my favorite language but is a good example with Part 2 of ISO
15926. This is semantic network with embedded ontology (mereotopology, 4D
extensionalism, class of classes, etc.). There will be formal semantics with
OWL 2 (DL and FOL variants), but I am prefer here HOL and not OWL at all.
OWL is not better for me than UML while for different set of reasons (I will
omit it here). (09)
I can express life cycle of a Valve in this Assembler in a reduced form:
http://techinvestlab.ru/pictures/iso15926_sample_diagrams/lcintegrsimple.png
Then I can express the same life cycle of the same Valve in the same
Assembler with more details:
http://techinvestlab.ru/pictures/iso15926_sample_diagrams/lcintegrfull.png (010)
3. Macro assembler or/and subroutines. I want not program in Turing Machine
language, even in Logic Turing Machine. I want go high. ISO 15926 (this is
example, only) have templates (Part 7) that essentially a "logical macro"
for a Part 2. You have a template (e.g. engineering Excell table that is
better than "engineering semantic network with reified relations"), then
work of "logical macro processor" and after this we have semantic network
ready to reasoning. Example from ISO 15926:
http://www.infowebml.ws/TS/ClassifiedIdentificationOfClass.xml (011)
4. But macroassembler is still assembler, I need more. There we have objects
that is en essence part of sematic network with defined interface. E.g.
"material object" that can be formed for instances of PossibleIndividual,
ActualIndividual, ArrangedIndividual, PhysicalObject, WholeLifeIndividual:
material object
+classifiers
+<hasClass>//for p7tpl:ClassificationOfIndividual(hasIndividual=id)
+properties
#<Property type> of <hasProperty>//for
p7tpl:InstanceOfIndirectProperty(hasPosessor=id)
#<Property type> of <Property value> <Scale>//for
p7tpl:IIndirectPropertyScaleReal(hasPosessor=id)
#<hasClassifier>//for part2:Classification(hasClassified=id) AND
type(hasClassifier)=Property
#<hasClassifier>//for p7tpl:Classification(hasClassified=id) AND
type(hasClassifier)=Property
+connections
#connected to <hasSide1>//for p7tpl:ConnectionOfIndividual(hasSide2=id)
#connected to <hasSide2>//for p7tpl:ConnectionOfIndividual(hasSide1=id)
#directly connected to <hasSide1>//for
p7tpl:DirectConnection(hasSide2=id)
#directly connected to <hasSide2>//for
p7tpl:DirectConnection(hasSide1=id)
#indirectly connected to <hasSide1>//for
p7tpl:IndirectConnection(hasSide2=id)
#indirectly connected to <hasSide2>//for
p7tpl:IndirectConnection(hasSide1=id)
+connected to <hasSide1>//for part2:ConnectionOfIndividual(hasSide2=id)
+connected to <hasSide2>//for part2:ConnectionOfIndividual(hasSide1=id)
+directly connected to <hasSide1>//for
part2:DirectConnection(hasSide2=id)
+directly connected to <hasSide2>//for
part2:DirectConnection(hasSide1=id)
+indirectly connected to <hasSide1>//for
part2:IndirectConnection(hasSide2=id)
+indirectly connected to <hasSide2>//for
part2:IndirectConnection(hasSide1=id)
//these 6 elements can be unfolded one level more
#connected via <hasUsage>//for
p7tpl:IndividualUsedInConnection(hasConnection=instance of connection type
above)
#connected via <hasUsage>//for
part2:IndividualUsedInConnection(hasConnection=instance of connection type
above)
+is part of
#part of composition <hasWhole>//for
part2:CompositionOfIndividual(hasPart=id)
#part of arrangement <hasWhole>//for
part2:ArrangementOfIndividual(hasPart=id)
#part of assembly <hasWhole>//for
part2:AssemblyOfIndividual(hasPart=id)
#feature of <hasWhole>//for part2:FeatureWholePart(hasPart=id)
#part of composition <hasWhole>//for
p7tpl:CompositionOfIndividual(hasPart=id)
#part of arrangement <hasWhole>//for
p7tpl:ArrangementOfIndividual(hasPart=id)
#part of assembly <hasWhole>//for
p7tpl:AssemblyOfIndividual(hasPart=id)
#feature of <hasWhole>//for p7tpl:FeatureWholePart(hasPart=id)
+has parts
#has in composition <hasPart>//for
part2:CompositionOfIndividual(hasWhole=id)
#has in arrangement<hasPart>//for
part2:ArrangementOfIndividual(hasWhole=id)
#has in assembly<hasPart>//for
part2:AssemblyOfIndividual(hasWhole=id)
#has feature <hasPart>//for part2:FeatureWholePart(hasWhole=id)
#has in composition <hasPart>//for
p7tpl:CompositionOfIndividual(hasWhole=id)
#has in arrangement<hasPart>//for
p7tpl:ArrangementOfIndividual(hasWhole=id)
#has in assembly<hasPart>//for
p7tpl:AssemblyOfIndividual(hasWhole=id)
#has feature <hasPart>//for p7tpl:FeatureWholePart(hasWhole=id)
+temporal composition
#has temporal part <hasPart>//for
part2:TemporalWholePart(hasWhole=id)
#has temporal part <hasPart>//for
p7tpl:TemporalWholePart(hasWhole=id)
#temporal part of <hasWhole>//for part2:TemporalWholePart(hasPart=id)
#temporal part of <hasWhole>//for p7tpl:TemporalWholePart(hasPart=id) (012)
This is already high level to use in not only in reasoners (this is semantic
network, huh?) modeling languages (with boxes and arrows) but also Turing
Complete Languages like Python or Haskell.
At this level I can start thinking about Architecture Language with multiple
diagrams, multiple types of objects, multiple domains (rocket architecture,
enterprise architecture, software architecture -- with some reservations),
and different notations that translates up to reasoner-enabled level.
Moreover, I consider that there will be multiple types of
"executors/solvers" (procedural, logical=reasoner, simulation solvers like
those in Simantics, etc.). (013)
At the very bottom we still have semantic network with mereotopology, 4D
extensionalism, modal realism, etc. (criteria 2 -- Assembler with
ontological commitments). (014)
5. We need language for mapping all alien's visions of the world to our's. I
believe that this mapping should be in HOL only and therefore better
performed in Turing Complete language. But this mappings goes directly to
semantic levels network. At TechInvestLab we are developing
mapping-in-the-Python software for ISO 15926. (015)
Integraph SP3D CAD software have some graphics saved in .dll (procedural:
compiled from Visual Basic) files, not in database. To translate these .dll
to other (declarative) types of geometry presentation you need a presence of
Turing Complete Language that have access to logical representations. This
is life that have not only reasoners and logical languages that are used by
engineers. (016)
6. I have as a good example of architectural language not SysML but
ArchiMate (http://www.opengroup.org/archimate/doc/ts_archimate/ -- this is
1.0 specification, now we have 2.0 that is even better because have
meta-level of requirements and implementation of architecture described in
ArchiMate). What I like in Archimate in comparison with SysML?
a) no attributes, only objects and relations. See Chris Partrige's book
about re-engineering of legacy like UML, COBOL and other intuitive
"substance paradigm" languages that support attributes into more
contemporary and not so intuitive "logic paradigm".
b) set of basic types and relations that directly support Enterprise
Architecture: this is clear example of successful types and relations that
differ from SysML's ones and still support architecture activity. I am not
very satisfied with this particular set, but to discuss this difference is
important. I wish that basic types and relations in ArchiMate was changed to
some kind of upper ontologies ones (OntoArchiMate) and then we will
specialize this to Enterpise Architecture concepts. What is important:
notion of System (with Life Cycle, Actor/Enabling System, Service,
Function/Constriction structural difference, etc.. is very high on Upper
Ontology level for me. World consists not from objects, but Systems that in
the eye's of an Actors -- but this is philosophy already, not language
engineering and considered as offtop in this thread).
c) basic presuppositions of "layers" (hardware, software, people that you
can see on last my Ontology Summit presentations. ArchiMate call as
Technology, Applications, Business respectively) as a way of structuring of
architecture thinking. This is amazing for systems engineers.
d) meta-level: goal-oriented requirements engineering (GORE) for developed
architecture; implementation and transition to operation projects planning
defined in version 2.0. Sure, this meta-level relations should be more
aligned with ontology. (017)
7. Then we can have a bunch of engineering DSL languages eco-system by
supporting translation of
-- contemporary ontology-based Architectural Language (that is not exist.
Let call it OntoArh if we are going to create it). Ontology-based is not
meant "OWL inside" or "DL decidability inside" or "formal semantics inside".
This is right c
-- legacy Architectural Language (by the way, UML/SysML is not in the
current list in
http://en.wikipedia.org/wiki/Architecture_description_language)
-- specialty engineering Legacy (like P&ID languages --
http://en.wikipedia.org/wiki/Piping_and_instrumentation_diagram, or any
other -- see Simantics approach).
-- new engineering languages that are enabled by Ontology-Based Language
Workbench (language workbench is an IDE with projectional editing that
support creation and usage of multiple DSLs. This is started as pure
software engineering initiative in 2005 ---
http://martinfowler.com/articles/languageWorkbench.html, but now is regarded
as modeling -- see Language Workbench competition 2012 that aimed to Piping
and Instrumentation diagram DSL support --
http://www.languageworkbenches.net/index.php?title=LWC_2012. Next step of
evolution should be shift to ontologizing from programming and modeling.
Next shift will be to language-oriented programming-, modeling-,
ontologizing-in-the-large). (018)
There are no clear means of granularity/modularity architecture support in
ArchiMate, it is shame! Views/viewpoint support is right out of the box, it
is as usual. (019)
> 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. (020)
I am not particular fan of both ArchiMate and ISO 15926 but it is more
promising start point to me to build something for the future having
successful contemporary technology of today. I completely agree that we
should not have Architecture language revolution and start from scratch. But
I am not considering UML/SysML as a right starting point for evolution.
There are other alternatives present and I trying to insist for an
alternative election. (021)
Sorry, it appears that my letter spur a fragment of traditional
language/OS/application type holywar. (022)
> There are other factors that have to do with
> success such as acceptance factors. (023)
Yes, sure. When we start something counterintuitive (like "Earth is not
flat" or "logic paradigm better suit for computers and engineers than entity
and substance one's") acceptance will be by definition low for a while. (024)
> I believe that you noted that your
> proposed candidate ISO 15926 did not have a good notation. (025)
Yes, it has very bad notations. And several other deficiencies (like choice
of OWL as a transport container: semantics of OWL and semantics of ISO 15926
Part 2 is rather different).
By the way, it is not only ISO 15926, but a "engineering ontology family" of
ISO 15926, HQDM, IDEAS and Gellish. There are a choice and a lot of field
experiments and successes here. (026)
> 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. (027)
Resonance with OOP and toolset was major factors.
Availability of free ArchiMate editor Archi and support from major
enterprise architecture software vendors is very important for
successfulness of ArchiMate. (028)
If I want to win with engineering ontology (e.g., only e.g.) ISO 15926 than
I need to develop best tools for it. Community of ISO 15926 fans is busy
with tooling. We (in Russia) participate: there are four ISO 15926 related
software developments that we are aware. Not comparable with OWL and XML but
not so small number alone for Russia, huh? (029)
> 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". (030)
I have in mind nuclear power station engineering problem, shipbuilding
(including offshore oil rigs) engineering problems, etc.. These are my
clients, their problems are my problems. (031)
> 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. (032)
No, your MDA "levels" are way more syntactical than you write about it. I
take from Conrad Bock that we need support of true ontology commitments (for
me this means classes of classes, 4D mereology, etc. included) and
correspondent expressions in notation. I simply take this point from his
papers and try to apply for a class (not to particular UML family) of
architectural languages as a whole. Then I supposed that architecture
language and general engineering language (like ISO 15926, Gellish, HQDM,
IDEAS) should be linked as source and target language to possibility of
automatic consistence checking between architecture and special engineering
language. Thus I think that Architecture description language is simply DSL
on base of low level ontology language (not OWL! This is "syntax only" for
me, not ontology. Not a good syntax, by the way). (033)
> 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. (034)
I add then to Conrad Bock guess that we need "strong" ontology (what in the
world, not merely what logical formalism) from the very bottom (your M0) of
language stack. I need philosophical logic in engineering, not pure
mathematical logic. Engineering deal with real life and real life
transformations, not only with symbolic strings and symbolic strings
transformation. Engineering need discussion about real life ontology
(classical ontology) and "ontology languages" (computational ontology). OWL
is about computational ontology, not about real life. I need more. ISO
15926, HQDM, Gellish and IDEAS are about philosophical logic first and plain
logic second. I satisfied with it. (035)
> 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. (036)
That I call syntax. Many people express their ontologies not in OWL or
something more appropriate for this purpose but in UML (and then they using
relational database to keep this ontology on a disk). I think there possible
more simple ways to provide logic paradigm syntax. If you know what objects
and relations is in a world of engineers (this is pure ontological question
in classical sense). (037)
I learn notion of System and Service in a study of real world and real
engineers but not from Sys in SysML. Up to now System in engineering
ontologies and Service in Archimate is a good reflection of "engineering
problem" for me. Syntax of SysML is not sufficient for capturing this
objects and relations directly. (038)
> 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. (039)
This is your and Conrad's way. This is Model-Based Systems Engineering. My
way is Model-Based Systems Engineering also. These are both formal modeling
with ontology patterns usage, but presuppositions different. (040)
> 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. (041)
If your language supports entities with attributes you are hardly supported
in-the-large. What is object of one project is an attribute of another. You
then need to re-engineer your object/attribute legacy to logical paradigm
(see BORO by Chris Partridge). For different paradigms better suited
different languages. (042)
By the way graphical language of BORO by Chris Partridge is not bad. If this
language have a good tooling this can be very interesting contender to UML.
But this language still equivalent to ISO 15926 Part 2 level and needs means
of getting higher and higher. (043)
Language matter for in-the-large problem. Languages also relates to
methodology of development. (044)
> 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. (045)
This is very common opinion. But this is not ontology then, huh? This is
"letters of the alphabet", something pure logical. You can use them as you
want it in your wold. You will not receive warnings if semantic will differ
substantially. Then you will need to have detailed manual point-to-point
clarifications. Ontology-based system federation have another stance. ISO
15926 starts where UML (and many other engineering standards of previous
generations) finished: "I give you my data, and you are responsible for
guessing about meaning them". Then there are many steps left for transfer
not only data but semantics also. (046)
A couple of weeks ago I asked one of the programmers in international team
that transfer "10" from one PLM to another: what is that"10"? He respond
that "requirements was to transfer values, not anything else". He cannot say
even UoM of this "10". This is "open semantics", "syntactic assembling" of
work of many people. Syntactic errors are very severe, but real debug starts
after compiling of syntax error cleared. (047)
> 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. (048)
Yes, toolset is better than absence of tools at al. UML is a legacy
state-of-the art. (049)
Let's see what tools we should develop to provide in MBSE world similar work
better.
People in ISO 15926 community have every day task of system federation. Most
of contemporary PLM systems that they federate have UML-like syntax as a
means for data modeling of respective systems. Ask people from ISO 15926 why
they not "leverage the power of UML" in their work and started to invent
ontology-based system federation without UML. (050)
> Your Proposed Solution: You propose JSO 15926 as a candidate. (051)
No. ISO 15926 is only part of needed and low level part. I will be glad to
change ISO 15926 in many aspects and working in this direction. (052)
I propose to use lessons learned by ISO 15926 community, and lessons used by
Simantic community. Also I suggest ArchiMate as alternative notation for
architectural descriptions.
Also I suggest Language Workbenches to integrate all these high level
engineering languages on a base of ontology with clear ontology
commitments. (053)
> 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? (054)
I believe to multi-paradigm computing, with different processors and their
languages (solvers, reasoners, virtual machines, evaluators, etc..).
Ontology languages is only small subset of systems and software engineering.
Sure, you can build submarines and nuclear reactors and autopoietic systems
and even AI systems if you will not stick yourself to one paradigm. FOL is
not sufficient. (055)
Best regards,
Anatoly (056)
> 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
> (057)
_________________________________________________________________
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/ (058)
|
