Hi Henson, (01)
There is one point I'd like to reply to. (02)
You say:
> Ontological commitment to Parts: UML has a Part construction which while
> having an incomplete semantics is founded on good engineering practice. (03)
I see this comment a lot and I think people are assuming it must be the case
without checking the specification.
I must admit I made the same assumption until, for my sins, I had to wade
through the UML specification in detail.
As far as I can tell the (formal) constraint on aggregation and composition
relations is that the life of the part must be contained in the life of the
whole - or that the part can only exist when the whole does.
This seems more closely aligned with a form of ontological (temporal)
dependence than mereology.
I know that people doing OO analysis use UML aggregation / composition to
represent whole-part relations, but the formal constraints in the
specification do not support this interpretation - and they certainly do not
give much of an idea what the intended interpretation is.
Programmers tell me that they use UML aggregation / composition to show this
kind of temporal dependence between classes - which ties in well with the
formal constraints. Others (e.g. Martin Fowler) say it is too confusing and
suggest not using it. (04)
I wonder whether anyone else has had doubts about this really having
anything to with mereology. (05)
You also said:
> but implementations enforce some of
> the ontological properties that one would expect of parts, e.g. a part
relation
> cannot be to itself. (06)
Only if it is strict whole-part - normally whole-part is reflexive. (07)
All this makes me wonder whether the formal semantics given for UML is
something of a re-interpretation.
Of course there is nothing stopping one re-interpreting UML aggregation /
composition as whole-part, but this is a different ball game. (08)
Regards,
Chris (09)
> -----Original Message-----
> From: henson graves [mailto:henson.graves@xxxxxxxxxxx]
> Sent: 02 March 2012 19:57
> To: 'Chris Partridge'; '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
>
> Chris,
> No problem with coming to the dialog late. I have attempted to sort out
what
> you have added; I see the following:
>
> CP: 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. 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.
>
> HG: Here is a partial response to your question of what UML got right, why
it is
> not in the COBOL camp, and some notes on why OWL 2 is totally inadequate
as
> a formal semantics for UML or ISO 15926. More will follow as I process
recent
> posts. By the way I can see an emerging panel discussion which takes
> Matthew's distillation unit as a starting point for discussion of how to
represent
> in various modeling languages and what ontology commitment needed. While
> the example is simple the issues are fundamental from the ontology point
of
> view and their solution or lack of solution will have serious impact on
modeling
> language development and how they deal with ontology. There are a number
> of participants who understand the issues well.
> My biggest disappointment is that the professional ontologists have been
> absent from this discussion.
>
> Formal Semantics: UML can be given a formal semantics for its individuals,
> classes, and properties in that class models can be embedded into a
reasonable
> Description Logic ( Berardi, D., Calvanese, D., and De Giacomoa, G. 2005.
> "Reasoning on UML class diagrams."). I also have papers embedding larger
> fragments of SysML into type theory. Type theory includes DL constructions
and
> can accommodate 4D semantics. Embedding in logic is critical in the long
run
> for collaboration, standards, and reasoning. I understand engineering
languages
> have not born that way and it takes a while to what their semantics should
be
> or if they are so damaged that cannot be given a reasonable semantics.
>
> Ontological commitment to Parts: UML has a Part construction which while
> having an incomplete semantics is founded on good engineering practice.
> Parts are represented not as individuals, but as binary relations. This
means
> that part instances are pairs of individuals, e.g., <a,b>:R where R is a
part
> relation. The part arrows in a diagram translate into a typed binary
relation. I
> will write as write as R(A,B) for an arrow A -<>B in a diagram.
> If you unwind the diagrams composition of relations is used. Even in UML
> family the diamond headed arrow has additional ontological semantics. I do
> not know about the formal specification but implementations enforce some
of
> the ontological properties that one would expect of parts, e.g. a part
relation
> cannot be to itself. Also while UML does not have the concept a
functional
> relation R(A,B) can be replaced or identified with an operation R^:A -> B.
I
> believe that this is what is needed in many places including Matthew's
> distillation unit example.
>
> Metamodeling facility: As several of us have noted a weak ontological
> commitment is better than one that is simply wrong. However, UML does
> provide a facility in which one can specify ontological semantics with the
meta-
> modeling facility. Conrad's papers correctly employ that tactic.
> Again there are improvements to be made there, but it lets groups specify
an
> ontological concept such as "system" as a meta-model class.
>
> Here are some notes on why I believe that OWL 2 is totally inadequate for
> engineering modeling languages. I think OWL 2 is a major accomplishment
and
> my comments do not demean it in any way. When I say that I mean that the
> language constructions in UML beyond classes and properties extend the
> expressiveness of OWL 2. This does not mean that they could not be encoded
in
> OWL 2 but only in the same sense that they could be encoded as a Turing
> Machine tape.
>
> If the professional ontologists talk about this kind of stuff or are
interested in it
> I hope someone will point me to what they have to say about for example,
> impact of choice of logical formalism on identify, time, and other such
> concepts, and on ontology typed part relations, on replacing functional
> relations with Skolem functions which enables treating a part more like an
> individual, etc.
>
> - Henson
>
> -----Original Message-----
> From: Chris Partridge [mailto:partridge.csj@xxxxxxxxx]
> Sent: Thursday, March 01, 2012 3:12 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: 'Matthew West'; 'Chris Partridge'
> Subject: RE: INCOSE Ontology Action Group, onto SysML/UML
>
> Hi Henson,
>
> 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.
>
> Chris
>
> > -----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.
>
> 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.
>
> >
> > Where to begin: It is always easy to say throw out the old and bring
> > the
> new.
>
> 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.
>
> > 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.
>
> Agreed - absolutely. I have two projects where we are doing exactly that
wrt
> UML.
>
> >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.
>
> logic-based semantics? What had you in mind? And how do you get from there
> to the intended interpretation?
>
> >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.
>
> 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.
>
> >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
> >
> (010)
_________________________________________________________________
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/ (011)
|