Using Mathematical Model Theory to Align Conceptual and Operational Ontologies in FIBO Robert Nehmer1, Mike Bennett2 1 Oakland University, Rochester, Michigan USA nehmer@oakland.edu 2 EDM Council, UK mbennett@edmcouncil.org Abstract. This paper addresses the relationship between a conceptual ontology and an operational ontology. To date there has been little agreement about what the distinction between these and little consideration about how a conceptual ontology can be operationalized into an operational ontology and vice versa. Where it arises, the discussion is often about whether a particular ontology is a conceptual ontology or an operational ontology. While that discussion is interesting in itself, it masks a deeper discussion. That discussion occurs when a conceptual ontology is created which is intended to be operationalized in a variety of settings. In this paper, we consider the situation of the Financial Industry Business Ontology (FIBO) as promulgated by the Enterprise Data Management Council (EDMC). FIBO’s intended use is as a conceptual model which would be operationalized in a variety of projects by various players in the financial industry. Those operationalizations lead to structures which are represented in some form of first order logic, such as OWL. We use model theory to formalize the relationships between the symbols of the operationalization and the interpretation of those symbols in the conceptual ontology. Keywords: Conceptual ontology, operational ontology, mathematical model theory, interpretation function 1 Overview In this research, we develop a method which uses concepts from mathematical model theory to inform the relationships between a conceptual ontology, an operational ontology and a software artifact. The research envisions a situation where there is an extant conceptual ontology which is intended to be operationalized in different contexts. It uses the Financial Industry Business Ontology (FIBO) as promulgated by the Enterprise Data Management Counsel (EDMC) in this capacity. The financial industry contains a large number of types of firms, such as retail banks, commercial banks, clearing houses, brokerage firms, etc. We suggest that if a single firm or a consortium of firms of a particular type wanted to use the FIBO conceptual ontology, they would not use the whole ontology but rather would build, let us say, their enterprise ontology as an operationalization of the FIBO concepts which have business value implications in their own firm. So, the operational ontology is for the entire firm. It, in turn, is used to create a variety of software projects which consistently use the operationalized concepts in their own business context. This research uses model theory to provide a general procedure to derive the operational ontology from the conceptual ontology and then derive the projects from the operational ontology. In the FIBO lexicon, an 'operational ontology' is an RDF/OWL based ontology which is fine-tuned for a specific business purpose. This is distinct from the material in the FIBO OMG specifications or the overall conceptual ontology models for the following reasons: • Business Conceptual Ontology defines the meanings of things in the domain of discourse. In financial securities, meanings are generally grounded in some legal or financial concepts; operational ontologies need only define classes and properties for things that for the most part will correspond to instance data; • Conceptual ontologies cover all the concepts that may be of relevance in some use case - that is, they cover more than one use case; • The role of a conceptual model and the role of an application data store are very different - even when, as with semantic models, the architecture and model components may be the same. That is, a conceptual model (including an ontology of business terms), is a technology-neutral view of the business requirements, whereas an operational OWL ontology, having instance data, is a physical datastore. Even if they were the same, their roles are different and so are the constraints and requirements under which they are built. • A conceptual model may use multiple inheritance (polyhierarchical taxonomies) to classify the subject matter in multiple ways. This is appropriate for a conceptual model but adds processing overhead for no real value in an operational application, be it an ontology or a conventional database application. • The FIBO conceptual models make extensive use of partitioning of the upper parts of the model. This is essential in disambiguating similar terms. Consider for example the difference between a monetary amount as an abstract unit of measure, and a concrete amount of actual money. Such partitioning (in this example Concrete and Abstract), is also polyhierarchical, and so may add some processing overhead to applications, again for no benefit. The EDM Council and OMG Finance Domain Task Force members are working on developing a series of operational ontologies, starting with derivatives and business entity concepts. In the course of doing this, we expect to more formally identify the differences between these and conceptual ontologies, and home in on the heuristics for extracting or deriving operational ontology content from the conceptual ontologies. This paper is an early attempt at such an effort. At the same time, the conceptual ontologies are developed in a strongly modular fashion, so that for many applications it may be possible to simply use a sub-set of the available modules (from http://www.hypercube.co.uk/edmcouncil/tech-oo.html). The paper proceeds by first considering mathematical models. Next, it considers how to use those models to describe the relationship between conceptual and operational ontologies. Next, it specifies the general derivation of specific projects from the enterprise’s operational ontology. Finally, it demonstrates a small proof of concept using a FIBO fragment. The diagram below (Figure 1) shows the overall relationships between the conceptual ontology, the operational ontology and the implemented software as modeled in this paper. Conceptual Ontology Interpretation Function Satisfiability Operational Ontology Truth Computability Implementation Figure 1. Relations among conceptual and operational ontologies and implementations 2 Mathematical models The methods chosen to implement systems developed to run on digital devices are all types of first order logic or finite state grammars. These are logic representations used widely in abstract computer science and mathematics. First order logic differs from other logics in that it allows for quantification of function and predicate variables only. In some logics, such as sentential (propositional) logic, no quantifiers are allowed at all. In others, the so called higher order logics, quantification is allowed on the function and predicate symbols themselves, not just on their variables. In these logics, formulas such as ∃𝑓 (𝑓(𝑥) ∧ 𝑃(𝑥) ⟶ 𝑓(𝑥) = 𝑃(𝑥) would be well-formed. Inductive proofs proceed in much the same way in first order systems as they do in finite state grammars. The differences are that more than one axiom may serve as the base, that axioms can be introduced at any time and that the production rules are replaced by rules of inference. The inductive methods appeal to a continuous reapplication of rules is often added as an axiom to systems of formal logic. In axiomatic form, it appears as (𝑃(𝑂) ⋀ ∀𝑛(𝑃(𝑛) ⟶ 𝑃(𝑛 + 1))) ⟶ ∀𝑥𝑃(𝑥). A question which must be addressed is how, in the derivation of formulas by repeatedly applying inference rules, the truth of the resulting formulas is preserved. This is answered by first considering the interpretation function again, then introducing models and, finally, discussing logical truth in models and derivations. The interpretation function is a map between the symbols of the syntactic language, L, and the objects of a set, M, about which the language has meaningful things to say. Here the set M is the set of concepts in a conceptual ontology. The interpretation must map formulas of L into their meanings in M and in structures of M, the conceptual ontology. Let φ be the interpretation function and divide φ into primary mappings and secondary mappings. The primary mappings will provide the interpretation while the secondary mappings provide the inductive element for complex strings of L. The language is considered systematically through its subsets. The specification is adapted from Manin [1977] p. 24-26. The specification of the interpretation _ function leads _ directly _ to the concept of a model. Any formula F is said to be φ-true if ║F║φ(𝑚) = 1 for all 𝑚 in 𝑀. For a set of formulas ∑, M is a model of that set when every formula of ∑ is φ-true. This is sometimes referred to as ∑ being satisfied by M. A subset of these formulas can be constructed as the axioms of a first order logic when the syntactic rules for formula building and derivation are correctly defined. The set of all elements and relations between elements in a model is called the universe of that model, denoted │A│, where A is the set of symbols of a model. The model will in most cases not be equivalent to the entire conceptual ontology. The usage of the term 'model' here is restricted to the definition above. Note that 'model' here should not be confused with mathematical models in general, such as linear or nonlinear systems. Nor should it be confused with mathematical modeling techniques. Rather, it is a set theoretic concept and is used as such throughout the discussion. A model contains a subset of the universe of the language of the model, the conceptual ontology, by definition. Additionally, a model for a language consists of an interpretation function, φ, so that the complete representation of a model is a pair of symbols of the language and the interpretation function. At times the representation of A is broken down into its component sets, depending on the context in which the model is being presented. The interpretation function is the semantic component of the model. It maps the symbols themselves to the appropriate constants, functions, etc. That is to say, the interpretation creates the structure of the model, for instance, requiring that '<' as a symbol be interpreted as 'less than', '+' as ‘addition’, etc. For this reason, models are sometimes referred to as structures. Another important distinction to make here is the difference between the language and the metalanguage. The language in first order logic consists of the symbols and inferences, as above. The metalanguage in first order logic and model theory is a powerful concept which allows an analysis of the language itself. The distinction is between a sentence of the language such as ∀(x,y,z)(S(x) = S(y) + S(z)) whose interpretation is, say, 'for all asset, liability, and equity accounts, the sum of the asset account balances equals the sum of the liability account balances plus the sum of the asset account balances' and a sentence about sentences in the language. 3 Model theoretic constructs between conceptual and operational ontologies The concept of a model can also be used to define the truth of formulas in a particular model. The idea of truth is closely connected to validity, completeness, and consistency as well as the method of proof employed in first order logic. The following discussion begins with the semantic, metalanguage of truth and proceeds to a discussion of the syntactic notion of deduction. It ends with a specification of how validity, completeness, and consistency are proved in first order logic. The standard abbreviated notation for a model is to use German capital letters, usually 𝔄 and 𝔅. The string '𝔄 ⊨ 𝜎' means that σ is true in model 𝔄. This truth is defined precisely by the interpretation function developed above and is therefore at the semantic level of the language. The symbol │𝔄│ is used to indicate the objects of 𝔄, such as accounts and ATs, of which the language speaks. These objects, of course, would not include the logical operators, predicates, etc., but only those objects which are terms, that is, constants, variables, and functions. Thus │𝔄│ = M in the discussion of the interpretation function. Suppose ∑ is a set of formulas and σ is one particular formula, then Σ ⊨ 𝜎 means_ that ∑ logically implies σ. In terms of _ the model, the interpretation is as follows. For every 𝑚 in which 𝔄 satisfies all formulas of ∑, 𝑚 also satisfies σ. Notice that ∑ can be empty in which case σ is referred to as a valid formula or a tautology. These two concepts are explained in more detail below. The symbol '⊨𝔄 𝜎' is used to mean that σ is logically implied in the model 𝔄. This notation is used when two or more different models are being considered. As such, elementary equivalence is alternatively defined as when any structure 𝔄 is a model for an arbitrary formula σ if and only if 𝔅 is also a model of σ, then 𝔄 and 𝔅 are elementary equivalent, that is 𝔄 ≡ 𝔅. This means that the two models cannot be distinguished in first order formulas. If, however, the weaker condition that ⊨𝔄 𝜎 ⟹⊨𝔅 𝜎 obtains among two models, where ⟹ again is the implication operator of the metalanguage, then 𝔄 is called a substructure of 𝔅. We now proceed to make this more specific by constructing an operational ontology from a conceptual ontology. Doing this is equivalent to constructing ⊨𝔄 as follows. This requires that as the components of M, the conceptual ontology, are chosen to be designed into the operational ontology, and that this is done in a way which is definable in M. That is, constructing the model 𝔄 is constrained to models that are satisfiable. It is important to note that not all models of theories (sets of sentences) constructed from the conceptual ontology are guaranteed to be satisfiable. The design criteria, done correctly, limits the elements of M that can be designed into the model and their relationships to those which can be satisfied in the structure. If we consider the case in the other direction, that is, defining the conceptual model from an operational model, situation is considerably simplified. In this case, the operation is equivalent to the designing of φ, the interpretation function. If we assume that the language in which the operational ontology was developed is satisfiable in the sense of a language being a set of true sentences, then we are guaranteed that there exists a model of the operational ontology. Note that in this case, 𝔄 will be equivalent to M unless more work is done to extend the concepts in M, the conceptual ontology. 4 Model theoretic constructs between operational ontologies and first order logic Although of less importance to this paper, we consider the relationship between an operational ontology in the sense of this paper and its underlying language represented by strings in OWL or some other formulation. Again, we can consider both directions: the operational ontology to the formal language and its opposite, the language to the operational ontology. Consider ontology to language first. This requires that a computable language is designed which will satisfy truth in the operational ontology. It would not necessarily require that the entire ontology be satisfied but only the components necessary for a particular implementation of the ontology. In the other direction, from language to operational ontology, what is required is to build a true language. That is, the language would be constructed so that it is provable in some ontology. That ontology operationalizes the language and is its operational ontology. It would not, however, be necessarily meaningful in the sense of being interpretable in a conceptual ontology unless, of course, we continued the design process and created an interpretation function for it. 5 Proof of concept using FIBO Consider the FIBO fragments below (Figures 2 and 3). The first is the REA claims concept diagram from the FIBO conceptual model. Here an REA claim (C) is defined on the part of an accounting reporting party (ARP). It occurs when there is a remaining imbalance in a commitment, such as in a contract which has not yet been completely fulfilled. It can be a debt claim (DC) or an ownership claim (OC). To build the interpretation function, really a set of functions, we map the symbols of the second fragment onto the semantics of the first fragment. Figure 2. REA Claims in FIBO Conceptual Ontology The second, related fragment has three terms and two relations on the buyer subtree. The terms are Buyer (B), Payment Obligation (PO) and Delivery Right (DR). The two relations are has Payment Obligation (hPO) and has Delivery Right (hDR). The interpretation function is { (B → ARP), ((PO, DR) → DC) } Notice that in FIBO as it exists, conceptually there is no distinction between a buyer and seller. This is because of the REA duality concept. Yet when the model is operationalized, the two aspects of buying and selling separate or unfold. Using Polish Notation, a satisfiable structure, again for the buyer alone, in this simple example is {hPO(B, PO), hDR(B, DR)}. This and the interpretation function is a model of the fragment. The implementation in first order logic can be represented simply as { hPO(B ∧ PO) ⊢ T; hDR(B ⋀ DR) ⊢ T } where T is “true.” Figure 3. Payment and Delivery Obligations in Operational Ontology References 1. Enderton, H. B. A Mathematical Introduction to Logic. Orlando: Academic Press, 1972. 2. Falbo, R. A.; Guizzardi, G.; Gangemi, A. and Presutti, V. (2011). Ontology Patterns: Clarifying Concepts and Terminology. Springer-Verlag Berlin Heidelberg. 3. http://www.hypercube.co.uk/edmcouncil/tech-oo.html 4. Lemaignan, Severin; Siadat, Ali; Dantan, Jean-Yves and Semenenko, Anatoli (2006). MASON: A Proposal For An Ontology Of Manufacturing Domain. Proceedings of the IEEE Workshop on Distributed Intelligent Systems: Collective Intelligence and Its Applications (DIS’06). 5. Long, F.; Zhang, L. and Wang, C. (2013). A Conceptual Logic-based Creation Method for Operational Plan Ontology Class Hierarchies. Fourth Global Congress on Intelligent Systems. 6. Manin, Y. I. A Course in Mathematical Logic. New York: Springer-Verlag, 1977. 7. Sivashanmugam, K., Verma, K., Sheth, A. P., & Miller, J. (2003). Adding Semantics to Web Services Standards. http://corescholar.libraries.wright.edu/knoesis/687