The Landscape of Assumptions

Robert D. King Charles D. Turnitsa Old Dominion University

robking@verizon.net CTurnits@odu.edu

Keywords: Assumptions, ontology. Abstract

The problem of how the explicit and implicit assumptions made during agent and simulation development are formulated and handled (or not handled) has received comparatively little research. Effective cooperation between multiple artificial agents requires not only an explicit representation of terms, concepts and processes, but also alignment of meaning between developers, integrators, and users. Assumptions, especially implicit ones, have potentially tremendous impact on establishing unambiguous representation due to potentially unintended interpretations.

This problem is important to agent directed simulation in several ways: agent mediated selection of simulation components requires methods for ensuring valid component interoperation; agents are a logical choice for automatically comparing sets of assumptions; and when potential conflicts are detected, agents have the potential to adjudicate and resolve them. This discussion will focus on the role of assumptions in modeling because it is fundamental to composing valid models and systems.

This paper summarizes how assumptions are defined, characterized, used and misused by modelers. It examines how assumptions can be used to identify potential conflicts between domain views.

1. INTRODUCTION The systematic construction of large-scale models and

systems from existing parts remains an elusive goal. Why? Some of the blame can rightfully be placed on the lack of pieces to assemble or the inability to locate the desired pieces when they do exist. But even when model components are in hand, problems remain because the chosen parts do not fit together well. True, some of the mismatches are caused by low-level problems of interoperability—which are difficult to overcome—but recent efforts have been making good progress in addressing many of them.

Nevertheless, there remains a class of problem that has received comparatively little research and that must be addressed before conceptual interoperability can become a reality. This is the problem of how assumptions are formulated and handled (or not handled). Among the reasons for little research is that assumptions are so much a

fundamental part of formulating a system solution that they are used in many different ways. For example: Some authors treat a list of assumptions as though it

were a theory of the world. A list of assumptions does not constitute a theory; a list of assumptions is a (often disjoint) collection of statements.

Some authors treat a list of assumptions as if it were a conceptual model. It is not; but a conceptual model should include a list of its assumptions.

Some authors take a shotgun approach in constructing a list of assumptions, listing each one that comes to mind.

Some authors correctly use a list of assumptions to specify restrictions on, and characteristics of components. All problems involve the interaction of domains that

exist in the world. Domains exist either physically (e.g. people) or logically (e.g. data). Every domain has a collection of assumptions that define various aspects of that domain. A domain expert is a person who understands these (often implicit) assumptions.

Assumptions are a fundamental part of every problem solution: a first and frequently overlooked step in problem solving is for the analyst to identify the problem’s assumptions. Many of the assumptions remain hidden and unrecognized until a deliberate effort is made to identify them. Often it is the unrecognized assumption that prevents a good solution.

Assumptions are necessary for three reasons: Assumptions reflect desired values that should be

maintained throughout the solution. Assumptions set limits to the problem and thus provide

a framework within which to work. These limits might include constraints of possibility, economics, or some other desired narrowing.

Assumptions simplify the problem and make it more manageable by providing fewer things to consider and solve. A problem with no assumptions is usually too general to handle. We begin by presenting an overview of definitions for

the term assumption. Next, we review pertinent literature regarding assumptions in modeling. Section 3 presents a formal definition and a taxonomy of use. Section 4 discusses how to compare assumption lists in the context of a small case study. A summary discussion highlights directions for future research.

2008 SpringSim 81 1-56555-319-5

1.1. Definitions Assumption has many interpretations1. Dictionary.com

[1] defines assumption as: 1 something taken for granted; 2 a supposition; 3 the act of taking for granted or supposing; 4 the act of taking to or upon oneself; 5 the act of taking possession of something; 6 arrogance; presumption; 7 the taking over of another’s debts or obligations. These dictionary definitions are at too high a level to be practically useful and are presented only for completeness.

1.2. Semantic Lexicons and Ontologies WordNet is a large lexical database of English,

developed and now maintained by the Cognitive Science Laboratory of Princeton University. Nouns, verbs, adjectives and adverbs are grouped into sets of cognitive synonyms called synsets, each expressing a distinct concept. Table 1 presents WordNet synsets [2] for assumption.

Table 1. WordNet synsets for assumption WordNet SYNSET

Definition and example

premise, premiss, assumption

a statement that is assumed to be true and from which a conclusion can be drawn. "on the assumption that he has been injured we can infer that he will not to play"

assumption, supposition, supposal

a hypothesis that is taken for granted. "any society is built upon certain assumptions"

assumption, laying claim

the act of taking possession of or power over something. "his assumption of office coincided with the trouble in Cuba

presumption, presumptuousness, effrontery, assumption

audacious (even arrogant) behavior that you have no right to. "he despised them for their presumptuousness"

assumption the act of assuming or taking for granted. "your assumption that I would agree was unwarranted"

There is a problem with using WordNet to define a term

rigorously: although there is a hierarchical structure to the WordNet database, its definitions can result in circular reasoning, a consequence of natural language processing.

The Suggested Upper Merged Ontology (SUMO) [3] was developed within the IEEE Standard Upper Ontology Working Group. First released in December 2000, SUMO was arbitrarily capped at around 1,000 concepts. SUMO originally concerned itself with meta-level concepts (general 1 Definitions and WordNet synsets dealing with Assumption (Christianity) are not relevant to this discussion.

entities that do not belong to a specific problem domain), and thereby would lead naturally to a categorization scheme for encyclopedias. Today, SUMO is at the apex of a collection of formal ontologies that include the MILO (MId-Level Ontology) and various domain ontologies. Together, these define a hierarchy of classes and related rules and relationships that is the largest formal public ontology in existence and that is being used for research and applications in search, linguistics and reasoning.

Oddly, SUMO does not directly contain the concept assumption. However, SUMO has been mapped to the entire WordNet lexicon. Thus, it is possible to relate English terms to concepts from the SUMO ontology by means of mappings to WordNet synsets. SUMO has an associated open source knowledge engineering environment, Sigma, which can be accessed online [4] to browse the SUMO/MILO ontologies. Using Sigma, the term assumption is found to map to five SUMO concepts, listed in Table 2

Table 2. SUMO mappings for assumption synsets WordNet SYNSET SUMO Concept

(subsuming mapping) premise, premiss, assumption

Supposition

assumption, supposition, supposal

Proposition

assumption, laying claim

Getting

presumption, presumptuousness, effrontery, assumption

SubjunctiveAssessment-Attribute

assumption IntentionalProcess SUMO is not without shortcomings. For example,

during SUMOs development it was difficult to justify the inclusion of the concept of “Mediating Entity”. Although the notion may be philosophically indispensable, it is not so in an engineering-oriented context, and, for this reason, it was removed from the merged ontology. Possibly, reasoning similar to this might explain why assumption is not a primary concept. Other features of SUMO include the fact that subclasses are necessarily disjoint, and that multiple inheritance is permitted.

The WonderWeb Foundational Ontologies Library (WFOL) consists of three modules: the Descriptive Ontology for Logic and Cognitive Engineering (DOLCE), the Object-Centered High-level Reference Ontology (OCHRE), and the Basic Formal Ontology (BFO) [5]. Both DOLCE and OCHRE are concerned with mereology (the formal theory of parthood), repeatable and non-repeatable properties, similarity, dependence, connection, and temporal order. BFO grows out of a philosophical orientation which overlaps with that of DOLCE and SUMO[6]. Unlike these,

1-56555-319-5 82 2008 SpringSim

however, it is narrowly focused on the task of providing a genuine upper ontology which can be used in support of domain ontologies developed for scientific research, as for example in biomedicine. Thus, BFO does not contain physical, chemical, biological or other terms that would properly fall within the special sciences domains.

SUMO/MILO, DOLCE, OCHRE, and BFO are all viable candidates to serve as the foundation for domain specific ontologies.

1.3. Definitions for Logic and Modeling Finally, there are other definitions to consider. In logic,

more specifically in the context of natural deduction systems, an assumption is made in the expectation that it will be discharged in due course via a separate argument. In this context, assumptions play important roles in logical proofs. Some proofs begin with assumptions as to the form of the solution. Other proofs begin with the assumption that a particular hypothesis is true and proceed in a manner that proves some logical consequence of the hypothesis as false, thereby proving that the inverse of the hypothesis is true.

Dewar, et al. [7] define an assumption as an assertion about some characteristic of the future that underlies the current operations or plans of an organization. Hofmann [8] offered a definition of assumption that supports the formal framework of modeling and simulation presented in detail by Zeigler, Praehofer and Kim[9]. Lastly, King [10] defined assumption as a statement, taken for granted, about the framework of a system solution. This is the working definition that most shapes the discussions that follow.

2. PREVIOUS RESEARCH Many engineering design texts have advice on how to

formulate good assumptions. Some of the literature focuses on what happens when assumptions go wrong.

Garlan et al [11] addressed an apparent lack of progress toward building systems from existing parts. They introduced architectural mismatch that stems from mismatched assumptions a reusable part makes about the structure of the system it is to be part of (more precisely, mismatches were between the developers of four software modules and only surfaced during integration). They noted that assumptions of one part often conflict with the assumptions of other parts and are almost always implicit, making them extremely difficult to analyze before building a system. They showed how an architectural view of the mismatch problem exposes several fundamental challenges for software composition and suggested possible research avenues needed to solve them. The four main categories of architectural mismatch are: Assumptions about the nature of the components,

including (1) infrastructure—assumptions about the substrate on which the component is built; (2) control model—assumptions about which component(s) (if

any) control overall the sequencing of computations; (3) data model—assumptions about the way the environment will manipulate data managed by a component

Assumptions about the nature of the connectors, including (1) protocols—assumptions about the patterns of interaction characterized by a connector; and (2) data model—assumptions about the kind of data that is communicated

Assumptions about the global architectural structure, including assumptions about the topology of the system communications and about the presence or absence of particular components and connectors

Assumptions about the construction process Foo [12] discusses the frame problem that has

occupied the attention of AI researchers in the logic of action. The frame problem is the challenge of representing the effects of action without having to represent explicitly a large number of intuitively obvious non-effects. Components can be functionally composed as long as they result in an engineering model. An engineering model does not (generally) suffer from the frame problem because of implicit assumptions, generally known as the inertia rule, made as a fundamental component of the problem statement and solution. The inertia rule is the assumption that effects are local unless otherwise stated. Put another way, the inertia rule is an assumption about what to do with missed assumptions—analogous to burying one’s head in the sand intentionally.

Assumptions were examined by Spiegel et al [13], who conducted a small case study in order to clarify the role that model context plays in simulation composability and reusability. They extended an example problem: compute the position and velocity of a falling body, which was described in detail by Davis and Anderson [14] in their monograph on modeling and composability. Spiegel and his colleagues found that a reasonable formulation of a solution included a surprising number of implicit assumptions—their non-exhaustive list included 29 constraints. They observed that failure to appreciate the importance of various constraints when selecting a model can lead to unacceptable results. Several assumptions, such as special relativity (assumed not to be significant) and Coriolis Effect (can be ignored), were not obvious2. While it may be that their original formulation for the falling body is a suitable approximation for a golf ball or cannon ball in flight, that decision should be made knowledgeably by a designer. Such

2 Even so, given any one of Spiegel’s listed assumptions, a competent engineer or physicist should be able to construct an example where taking it into account is critical.

2008 SpringSim 83 1-56555-319-5

a decision can only be made if the assumptions associated with each model are identified and understood.

The HLA ‘Federation Development and Execution Process’ (FEDEP) [15] describes a structured, systems engineering approach to federation development and execution. As a ‘guide to best practices’ the FEDEP falls short in that it mentions assumptions only twice, almost en passant in its manner, and in the most general terms. It states, “The federation conceptual model describes what the federation will represent, the assumptions limiting those representations, and other capabilities needed to satisfy the user’s requirements.”

Assumption-based Planning (ABP) [7] is a process developed at the Rand Corporation that is notable with respect to this discussion for its limited, but accurate, definitions as well as providing an extensive framework for assumption use. In ABP the task is to identify those assumptions that are vulnerable to failure in the time frame of planning interest. In ABP, an assumption is important if its negation would lead to significant changes in those operations or plans. It is a rare organization that explicitly sets out all the important assumptions it has made. More typically, those assumptions must be identified from documentation, interviews, and observation. Even when such assumptions are written down explicitly, unstated, im-plicit assumptions remain to be identified and are evident only upon reflection and study. Identifying an organization's important explicit and implicit assumptions is a useful exercise in itself as a way of clarifying an organization's identity and mission. ABP identifies signposts—indicators of when assumptions are violated—and uses them as triggers for initiating alternative actions. Finally, ABP also provides a framework for planning actions that (a) protect or maintain the state of vulnerable assumptions, (b) are contingencies in the case that vulnerable assumptions fail.

3. ONTOLOGY This section presents an ontology of assumptions as

applied in development and use of models, simulations and software agents. Objects, characteristics, processes and concepts require unambiguous meaning. That is, a basis in ontology is critical. Ontology captures knowledge about a domain of interest. Beyond the terms used to describe and represent an area of knowledge (subject matter), ontology is the model (set of concepts) for the meaning of those terms. Ontology thus defines the vocabulary and the meaning of that vocabulary within a domain. By encoding domain knowledge (i.e. its properties, values and concepts), ontology makes it possible for agents to share and to reason about it.

3.1. Definition of Assumption Figure 1 presents the definition of an assumption in

terms of its component parts (assumption function, referent,

scope, and proposition). It is a statement of the use of an assumption with respect to a system. As much as possible, examples offered in the following discussion of each component will extend the falling body problem used in [13].

assumption <=> (assumeFN referent scope Proposition) where: assumeFN describes how the assumption is used by the model or system referent is the model or system component that the assumption is about scope is a description of which parts of the system the assumption refers to Proposition is a statement about the referent’s existence, relations, or quality

Figure 1. Assumption Definition

Assumption function. The assumption function describes the role of the assumption in potentially modifying system behavior. It is one of the following terms: [uses | does_not_use | requires | ignores | denies]. Note that the latter three terms establish the assumption’s relevance. Table 3 gives example assumptions that might be used when adding wind to the falling body problem.

Table 3. Assumption function examples assumeFN example Interpretation uses body component (wind affects)

the body is affected by wind

uses body component (wind ¬affects)

the body is not affected by wind

uses body component (wind 9 mph)

the body model uses 9 mph for the wind

does_not_use body system (wind affects)

the system does not use the effects of wind on the body

ignores body system (wind affects)

the system is not affected by whether the body is affected by wind or not

requires body system (wind *)

the system requires that wind to be taken into account

denies body system (wind *)

the system requires that the wind be ignored

Referent. The referent of an assumption is what it refers

to. Referents can be an object, a model, a process, a system, or the characteristics of one of these. When an assumption

1-56555-319-5 84 2008 SpringSim

acts as a constraint, the referent is what is being limited by the assumption, e.g. “the mass of the falling body remains constant throughout the operation of the model.” In this case, the referent is the mass of the falling body.

Scope. Scope is a description of which portions of the overall model (system) that the assumption applies to. Note that scope can be explicitly or implicitly stated. Table 4 lists the various kinds of scope. A system is a collection of related components, assembled for a purpose, but which exist within an environment. A model of such a system is defined as an abstraction of some type[16]. The abstraction consists of representation of the objects and processes representing the subsystems (the components), the behavior of the overall model itself (the system), and how it interacts with objects and processes outside of itself (the environment). e.g., “the body, gravity, and the ground are all components.” The overall process of a body falling is the system. Everything else is the environment, such as the body of atmosphere, any nearby bodies that might exert influence on the model, and so on.

Table 4. Assumption scope Scope Definition / example Component The scope of the assumption is the

component itself. “the falling body is a single object”.

System The scope of the assumption is the entire system that contains the component. “the physics of the falling body model are strictly Newtonian.”

Component-Environment

The scope of assumption is the relationship between the component and its environment. “the falling body is not affected by any radiation or heat.”

Component-Component

The scope of the assumption is the relationship of the component to other components of the system. “the falling body and the ground will not affect each other.”

Component-System

The scope of the assumption is the relationship between the component and the system. “the ground is the surface of a mass large enough to exert 1G throughout the model.”

System-Environment

The scope of assumption is the relationship between the system and its environment. “the process of a body falling through space will not affect the air in the surrounding space.”

Proposition. The proposition of an assumption is what it is saying – the statement that it is making. Initially,

propositions are expressed in natural language statements, e.g., “the mass of the falling body remains constant.” However, these must be encoded in a knowledge representation language (e.g., OWL-DL or KIF) before they can be used by a software agent such as a description logic reasoner. Thus, the proposition will be specified using a formal language and in terms from a formal ontology.

Note that propositions are not restricted to simple concepts—they may encompass the content expressed by theories, books, and even whole libraries. To illustrate, consider the statement, “the falling body problem uses Newton’s Second Law.” This encapsulates the concepts of force, mass and acceleration; and, by extension, the concepts of the velocity and position.

Propositions used in assumptions can be classified by type—how each is used—and may be further categorized as: Existential – affecting the referent’s existence Relational – affecting the referent’s relation with

another component Qualitative – affecting characteristics of the referent,

which may be: o Behavioral – specifying the referent’s behavior o Temporal – specifying temporal aspects of the

referent o Spatial – affecting a spatial aspect of the referent Proposition type is not partitioned exclusively; it is

possible for a proposition to fit into multiple categories at once. To illustrate, consider the assumption: “the ground remains non-permeable throughout the life of the model.” Taking the ground as referent, the proposition is that it is universally non-permeable. In terms of quality, this assumption is both temporally and spatially universal throughout the life of the model. It is also relational in that the assumption affects the relation between the ground and the falling body. In terms of category, this assumption affects the existence of what it is related to—the falling body cannot exist inside or underneath the ground.

3.2. Taxonomy It is helpful, at this point, to identify some of common

properties by which assumptions can be classified. This is not intended to be an exhaustive list, and by its nature is not hierarchical. Intension vs. Extension - Definition by intension is

definition by giving all the criteria by which something is satisfied, thus defining a set. Extension is defining something by listing all of its examples[17]. The first (intension) yields a system under which something can be evaluated as being part of the set; the second (extension) yields a list of constituent members of the set. “The body will bounce off of anything solid. The body will bounce off the wall, the floor, and the

2008 SpringSim 85 1-56555-319-5

obstacle. The first of these is an assumption defined by intension, and the second is defined by extension.

Explicit vs. Implicit - Explicit assumptions are often stated in the description of the model or system. They are presented in such a way that they can be directly referred to. Implicit assumptions often concern knowledge about the context or world that the model or system is expected to operate in. “The falling body starts at an at-rest condition. The laws of thermodynamics are in effect throughout the process of the body falling.” The first of these assumptions is most likely explicit, and is stated in the description of the model. The second of these is implied, by the fact that it describes a physical process, existing in a 3D world, with normal laws of physics.

Primary vs. Derivative – Derivative assumptions are derived from primary assumptions. “There are no bodies, other than the ground, in the environment that the falling body is falling within”. The derived assumption from this is that the effects of gravity are only applied by the ground, as there are no other bodies to consider.

Load bearing vs. Non-load bearing - This refers to the importance of the correctness of an assumption with respect to the problem solution it is a part of. If the assumption affects the overall behavior of the model or system in such a way that it cannot be ignored or accounted for, then it is considered to be load-bearing. If, on the other hand, the effects of the assumption (perhaps on the behavior of a single component, or on one relation between two components) can be accounted for, or corrected within the final results, then it is considered to be non-load bearing.

Joint vs. Disjoint with others - This refers to whether the assumption acts independently or whether it operates in conjunction with other assumptions. This raises the question of how they are joined. Boolean combinations are suitable if the assumption can be evaluated with respect to its truth. Other methods of combining, such as descriptive logics, may apply.

Exogenous vs. Endogenous - This refers to the source of the assumption. An exogenous assumption is one that comes from outside the system and is unaffected by the model. An endogenous assumption is one that originates from within the model and possibly affects it.

Dynamic vs. Static - This categorization addresses the question, “is the assumption fixed over the course of a solution?” The course of the solution may refer to temporal or spatial or behavioral stability. This property of the assumption can most likely be described by the type categorization characteristics.

Deterministic vs. Probabilistic - It is likely that some assumptions will always have the same, repeatable and measurable, effect on the model, or system. These

assumptions are deterministic. On the other hand, there may be assumptions that have some random factor, either intrinsic or representational (due to not knowing all of the affecting variables).

Controllable vs. Non-controllable - It is possible that some assumptions might be able to be controlled, but are worth evaluated in a controlled state vs. a non-controlled state. Other assumptions might not be able to be controlled. Consider, “The surface of the body is covered in non-reflective paint. The falling body will not pass through a physical object.” The first of these assumptions is controllable, the second is not.

3.3. Assumption Use This section addresses how assumptions are used. By

themselves (i.e. as simple statements), assumptions are fairly useless. Assumptions become important when they shape the framework of a solution. An assumption becomes a constraint on the framework of a solution only if it is challenged (questioned, or considered). Unchallenged assumptions can become hidden, violated constraints.

As previously stated, assumptions reflect desired problem values, simplify the problem solution, and set problem limits. Note that only the simplest of models uses single, primitive assumptions. Most often, a list of assumptions is needed to capture the conceptual model that underlies a system component. The individual assumptions on a list can act independently or in combination. This raises a question that is both practical and philosophical at the same time: What does it mean to combine assumptions?

Boolean combinations are one possibility, particularly when the truth values of one or more assumptions are at issue, such as when comparing lists of assumptions associated with different model components, e.g., to ascertain whether the assumptions associated with model components are valid. Functional relationships are another possibility, particularly when dealing with complex or derivative assumptions. The difficulty is that that the specification of an assumption’s proposition can potentially encompass an entire theory. This raises the question whether propositional logic that deals with simple declarative propositions, is sufficient, or if first-order logic (that additionally covers predicates and quantification) or second-order logic (extends first-order logic by adding variables and quantifiers that range over sets of individuals) is required.

4. COMPARING ASSUMPTION LISTS: A CASE STUDY This section discusses how assumptions can be put to

use in modeling and simulation. As observed by one of the authors [10], the difficult

part in providing conceptual alignment between models is handling frame assumptions and model constraints to

1-56555-319-5 86 2008 SpringSim

resolve conflicts between domain views. Consider the following example: suppose that the assumptions have been listed for a particular model that is being integrated with a system that has its own set of assumptions. How can it be determined whether the assumption sets are compatible or not? Addressing the question suggests a multi-level strategy. To illustrate, let the model f be a model of wind with two alternative assumptions as shown in Table 5. The value of the function f(uses) indicates whether wind is accounted for in f or not.

Table 5. Wind assumption function values assumption function alternatives for model f

Interpretation

uses body component (wind affects)

The body is affected by wind f(uses) = 1

uses body component (wind ¬affects)

The body is not affected by wind f(uses) = 0

Let g be a system with various alternative assumptions for wind modeling as shown in the left hand column of Table 6.

Table 6. Top level proposition comparison strategy assumption function of system g

comparison with model f

uses (g=1) The system uses the effects of wind on the body does_not_use (g=0) The system does not use the effects of wind on the body

f(uses), g 0,0 – don’t care 1,0 – raise alert 0,1 – raise alert 1,1 – aligned: no alert

ignores (g=i) The system is not affected by whether the model uses wind or not requires (g=r) The system requires that wind to be taken into account denies (g=d) The model requires that the wind be ignored

f(uses),g 0,i – don’t care 1,i – don’t care 0,r – raise alert 1,r – aligned: no alert 0,d – not found: no alert 1,d – raise alert

The right hand table column presents the top level

strategy for comparing each assumption in the set for the model f with assumptions about the system, g. Where the strategy indicates a “don’t care” condition, the comparison between the assumptions in f and g can be skipped. The strategy indicates “no alert” where a successful search (or a

successful failure to find, in the case of ‘denies’) produces a satisfactory result. Cases labeled “raise alert” are caused by indeterminate search results, and are subjected to additional processing—ultimately, resolution by human judgment.

The strategy is dependent on an efficient method for comparing assumption sets. Several methods suggest themselves as candidates. Among the most promising is analogical reasoning, described by Sowa and Majumdar [18]. They analyze the relationships between logical and analogical reasoning and describe a highly efficient analogy engine that uses conceptual graphs as the knowledge representation. Their methodology employs three methods: Matching concept types, in order of increasing

semantic distance: o Identical types. o Subtype - supertype. o Siblings of same supertype. o More distant cousins.

Matching subgraphs: o Match isomorphic subgraphs independent of type

labels. o Merge adjacent nodes to make them isomorphic.

Finding metalevel mappings that can relate even though they are not isomorphic. Application of the method of analogical reasoning to

the problem of detecting potential conflicts between lists of assumptions begins by comparing the propositions of one list with those in the other. Where there is zero semantic distance between propositions, it is said that they match and no further processing is needed. For all other cases there is either a partial match, a match in metalevel mappings, or possibly no match at all. Each of these requires adjudication.

The kind of adjudication depends upon the assumption function associated with each proposition and whether the assumption is load-bearing (as defined in section three) or not. The intention is that for load-bearing assumptions that are relied upon, or cared about, the adjudication is performed by a human or an agent that supports a human. The results of the adjudication can be stored and recalled at future times to provide precedents to human operators. The results can also be used to train agent-based systems.

5. SUMMARY DISCUSSION Although it is not widely discussed in the literature,

conceptual models always involve a particular viewpoint. This may be the viewpoint of the model developer, system integrator, federation member, verification team associate, model results user, software agent designer and so on. Aligning conceptual models means, ultimately, mediating between viewpoints. Assumptions are an implicit portion of a conceptual model. When comparing conceptual models most practitioners focus on alignment of the explicit

2008 SpringSim 87 1-56555-319-5

portions of the model. It is the authors’ view that alignment of assumptions is an equally valid endeavor.

If the manner in which assumptions are represented and used can be standardized, then it becomes possible to formalize reference frames. In turn this enables semi-autonomous detection of mismatches in conceptual models, at least with respect to those critical assumptions that a system relies upon.

This paper has summarized the authors’ research on the topic of assumptions. The topic is broad and limited space has enabled presentation of only its most important parts. It has introduced: a formalism for representing assumptions, a method for comparing assumption lists between

system components that accounts for usage and relevance, and

a taxonomy of characteristics. Future research includes implementation within a

software agent architecture, verification tests using specific examples, and elaboration of the comparison strategy to take account of component scope. Consideration will also be given to how each characteristic in the taxonomy shapes the process of formulating and comparing assumptions. REFERENCES

[1] "DICTIONARY.COM: assumption,"

http://dictionary.reference.com/browse/assumption, last accessed 10-30-2007.

[2] "WordNet Search 3.0," http://wordnet.princeton.edu/perl/webwn, last accessed 10-24-2007.

[3] I. Niles and A. Pease, "Towards a Standard Upper Ontology," in Proceedings of the International Conference on Formal Ontology in Information Systems (FOIS), Ogunquit, Maine: ACM, 2001.

[4] "Knowledge base Browser," http://sigma.ontologyportal.org:4010/sigma/Browse.jsp?kb=SUMO, last accessed 10-30-2007.

[5] C. Masolo, S. Borgo, A. Gangemi, and A. Oltramari, "Ontology Library (final)," Laboratory For Applied Ontology, Torento, Italy,WonderWeb Deliverable D18, 2001.

[6] P. Grenon, "BFO in a Nutshell: A Bi-categorial Axiomatization for BFO and Comparison with DOLCE," Institute for Formal Ontology and Medical Information Science (IFOMIS),06/2003, 2003.

[7] J. A. Dewar, C. H. Builder, W. M. Hix, and M. H. Levin, "Assumption-Based Planning: A Planning Tool for Very Uncertain Times," The Rand Corporation, Santa Monica, CA,1993.

[8] M. A. Hofmann, "Modeling Assumptions: How they affect Validation and Interoperabilitiy, 05E-SIW-

002," in Proceedings of the European Simulation Interoperability Workshop, 2005.

[9] B. P. Zeigler, H. Praehofer, and T. G. Kim, Theory of Modeling and Simulation, 2nd Ed. John Wiley, 2000.

[10] R. D. King, "Towards Conceptual Linkage of Models and Simulations, 07F-SIW-066," in Proceedings of the Fall Simulation Interoperability Workshop, 2007.

[11] D. Garlan, R. Allen, and J. Ockerbloom, "Architectural Mismatch: Why Reuse Is So Hard," IEEE SOFTWARE, vol. 12, no. 6 pp. 17-25.

[12] N. Y. Foo, "Why Engineering Models Do Not Have A Frame Problem," in Discrete Event Modeling And Simulation Technologies. H. S. Sarjouhian and F. E. Cellier, Eds. New York: Springer-Verlag, 2001, pp. 15-26.

[13] M. Spiegel, P. F. Reynolds, and D. C. Brogan, "A Case Study of Model Context for Simulation Composability and Reusability," in Proceedings of the Winter Simulation Conference, 2005.

[14] P. K. Davis and R. A. Anderson, "Improving the Composability of Department of Defense Models and Simulations," RAND National Defense Research Institute,2004.

[15] "IEEE Recommended Practice for High Level Architecture (HLA) Federation Development and Execution Process (FEDEP) (IEEE Std 1516.3)," Institute of Electrical and Electronics Engineers, 2003.

[16] M. Broy, "Multi-view Modeling of Software Systems," in Formal Methods at the Crossroads: From Panacea to Foundational Support Berlin / Heidelberg: Springer, 2004, pp. 207-225.

[17] A. Church, "Dictionary of Philosophy,". D. Runes, Ed. Totowa, NJ: Littlefield, Adams & Company, 1972, pp. 147-148.

[18] J. F. Sowa and A. K. Majumdar, "Analogical Reasoning," in Proceedings of the International Conference on Computational Science, de Moor, Lex, and Ganter, Eds. Berlin: Springer-verlag, 2003, pp. 16-36.

AUTHORS’ BIOGRAPHIES ROBERT D. KING is a PhD candidate in Modeling and Simulation at the Old Dominion University (ODU). He received his B.S. in Electrical Engineering (cum laude) from Marquette University and performed graduate studies at the Naval Postgraduate School. His PhD research focuses on the role of assumptions in model interoperability. CHARLES D. TURNITSA is a Ph.D. candidate at the Virginia Modeling Analysis and Simulation Center (VMASC) of the Old Dominion University (ODU). His PhD research focuses on ontology for M&S interoperability.

1-56555-319-5 88 2008 SpringSim