| Development | Modeling Principles | Explanation |
FIBO is created according to the following principles:
the above bullet list will be replaced by a diagram shortly
A mature development process is one in which the business provides the first point of reference and the final say in what is developed. This is true whatever the technology (these principles apply equally whether the technology is electrical, mechanical or information technology).
A mature development environment is described for example in the Data Maturity Model for data, or in the Capability Maturity Model for other types of development. The ISO 9000 series of standards also describes the principles for implementing a mature business environment in which the things delivered by a business to its customers can be seen to conform to their stated requirements.
Part of the implementation of a mature development environment is the provision of business-facing representations of the problem domain, as described under the next principle.
Key to the successful implementation of any technical deliverable is the provision of an independent, business-facing view of the subject matter. This may take one of several forms: for programs, a formal specification or use cases describing what it is to do; for logical operations, a formal statement of business logic; for process, a business process model. For data, the business-level view of what is in the data, is a representation of the meaningful concepts which the data is to represent. This is known as an ontology
These several business views together represent what are often called "Conceptual" models. Terminology and usage may vary in different development methodologies, but any development method which puts the business in control of its assets will have models of this kind. Any technical development which is undertaken with these, is not mature. Symptoms of a lack of development maturity include late deliveries, budget over-runs and deliverables which do not meet the expectations of the business.
Note for technical modelers: A conceptual model, such as (for data) an ontology, is not a more abstract view of the solution. It is a concrete model of the problem.
Syntax is not semantics.
This may appear obvious, but it is worth re-stating here. Rendering a model in a 'Semantic' format such as RDF/OWL does not automatically make it meaningful. Meaning relies not on the syntax of the language used in creating the model; it relies on the principles by which the model represents meaningful concepts (classification, abstraction etc.), and on the formal model theory by which the model relates to the subject matter.
If you take a logical data model design, and re-render the model content into RDF/OWL, the result is a logical data model in OWL. This may have its uses, but rendering it in OWL will not have made it meaningful.
Conversely, if a model is rendered using UML tooling this does not automatically mean that it is not an ontology - whether it is or not depends on the model constructs, what these stand for, what logical constructs they represent and how they relate to the subject matter (i.e. what do the items in the model represent).
Some modeling syntaxes are better suited for meaning than others. The Web Ontology Language is well suited for writing ontologies. So are certain other syntaxes such as the Common Logic Interface Language (CLIF), the Cyc format and so on.
Classification of the subject matter is an important pre-requisite to creating a meaningful ontology. A classification system is known as a 'Taxonomy'. This can be understood by considering the Linnaeus Taxonomy of Species. In Linnaeus, as in any other taxonomy, subject matter is represented in classifications or 'taxa', with the most general at the top and with more specific items at the bottom. Properties of things are inherited, so that for example one does not need to state that birds have a backbone, mammals have a backbone, fish have a backbone and so on - these are all inherited from the common, more general term of 'Vertebrate', which is defined as anything which has a backbone.
There are many schemes by which things may be classified. In order to build a meaningful ontology, we use the specialization / generalization relationship. This is a transitive relationship in which properties are inherited from the more general to the more specific items in the hierarchy, all the way down to the most specific things in the model. This relationship happens to be included in the UML Class Diagramming language, but is not unique to technology (it can be traced back to Aristotle, and one of his syllogisms).
In FIBO we have applied these principles to every item in the ontology. Securities, derivatives and so on are classified hierarchically, but so also are the various things which are referred to in facts about those - such as legal or contractual rights and obligations, accounting concepts like equity and debt, and so on.
Classification schemes may be monohierarchical (each item has one immediate parent) or polyhierarchical (items may have more than one immediate parent). For example a whale may be classified both as a mammal (in Linnaeus) and as a marine animal (classified by habitat). FIBO uses polyhierarchical classification in order to classify the subject matter by each of the facets which may be of relevance in one or another application use case. So an Interest Rate Swap is both a Swap (classified by contract structure) and an interest rate derivative (classified by underlying asset type).
For each new class of 'Thing' which is added to the ontology, we ask ourselves two questions:
These questions are asked all the way up to the top of the taxonomy - the class of things of which everything is a member. As a result, everything in the model is described in terms of the 'simplest kind of thing' of which it is a special kind. These simplest kinds of thing are called archetypes, in line with the natural English meaning of that word.
The result is a model in which everything may be described in terms of simple, abstract, atomic building blocks. This avoids the brittleness associated with data models: if and only if we have abstracted each thing adequately, new terms may be added without disturbing the existing model content.
This is particularly relevant in financial services: many new instruments, especially over the counter derivatives instruments, may be invented on the fly by industry participants. They do so by combining the real-world variables which exist, into new combinations. As long as the ontology reflects this degree of abstraction of the subject matter, new kinds of instrument can be defined at any time. In fact, all we are doing in naming a new instrument is defining a new combination of the existing abstract concepts, putting it in the relevant place in the taxonmy, and giving it a name.
A good practice in ontology development is to partition the ontology at the top of the taxonomic hierarchies, so as to identify conceptually different types of concept. In FIBO we have created three separate, non mutually exclusive partitions (these are explained in detail elsewhere). This is a vital component in distinguishing between meanings of otherwise similar concepts. For example a monetary amount as a unit of measure, and an amount of actual money, have the same properties but very different meanings - one is abstract, the other concrete. Similarly, and agent in the context in which it plays some role is a very different concept to the kind of entity which may act in that role.
FIBO partitions the ontology content in three ways:
Terms in the FIBO models are represented in a way that represents formal logic. In particular, a sub-set of formal logic is used, known as First Order Logic (FOL). Most if not all ontology languages are grounded in formal logic in this way. As a result, an ontology in one format can be unambiguously interpreted, and may be easily represented in any other ontology language without loss of content or precision, unless that other language only supprts a smaller sub-set of formal logic.
This is an important pre-requisite for any conceptual model. Other conceptual model formats are framed in terms of different aspects of formal logic, or extensions such as modal logic, deontic logic and so on. In this way, any such model is technology-neutral (it is framed in the common, universal language of mathematics), and is also complete and unambiguous.
It is this use of formal logic which makes the ontology unambiguous and complete. Syntaxes such as OWL are framed in terms of First Order Logic and this is why they may be used to create meaningful models.
Model theory describes how a given model relates to its subject matter. A data model is a model of some data, whereas an ontology is a model of some real things. An ontology is defined by the fact that the subject matter of the model is the things and properties of those things in the business domain (known more formally as the problem domain).
That is, the model stands in a formal relationship to its subject matter, and in the case of the FIBO ontology that formal relationship is ontological. This relationship is formally documented in the standard.
Model theory therefore plays an important role in making the ontology meaningful.
In technical discussion one often hears the phrase "That is philosophy" or "That is academic" presented as a valid reason for not pursuing or implementing something. We would like to see this go the same way as the phrase "That is just semantics".
The academic world view is simply one which takes what has been reliably established as being provable, and builds upon this so that any new idea or assertion can be backed up. This is not a bad thing. It is tempting, in the world of software development, to tackle each new problem as though it has never been tackled before. This is not a good use of commercial resources.
One of the guiding principles of FIBO is that we have not sought to reinvent anything. Rather we aim to deliberately build upon work which has been done before.
We also work actively with the academic community, for example in formally modeling transaction concepts in the ontology, in better understanding the application of classification theory and so on.
Philosophy is a branch of academia that has been going for quite some time. From Aristotle to Leibniz to Russell to Peirce, philosophers have provided the thinking and the material with which to create meaningful models of the world. There is no need to reinvent any of that. Our approach to model theory, to classification, to semantics and so on, is all built on work which has gone before, not stuff we have made up.
The Enterprise Data Management Council is a standards-focused organization. Standards provide the means for industries to collaborate for the greater good of that industry and its participants.
We believe that business terms are best understood by business practitioners - it is not up to ontologists to decide what a term means, our role is simply to find out and to formalize those meanings.
The best people to determine what is the precise meaning of a given term, are the people from whose industry or community that term arises. We should not reinvent real estate terms just because we need them in a term for a mortgage backed security or a loan. Rather, we should seek to work with the communities of practice that best understand the given subject matter.
This is essential in order to adequately apply the principles of abstraction and classification. Things in the real world are not always classified neatly into industry verticals, but the nature of the things themselves is best understood by going to the standards groups in those industries or communities.
Most industries have technical standards for messaging or for data models. In a small but growing number of industries, these are being supplemented by formal semantic models built according to Semantic Web principles. We seek to work with all such bodies that deal with terms we are also interested in, and to adopt or extend the concepts which they have defined.