Yesterday, I sent a note to the OMG AE-SIG with comments on some issues
raised by Ed Barkmeyer. An excerpt from that note is copied below. (01)
In that note, I mentioned two different ways to reconcile independently
defined theories. I'll call them the Superset Method and the Black-Box
Method: (02)
1. Superset. Given two independent theories A and B, each of which
is a specification or ontology that describes some aspect of a
particular domain, create a larger theory C that is a superset
of all the axioms from A and from B together with additional
axioms or rules that specify mappings between terms (i.e.,
functions, relations, and types) that may have different names
and definitions in A and in B. (03)
2. Black Box. Given two independent theories A and B, which have
completely incompatible and inconsistent foundations, but
which are both adequate to describe some aspect of a particular
domain, don't even attempt to create a superset of both. Instead,
treat A and B as black boxes whose internal variables and structures
will be ignored in all interactions. Just define a simple theory C,
which specifies a bare minimum of necessary axioms or constraints
on those functions, relations, and types that are used to describe
the interfaces where systems based on A or B must interact. (04)
As an example of the Superset Method, see Ed's description of two
views of a "cordless hand drill" below and my description of how
to construct a superset theory that includes both. (05)
As an example of the Black-Box Method see slides 65 to 67 of (06)
http://www.jfsowa.com/talks/iss.pdf
Integrating Semantic Systems (07)
After I wrote that note, I was wondering why there were just two
methods and whether there could be other methods different from
those two. Finally, it dawned on me that the answer lies in the
lattice of theories: (08)
1. If two theories A and B are consistent, there must exist
a common specialization that includes all the axioms of both,
possibly with some additional mapping axioms. (09)
2. But if A and B are inconsistent, their only common specialization
is the inconsistent theory at the bottom of the lattice. However,
all pairs of theories have consistent common generalizations. If
both theories have compatible values at the interfaces, those
interfaces must be in some common generalization. That theory
is the one that specifies the interfaces of the black box. (010)
This answers the question why there are two methods. But it is
also possible to have mixed methods. For example, the cordless
drill might have components, such as a motor or battery, which may
be supplied as a black box by some vendor. The superset theory
includes all the detailed axioms required by the company that
manufactures the drills, but it might treat some of the components
as black boxes. (011)
There is one other point that I didn't address in that previous note:
how to find the mapping axioms or rules between the two theories that
form the superset. If the theories are consistent, such mappings must
be possible, but finding them might require some effort. (012)
As an example, see the two different ways of describing the structure
of blocks and pyramids in slides 84 to 90 of iss.pdf. As that example
shows, the mapping may require considerable analysis and searching.
Some conventions on common terminology can help make those mappings
easier to find, and some tools such as the analogy engine can help. (013)
But note that any two theories A and B have common generalizations,
even though not all pairs have consistent common specializations.
Therefore, the Black-Box Method can always be used to support
interoperability at the interfaces. The Superset Method enables
deeper and more detailed interoperability, but if it's too hard
to find the mappings, the Black-Box Method is an alternative. (014)
John Sowa (015)
-------- Original Message --------
Abbreviated version of a note on 17 Aug 2010
From: John F. Sowa <sowa@xxxxxxxxxxx>
To: edbark@xxxxxxxx
CC: architecture-ecosystem@xxxxxxx (016)
Some comments on your previous note: (017)
> Integrating models is about stating relationships among the elements
> of the system that appear in the models. Each viewpoint on the system
> depicts elements of the system in terms of the classifiers that are
> important to the viewpoint. There is no reason to suppose that the
> classifiers in two different viewpoints, and thus the language concepts
> of the different viewpoint languages, would be the same, or clearly
> related in any way. And there is no reason to suppose that the
> relationships between two descriptions of the same system element has
> anything to do with their classifications in different languages. (018)
All those OMG models are theories in some version of logic, and they
can all be expressed in the same version of logic (which we have
previously called a Foundation Logic and which I have recommended be
Common Logic, but I'll call it FL to avoid making any prejudgments). (019)
> Sébastien's tenet is that classes will be related to things that are
> like classes and associations will be related to things that are like
> associations, and that it is meaningless to relate a 'class' in one
> model to an 'activity' in another, or to an 'association' in a third.
> Yet all of these are common occurrences when you change viewpoints.
> The SAP model models an 'activity' as a 'class' ('table'), because the
> ERP database contains the characteristics of the activity that relate
> to scheduling it. (020)
I agree. But that is an artifact of the differing terminologies
used in different modeling languages. When we map those models
to FL, we can use *only* the barest minimum of logical terminology. (021)
We won't have classes, associations, tables, or activities. In CL,
all possible relationships are represented just by relations and
functions. You can name them anything you please, but that doesn't
change their logical status. Collections of sentences in any logic
are usually called *theories*. If you wish, you can call some CL
sentences facts, rules, or axioms. But in CL, they are just
sentences. That makes the debate over terminology irrelevant
at the logical level, but people can use whatever words they
like for other levels. (022)
For the mapping to logic: (023)
Every viewpoint V on a model M is also a theory, and when V and M
are expressed in FL, M implies V according to the logic FL. If M
does not imply V, then V is not a faithful viewpoint on M. (024)
The classifiers of V form a set C of relations and functions that
can be defined in FL and are sufficient for expressing the theory V.
It is possible that the model M is expressed in a set of relations
and functions R that does not include the set C. But since M and V
must be compatible (because M implies V), it must be possible to
state mapping rules in FL between relations in R and those relations
in C that are not in R. (025)
If V1 is another viewpoint on M, the theory of V1 when stated in FL
must also be implied by M. And the classifiers of V1 must be
another set of relations C1, which are also definable in FL. (026)
And if V1 is a faithful viewpoint on M, then M must imply V1.
Since M also implies V, M must imply the conjunction V & V1.
Therefore, if M is a consistent model, V and V1 must also be
consistent. But I agree with Ed, that "There is no reason to
suppose that" V and V1 would be "clearly related in any way." (027)
However, V and V1 must be somehow related, even if unclearly,
indistinctly, or indirectly. And our logic can tell us how. (028)
> My favorite example of viewpoint difference is the design view and
> the manufacturing view of the cordless hand drill. The design view
> is that it consists of a power supply, a motor and trigger, a drive,
> and a casing, with each defining a collection of parts. The manufacturing
> view is that the right half of the casing is the shell, and the first set
> of parts is those that go on the bottom of the shell and can be placed
> by a robot, the next set are those that are placed on the first and
> connected by a human operator, etc. The parts are the same, but the
> organization and classifications are entirely different. Some placements
> and connections implement subsystems and interfaces! (029)
Good example. But this is a simple case compared to some. (030)
The first observation I'd make is that there is a fixed set of parts
for both views and the final assembly in both views is identical. (031)
But the full model M must include a sufficient number of functions
and relations that can subsume both views. It must include ways of
grouping parts according to the design view and ways of assembling
parts according to the manufacturing view: (032)
1. The model M is an FL theory that uses a set R of relations and
functions that can describe all the parts, their placement in
the final assembly, and sequencing operators for relating parts
and subassemblies to larger assemblies. R need not contain
a notion of time, but it must contain sequencing relations
for stating how each part and subassembly is related. (033)
2. The design view V1 is a theory that is implied by the final
assembly reached at the end of the manufacturing process.
It would express static relationships among all the parts
and subassemblies. The classifiers in C1 may contain
descriptions of subassemblies that differ from the order
in which the manufacturing process creates them. There
is no contradiction, since the design view is a way of
looking at the final product, not at the assembly stages. (034)
3. The manufacturing view V2 is a theory that states all the
sequence-dependent steps in creating each assembly from its
parts. It need not have a notion of time, and it can leave
open the question of ordering of some of the subassemblies.
But it must be explicit about necessary constraints in the
sequencing. There is no requirement that the order of
constructing assemblies in V2 must be identical to the
order in which the final results are viewed in V1. (035)
But in real life, situations can become far messier, especially
for independently developed legacy systems. Those cases are
covered by slides 65 to 67 of iss.pdf. (036)
> In UML the patch for "inconsistent models" in different viewpoints
> is the Dependency -- a relationship UML doesn't understand, or
> forbids. (037)
Many such cases can be handled by the example above of making
a very general model that subsumes both the design viewpoint and
the manufacturing viewpoint. (038)
But other cases of inconsistent models may result from issues
that are discussed in slides 65 to 67. The way to avoid those
issues is to ignore the internal details of the systems and
just model the interfaces. (039)
I believe that the methods outlined in this note and in the SIO
slides are sufficient to cover all the cases that are required for
the OMG. With a decent FL, these issues can be defined precisely.
Otherwise, all you have is a vague cloud of words that cannot
ensure compatible implementations. (040)
John (041)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (042)
|