This paper describes a number of design techniques employed in the Financial Industry Business Ontology (FIBO) series of standards. These are compared to the notion of a conceptual ontology as a computationally independent artefact. An example is given in the applications of the Interest Rate Swaps (IR Swaps) FIBO ontology, where some ontology elements may be re-used to represent different concepts in different kinds of ontology application. Some proposals are outlined for the use of a higher-level industry concept ontology to provide disambiguation between the concepts referred to in different ontology applications. This paper is intended to promote discussion on possible crossdomain and upper ontology components for use across these different kinds of ontology application.
The Financial Industry Business Ontology (FIBO) [
The notion of a ‘term’ as used in the financial industry is only loosely defined and the original work on what was to become FIBO took the approach that what was needed was a model of the concepts represented by words or ‘terms’ in industry data and communications. That is, the objective pursued by this author in the original development of FIBO was to provide a reference model for semantic interoperability across a range of technologies by providing conceptual clarification and disambiguation of concepts and by defining the formal real-world semantics of concepts in the financial domain. This style of ontology is referred to in this paper as a ‘conceptual ontology’. Elsewhere, terms like ‘business concept model’ are used to avoid confusion with other uses of the word ‘conceptual’ among IT practitioners.
FIBO as published is intended to provide a number of ontologies in the Web
Ontology Language (OWL) [
There is a growing awareness in the financial industry of the need for a more
conceptfocused kind of ontology to provide formal semantics for industry terms. For example
in ISO TC68 SC9 Working Group 1 [
The use of the term ‘Upper Ontology’ in these business contexts should be interpreted as referring to a combination of top level and cross domain ontologies, the purpose of which is to provide a computationally independent representation of the semantics of the domain of discourse, in this case the domain of finance and commerce. This would be a ‘conceptual ontology’ in the sense that that term is used in this paper.
This paper looks at the balance of concerns between conceptual (computationally independent) ontologies and those ontologies design for a specific purpose or range of purposes (informally, ‘operational ontologies’). Some distinctions observed between conceptual and operational ontologies in the FIBO ecosystem are given as an illustration of the kinds of issues that arise in determining how instance data (individuals) are to be populated in applications of the latter. Here we have chosen one aspect of these differences, namely the way in which certain classes of the operational ontology appear to be intended to be used for more than one kind of thing in the domain of discourse. The assertion explored here is that a conceptual ontology needs to have a good set of upper and cross-domain ontologies in order to provide the kind of information needed by implementers of operational ontologies (including implementers of the published FIBO standards material) in order to correctly assign data to classes and properties.
This paper explores the implications of these design arrangements and proposes the use of computationally independent conceptual ontologies including the framing of their concepts within a set of top level ontology partitions, as a means to provide management and oversight of these applications.
Taking a specific example observed in these ontologies during some proof of
concept work for Blockchain applications [
Section 2 gives an overview of the FIBO standard, describing the evolution of FIBO from a computationally independent conceptual ontology to a set of ontologies intended for use in OWL based applications.
Section 3 introduces the design conventions followed in the released OWL components of FIBO, based on observations of the differences between FIBO as a released standard and the original conceptual ontologies developed for the industry.
Section 4 goes on to focus on one specific design convention, whereby certain classes and properties are seen to be conflate concepts, presumably by design. This is illustrated by an example from the financial instrument class of Interest Rate Swaps, where the re-usability or under-specification of some classes was observed during a proof of concept activity. The weaknesses of this design convention are explored, in particular the way that the precise semantics of these concepts are left to the implementers of future applications.
The need for a conceptual ontology is asserted, and in Section 5 a number of application contexts are given for the financial industry and beyond, that would need to be taken into account in understanding how operational ontologies are likely to be deployed in industry applications.
Section 6 sets out a minimum requirement for set of upper and cross domain ontologies to be used in business ontologies and suggests how these would address the weaknesses described in Section 4.
Section 7 sets out the core proposition of this paper, that industry should work towards a consensus set of re-usable cross domain ontologies integrated within a suitable simple upper ontology partitioning layer.
Section 8 sets out the conclusions of the paper and aims to frame further discussion on these topics.
FIBO was originally conceived as a computationally independent conceptual ontology,
but was modeled using the basic constructs of the OWL language within a
businessfacing presentation format. This was known as the ‘Semantic Repository’ [
During initial socialization of this work it was challenging to explain to the potential users of these models that what was being proposed was not in fact a data model. A number of potential arrangements were explored during 2007 and 2008 for the modeling of formal semantics of concepts in the financial services domain. One additional instruction given to the author was to ‘Keep the philosophy out of sight’ (private correspondence with the author); it was not practicable to simply represent the industry concepts in formal logic, there needed to be tool support for presentation and business validation of the model content.
As described in [
One challenge in using OWL for computationally independent ontologies is the expressive power of the language: not everything that needs to be said about the business problem domain can be said in the sub-set of logic that OWL represents. The initial FIBO conceptual ontologies were therefore considered as being a sort of conceptual core around which other kinds of assertion might be made.
Another potential issue with the use of OWL was the lack of any methodological support for concept representation, leaving it the individual modeler to find the best ways to represent things in the problem domain. This was not considered to be a weakness but rather an absence: for the early conceptual work on what was to become FIBO, the beginnings of a conceptual modeling framework were drafted to address these matters, although as noted above these were of no interest to the end users of the models. OWL itself was simply considered as one syntax in which model content could be represented.
Although OWL was considered as the underlying language for the model content,
even the existing OWL tooling was considered to be inadequate for a ‘technology free’
business presentation and so the OWL constructs were rendered in UML tooling using
the Ontology Definition Metamodel (ODM) [
The FIBO ontology was originally conceived as a computationally independent
reference ontology. The concepts were framed within a fairly basic set of upper
ontology partitions, based on the top layer of John F Sowa’s ‘Knowledge
Representation” lattice of theories [
The documented basis for most of the concepts in the initial parts of FIBO is that these represent the commitments enshrined in the terms and conditions of contracts. This forms the basis for the definition of financial instruments, as these are all contracts of one sort or another. Other components of FIBO deal with corporate actions, securities issuance processes and securities transactions. The intent with these is to provide a comparable real-world grounding of the concepts in terms of events and activities.
The FIBO standard ontologies that are made available via the OMG in contrast
provide a set of ontology design artefacts for use in inference processing. These may be
considered as designed artifacts comparable with logical designs in other technologies
and are sometimes referred to as ‘operational’ ontologies, though this term is not used
within the FIBO ecosystem itself. A more detailed treatment of the distinctions
between these kinds of ontologies is given in [
Certain design decisions have been made for this FIBO standards content which distinguish them from a computationally independent model of the subject matter as originally envisioned. According to some recent statements these design decisions include the use of certain classes to represent more than one set of things in the domain of discourse1. This stated design approach has implications for the management of application ontologies and their data.
As part of the process of submitting FIBO to the OMG as a series of standards, the focus of FIBO has shifted from the use of OWL as a means to frame conceptual meaning, to the application of design rules suitable for OWL-based ontologies for inference processing and reasoning.
The design conventions for this style of OWL in FIBO have not been formally documented but may be discerned by considering the changes made from the original conceptual framing of FIBO to the style of ontology considered suitable for release as an OWL-based standard. These design changes include but are not limited to: 1. Removal of references to upper ontology material 2. Removal of domains and ranges from many object properties 3. Object properties whose domain is a union of unrelated classes 4. Substitution of ontological representations of information constructs such as names, for simple datatype properties with ‘string’ as their range 5. Substitution of social constructs (where these give the business semantics of a concept) for data elements that may provide evidence of the existence of such constructs 6. Conflation of similar concepts, for example combining into one class the notion of a clearing house as a functionally defined entity and the role of that clearing house in some securities transaction.
It is not the intent of this paper to critique those design decisions. For the most part we assume that these decisions are reasonable for the perceived range of competency questions and usages to which these ontologies are to be put. We also note that these design decisions are a principled application of the computational constraints of the design of an OWL based solution or set of solutions.
These are therefore not computationally independent models. Rather they are derived from the earlier computationally independent models that made up the initial conceptual FIBO material.
One of the design conventions observed in the published FIBO OWL standards is the apparent intention that certain classes and properties may be considered to be polysemic.
An example of reusable concepts occurs in the area of Interest Rate Swaps (IR
Swaps) [
IR Swaps are effectively transactions and like most transactions these have a
corresponding contract, usually made up of an over-arching master agreement plus
transaction-specific terms in a separate message that is deemed to have contractual
standing. There are terms for interest rates, interest amount accruals and payments,
these rates and accrued amounts being accrued and paid down on a periodic basis. In
FIBO the semantics of contracts is focused around the notion of a ‘commitment’ and
draws upon the REA Ontology [
In FIBO the definitions of the terms for IR Swaps, being the terms of a contract, are definitions of the commitments made by each party to the other.
Meanwhile there is a business requirement for reporting on the interest accruals
and payments that happen during the life of the swap [
In the released FIBO as currently designed, it is seemingly possible to take the same ontology and populate it with data (OWL Individuals) representing different semantics, specifically terms definitional of the contract and terms for reporting of individual transactions.
Assuming this practice persists, one can reasonably ask why an ontology is used at all and not simply a data model? Given the current practice, users need to be aware that wherever classes are or might be populated with different data in different usage contexts, data from one such application cannot be interoperable with data from the other. This need not be an issue as long as users of the standard are aware of this feature. However, the use of the same namespace for a multiplicity of incompatible applications’ data clearly represents a risk for data management, reporting and compliance.
Ontologically there are two distinct kinds of ‘things that happen’ that are both of
relevance to IR Swaps. As conceptualized in the original FIBO conceptual modeling,
there are things that should happen (prescriptive) as in a business process workflow
description or in this case the required payments, accrued obligations and so on as
prescribed in the terms and conditions of the contract. Then there are the things that do
or will happen: the actual occurrences whether past, present or anticipated in the future.
These are events or activities with dates, specific amounts of interest accrued at specific
calculated rates, monies owed or accrued as of a given date and so on. For a separate
but comparable treatment of these considerations see also [
In the published Interest Rate Swaps FIBO ontologies the same classes appear to be intended to be used for both. There are at the time of writing some inconsistencies in the concepts that are ancestral to these concepts in IR Swaps, but there is also (by design) no use of upper ontology and consequently no means to distinguish between intended and actual occurrents, although there are the concepts of ‘Occurrence’ and ‘Occurrence Kind’ that partially allow this distinction to be made. It is assumed that these questions are left to implementers of ontology-based applications that would reuse FIBO components.
The intended occurrents modeled here would be framed in some upper ontologies not as occurrents at all but as dispositional notions (commitments being dispositions, along with beliefs, tendencies etc.). Other upper ontologies, including the prior FIBO conceptual work would define these commitments as kinds of social construct, with a relationship to the concept of an event that ‘should’ happen. There is a range of valid ways to frame these concepts but the published FIBO standards, being intended to operationalize OWL, leave these distinctions to the end user. The intended semantics of a given class therefore depend on the context in which data is assigned to these classes and their related properties.
Given that FIBO has the stated policy not to use upper ontology or cross-domain abstractions (particularly social constructs and most things that are not materialized as data), it is recommended that operational ontologies like FIBO and those derived from it should have some traceability to an explicitly conceptual ontology. This would address not only the above observed example of polysemy but also other common design patterns seen in OWL ontologies used for applications, such as the reduced use of property domains and ranges, the use of data surrogates for real world social constructs, and others as noted previously.
While some examples of such polysemy have been removed from the FIBO
models since this example was uncovered, the design justification for doing so has
been clearly stated in correspondence with the author, though not formally
documented. Other examples have been identified in the area of ‘values’, where a given
class may be taken to represent the prescription of a value or an actual occurrence or
measurement having such a value. It should be noted that these distinctions were not
made in the original conceptual models, where these were simply regarded as the
concept of a value or other such matter without reference to context or usage.
Subsequent research and feedback, in particular with reference to the proposed
Semantics for Information Modeling and Federation (SMIF) standard [
The reusability of ontologies is not the same thing as the reusability of classes and properties to mean different things in different contexts as indicated by the example explored in this paper, and should not require this. Clearer guidance and design conventions are clearly needed for end user developers in order for these operational ontologies to be reusable in different contexts. The use of a separate conceptual ontology should therefore enable re-use of operational OWL ontologies such as those published as parts of FIBO.
In order to identify the range of possible concepts needed in the proposed upper and cross-domain ontologies, the first step would be to catalog the range of ways in which a given set of operational ontologies may be used. The relevant high-level concepts can be identified from these. For example in the IR Swaps case one would identify the need for prescriptive and descriptive occurrent partitions.
The kinds of contexts required for financial applications would include: 1. Reporting, including trade reporting 2. Transaction processing (straight through processing) and associated messaging 3. Risk management and reporting 4. Regulatory compliance 5. Integration of new and existing data feeds, applications etc. across different systems (middle, front and back office). 6. Mergers and acquisitions 7. Customer relationships management, cross-selling and up-selling 8. Know your customer (KYC) compliance and reporting 9. General Data Protection (GDPR) and the privacy of individuals’ data 10. Loan applications, other applications and proposals 11. Product management (including retail financial products)
Each of these and others will determine the concepts that need to be stood up in the cross-domain ontologies in order to provide the contexts needed to distinguish between separate concepts that may use the same words in data models or reports, for example, a loan as a product versus a loan as a contract between parties.
The polysemic application of such words or terms in language should not be taken as a reason to create ontology classes and properties that correspond to words and are overloaded in a similar way. Inspection of some part of FIBO suggests (perhaps incorrectly) that this has sometimes been the approach taken by model designers, which if it were the case would call into question why ontology is being used at all. Instead of focusing on words, any operational ontology should focus on concepts, ideally framed with reference to some conceptual ontology.
Some of these contextual distinctions are clearly demarcated within FIBO and comparable ontologies while others may not be. Relevant contexts would include process contexts (such as loan applications, transaction workflows), data usage contexts, risk versus real events, planning and scheduling and so on.
The distinction between conceptual and operational ontologies is explored in [
It should be possible to apply this approach to the deployment of FIBO ontologies that have overloaded semantics and other design features. In this case, an operational ontology would be stood up in its own namespace, using a localized copy of the relevant FIBO ontology supplemented by a suitable core ontology consisting of crossdomain ontologies integrated within a set of top level ontology partitions.
To support such arrangements, the industry needs to be able to refer to a core ontology that integrates and distinguishes between different contextually sensitive material. In the example given for Interest Rate Swaps, these would include distinctions between: 1. Prescriptive Occurrents: definitions of things that are prescribed as needing to happen, or as being mandated by some party or committed to by some party; 2. Descriptive Occurrents: definitions of things that actually happen, on some given dates in the past, present or some projected future, and having specific values for interest rates, accrued monetary amounts, netted payments and so on, as of those dates.
Similar sets of upper ontology material would be needed in other places where FIBO consciously conflates concepts, such as the observed conflation of parties in roles and functional entities for participants in the securities transaction lifecycle.
One proposed solution to the IR Swaps example can be found in work carried out
within the FIBO Foundations Content Team, in which the class of ‘Occurrent’ was
subclassified into several sets of pairwise disjoint facets, including those of Prescriptive
Occurrent versus Descriptive Occurrent, described briefly in the submission to [
Other sub-partitioning of the Occurrent partition of a suitable top-level ontology would also be suitable for this requirement.
It should be realistic to come up with a definitive set of core ontologies for use across business, finance and commerce, including for example insurance, logistics, real estate and financial services. Given the nature of business concerns (profit and loss, risk, legal interactions, regulatory conformance, supply chain management, customer relations and so on), as compared with the diversity of theories that underpin physics for example, it is this author’s contention that this undertaking would be simpler than trying to achieve this across the realms of physics, chemistry or biology.
Such a core ontology should focus explicitly on the notion of the ‘concept’, since many of the concerns of business relate to planning, risk, strategy, commitment and other management concerns in which the enterprise must necessarily form the concept of some matter whether or not that matter is ever present in some real or imagined world.
It should be feasible to integrate the best of breed of the concepts across the
available top level ontologies. The pre-existing ‘conceptual’ work carried out during
the earlier part of the development of FIBO may also inform the process of selecting
from and integrating between these concepts. Available cross-domain ontologies are
also of value and could ideally be integrated within a common set of top level ontology
partitions, in particular REA [
It is recommended that solutions that make use of operational or design ontologies be framed within a broader conceptual ontology framework, without the contents of such a framework needing to be included within the assertions that any such application will refer to. The conceptual ontologies referred to would exist in a separate namespace from the operational or application ontologies, so that conceptual assertions are not imported into the application.
This approach would enable operational ontologies to be re-usable and also help to identify when a given operational ontology should not be used in a given context, or should only be used with careful isolation of the resulting data, that is, not treating the data itself as reusable across more business contexts than the semantics of those data elements would support.
Ideally, application-specific (operational) ontologies would be derived from the conceptual ontology in such a way that the design is fully traceable and the data from any one application can be maintained separately to the data from any other application even when the same operational ontologies are employed. Suitable metadata relationships can be derived to represent something similar to the ‘trace’ relationship in UML (for example ‘implemented as’) relationships.
For many of the design conventions employed in FIBO released ontologies and other comparable ontologies, it should be feasible to come up with a number of repeatable heuristics for deriving suitable design patterns from the conceptual representations of things in the world. Specific examples are out of the scope of this paper but could include for example deriving end user context-specific, simple sets of classes and relationships from concepts defined ‘in the round’ with reference to ‘relative things’, ‘role mixins’ or other conceptual patterns. Some of the design patterns observed in the FIBO released standards, including the polysemic use of some classes and properties, may turn out to have been mistakes; some principled application of the relationships between conceptual and operational ontologies would provide some guidance and design auditability that would avoid or expose the possible unintended consequences of this approach.
The specific design approaches taken for FIBO standards are not in question. These ontologies are intended to provide a set of ontologies that may be re-used across a range of financial industry applications that make use of Semantic Web technology. However the particular example whereby certain classes are observed as being able to be used to frame similar concepts in different application contexts is considered risky at best and this author would recommend that this be avoided.
The creation and use of a common, cross-industry core ontology is recommended as the next component in enabling industry to roll out a range of compliance and reporting applications that make use of semantic technology and that are able to leverage the in some cases under-specified elements of the FIBO standards as well as to support re-use where this is appropriate and to signal when it is not.
This approach is also indicated for other design patterns such as properties with no domain and/or range, the use of data surrogates in place of the truth makers of a given concept and so on. In this way, designers of ontology-based applications may take account of the technical limitations imposed by any solution architecture without losing the ability to trace classes and individuals and their properties to the original business meanings of the concepts concerned. Failure to do this may in some cases result in ontology-based data that is not as reusable as they might appear from a casual inspection of the content.
There is considerable scope for further investigation and research in these areas as well as in the potential for providing practical methodological support for ontologies across the engineering development lifecycle.