John, (01)
That's fantastic, and nicely concise. Can I potentially refer to this
note in any papers, notes etc. about how we at the EDM Council want to
try and deal with interoperability with existing standard ontology
terms? I'm familiar with the ISS paper you presented at SemTech, which
covers the Black Box approach but I think this summary of how these two
approaches relate, is useful in itself. Or is there a paper coming which
will develop this? (02)
Best regards, (03)
Mike Bennett (04)
John F. Sowa wrote:
> 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.
>
> 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:
>
> 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.
>
> 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.
>
> 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.
>
> As an example of the Black-Box Method see slides 65 to 67 of
>
> http://www.jfsowa.com/talks/iss.pdf
> Integrating Semantic Systems
>
> 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:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> John Sowa
>
> -------- Original Message --------
> Abbreviated version of a note on 17 Aug 2010
> From: John F. Sowa <sowa@xxxxxxxxxxx>
> To: edbark@xxxxxxxx
> CC: architecture-ecosystem@xxxxxxx
>
> Some comments on your previous note:
>
>
>> 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.
>>
>
> 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).
>
>
>> 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.
>>
>
> 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.
>
> 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.
>
> For the mapping to logic:
>
> 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.
>
> 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.
>
> 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.
>
> 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."
>
> However, V and V1 must be somehow related, even if unclearly,
> indistinctly, or indirectly. And our logic can tell us how.
>
>
>> 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!
>>
>
> Good example. But this is a simple case compared to some.
>
> 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.
>
> 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:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
>> In UML the patch for "inconsistent models" in different viewpoints
>> is the Dependency -- a relationship UML doesn't understand, or
>> forbids.
>>
>
> 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.
>
> 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.
>
> 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.
>
> John
>
> _________________________________________________________________
> 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
>
>
>
> (05)
--
Mike Bennett
Director
Hypercube Ltd.
89 Worship Street
London EC2A 2BF
Tel: +44 (0) 20 7917 9522
Mob: +44 (0) 7721 420 730
www.hypercube.co.uk
Registered in England and Wales No. 2461068 (06)
_________________________________________________________________
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 (07)
|