The Financial Industry Business Ontology

The Financial Industry Business Ontology
Explanatory Material Mike Bennett, EDM Council August 1 1 1 1

Overview Definition of an ontology Overview of classification theory
Transformation from a taxonomy to an ontology. The Financial Industry Business Ontology (FIBO) From business semantics to an operational ontology This presentation describes the thinking behind the Financial Industry Business Ontology. This is an in-depth look at the principles which have been applied, and the history of how the ontology was developed. The presentation begins with some background on formal engineering development methodology as applied to the management of data assets. We introduce the basic principles of classification theory (there is another deck with more detail on that). Then we show how to extend from a classification hierarchy (or “taxonomy”) to a formal ontology. There is a section of these slides showing how we explored the application of semantics theory to the problems of modeling financial instruments, with some experiments and lessons learnt at the beginning of the development of FIBO, by way of background. After looking at the FIBO development, these slides go on to explore the possible ways in which FIBO may be put to work in an operational environment. This covers conventional technology applications (using FIBO in the role of a conceptual model), and also semantic technology applications. Audience: This presentation is aimed at a technically literate audience, A more detailed set of slides covers the detailed theoretical aspects of classification and of formal logic representation, and may be read in conjunction with this deck by anyone with an appetite for a deeper theoretical treatment of the subject matter.

Copyright © 2010 EDM Council Inc.
Data Governance A Bank is in essence an IT Company Software manufacturing Data production, consumption, Information supply chain So how do we manage the business view of data? Language interface business to IT Conceptual model The thinking behind the development of FIBO has its origins in engineering principles. In any branch of engineering, be it electronic, mechanical, civil or information technology, there are certain approaches to the development of some commercially useful end product, which are typically followed in any mature development environment. The application of these principles in information technology are quite varied, but most firms which remain successful in delivering IT solutions to paying customers have done so by applying these engineering principles to their work. Banks however are not usually considered as software companies. Where an industrial firm may have a Quality Assurance officer, the financial institution would have a Compliance Officer who has a similar but different role. However, financial firms are no longer simply consumers of information technology: not only do they rely on information technology for every aspect of their business success, they also use it to gain competitive advantage. Meanwhile, they also carry risks, including the operational risks of IT systems going wrong. In short, there is nothing about a financial firm which would justify not taking the same approaches to IT development as a software manufacturing firm would. A part of the mature management of any engineering deliverable, is to manage the interface between what the business needs (and is paying for), and what the technologists deliver. This is what we call the “Language Interface”: the boundary between the owners of the business problem, and those responsible for delivering a solution to that problem. Copyright © 2010 EDM Council Inc.

Managing Semantics How do firms usually manage and specify the requirements for technical development? Typically the business terms and definitions are put into a spreadsheet, or in some cases they are recorded only in s or meeting notes. Illustrated here are screenshots for a few industry standards. On the left, a diagram from a computer aided software design (CASE) tool called a UML editor. This shows logical design elements for terms within the ISO standard. On the right are two representations of XML messaging designs in the FpML derivatives messaging standard. These are both world-class standards, representing the state of the art in logical data model design and physical message design. However, the above views are the only means which business subject matter experts have to validate that the model or message content is complete or correct. If new changes are required – for example if a new derivative contract is invented, if a new payment method comes into play or there is a new regulatory reporting requirement – then someone on the business side needs to validate that the new terms are correct and complete. There is nothing on “their” side of the language interface to enable them to do this. Instead, the business stakeholders are expected to learn and understand two things which lie outside their day to day competence: the formal language in which the model content is presented (UML or XML for example), and the design principles which the technical team has chosen to apply when designing the database or message structure to meet those unseen business requirements. The next few slides explore some principles for bridging the language interface.

Conceptual Model for Data
Conceptual Model (Semantics) Realise Logical Model (Design) Implement There are several kinds of model in systems development. From the bottom up the ones we are interested in are: Physical Model (“Platform Specific Model” or PSM): this represents the implementation of some solution in some specific environment Logical Model: (“Platform Independent Model” or PIM): This represents some design in a way which is independent of the implementation of that design in one specific environment. Conceptual Model: This does not represent a design at all. The conceptual model defines the business problem space – for example, in the area of data, this would be something which represents the semantics of the data. Note for Modelers: These types of model are often referred to as different “levels of abstraction”. In some methodologies, the conceptual model is defined as a more abstract model of the solution. This is not the usage in these slides. We define a conceptual model not as a more abstract model of the solution, but as a concrete model of the problem. That is, this type of model belongs in a different domain: the business domain. Physical Model (Implementation specific) Copyright © 2010 EDM Council Inc.

Conceptual Model for Data
Business Conceptual Model (Semantics) The Language Interface Logical Model (Design) Technology This diagram illustrates the “Language Interface” described previously, delineating the domain of the business and the domain of technology: Above the line, any model should be in the language of the business – it is owned by the business, understood by the business and validated by the business. This is the firm’s means for tying technical development back to the needs, motivations and risks of the firm itself. Below the line are models to do with technology. There may be many of these, at different levels of abstraction of the proposed solution. The precise kinds of models will depend on whether they are models of data, of program code and so on. Even when a firm chooses to rely on individuals who are comfortable working on both sides of the language interface, it is important to keep these kinds of model distinct. This is what gives the business independent, auditable oversight over the development of its assets. These are the principles of conceptual model in general. How is this applied to data? The next couple of slides go into more detail on this. Physical Model (Implementation specific) FIBO bridges the “Language gap” between business and technology Copyright © 2010 EDM Council Inc.

Development Lifecycle for Data
Level (from Zachman) Data Function Scope (contextual) Things relevant to the business Set of business processes 1 Business Model (conceptual) Semantic Model Functional Requirements (Use Case) 2 System Model (logical) Logical Data Model Logical Design 3 Technology Model (physical) Physical Data Model Physical Design 4 Detailed Representation Data definition Program The diagram shows an extract from the Zachman Framework for Information Architecture (Ref: ) Shown here are the first two columns. These relate to data and to program function. This column division corresponds to a similar duality in the UML modeling language, where these are called the Structural and Behavioral aspects of the technology. UML provides both structural and behavioral model formats for solutions. In the problem space, UML has a model format for representing behavioral requirements – the Use Case model. In the structural column, the equivalent to specifying requirements is specifying semantics, for which we need a semantic model of some sort… Copyright © 2010 EDM Council Inc.

Development Lifecycle for Data
Level (from Zachman) Data Function Scope (contextual) Things relevant to the business Set of business processes 1 Business Model (conceptual) Semantic Model Functional Requirements (Use Case) 2 System Model (logical) Logical Data Model Logical Design 3 Technology Model (physical) Physical Data Model Physical Design 4 Detailed Representation Data definition Program What is the conceptual model for data? This is a semantic model. A Semantic Model is any formal representation of the semantics (business meanings) for which some data model is to be developed. A semantic model then is a conceptual model for data. It needs to conform with the same rules as other conceptual models, such as a requirements specification or a use case model. What are the rules for a conceptual model and how are these applied to the creation of a semantic model? Copyright © 2010 EDM Council Inc.

Conceptual Model Requirements
Must be owned and validated by business Manage the “Language interface” between tech and business subject matter experts Everything should be in English No techie terms and casing like “objectProperty” Everything should be reviewable Spreadsheets dialect-free diagrams These are the formal requirements for any conceptual model. The intention of such a model is to manage the language interface between the business and the technology. This is owned and reviewed by the business, and therefore should be in business language. This means that technology language features such as camel casing, repurposed punctuation marks etc., which are common in technical models, are not appropriate for a conceptual model. The reason for this is that the conceptual model is the means by which the specifies what is to be developed, and is also the model against which the final deliverable are validated, for example through tests or reviews. Similarly, future changes to the model start out as changes to the conceptual model, which are then implemented as changes in logical designs and then in physical implementations, which may be tested or reviewed against those original business changes, so completing the circle of specification, development and validation. This then sets out the agenda for producing a semantic model for industry terms. These requirements are to be applied to the modeling of semantics. This is the guiding set of principles behind the FIBO modeling initiative. Copyright © 2010 EDM Council Inc.

Industry Standards Experience
Business knowledge gained during reviews is either Lost Buried in meeting minutes Kept in uncontrolled spreadsheets in a variety of structures Data Dictionaries try to link business definitions to data elements but data elements are reused across business meanings and usage contexts (good design again) Good design is weak semantics Industry conclusion “We need a semantics standard” First, some history of the experience gained through industry standards initiatives, in which the above principles were not generally applied. In the development of industry standards, it has often been the case that the business knowledge which was brought to the table was captured directly into the technical design of the standards. This means that there is not a separate record of the business meanings themselves. For a one-off development effort this would be appropriate, but industry standards need to be updated from time to time in the future. Also, participants need to validate whether the terms that have been represented in the model cover their own terms and requirements. One way of trying to address this has been the “Data dictionary”. However, unless each element in the dictionary refers to one meaningful concept, the definitions soon become clouded, or there are several definitions against the same data field, qualified with ifs and buts. This is to be expected, since any well designed data model cannot also be a semantic model. Conversely, any well made semantic model – any model which represents each meaningful concept once – will not be a good data model design. It is not a criticism of a message standard or a logical data model standard, to say that it is not a good semantic model. If it was a good semantic model it would not be a very good logical design, and vice versa. The role of a semantic model and the role of a logical data model are simply different. Many of the standards developments initiatives in the financial industry have given rise to excellent, usable and valuable technical standards. Some of these have been under-utilized since there has been no clear way to show potential users what business terms are covered in those standards, or how to find those terms. At the same time, there has been a growing realization among business participants that what they really needed first and foremost was some simple, non technical, non designed representation of the business terms and definitions. Eventually the industry participants came to the same conclusion as would have been reached by following the formal methodology approach described above: that in order to develop and maintain best of breed technical standards, and in order to develop or integrate data assets within and across financial firms, the main thing the industry needed was a semantic standard: a formal, factual representation of the business concepts and real-world relationships among those concepts. A representation of the world is also called an “ontology”. The industry needed an ontology.

Ontology “A formal specification of a conceptualization” But What formalization? What conceptualization? That defines what sort of ontology What is an ontology? One definition which is often quoted is that it is a “formal specification of a conceptualization”. We need to narrow this down a little in order to develop a practical, useful industry ontology. What sort of formalization is appropriate for our purposes, and how does the ontology “conceptualize”, or in other words what are the concepts that are to be represented. The two questions which this definition begs point to two important aspects of any ontology development: Notation: how are the model elements framed in terms of formal logic? Model theory: what is the relationship between elements of the model, and the things they are meant to represent. The notation question leads us to look for a model syntax which is grounded in some formal logic. The model theory question means that the ontology should be a model in which each element of the model stands in a formal relationship to the subject matter. So for example a class in the model must represent some set of real or possible things in the world itself. The conceptualization question also points to what is called the “ontological commitment”. An ontology which makes an ontological commitment of 100% to the problem domain is like a map with a scale of 1:1 – not very useful. In developing the ontology one has to consider the scope, granularity, time dimension and so on, of the aspects of the real world that are to be modeled in the model. Copyright © 2010 EDM Council Inc.

Some Terms Taxonomy A structured classification scheme Linnaeus Taxonomy of Species Taxonomy of Financial Instruments Ontology Adds formal properties to a taxonomy Describes real world things Vocabulary or Lexicon Deals with the words for things A semantic model is a business conceptual model, so no-one should need to learn any new words in order to review, manage or update it. However there are a couple of semantic modeling terms which are worth knowing in order to discuss the development of the ontology itself. It should not be necessary to explain these terms to business subject matter experts in order for them to review and validate the ontology, however we find that the concept of a Taxonomy is worth explaining at a business level. There is no need to ever use the O word. We define it here because we are describing how we developed this ontology. The definitions given above represent what appears to be the consensus in the academic community on the usage of these terms, though some usages may vary. Essentially, a taxonomy is the backbone of an ontology – there are many forms of taxonomy, but only a few which are appropriate to developing the kind of ontology we have here. At its most basic, a taxonomy is simply a system of classification (the word ‘taxa’ means the same as ‘category’ or ‘class’ in plain English). A taxonomy classifies the subject matter; an ontology adds facts about the things in the taxonomy, and a vocabulary gives definitions for those things. An ontology has one and only one element for each meaningful concept. It is a model of meanings not of words. Another important term is the vocabulary (or dictionary or lexicon). This is based around words, and is effectively the complement of an ontology. Where an ontology has one entry per meaning, the lexicon has one entry per word. Where ontologies have synonyms (different words with the same meaning), a lexicon has different meanings for the same word*. *Actually the ‘nyms’ are quite complex – because words can be written or spoken, there are different terms for words that sound the same with different meanings (like bear and bare), and words which look the same with different meanings regardless of how they sound (like bass and bass, but also like monitor and monitor). This is a complex subject, but the actual opposite of synonym in the world of the written word, is ‘heterograph’. So vocabularies for IT systems development would have heterographs where one set of characters represents two or more separate meaningful concepts. Copyright © 2010 EDM Council Inc.

Taxonomy Taxonomy: system that can be used to group, arrange, and describe items according to meaningful principles, and which provides users with an overview of the domain being organized Lambe (2009) A taxonomy uses a classification scheme to arrange the items in the domain of discourse A Taxonomy forms the basis for any ontology A taxonomy applies some coherent classification principle to the subject matter, to arrange things in a formal structure. For FIBO, as for most semantic web ontologies, the principle followed is that kinds of “Thing” in the model are arranged in an “Is A” relationship hierarchy, such that each class of thing inherits properties that are asserted about its parents or ancestors. Also in FIBO and other semantic web ontologies, it is possible to include classes of “Thing” in more than one taxonomic hierarchy, i.e. each thing may have more than one parent class, provided it is something that really inherits properties from all of them. So for example derivatives may be classified according to contract structure (forward, swap etc.) and according to underlying asset type (currency, commodities, rates), without either of these taxonomic hierarchies needing to take precedence over the other. With a technical database design one has to choose a single hierarchy but with a semantic model one does not. In FIBO, everything in the model is arranged in a taxonomic hierarchy. That is, not just the securities and contracts and so on, but also all the things that need to be referred to in facts about those. So for instance accounting concepts, geographical concepts and so on, are also arranged in their own taxonomy. These taxonomies are all brought together at the top of the model, under a class simply called “Thing”. Thing is simply the set of things of which everything is a member. Copyright © 2010 EDM Council Inc.

From Taxonomy to Ontology
Ontology: the study of what is Ontologies (plural): the real world universe as it is referred to in a computer application Informal: every application has an ontology, whether it’s documented or not Formal: uses formal logic in some notation Semantic Web Uses a formalism which can be reasoned over An ontology takes a taxonomy as its starting point. From a classification hierarchy of the things which are of interest, properties are added to define possible facts about things. The word ‘ontology’ originates from the study of ‘everything’. In computer science, every program which has variables or makes reference to some data model, effectively has its own universe of “everything”; its own ontology of real world items. However, unless this has been documented in some notation which is grounded in formal logic, it is hard to see or understand the ontology of the application. Formal ontologies provide the means for documenting the ontology of applications. Formal ontologies in the standards space provide a means for multiple applications to talk about the same terms, knowing these have the same meanings, and so allow for interoperability, reuse of data and so on. After exploring a number of options, we elected to use the formal notation which is used in the Semantic Web, namely the Web Ontology Language (OWL). This standard language supports a growing number of freeware and commercially available tools called “reasoners” which can carry out operations over the ontology and draw conclusions from it or draw conclusions about instance data as long as that data is also described in terms of the ontology. Copyright © 2010 EDM Council Inc.

Model Theory and Semiotics
For any model we may ask: What is that to which the model elements correspond? What is the formal grounding of the symbols in the model For an ontology: The things to which the model elements refer are real things in the domain of discourse The grounding is formal logic Model theory is an important consideration in any kind of model. A UML class model is a model of object oriented classes, which may be implemented in a computer system. Sometimes UML models are framed as being models of something else. Any model has some relationship of the form “What is this a model of?”. This is part of what we mean by “Model theory”. In an ontology, the model theory states that the elements in the model stand in a formal one to one relationship with real things in the universe of discourse (the real world). This is one thing which makes it an ontology: if a model is in OWL but does not represent real things, it is not really an ontology. The next few slides describe some of the early investigations we carried out in order to work out how best to model financial industry concepts, in formal semantic models, using the available ontology tooling and notation. This is background to what we did not do as well as what we did eventually do. Copyright © 2010 EDM Council Inc.

Possible classes of Thing
This is the very first experiment. Using a freely available tool called Protégé, we listed a number of kinds of “Thing” which were of interest in the financial space. These are all defined as being a sub-class of the universal class called “Thing”, that is the set of things of which everything is a member. The class of “Thing” is a standard part of the OWL language and gives every ontology an explicit model theory relation. Note that there is also a class of “Nothing” which is the complement of “Thing”, and is the set of things of which nothing is a member. Everything else in the model is some narrowing down of the universal set of “Thing” to some specific sub-set of Thing. Whether a given individual in the world falls into our outside of that sub-set depends on its properties. In designing the taxonomic classification of things, we grouped them according to common characteristics. The ISO Classification of Financial Instruments standards provides just such a classification system, and was used as a starting point (but without including categories which have no common properties, such as “other”) 23 June 2010

Example “Thing”: Equity
Real world definition of Equity: "An equity is a financial instrument setting out a number of terms which define rights and benefits to the holder in relation to their holding a portion of the equity within the issuing company". For the class of all things which are an equity security, we want to define what are the facts about it which define membership of this set. That is, what is there about something such that, if it is true of a given thing, then that thing belongs to the set of all things that are an equity. The above definition sets out exactly what we mean by the term “Equity” here. The statements made in this definition can then be articulated as distinct properties which would apply to any real world item of which it would be true to say that that thing was an Equity in the sense intended here. Note that here we use the word Equity as being more or less synonymous with “Share”, that is a specific kind of instrument. The ISO FIBIM model also uses the word Equity in this way. The same word Equity might also mean the actual equity in the company itself. That is an amount of money such as one million Dollars, which someone holds in some company. These are two meanings, with the same word or label. There are not enough words in the language to go around, so it is important that we not treat words as though they were themselves the carriers of meaning; they are not, they are just labels. The meanings are in the properties (and, independently, in the definitions). In our experience, people may argue forever about the “correct” meaning of a word, but can agree about the meaningful concepts themselves much more readily. In an ontology we don’t care much about the words other than to find the most convenient and widely understood label for a concept. The other words people may use for that same concept are recorded as synonyms. 23 June 2010

What is an Equity? Or to put it another way… Equity Equity security
Instrument Terms Financial Instrument Is a kind of Has rights defined in In relation to The written definition given above can be rendered diagrammatically. Note that this is just a simple “white board” type of diagram – we are drawing boxes and lines freehand to capture visually what we previously captured in words. No modeling language or syntax is in play at this point. Note however that we have instinctively used boxes for one kind of concept (broadly, kinds of thing), and lines for another kind of concept (broadly, relationships between kinds of thing). As it turns out, this is also how the Semantic Web notation can be represented in some tools. 23 June 2010

What is an Equity? Using OWL to define the classes of real things in the world, and the facts about those things Modeled in TopBraid Composer Taking the above, informal, business facing view of our definition for “Equity”, we now put into the formal ontology we were looking at before. This is still an OWL ontology but is now represented in a different tool (the excellent TopBraid Composer tool). Note that since everything has to be a kind of Thing (a class whose ultimate parent is Thing), we have defined kinds of things which are ‘Contractual Terms’, and kinds of thing which are ‘Financial Considerations’ as well as kinds of thing which are Financial Instruments. Note for modelers: Although this tool is visually excellent for developing formal ontologies, it is not a format which you would want to show to a subject matter expert. Even if the model format seems easy to understand, it telegraphs to a business reader that it is in a language they have not had the privilege to learn. We need to find a way of representing things back to the business in the sort of simplicity we had on the previous slide. 23 June 2010

Financial Semantics in OWL
Pizza approach “Everything is a Thing” What about common terms? accounting terms for equity, debt, cashflow Places, time concepts Legal terms (securities are contracts) Better partitioning needed Having carried out the experiments described above on modeling equities, we came to a number of conclusions about how to proceed in modeling industry terms semantically. We started our journey with the excellent “Pizza Ontology” tutorial exercise (ref: ). The Pizza Ontology is characterized by the fact that everything that is of interest in the specific application, is a sub-class of “Thing” directly. So cheese is a thing, meat is a thing, bread is a thing and so on. This is good for demonstrating the principles and tooling, and would also be a good basis for building a small ontology for an individual application. However, we are trying to build a standard ontology and one which formally defines terms in any number of standards, messages, databases, applications and so on. This means that what we might loosely call the “Pizza approach”, although ideal for a teaching aid, would not be appropriate for an industry standard ontology. This needs a bit of explanation. If we were to use the Pizza ontology in a standards setting – for example as part of a standard ontology for food and drink, then it would soon break. If the ontology needed to include other kinds of bread besides pizza base, other kinds of dairy besides cheese, kinds of meat which need not be sliced thinly and so on, then it would not be able to handle this without first needing to break the direct link in the taxonomy between say cheese and Thing, in order to insert new, more general categories of thing. The same would be true of the prototype financial ontology shown on the right of the diagram – this is effectively a “Pizza” ontology of financial instruments – it will not be extensible, interoperable, usable across more than one or two applications and so on. This architecture, which is ideal for teaching and for many applications, is not suitable for an industry standard. If we get the taxonomic hierarchy right, and abstract everything all the way from the most general to the most specific classifications of each kind of thing, then it should also prove possible to use our ontology alongside other ontologies – especially if these have been framed along similar lines. If this is done right, we should also be able to refer to terms which are also referred to in other businesses or industries. Terms about time, geographic, accounting, legal and so on, are all terms which we need to refer to or to specialize from (e.g. shares are a kind of contract; municipal bonds are issued by municipalities). These all need to be in the ontology, arranged in suitable classification hierarchies, and ideally with some rigor in the way that the terms as a whole are partitioned. This is the challenge we wanted to meet in building this ontology. 23 June 2010

Experiment: Ingest a logical data model into OWL
The Semantic Web Web Ontology Language Based on Subject-Verb-Object “Triples” Widely used Protégé tool Experiment: Ingest a logical data model into OWL Result: a logical data model in OWL Syntax is not semantics! Summarizing the results of the above investigations: We decided to use the Web Ontology Language (OWL) as the basis for a formal representation of business semantics, because it had a suitable syntax (triples, that is model constructs in the form of “subject-verb-object”). It is grounded in a well defined sub-set of first order logic, and it is widely used. Free tools exist for OWL, such as Protégé, as well as a growing number of commercial tools. As a thought experiment, we ingested an existing logical model into OWL and looked at it using the Protégé tool. The result, as would be expected, was a logical data model in OWL – not an ontology. It is clear that in order to create a meaningful model of business concepts, we need to do more than simply use the syntax of OWL, we also need to apply that syntax in a meaningful way. It seems obvious when framed in this way but: syntax is not semantics. This has implications…

Making it Meaningful Putting something into RDF/OWL does not make it meaningful Only you can do that So, what is a meaningful model 1. Formal relationship between model and subject matter: “Everything is a Thing” 2. Formal notation grounded in common logic 3. Abstraction of kinds of thing into their simplest possible building blocks Contracts, Parties, Legal Entities etc. Syntax is not semantics. The syntax used, whether it is OWL or some other, does not of itself make that model meaningful. Something else needs to be done. There are several elements to making a meaningful model: The model must show (or have documented) a formal relationship between the model elements and what they represent. For it to be an ontology, this relationship must be to things in the real world. The OWL language covers this by having the non syntactical) element “Thing” and by insisting that every class in the model is a sub-class of that class. The model notation should be grounded in some set of formal logic constructs. That is, the model must use (and the syntax must let it use) formal logic alone to make assertions about the subject matter. This is not the case with (unextended) UML models since the classes in these are grounded in object orientation theory and not in formal logic. By having the model constructs grounded in formal logic, there is no ambiguity about what is represented. The same representations can be rendered in any other model syntax which also has a grounding in formal logic. Formal logic comes from the body of thought which is mathematics, and so it is academically referenced, universally understood, and not open to interpretation. This means that the modeler can unambiguously make meaningful assertions. In order to apply the formal logic of set theory, and the model theory in which everything is ultimately a sub-class of “Thing” (a set of things which are themselves members of the universal set), it is necessary to define each kind of thing in terms of the more general set of things of which it is a member. That is, each set should have a parent or ancestor which is the answer to the question “What kind of thing is this?” Otherwise the model is simply a stand-alone model of concepts which may be meaningful in themselves (semantics by fiat i.e. by the modeler saying so), but whose meanings are not fully reflected in the model. By answering the question “What kind of thing is this?” the modeler is making meaningful statements about the model content. Please refer to the separate detailed slides on classification, logic and model theory for more details on this.

Theory of Meaning – in English
The model consists of: Things A Thing is a set theory construct Arranged in a hierarchy called a “Taxonomy” Like taxonomy of species Facts Simple facts (names, dates etc.) e.g. “Issue Date” is a date Relationship Facts (relate one thing to another thing) e.g. “Share confers Voting Rights” Things so referenced are also in taxonomic hierarchies Other set theory concepts Disjoints, Unions The theory of meaning which we have applied needs to be described in plain English to model reviewers in the business domain, so that they can validate it, add terms to it and so on. Since the underlying logical formalism is basically that of set theory, this is relatively simple. We describe the model in the terms shown above. This is all that reviewers need to know. They also need to be shown what are the model constructs which represent the above logical assertions. That’s it.

Theory of Meaning – in English
Taxonomy: Like Taxonomy of Species Animal v Plant Vertebrate v invertebrate Mammals, fish etc. Each thing is defined by what facts distinguish it For each new thing: What sort of thing is it? What facts distinguish it from other things? If an animal has a backbone, it belongs to a set of all things that are a vertebrate If the animal has hair, is born alive, feeds its babies with milk and has a four chambered heart, it belongs to the set of vertebrates that are a mammal Further illustration of the meaning of “Taxonomy” as applied in FIBO. This is used as part of the introduction to FIBO models for business domain experts. We use the example of the Linnaeus Taxonomy of Species to show how taxonomic inheritance of properties works and how each class shown on the diagram (we try not to use the word “class” though), represents a set whose membership is defined in terms both of what “kind of thing” it is (its parents or ancestors) but also in terms what facts about a given class of thing, distinguish it from other classes of thing that have the same ancestors. This involves some simplification (since the Linnaeus taxonomy now links to underlying phenotypes), but is suitable for getting the basic principles across to that audience. In brief, there are just two questions which are asked of every class of Thing in the model, and that would be asked if a new class were to be added, for instance if one wanted to name and define a new kind of security: What sort of thing is this? - this question defines which parent class or classes the new thing should have; What distinguishes it from other, otherwise similar things? – this question defines what are the properties that need to be asserted about the new class of thing. These properties will generally be different to the properties of other classes with the same parent. Otherwise they should be properties of the parent. The answers to the first question situate the item within the taxonomy. The answers to the second question extends from taxonomy to ontology. If there are no properties of a thing which distinguish it from some other thing, then it is the same thing (at least within the level of detail which is considered appropriate for this ontology – the ontological commitment). In this case, the new term should simply be identified as a synonym of some existing term. It is important not to create new classes or properties for words that have the same meaning as concepts already in the model. To do this would be to create a vocabulary, not an ontology. There are better languages and formats for doing that. The model should not be a mix of ontology and vocabulary – each meaningful term or concept should be modeled once and once only. This is sometimes described as “Duck typing”, from the statement below: “If it walks like a duck, swims like a duck and quacks like a duck, it belongs to the set of all things that are a duck.” However, strictly speaking, these are all behaviors, not properties. So the duck-typing example, while it helps business people understand the notation, should more correctly be replaced with the statement given in the slide: If an animal has a backbone, it belongs to a set of all things that are a vertebrate If the animal has hair, is born alive, feeds its babies with milk and has a four chambered heart, it belongs to the set of vertebrates that are a mammal

Applying Meaning to Financial Semantics
Everything is a Thing What kind of Thing? What distinguishes it from other things? Share is a Security is a Transferable Contract … is a Contract What properties? Share gives the holder some Equity Share confers on the holder some Voting Rights Given the above thinking, we now come to apply this to the semantics of terms in the financial industry. The two questions described on the previous slide were addressed to each of the items of interest in the industry, starting with the terms in the ISO logical data model. This is a logical data model, with good model design, but the designed elements of that model were put there in response to business knowledge about what the industry terms are – so this was a good starting point for finding terms for which we now needed to define the formal semantics. Starting with Equity (synonym: share). What kind of thing is a share? It is a security. What kind of thing is a Security? It is a kind of contract which may be bought or sold by the holder (the holder is effectively one party to the contract, the issuer being the other, principal party). We labeled this “Transferable Contract” as there is no obvious label for it. Other transferable contracts include software licences. What kind of thing is a Transferable Contract? It is a kind of contract. In fact it is a kind of written contract, which is a kind of contact (since not all contracts are written). From this we have a taxonomic hierarchy with Contract at the top, and Publicly Traded Share at the bottom. In fact the term called Equity in ISO really means “publicly traded share”, and so this is not directly synonymous with share since some shares are privately held, and thus outside the scope of ISO but not outside the scope of reality. We arranged the taxonomic hierarchy such that at each level, new and future kinds of contract could be described. If we had not, then for example when we came to model legal entity relationship hierarchies, which are based on shares, we would have had to “break” the model in order to distinguish traded from privately held shares. This is a lesson in how the implied scope of the original set of data terms (ISO in this case, which describes only publicly traded instruments) should not dictate the structure of the ontology if it is the interoperable with ontologies for other business applications. Second question: what facts distinguish this class of thing from others like it? There are many kinds of security. These are all transferable contracts, and they are all the kind of transferable contract which is a “Security”. There are common facts about Security, such as that it has a security identifier, an issue date, an issuer, registration and so on. These facts are true whether something is a share or a bond, and whether it is traded on an exchange or over the counter. So what makes an Equity distinct from any and all other sub-classes of Security? The answer of course is that it gives the holder some share in the equity of some company that is incorporated by the issues of shares. This distinguishes it from a bond, which gives the holder some participation in the debt of some legal entity (not incidentally limited to entities that are limited companies). To define this property, we also need to define what Equity itself is – that is, not “Equity” as a share instrument, but equity the actual amount of money issued as equity by the company, a portion of which the holder of the Share has by virtue of their ownership of that share. This means that the model now needs to contain accounting concepts such as equity (and of course debt, if we are formally define debt instruments). Another feature common to most shares is that they confer some voting rights. Unless the share is a non voting share, there are rights that accrue to the holder as a result of holding the share. There may be more than one kind of voting rights, for different classes of share. The precise details of the rights themselves are to be found in the detailed terms sheets which set out the rights of the holder (recall that a share is a contract, so like any contract it has terms and these terms are descriptive of rights and obligations of one or other party in respet to the other). Note for implementers: Note that here we are defining the facts of the matter – the properties which make something actually a Share or actually a Bond. These facts are grounded in accounting terms (equity, debt) and legal terms (rights, obligations). This is not the same as having instance data – there is no instance of a right or some debt. It is these legal and accounting facts which confer meaning on the concepts – that is, we are defining what the thing actually means in the real world. Recall that this is a conceptual model so we should not even be considering data or implementation questions at this point – we simply want to formally state what it means to be a Share. When it comes to creating an operational RDF/OWL ontology application for the above concepts, you will find that there are usually data elements which are a sort of “signature” for a given legal or accounting fact. For instance, if the holder has certain voting rights, you can expect to find instance data which describes those rights or possibly an enumerated datatype describing what possible rights there may be. These signatures may be used to distinguish one kind of thing from another from the available data using reasoners, provided that the ontology adequately defines not only the legal and accounting facts, but also the information (on temrsheets etc.) which may be found in the company of these facts. Copyright © 2010 EDM Council Inc.

Where does this lead? Taxonomy of kinds of contract Taxonomy of kinds of Rights Rights, Obligations are similar and reciprocal concepts Note that these don’t necessarily correspond to data Semantics of accounting concepts Equity, Debt in relation to assets, liabilities Cashflows etc. Semantics of countries, math, legal etc. The above thinking, even applied only to shares, gives rise to a model in which there is not only a taxonomy of kinds of contract (the things we started with) but also model material about rights and obligations, equity and debt and so on. The model theory obliges us to make everything a sub-class of Thing. In a stand-alone application some of these items could simply be put into a separate partition (like the flavor partition for the Pizza example ontology). However, this is not an ontology for a stand-alone application. For each of the things for which we have had to define facts about the contracts (the “confers rights” or the “represents some equity” properties of shares for example), the model needs to include the thing which that assertion refers to. Therefore, those things need to also be disposed in taxonomic hierarchies. This means that we need a hierarchy of kinds of rights and obligations, arranged so as to define what kinds of things they are; a hierarchy of kinds of capital such as equity and debt, and so on. Looking ahead, anything we need to assert in order to distinguish one class of securites from another, needs model content to point at. For instance, municipal bonds are distinguished by what sort of tihng issues them, as are sovereign bonds, corporate bonds and so on. So the model must contain municipalities, countries and corporations. Other ways of classifying securities include cashflow structures. If the ontology is to represent concepts which are of interest in the front office, it must be able to define terms such as floating rate note versus fixed income, and amortizing versus bullet redemption structures. These concepts are distinguished from one another not by their issuer types (anyone can issue any of these at least in principle), and not by their capital type (they are all debt instruments), but by their cashflow behavior. This means that we also need to be able to refer to basic mathematical operations from which the various formulae are derived. We need not model the mathematical formulae mathematically, but we do need to describe the possible features of a formula in order to create new sub-classifications of these instruments based on differences between formula (for example, one will have an index reference for floating interest rates, another will not because it represents fixed interest). Copyright © 2010 EDM Council Inc.

Global Terms Rationale:
Everything is a specialization of some more general term Legal, accounting, events, transaction semantics Facts about instruments are stated in terms of other things Countries, formulae etc. Want to derive from and align with the best ontologies for these area Disposed under a common framework FIBO models are extensively partitioned Shared Semantics: Align with standard ontologies where these exist Leverage OMG standards e.g. Date Time Vocabulary Work with academia and standards (ongoing) Transaction Semantics: REA, XBRL-GL From these considerations, it becomes clear that we need to model many concepts which lie outside of the financial services industry, in order to make meaning assertions about securities or other industry concepts. As a minimum we need business entities, legal concepts (contract, terms, rights), accounting concepts (equity, debt, asset, interest), geopolitical terms, mathematical constructs, and a host of basic business concepts such as transactions (for derivatives), service provision (for exchanges) and so on. By definition, none of these are unique to financial services. By referring to these terms, we make meaningful statements about financial industry concepts, in the context of the wider world. It is this which makes FIBO a meaningful model and not simply a stand-alone application data model. To achieve this we also need to identify ontologies for those other terms. We have created “placeholder” models for all of them, and are committed to finding the communities of practice which are best placed to understand and formally define each kind of term. Over time, we also expect to see emerging formal ontologies for these terms. When we started on this, there were not very many of these. As part of the OMG standardization process, we have also set out what are the formal requirements for identifying and if necessary privileging the various standards and industry bodies that may have formal ontologies for these terms. One consideration is that the ontology should take a similarly rigorous approach to meaning as we have here – though even without this we would still want to take the term and any formal definition that each standard has. There are also interesting ontologies in academia, and to the extent that these have traction and address problems that are not addressed in other formal ontologies, we want to use them. A very good example of this is the REA (Resource-Event-Actor) ontology for transactions, from Michigan State University (ref: ). We started out by using only a small set of the REA terms, to define properties of derivatives transactions. Subsequently we realized that many more of the REA terms correspond to or are sub-classes of legal and contractual terms that we still don’t have a standards based source for. In addition, REA describes transactions from a party-neutral point of view, while the concepts in play in XBRL for accounts reporting, and in double entry book keeping generally, are party-specific. We are able to use the high level partitioning of our model to describe many of these terms with reference to one another – creating an overall ontology which makes use of the concepts in REA and in XBRL in order to cross reference these terms to one another. This is an example of what we would hope to do in other areas. We are also migrating the date and time terms in our initial temporal models, to the OMG’s Date Time Vocabulary standard.

Financial Industry Business Ontology
FIBO Industry Standards XLS Boxes & Lines User Commitments Original Content ISO 20022 FpML XBRL SemWeb OWL constructs ODM UML Tools MDDL Sub-set for readability Theory of meaning BIAN SME Reviews Archetypes This is the overall picture of the FIBO standard. Center: The FIBO Business Conceptual Ontology Top left: the ontology was initially populated by reverse engineering the technical model elements of the standards shown (along with some member-donated terms), by asking of each term “What kind of thing does this represent?” These were maintained in the Semantics Repository in a UML tools called Enterprise Architect. Top: A series of Subject Matter Expert reviews were carried out against this model over four years, to validate, extend and finalize the model content. Top right: In order to be able to carry out SME reviews, the model content needed to be presented in business-readable formats. The two formats used were spreadsheet, and “Boxes and lines” diagrams in which the model content was presented visually but free of (most) syntactical material. Bottom left-center: The content of the model was composed entirely from the model constructs of the Web Ontology Language (OWL), and (Bottom left) modeled according to the theory of meaning defined for OWL. Bottom right-center: in order to maintain OWL constructs in the FIBO model and have a tool which could present these constructs in a business-facing way, we used what was then an early draft of the Ontology Definition Metamodel. We made considerable changes to this in order to conform with our own requirements for business-facing presentation (without which, it is not a usable conceptual model). The current OMG standards proposal updates the underlying metamodel and profile to the most recent version of ODM, that is version 1.1. Bottom right: as a result of bringing the model into line with all of ODM 1.1 as distinct from an adaptation of the ODM early draft, it becomes possible for certain tools to be able to transform this to RDF/OWL. This should be treated with caution since this is RDF/OWL of a fully nuanced, legally and conceptually grounded Business Conceptual Ontology, and so is necessarily very different from the RDF/OWL ontology in a semantic web reasoner-based application. For the latter, you would need a sub-set of the content (not shown here). Right center: As well as adapting and extending the early draft of ODM for readability, we came up with a way of visually representing the “simplest kind of thing” abstractions upon which the model depends. We called these Archetypes, and used the tool functionality in the UML tooling, to display these in different colors and/or graphical shapes, thereby creating more visually rich diagrams. In the update to ODM 1.1, we added considerable new work to the model in order that the “archetype” information relevant to each class could now be rendered in RDF/OWL as OWL Annotation Properties. This makes those properties accessible to semantic queries. RDF/OWL ODM v1.1

What we wanted Business meanings In business language
For business people This is what we needed to create in FIBO, for an industry semantic model that represented business meanings and was validated as all good conceptual models should be…

What we wanted Business meanings In business language
Not data dictionary In business language Not a design For business people No funny symbols and things No language to learn Just the facts Boxes and lines – something like this… Elaborating on the above… These are the basic premises and requirements for FIBO. An example follows:

Sample Screenshot Thing “Is A” relations This screen shot is from the web interface, where selected diagrams and tables are presented for review. This shows the basic types of construct in the model. These are explained to first-time viewers, before we can be confident that they know what they are seeing. Nobody needs to learn any RDF/OWL modeling, syntax or terminology but the minimum number of constructs which we have used to present set theory logic to viewers does need to be explained. The model shows “Thing” classes (see terminology notes below); taxonomic relationships, relationship facts, and mutual exclusivity between sets. We do not use the OWL words for these constructs when explaining these diagrams, or ever in SME review sessions. The taxonomic arrow takes a bit of explaining because it is exactly the same in appearance and meaning as the UML Generalization relationship. This is correct – the semantics of the OWL taxonomic relationship is precisely the same, and both the UML and OWL term can be referenced back to one of Aristotle’s four primary syllogisms. This makes it technology neutral, even though the syntax needs explaining. It is the only piece of logical notation which really needs explaining to business participants, and this is unavoidable if we are to get good feedback and input into taxonomic structures. Simple facts (OWL Datatype Properties) are not shown in this screen – these are introduced to readers in a later screen. Simple facts as we call them are shown as text entries in the boxes, and they look a lot like UML Attributes (because that is the UML construct used to express them). Modeling Terminology: in this business-facing explanation we use the word “Thing” to mean a class of thing. In some modeling theory and practise, the word Thing refers to a specific instance. This is not something we need to trouble business domain experts about. In any case the OWL language uses the library object “Thing” to refer to the set of things of which every individual is a member. The word “Thing” as used here, more correctly means a class of thing – in the natural language sense of the word “class”. Relationship Fact Copyright © 2010 EDM Council Inc.

Example: Credit Default Swap (CDS)
Another illustration from the model. This one shows a set of terms from the Credit Default Swap. Only selected terms are shown. Note the differences in coloring and appearances. This indicates what archetype a given thing is. Archetypes shown in this illustration include transactions (green), conferred things i.e. rights and obligations (brown), contracts (light brown), sides or legs of transactions (a different archetype but with similar coloring), and Party – the stick man which represents some autonomous entity in some role specific to some context (here, buyers and sellers). Copyright © 2010 EDM Council Inc.

Spreadsheet Here is the second business-facing representation format, the spreadsheet. This is intended to be as close as possible to the sort of spreadsheets that are used extensively to define business requirements and meanings. FIBO is intended to formally fill the role which such spreadsheets commonly fill informally. Some of the spreadsheets people use are quite complex, and do not follow a standard format. We have taken the constructs in the OWL model, and just as we did with the UML representation we devised a spreadsheet structure which is complex enough to convey the concepts in the model, and no more complex than that. All concepts in the model are displayed with the exception of relationships between relationships (that is, sub-properties and inverses of properties). Some business people are more comfortable with spreadsheets, others are more comfortable with diagrams. This is why we needed to provide both. Copyright © 2010 EDM Council Inc.

Sample screenshot 2: Different types of Thing
Another illustration of a few selected terms, this time as a screen shot from within the model editor. Again we have archetypes for transactions, for sides of transactions, for contracts, for conferred things (rights or commitments) and also the archetype for reference entities such as underlyings. This style of diagram presents enough detail for the business SME to say whether it is right or wrong, complete or incomplete. Initial drafts of these diagrams are intended as essentially “straw men” for comment, validation and extension by the business. That is, this is a knowledge gathering activity making use of drafts of the conceptual ontology. Note that diagrams are produced and maintained with two ways of looking at the Relationship Facts (shown here as blue lines). The full view has a small box attached to each line, which is used to define relationships between relationships – namely sub-property hierarchies and relationship inverses. For business presentation and review purposes these blue boxes and the relationships among them are not usually shown. This style of diagram shows the same level of detail as the spreadsheets. The semantic modelers need to maintain relationships between relationships since it is unlikely that business SMEs have the modeling background to deal with those kinds of modeling concept. The EDM Council Semantics Repository

So what is FIBO FIBO has these distinct aspects:
The Business Ontology Presentation for Business Readability Released in discrete ontologies by subject area FIBO for Business Entities is currently under submission Securities, Loans, Derivatives to follow Corporate Actions, Transactions later Leverage other OMG standards and shared semantics What are the essential aspects of what FIBO itself actually is? Since this was created as a business conceptual model there are certain rules for conceptual modeling which must apply to FIBO and are as much a part of what it “is” as the actual model content or the syntax in which it is maintained. The main components of FIBO therefore are the business conceptual ontology itself (BCO) and the means for presenting this to SMEs for review and validation. The content of the original “Semantics Repository” is maintained in a specific UML tool, under the early draft of ODM with all the adaptations we needed to make to support the business presentation aspects of FIBO. Sections or parts of sections of this are being proposed as OMG standards. Part of the process of putting these forward as OMG standards, is to update the underlying metamodel and profile. This also makes it possible to produce RDF/OWL serialization of this same conceptual model content. The first section being updated and presented into the OMG standardization process is the Business Entities component. Other sections will follow as shown. Some, such as Corporate Actions, may also be able to make reference to other OMG standards e.g. BPMN for their proicess component, although we do also have a process ontology set of archetypes.

From Business to Operational Ontology
Uses for FIBO Semantic Technology applications Conceptual versus Operational Ontologies Transforming from one to the other Use of metadata The next few slides move from “What is FIBO?” to “How do we use FIBO?”. This slide shows the main topics we will cover in this part. Copyright © 2010 EDM Council Inc.

FIBO Application FIBO Conventional Tech Semantic Web Repository Semantic Data Model Logical Data Model Physical Data Model MDR XLS Mapping Model Driven Development OWL Model Reasoners Linked Data This diagram illustrates the various ways in which the FIBO Business Conceptual Ontology may be put to work. The ontology itself is a conceptual model and therefore not an application – so these are the different ways in which the terms in this conceptual model may be used to implement or integrate in the realm of physical applications. The first consideration is, what form does the data take – i.e. what is the instance data? This may be in RDF triple stores, or it may be in conventional databases. It will not be in both formats simultaneously. The right hand side of the diagram illustrates the semantic technology application space, while the left hand side summarizes some of the deployment scenarios in which the model may be used as a conceptual model for conventional applications. The left: conventional technology deployment scenarios The FIBO conceptual ontology resides in a UML model repository, where it has been modeled using the profile defined for the Ontology Definition Metamodel (ODM) standard, so that an OWL model is maintained and diagrammed in a UML tool. Model Driven Development: Any UML tool which has the FIBO content in this way, can be used in the normal way in which UML is intended to be used, that is for model driven development. The user’s model repository would be populated with the relevant parts of the FIBO content. This is extended locally with the semantics of terms that are specific to the business and so not in the standard. Then the modeler adds UML packages for logical data model design and for one or more physical models, along with any packages needed for conceptual (use Case), Logical and Physical on the ‘Behavioral’ side of UML i.e. Activity, Sequence, State etc. models. The UML “Trace” relationship may be used to identify logical design constructs against the conceptual model constructs (FIBO content) against which these have been designed. This brings a level of rigor to the development, as these UML tools are intended to do. Mapping: At present many people use spreadsheets to identify business concepts, to maintain definitions and so on. People may not be used to thinking of these spreadsheets as conceptual models, but this is the role they are fulfilling. The spreadsheet or tabular view is intended as a direct replacement for these informal, unmanaged spreadsheets. The idea behind this was simple: could one come up with a standard format for spreadsheets of business terms, definitions and relationships? By creating a spreadsheet format for the OWL constructs in the model, we have just such a spreadsheet. A spreadsheet can be used for mapping between feeds or between different data models, using the semantics of FIBO as a common point of reference. Using FIBO in this way is simply a matter of using the spreadsheet views from the model in place of the existing uncontrolled spreadsheets around the business. Metadata Repository (MDR): A metadata repository provides a means to manage the information assets across the enterprise. There are essentially two kinds of metadata – that is, data about data. One is the metadata around data provenance, data quality, workflow etc.; the other is the metamodels of the various logical and physical data formats which are represented in the metadata repository. In order to manage and maintain information at the level of business semantics, the metadata repository would need to include a metamodel of the semantic model. In the case of FIBO, this is the Ontology Definition Metamodel. Some MDRs come with this capability pre-configured. Right hand side: Semantic Technology To take advantage of semantic technology capabilities, the data itself must be stored in RDF triple stores. An OWL ontology derived from FIBO defines the meanings of the concepts which are represented by that instance data. Note that not all of the constructs in FIBO correspond to instance data. For example, the very terms which give a term its meaning – rights, obligations, commitments and so on – may not always correspond to instance data. They therefore do not need to be in the ontology which is used for the operational semantic web application. We refer to the ontology which is needed for the application as an “Operational Ontology”. Semantic technology applications include reasoners which can draw inferences from the data, automatically classify instruments or entities based on instance data about them, and so on. Another semantic application is querying. Queries can be framed semantically, and these operate on the instance data in the RDF triple store by searching for patterns in the graph. Linked data, including “Linked Open Data” sources, provides bottom-up, instance level data about items of interest in the world. The availability of rich ontologies, particularly if these are interoperable with other ontologies, means that instead of the linked data referring only to a small number of concepts (such as people, musical works and so on), the data can be tagged against a much wider range of concepts. Another application is the use of semantic technology reasoners to search across conventional data stores. These applications use code which converts the semantic query into conventional database queries. An ontology provides a common point of reference for these. The operational ontology for this kind of application needs to cover all the concepts which may represented in any of the different data stores which may be queried – so this is likely to be a much larger sub-set of the overall Business Conceptual Ontology, than would be needed for a single semantic reasoning application. Semantic Query Copyright © 2010 EDM Council Inc.

FIBO Application As a common reference point Model Driven Development
Mapping, integration Replaces ad hoc spreadsheets with a formal project deliverable Extend locally for concepts within the firm Model Driven Development Position as “Business conceptual model” Manage the “language interface” between Business and IT Semantic Technology applications Implemented across conventional data stores New application infrastructures (Triple stores) See previous slide for notes on these points.

FIBO Semantic Technology Applications
Model one get one free Full and formal representation of the business facts as a common language across the enterprise Rendition of this in Semantic Web format (OWL) opens the way to semantic technology applications Formal reasoning across subject matter Automatic classification of product types Querying across subject matter Business Conceptual ontology (FIBO) transformed into “Operational Ontology” The ability to use semantic technology applications is a by-product of the fact that we chose to represent business concept semantics using the RDF/OWL language rather than some other format. The availability of semantic technology applications opens up a whole new raft of possible applications, without changing the need for the organization to have a conceptual model as part of its formal governance framework. As time goes on, we expect to develop a formal development methodology around the use of semantic models both as conceptual models and as operational ontologies derived from these. With conventional technology, which has to be mapped to the ontology or linked with trace linkages. With semantic technology on the other hand, an operational ontology would generally be a sub-set of the terms in the overall conceptual ontology. Development of the operational ontology for a semantic technology application is a matter of using the appropriate sub-set of the terms in the overall conceptual ontology. To derive a suitable operational ontology from the overall Business Conceptual Ontology requires a number of techniques and transformations. At this time, we are working through what these transformations are. In the future, it may be possible to automate these to some extent. One thing which may help with this is the way we have dealt with some of the more “philosophical” aspects of semantic modeling. For example, philosophy teaches us that every meaningful concept which may be defined falls into one of three types: a meaningful concept which represents a thing in itself regardless of the context in which the term is used (such as a person); a concept which refers explicitly to some thing in some role (such as a parent); and a concept which is the context in which that second thing is defined (such as parenthood). The third type of thing represents a business context. By linking the contexts to the roles which may apply in that context and (via the property of ‘what thing may fulfil this role?’) to the sort of independent things which may play a role in those contexts, it should be possible to directly extract sub-sets of the model as appropriate for well defined use cases.

Conceptual and Operational Ontology
Conceptual Ontology Includes concepts like rights, obligations Meaning is grounded in law Does not care if it is decidable or how long it takes to reason over it Operational Ontology Must conform with the stated technical constraints Reasoning Decidability Combines ontology (classes) with “individuals” (instance data in triple store format) How to get from one to the other? The business conceptual ontology (BCO in FIBO), like any other conceptual model, is a model of the problem as the business sees it and without reference to technical design requirements or constraints. There are many constraints which rightly apply to the design of an ontology in an application, but these necessarily do not apply to the BCO. For example, the conceptual ontology may contain many assertions which are framed (or “grounded”) semantically in terms of legal, financial or business realities which do not directly correspond to instance data. We have not considered instance data when defining the meanings of things, we have simply asked ourselves “What does it mean to be this thing?”, and asserted properties accordingly. The operational ontology should not include terms which do not correspond to instance data. It also does not need to include multiple inheritance as these may impede performance. Whether they do or not is a matter for the implementer; but there is no compelling reason for any one operational ontology to reflect all of the taxonomic structures of the BCO. Defining the precise transformations or operations needed to extract operational ontologies from the Business Conceptual Ontology is a matter for ongoing investigation within the FIBO project. Copyright © 2010 EDM Council Inc.

How to get from one to the other
Select a single classification facet Collapse the taxonomy above the domain Ignore terms which do not correspond to data Rights and obligations Policies, strategies, goals Identify those terms which correspond to instance data For most rights and obligations, some data signature is likely to be present Use property chaining in the conceptual ontology to relate several more abstract but meaningful properties, with one concrete and data-focused property which can be processed. This slide shows some possible pointers for extracting an operational ontology from some FIBO Business Conceptual Ontologies. This is a matter for ongoing work and research at this time. Note that for things which give something formal business meaning such as rights and obligations (meanings grounded in law not data), there is usually likely to be some “signature” in the form of physical data which gives a clue that such a right or obligation is present. For example if someone is obliged to pay interest, there would be formal contract terms setting out what that interest is as a percentage amount, and how it is to be paid. Also for those “relative” things which exist in FIBO, if the relative concepts are to be ignored then relationships around these need to be defined in the ontology. Rather than making the implementer deal with this, FIBO is structured in such a way that these direct relationships should always be present, so that for the operational ontology one may simply ignore those “relative” concepts, unless they are specifically needed. Copyright © 2010 EDM Council Inc.

Ontology Metadata Standard metadata for definitions, notes, provenance etc. Additional metadata for mapping, regulatory cross reference etc. Available in OWL versions of FIBO Annotation Properties: not reasoned over Object Properties: seen by reasoner Both are visible to semantic querying New to the OMG standardization of the FIBO content: many of the things which were not covered in OWL constructs (such as ‘synonym’) and the things which we added to the ontology using textual notes fields in the UML tooling, are now being added to the ontology as OWL Annotation Properties. Annotation Properties are a special kind of property in OWL, which may be ignored by a reasoner. We have created a set of new annotation properties, and also incorporated existing annotations into the FIBO model framework form the ‘Simple Knowledge Organization System’ (SKOS) standard. These new annotations will only become available within FIBO as part of the updating of the underlying metamodel, since these use features of the most recent version of ODM and were not in the model before. Availability of this feature is therefore aligned with availability of the OMG-conformant standard version of the model content. Copyright © 2010 EDM Council Inc.

2012 2013 Beyond Provisional Roadmap Q1 Q2 Q3 Q4 FIBO-Foundations
Global Terms and modeling framework Industry review OMG finalization Final FIBO Business Entity Domain ontology Industry review OMG finalization Final FIBO Securities Domain ontology Industry review OMG finalization Final FIBO Derivatives Domain ontology Industry review OMG finalization Final This is a very provisional view of the intended releases of FIBO standards. The timing of the first standards specifications (December 2012) depends on the availability of a team of business subject matter experts, and depends on their having completed the process of (a) validating or extending the existing FIBO-BE material, and (b) determing what is the precise scope needed for LEI and related regulatory compliance use cases. That scope will probably dictate that a sub-set of the terms currently in the FIBO BCO are to be included in the formal draft of the FIBO OMG standard specification. FIBO Loans Domain ontology Industry review OMG finalization Final FIBO Market Data, CAE, Portfolio, Payments Other Domain ontologies FIBO Market Data, CAE, Risk/Reporting Other Domain ontologies FIBO Market Data, CAE, Risk/Reporting Other Domain ontologies FIBO Market Data, CAE, Risk/Reporting Other Domain ontologies Copyright © 2010 EDM Council Inc. 43

FIBO OMG Specifications
Deliverables FIBO Business Conceptual Ontology (BCO) Adaptive: Web-accessible FIBO presentation FIBO OMG Specifications FIBO Foundations FIBO for Business Entities Etc. This slide shows an overview of the distinct parts of the FIBO universe as we currently see them. There is a separate set of explanatory notes (as slides and as a page on the Semantics Repository website), which describe the scope of each of these in more detail. Briefly: Business Conceptual Ontology: the full, legally grounded and philosophically nuanced repository of the business meanings of concepts; Adaptive Presentation Layer: User-accessible, web based, business-facing representation of the FIBO content in diagrams and tables. Designed to supplement and improve upon the current, UML tool-derived diagrams and spreadsheets. Will be more interactive than these. FIBO OMG Specifications: Sub-set of the BCO content, which is considered necessary and sufficient to meet each of a number of formally defined use cases in the industry. Excludes any terms which do not meet some application use case. Is a super-set of the terms which might exist in one Operational Ontology to meet on use case. Operational Ontologies: one per use case, formally designed and constrained RDF/OWL ontologies which are derived from the overall content of FIBO but which contain only those model elements for which there is operational data. These do not need to fully capture the meanings of terms because the Conceptual Ontology already does that – but those terms which are in these models, are known to be meaningful concepts because of their relationship to the BCO. Operational Ontology (main business use case – common reference and querying across multiple data sources) Operational Ontology Operational Ontology

Main Take-away Points An ontology extends a taxonomy which is organized according to some classification principles An ontology is not another sort of data model It does not replace or displace messaging standards, database schemes or anything else Common semantics is about the business view of what’s in data Enables mature approach to technology management Putting it in a SemWeb tool doesn’t make it meaningful You do Two ways to leverage FIBO Common semantics Semantic Technology applications Regulators and the industry are paying attention! These are the main points which come out of our investigation into how to model financial industry terms semantically, how to define ontologies at a conceptual level, and how to put this to work in each of the practical architectures that may obtain in a financial industry firm: Classification leads to a taxonomy A taxonomy may be extended into an ontology by the addition of properties A semantic model or ontology is not a kind of data model. It does not replace any existing data model. It does not represent a technical design in the way that a data model would. It is developed independently of any data model design. Because there is an ontology to deal with issues of meaning (semantics in the literal sense), there is no need to data models to have to reflect business meanings, and no need to show data models or any other kind of design (message schema diagrams etc.) to the business community. This separation between the kinds of model that reflect the work of technical designers, and the kinds of model that reflect the business view of the world, puts the user firm on the road to a more formal data governance process. Business stakeholders have visibility and control of the business aspects of a project (what a thing does, what a term means), while technology developers do not need to fully understand the business domain in order to develop solutions which meet the business requirements and business semantics. This is a mature, engineering principles based approach to technology development. The use of Semantic Web syntaxes (RDF and OWL) does not magically make terms meaningful. Some syntaxes are more expressive than others, and some are more logically consistent than others. We recommend the use of Semantic Web syntaxes in order to be able to capture meaning, but simply putting something into a Semantic Web syntax does not, of itself, make those terms meaningful. There is no magic in the syntax. Instead, when modeling the business semantics of some business domain, it is necessary to understand the semantics of the terms, to classify things according to the basic nature, to use abstraction of real world concepts, to ground those concepts in basic legal, accounting and other real world concepts, and to partition the model according to different kinds of concept. FIBO is a business ontology constructed to be as meaningful as we are able to make it. This provides a common point of reference to identify precise meanings that can be mapped or referenced in conventional technology application development, in integration, as a point of reference in a “top down” design of solutions and so on. It also opens the way to new applications of the new “semantic technology” architecture. In this way, FIBO provides a better means of management and control for conventional applications along with access to new opportunities afforded by the Semantic Web architecture, giving everyone the best of both worlds. Common meaning (which is all that “semantics” is really about), has applications beyond technology. If someone needs to formally describe a rule or a requirement, the logic of that rule or requirement can be stated in terms of the common semantics defined in FIBO. The alternative, defining rules with reference to physical data fields or logical designs, would cause inefficiencies and mismatches. Common semantics provides a common point of reference for rule-making and description in the business domain. These features mean that the industry is starting to recognize how the use of formal semantic model bears dividends both in solving old problems and in opening up new opportunities. FIBO implements these principles across the field of securities, derivatives, loans, business entities and so on, to provide the common semantics of the industry. This is an industry resource owned and developed by the financial industry itself, and represents the best record of the knowledge of detailed terms and definitions, that is detailed meaningful concepts, in this industry.

The Financial Industry Business Ontology

Similar presentations

Presentation on theme: "The Financial Industry Business Ontology"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The Financial Industry Business Ontology

Similar presentations

Presentation on theme: "The Financial Industry Business Ontology"— Presentation transcript:

Similar presentations

About project

Feedback