 Hello everyone and welcome to our next DDW session called modeling patterns for strategic business data analysis using knowledge graphs. Our presenters today are Dean Elemang semantic web consultant at working ontologist and a Lisa Kendall partner at thematics partners. No audience members are muted during these sessions so please submit your questions in the Q&A window on the right of the screen and our speaker will respond to as many questions as possible at the end of the talk. Please note there is a linked form at the bottom of the page titled the EDW conference session survey. This is where you can submit session feedback and we encourage you to do so. Also there is a small icon to the lower right of the screen which will enlarge this window with the speaker and slides. So with that housekeeping out of the way let's begin our presentation now. Thank you and welcome to Dean and Elisa. Thank you Eric. So Elisa and I have been working for a number of years together on a project called FIBO the financial industry business ontology and we're going to use FIBO as our example for the way these modeling patterns work. But before we get into the patterns themselves I want to talk a little bit about the role that FIBO plays in strategic data management and the specific challenges that an industrial ontology like FIBO faces to sort of set up the need for the design patterns that Elisa is going to talk about in the second half of this talk. So to do that I have different kinds of data that someone has to manage in general. Application data, this is when you're building an application is the data that the application itself manages. So this could be transaction data, history of the application, the actual things that are in the application itself. So it's pretty local in its scope. And then there's enterprise data. If you're managing enterprise there's data that you need to keep from one application to another things like customer information, product information and that kind of thing. But at an even larger scale there's something I like to call industrial data. And this is the data that actually cuts between different enterprises in an industry. What sort of data is that? That's things like regulatory data. That's the most obvious one where the regulators have a right to and need to have access to data from lots of different enterprises. But it also includes data, product research in the case of things like pharmaceuticals and agriculture. The basic science is data that's out there that everybody shares. Data about liability, about market history. This is data at an industrial level. So why do we want to manage industrial level data? These are the obvious reasons to begin with. Regulators have to on the one hand specify what is the data that we actually need to collect from the industry. Also, when the industry members submit that data the regulators have to be able to understand it. They have to be able to compare data across different submissions. And this is whether we're talking about financial regulation where we need to know about financial instruments or food and drug regulation where we need to understand about those products, medical things about medicine, interact with patients. And there's also customer centric data. Well why would you ever share customer data with other enterprises? When many industries this is key for instance if you're migrating data from one company to another that happens in medical records all the time. A patient goes from one clinic or a hospital to an emergency room to a treatment center and their data needs to be able to follow them. Also regulations like the GDPR, CCPA. These are regulations about a person's right to control over their own data about personal privacy. So this is information that cuts across multiple enterprises. It's about the individual who goes from one enterprise to the next. But there's also things like code lists and data models. These are things that companies can share to be able to communicate with each other in a market. We'll see some examples of that in just a moment. So a knowledge graph. Now if you're at this conference you probably have a good idea of what a knowledge graph is. It's a graph of data at a large scale that allows you to share data typically at an enterprise level but in this talk we're talking about sharing data at an industrial level. What can a knowledge graph do for us at an industrial level? So knowledge graphs typically or often contain ontologies. Ontologies are actually providing reference structure. So an example of something an ontology might say is that an address includes a country, a subdivision and a postcode. Now we all know that addresses have these pieces but what an ontology can do is to specify that and all refer to this in a common way. Or an account is held by an account holder but more specifically a customer account is held by a customer which is a particular kind of account holder. These examples actually come from FIBO and I'm not going to go into great detail of these examples so Lisa will give some examples that she goes into detail in later on. On the controlled vocabulary side a knowledge graph can also include controlled lists of items. Some examples of these are quite common in many industries. In agriculture there's a very successful vocabulary called agriVoc. This provides terminology for farmers to share information with chemical companies to share information with brokers and suppliers. The entire supply chain can use information from agriVoc to align their data. LCC, languages, countries and codes. This is a standard maintained by both the OMG and ISO to talk about recognized countries and how we refer to them. The North American industry classification system NAICS is used by banks and governments all over the world. Even though it's North American where it started to align industry types. So this is how banks do what they call KYC, know your customer. This is one of the ways that they unambiguously talk about the business that their customers are in. And also you have data sets that can be shared in finance and banking. There's a thing called the GLIFE. This is the Global Legal Entity Identifier Foundation. They provide identifiers for registered companies around the world. And in life sciences and pharmaceuticals, KEBI, the chemicals of biological interest. These are lists of chemicals that we can use to refer to so that industries can share information about these things. So these are the sorts of things that a knowledge graph can bring at an industrial level to help an industry operate more smoothly in terms of data management. Now let's get to an example of what an industry ontology has to do in such a setting. So what we're looking at here is we're getting to what is the role that something like FIBO and industry ontology can play when you've got multiple stakeholders that are working together. So let's imagine we have two stakeholders here. Company A is a stockbroker. And so what did they do? They keep records of transactions where people or entities purchase equity in other companies. So we see a couple of purchase orders here. Purchase order one, ACME bought 100 shares of stock in a company called EXU. And the total price of that is $22,174 U.S. dollars on a certain date. Another technology bought a stock called PBQ. Its volume was 50 and so on. So this might be data from a relational database or maybe a spreadsheet or report or something. And it's structured in a particular way that makes sense for company A. Now we can draw some conclusions from this. We can conclude that ACME now owns some interest in EXU and Fuji owns an interest in PBQ. But we don't represent it that way. That's not what a stockbroker needs to know. They need to know things about transactions, volumes, and dates. We see a government agency. This government agency is interested in keeping track of ownership for a number of reasons. They want to understand tax liabilities. So when they levy a tax, who do they actually levy it to for activities of certain organizations? It also supports money laundering investigations, fraud investigations. Who is the actual owner of some entity that took some action? And for them, they are really interested in what the banks call the legal hierarchy. That is, what are the legal responsibilities of one organization with respect to another? And they might represent it, for instance, in JSON, where now we see ACME owns EXU is directly represented. We don't actually know the transactions that created that ownership. The government is interested in that. They probably have no business in knowing about that. But they are interested in the legal hierarchy. So these are two different ways to represent data that cover, to some extent, the same information. Now, which of these ways of representing data is right? Well, what does it even mean to be right? There's a company out there working every day, every couple of seconds, doing transactions and stocks. There's a government agency out there pursuing investigations. Neither one of these is right. Each of these representations is fit to purpose. And this is a really important thing to understand that we're not talking about the right way to do data. We're talking about the fit way to do data fit for purpose. And that's really important when you think about the role that an enterprise ontology like FIBO can play. Now, you might say, well, gee, our job is to get it right. Well, wait a minute, if we are getting it right, that means we're telling at least one of these folks that they got it wrong. We are not going to be very popular with the folks that we're trying to help do regulations or data sharing or whatever. If we say to at least half of the organizations out there, probably all of them, oh, by the way, you got it wrong. The business that you are doing every minute of every working day is being transacted incorrectly. No, we're not going to be very popular if that's the way we work. So what can we do? We are charged is to help an industry. In the case of FIBO, the finance industry share data to improve how that industry works to prevent things like the crisis of 2008. To have more transparency into this industry. If we can't come in and say, we have it right, what can we do? Well, we can do something similar to what the vocabularies do. We don't say that this is the right thing. What we say is here are some things you can reference. And when you reference them, you can relate this to your way of doing things. And now the two of you can relate to one another. So if I say, how does their record refer to my record? I don't quite get this. If we provide a common reference, that facilitates that. And a very simple example. On the left, I have a contract. I bet many of you have executed a contract like this. It's actually what is called in real estate a purchase and sale agreement. There's a seller, there's a buyer, there's an asset in this case, it's a house, there's a cost, there's a closing date, a lot of other stuff. But I'm sure all of these concepts are familiar to many of you because you've either bought or sold a house sometime in your life. And that contract has these five pieces to it. Now there's a lot of stuff there, but on the other hand, your condo association, for instance, or your homeowner association is interested in this fact that you own this property. A much simpler piece of data over on the right. How do they relate together? That is the job of the reference ontology to help us answer this. So is our job to model the real world the way it is? No, that's not our job. Every stakeholder has their own idea of how the world is that is fit to the business that they do. We're not going to tell them they're wrong. We could come in and say, the government has told us that we are right to buy fiat, do it our way. That's going to be even more unpopular, because now we actually admitting we're getting it wrong, but telling you to do it the wrong way just to be in alignment with us. No, that's really going to be bad. What we could do is say, let's find a little bit that everybody has in common and model that. Well, okay, that's kind of getting there, but that's actually not very much. Even a simple idea like ownership, we have very different things. What's the common notion here? Those things and things that can own them. That's really not a whole lot. We should be able to do a little bit better than that. So what is our job? We have to anticipate out in the industry what those models will look like. I just anticipated two of them. This isn't as hard as a lot of experience in enterprise data modeling. We have some idea what challenges people face. But we are anticipating. We're not edicting and we're not collecting all the data from all of them. We're anticipating what they're going to have to do because of the use cases that they are supplying. I'm starting to steal at least this thunder now, because she's going to talk about. Then we bring the features from those anticipated models together into an ontology, a common shared model. That is going to help the designers mediate between that. That's our real job to design that model so that these things can relate to it. Of course, we can't just do that by edict. That's got to be a two-way street. We've got to be able to evaluate that against real-world situations. These models are existing because they help someone in their business. They provide value to somebody and there's a use case for that. To talk about FIBO in specifics, that's the general role that any industry ontology is playing. Let's come down to FIBO. For those of you who don't know a bit about the history of FIBO, the financial industry business ontology is an industry-level ontology, which is what I've been talking about, that tries to standardize all of these things, terminology, relationships and logic, to reconcile all the things happening in the financial instrument industry. It's been going on for just over 10 years now. It actually got going around 2008 in response to that crisis. We moved it into RDF OWL so we could share it and have logical consistency over it in 2013. Now it's been released as a joint effort of the EDM Council and the Object Management Group starting around 2015. We release it every quarter, so it's March, June, regular quarters, developed by domain experts and a team of ontologists, and it's all freely available at the links that you see here. Now we're working to publish a new baseline along with in collaboration with the OMG underway later on this year, but that will be governed by the same principles that the current one is of being open and free for the industry to use. So now I've only made it, I'm out of a minute over, sorry about that, Alisa. So Alisa, to talk about how the actual construction of FIBO responds to the challenges that I've talked about in the first part of this talk. So go ahead, Alisa. Okay, next slide. There we go. Yeah, so FIBO was originally developed to address this one single use case, which was to be a common vocabulary for regulatory requirements related to transparency. That's a huge ginormous area. And so what we've tried to do since then is drill down into some more specific use cases around representation of securities, for example, for specific kinds of standard reports and to address some of the requirements that have been coming out of both the EU and the US related to governance, data management, risk data management and vocabulary specific to those areas. The regulators are really demanding more and more transparency. They're looking for additional features in some of these ontologies so they can cover things like cryptocurrency, hedge funds and how to address short selling, and even some of the more nuanced implications that have shown up recently in issues like that brought on by Archegos Capital. And so establishing a common way of talking about these instruments, their behaviors, who the counterparties are and how broadly their exposure extends, which is the piece we'll focus on in a couple of challenges, is really the primary use case for FIBO. And for those of you who aren't aware, there is new legislation, relatively new coming out through Congress called the Financial Transparency Act, which actually mandates the use of ontologies to enable consistency from the regulator's side of the equation. And I suspect the regulators will pass that on to all of the banks that they regulate, so stay tuned for that. Next slide. Okay, so what is a pattern and what is it that we're talking about here? First, financial instruments are really, really complicated and the relationships between them are really, really complicated. And so if people are talking about a graph and graphs as used in machine learning and other kinds of applications for various analytics, what you're talking about is really an arrangement, a pattern is an arrangement of the nodes and the edges in that graph. From an ontological perspective, and now when we're talking about a knowledge graph, we're talking about reusable arrangements of classes, relationships between them, some of the specific individuals that participate in those relationships, and the logic that hooks it all together in that knowledge graph. And so that is the structure we're building, the sort of the schema for the knowledge graph with respect to the ontology, so that the data that is implemented in that knowledge graph is navigable in a variety of ways to help manage that complexity and to help answer some of the questions that the regulators are interested in. And many of the patterns we'll talk about today are common. Professional data modelers will find many of them very familiar. As it happens, a lot of the people working in knowledge graphs and machine learning are not familiar with some of the patterns that professional data modelers know. But there are also patterns that are much easier to implement in a knowledge graph than in relational and multi-dimensional databases. And so we'll talk about one of those in a few minutes. Next slide. So there are two sort of kinds of patterns that I'll talk about today. The first group, or what I'll describe as simple patterns, many of these are things that data modeling professionals are already familiar with. Things versus strings, which is a pattern that has been around for many, many years predates the internet by at least a decade or two. Assigning names to things, how do we do that and how do companies deal with name resolution, but not only companies, but the regulators that are interested in rolling up data across companies, how do they resolve names? Whether it's for a customer 360 application, know your customer as Dean mentioned, other kinds of risk analysis required for banking, understanding the names and how they relate to one another is a huge problem. And then identifying things and identity resolution is even more challenging than name resolution as it happens. Relating codes to things, relating classifiers to things, putting things in buckets, using the NAICS codes, for example, describing who an organization is or what bucket they fall into, all of those patterns are patterns that we implement in FIBO. And I'll talk about a couple of them now. Next slide. So first, let's start with a pattern that we call things versus strings. And from a knowledge graph and graph perspective generally, Google popularized that term in about 2012. When they put together their knowledge graph group internally with a goal of providing much better structured information to their community or to anyone using their tooling, better than just a list of links. So what you see in the center is the list of links, if I queried about Charles Saunders' purse. And on the right, what you see is what they call a knowledge card, the information about purse that comes back from their knowledge graph about him. Next slide. So the knowledge graph itself isn't just strings, it's pointing to real things in their graph that in turn point to other things. So the notion of somebody having a biography, of having a date of birth or date of death, of editing certain materials, of authoring others, of influencing certain people who then influenced other people, of studying at certain institutions. There are references under the hood in the knowledge graph about each of those things. Next slide. So what that looks like, in fact, under the hood is you have a link perhaps to the biography of purse that's in Wikipedia. Or you have links to the actual bibliographic references to the things that he edited or to things that he authored and links to knowledge cards for the people he influenced and for the university he studied at. Next slide. So taking that to the next level, inside of our standard for industry, looking at how we name things that people can use across organizationally. You could represent somebody's name as a string. You could look at the legacy ways people describe other people, like having a first name and a middle name and a middle initial and a surname Dean and I can tell you at nauseam how many bank databases we've looked at that include all of those elements, making both of us crazy. And their names differently and they have different shortcuts for referencing all of them and, you know, how do you know what prefixes preferred under what conditions. Does everybody have a first name people in Indonesia only have one name they don't have a first name or a last name. Is their middle name repeated they have more than one middle name I happen to they have a middle initial which which middle name is it an initial for is their last name hyphenated do they have multiple last names as of when. My married name count in my name my whole life, because, you know, there are all these kinds of questions that you have to be able to answer. And so what we've created is a pattern for representing names so that you can point to the right elements, depending on what you're trying to integrate or more importantly what your research requirements require so next slide. So the pattern that we're going to show you is one that we are still back filling in FIBO. And what we've done is we created sort of a structural name that name may have an applicable date period it may be used in some context it certainly should have at least one source. And it may be a legal name, a familiar name, a sorting name, the structure of the person's name needs to include for both cultural sensitivity and for search capability, both a family name and their full name. But having all these other sort of legacy prefixes and surnames and and first names and middle names doesn't necessarily serve us well over time. We can include legacy names, but the primary structural name should be one that's culturally sensitive and that we need to use across a bank or a set of banks or through the regulatory process and so on. And the pattern for representing names for organizations is similar. And one thing to note is that the pointers from our contextual name go from the name to the thing that they're naming, as opposed to the other way around and we use inverse relations to infer that a person has a certain name, or a sorting name, rather than stating it overtly, so that we can map and integrate multiple names from multiple sources at the same time without any conflict. Next slide. So another similar pattern has to do with identifiers and identification. And this is one that should be familiar to most data modelers and to other folks that have used some of the metadata standards out there like ISO 111 79. An identifier identifies something, not the other way around. We are not born with social security numbers they are given to us at a certain point in time by a government agency. Structured identifiers including those that are composites, for example an ISIN, which is an identifier for a financial instrument, includes a country code, whereas an MSIN or the national security identifier does not include the country code. So you've got structured identifiers, you've got unstructured identifiers, some of them are registered with a registration authority, many of them are defined in certain schemes. And identifiers are things themselves and we can layer these patterns and use the elements that are appropriate for the kind of identifier we're talking about. Next slide. There we go. So here's an example. Earlier in the talk Dean mentioned the LEI data. This is data about legal entity identifiers that's published by the Global Legal Entity Identifier Foundation and represents an ISO standard for representing identifiers about legal entities. So Citibank National Association is identified by an LEI. Banks and regulators require LEIs to identify the counterparties in financial contracts. So you can see here from a search on the glyph site, the legal entity identifier for the glyph, but not only is it an identifier, it includes their validation sources, which dates it's valid for and other information about the entity that are important for validating who they are. The search on the glyph website is powered by ontologies that were derived from FIBO originally and then enhanced and made standalone to support the glyph processes. And there's data for, I think it may be now 1.7 million records available on data.world using those ontologies. So next slide. So here's the example for Citibank using our structured approach. So you've got Citibank National Association, the identifier identifies Citibank. It's used for the inverse and the identifier itself has the tag you saw in the prior search. It's used in context of some data store or regulatory repository and the source for that is the glyph foundation. Next slide. So we also want to talk a little bit about some more complicated patterns. Some of those you'll recognize, but the final one I think may be a little more than most people have seen before. So associating parties with the roles that they play, applying the identifier to the right element, whether it's a party or a party in the role that it's playing. And then situational analysis linking those parties and roles to patterns that are time bound, which is the important pattern that we want to share with you that has been something we've developed in FIBO that we think has pretty widespread application. Next slide. So the party role example is one that I've seen in many, many recommendations for professional data modeling and representation. We use it in FIBO as well. So a legally capable natural person, which is someone who can enter into a contract is a person and is a party in our model. A legal entity is an organization and is also a party. And a party that is a legal entity might play the role of a regulatory agency, might play the role of a financial institution. And in the case of the Federal Reserve Bank of New York, play both roles, depending on what it is that they're doing in the moment. We can associate identifiers with better semantics with either the party or the role that they play, depending on what is important for the use case. With respect to things like identifying institutions that are counterparties to financial instruments, we care about multiple things. We care about the LEI that identifies the legal entity. But we also care about the FDIC certificate, the bank routing number, the charter, and other identifiers that are associated with the role of being a depository institution or being a brokerage or being an investment bank. And those identifiers are associated with the roles so that we can then roll up roles for an organization that plays more than one role and understand how to then roll up and do analysis over the risk involved in some of the relationships that they have. Next slide. So the point that we wanted to get to is that some relationships are a little more complicated. So a situation is a setting, a state of affairs, or some complex relationship that is probably stable for some period of time. And examples of these relationships that are important for counterparty analysis include ownership, control, possession, which might or might not imply ownership, affiliation, beneficial ownership, board membership, and the like. And so analysis of patterns that fall into this camp allows us to traverse those relationships and understand not only who is who, but who owns who, who might know who, who might have influenced who, who trades with who, and so forth. And because many of the institutions that we're talking about have thousands of legal entities, rolling that information up to understand the overall risk that a large institution has is not for the faint hearted. And so understanding these patterns and using those patterns as the basis for machine learning or other rule analyses allows us to do a number of things, including explaining the results you get from those analyses, which is a difficult task at best. Next slide. So ownership is one I'll use as an example and how can we better represent ownership. I might know that there that some holding company is an owner of something and one of the things that they own is an asset, which is a financial institution. But how do I connect that to all kinds of other evidence for that ownership and the period of time for which it is applicable. Next slide. So for FIBO, we've established over a number of years, a basic situational pattern. So what that means is that you have the party that is playing the role of some actor or undergoer in that situation. All situations have actors, not all situations have undergoers. And those situations hold during some period of time, and they may or may not have other information provenance evidence associated with them. Next slide. So now we're going to add a layer on top of that and we're going to use a technique that's unique. We believe to the knowledge graph approach that we've taken and to the languages that we use for knowledge representation, including property chains. And what you see on the diagram are these connections for more complicated properties that associate with the situation. So if I want to go from the situation directly to the bank or to the legal entity rather that participates in that situation, I can use this has active party property, exactly a chain of has actor chained with is played by in order to give me the connections through that situation of who the legal entity is related to that situation. And on the other side, if that situation applies to something like a contract or to some party that I can go the other way and say, well, I want to know who is experiencing this situation by chaining where the other has under go or with his plays by and we can do the inverse as well. So each of these sets of properties are inverses of one another. They all connect through the situation, so that we can actually connect the dots doing complex queries, and other analyses over the knowledge graph. Next slide. So here is an extension of that where we've added even more property chains so we can go from the party on one side of the situation to the party on the other side of the situation through that situation linking all of the dots. And so the actor in the situation might act on the undergoer and vice versa the undergoer is affected by the actor. And those are each property chains. So actor to undergoer is the chain of axion has undergoer and so forth and you get the idea. So now let's go on to a little bit more complexity. So suppose on the next slide we want to then go the other way from the from the party from the individual legal entity or person to the thing that they're affecting through that situation. And so again, we've created a series of property chains that actually go all the way around the pattern from, for example, from the party that is the person to the actor that, which is the role they're playing to the situation they act in to the undergoer that is the under the other party and the situation and there may be more than one undergoer to the role that undergoer is played by to the individual that undergoers is representing. And so that particular chain we call plays active role that directly affects and there is an inverse chain which is experiences directly that goes the other way around the mulberry bush. Next slide. So Lisa and Dean just a heads up we have a couple more minutes until our scheduled Q&A time. Okay, so ownership back to that the way that we use these patterns ownership could be partial. It requires evidence. It might be beneficial through a broker or custodian that tends to obfuscate who the owner is and ownership structures are layered through subsidiaries. And so having a graph structure that allows us to understand who the owning party is who the what the owned asset is who owns it and and what it is an asset of all those relationships are actually properties of that pattern I just shared with you and combined with entity and identity resolution. We can actually put those things together to identify who owns who who owns what and help people roll up risk and this is the most important take away from the slides. And so now let's go to an example really quickly and then we can get to questions the next slide. So this is an entity ownership in FIBO and this is an image from protege where we've actually run the reason or to get some results we can share with you. It's it's sort of eye candy at this point but you can look at it offline so has owned entity is a property of the chain as I mentioned has owning entity is a sub property of the inverse chain. And so we connect that to this concept of entity ownership. Next slide. So here is an example for city for city bank National Association and the inferred relationships fill in some of the blanks. And so we can see that city bank National Association is in an ownership relation with City Corp LLC. And we can also add the fact that their ownership percentage is actually 100%. And if we had built out the example more completely we could actually show the link to the contract that is evidence for that relationship. Next slide. So now because of the way that we've implemented this in that graph using that pattern, starting from city bank National Association, we can see when we describe city bank that C Corp LLC is their direct owner. But we can also get through inheritance through that pattern. The city group bank is actually their ultimate owner. And we've inferred that through the pattern that we just shared with you which means we can roll up ownership for the 3500 or however many more than that legal entities that city group ultimately owns. Next slide. So finally what we wanted to let you know is there are a number of these patterns in FIBO what we shared with you is just the tip of the iceberg. We're really hopeful that you can look at the slides and then think about it for a bit. Download FIBO if you like and then ask us all kinds of questions so we can point you in the right direction. And just want to thank you all for being with us today. That's great. Thank you so much, Lisa and Dean. Let's dive into some questions. We have several. The first one here is from Abishak Agarwal and says, What is the process for ongoing maintenance and distribution of FIBO? Who are the stakeholders involved in the maintenance of this ontology? If regulators request for a change or update, how and where to submit that request? And I will tell you that Pete Rivett popped into the chat as well and gave the link to the GitHub repo and also a link to some resources on the EDMC website. But I wanted to ask this question anyway and see if you had any advice for perhaps business stakeholders within organizations that may not go straight to GitHub. Is there cultural processes in place if an organization wants to make this kind of request? There certainly are. So I'll start and then I'll turn over to Dean. So the first from a regulatory or any organization, whether it's Citibank that doesn't like the way we've represented them or some other bank that has a use case they needed to solve. There is a process they could come through the EDM council. There are links on the council website to the FIBO working groups. There is a link to getting involved. They can find us through that process, but also they can raise issues either in GitHub or simply send them through the council for us to address as a group. And if they want to participate in that, the more the merrier and we welcome anybody who wants to join us. And Dean, you want to talk a little more about the specifics? Actually, no, because I feel like Pete covered that really well. So I want to thank you, Pete, for doing that. And I think we should probably move on. Okay, okay. Next one up is from Dominic Ebeling. Dean specifically, he wanted to ask you FIBO is an offered recited example at EDW. Are there models for other industries with similar reach? I don't know about similar reach. I think FIBO is being part of the most ambitious project of its kind that I'm aware of. However, it's worth pointing out, for instance, there's a whole set of projects that go into the name OBO, the open bioinformatic ontologies, and inside of OBO. OBO is a lot of similar projects. There are projects that are actually very similar to FIBO in terms of their goals. Exposure ontology that is used inside of OBO to coordinate data sets that drive things like toxic exposures or infectious exposures. The EDM council itself is branching out into other areas. And so we've recently started an effort to work on an ontology in the automotive manufacturing industry. And if anybody listening is in or interested in that industry, just as Alisa said with the working groups that she has been leading inside of FIBO, the automotive industry working group is quite interested in having industry experts either from individual companies or regulators come in and join us. And if you're interested, contact us and I'll get you an invitation to that. But it's also worth noticing that a lot of ontologies that play this role show up guys of some application. So an example of that is, for instance, there was a project that the European Commission sponsored a few years back called Open Facts. Now, if you look at Open Facts, it does a whole lot of things. There are third party applications built on it, had a whole API built on it. And one of the many things that Open Facts had in it was, and to some extent still is, Open Facts is kind of distributed how it's being managed nowadays that the EC funding is ended. But there is an ontology in there that talks about what are the things not strings in all of these data sets? How do they relate together? Basically, like any of the diagrams that Alisa or I showed where we had some diagram of how things relate to each other that you could use to reference other data sets. And a big part of the Open Facts work was doing that mapping as well. So often you don't see these things advertised as ontologies like FIBO does. You see them advertised as knowledge graph applications or data services and the backbone of them actually is an ontology. Possibly with the similar ambition as FIBO, but it's not presented that way. But yeah, there's a couple others there that I've just mentioned. If you go hunting, you'll find some more. Yeah, there's two others actually that I'm familiar with. One is going on at OMG now in retail. So the National Retail Foundation, which some of you may know of, which is the group that publishes Christmas sales, for example, were up 30% over last year or whatever it happens to be. They had a standards body called the Arts Council up until a few years ago, which they spun out to the OMG. So the Arts Council is now the retail domain task force of OMG. And they are in the process of building out a retail industry ontology sort of in parallel with FIBO and using some of the processes we've put into place for FIBO to replace their reference data model over time. Because it's dated, it doesn't reflect the current digital requirements that they have, and it's tough to revise it. It consists of over 31 standards and even more that they represent, but the reference data model that covers them is pretty brittle. And so they're replacing that with a retail ontology. The other group that I'm aware of is called the Industrial Ontology Foundry, or IOF, and that's in the manufacturing space. And NIST is sort of sponsoring that effort, but there are universities and manufacturers all over the world participating in that effort. And of course I'd be completely remiss if I didn't at least say the words schema.org in response to this. There's so much to say about schema.org and in what extent is it a response to this question and what extent is it not that I don't think we have time to get into. But it certainly has to be mentioned. It definitely plays in this space, although in somewhat a different way than we're describing here. But yeah, I simply have to say it. Otherwise, people would say, why on earth did you not mention schema.org in response to that? Duly noted. You have officially mentioned it. Laurel Schiffern wanted to know, in the financial industry, is there a good adoption of FIBO or are organizations creating their own ontologies? Yes. I say yes, and the jury is out. Yes, in the sense that Dean and I both are working with institutions that are using it directly. And there are others. I think Pete is working with at least one institution that's using it directly. Some institutions we're familiar with have used it for various purposes, like as a reference glossary or as a reference model rather than strictly for implementation purposes. But at the institutions that Dean and I work with, it's being used directly as a part of their knowledge graph. Yes, there's two ways. There's two ways we see this happening. When Lisa refers to directly, that's someone who actually is to some extent treating FIBO as if it were a regulation. You're saying, hey, let's start with this. After all, they did a lot of cool modeling work. Let's start with this and do this in our organization. But we also see organizations are going the other way around saying, well, you know, we really want to develop our own ontology for all the reasons that I talked about at the beginning of this talk. But this reference FIBO is actually pretty cool. Every once in a while we have some distinction that we're thinking about, and that's really where the patterns come in, about distinction. How do we manage? Well, one of my clients said, oh, we realize there's a difference in the thing called a role and the entity that plays that role. We need to model this. And then everyone heaves a deep sigh because they realize this is a lot of work. But they say, Dean, you know about FIBO. And I go, sure, here's what FIBO says about this. Ah, good. We get to advance past go now and collect our $200 because we've got this head start. They're not using FIBO lock, stock and barrel, but they're drawing upon it in this way. The other thing we should say, though, is that there are several regulators that have been poking around at FIBO and at least three that have participated in some of our working groups. And of those, the Federal Reserve in New York actually reached out to me recently because they're more interested in getting reengaged. The CFTC Commodities Futures Trading Commission is looking at using FIBO as the basis for a proof of concept to replace some of their integration challenges. The FDIC is also considering using it with respect to dealing with some of the challenges they have for data integration and there are others in the queue. So the fact that the regulators are starting to think that it is good enough for them to start working with has made all of us really sort of stand up and think, oh, okay, we're not so bad. Maybe we've done something useful. So not only is it useful for the institutions, but the regulators are starting to use to consider using it anyway as a lingua franca to work with those institutions, which is a very interesting thing. All right. Thank you both so much. I'm afraid we are out of time. There were a couple other questions we didn't get to, but the Q&A will stay active. So feel free to hop over there and engage after the session. Thank you, Dean and Alisa for this great presentation. Thanks to our attendees for tuning in for your engagement and your great questions. Please complete your conference session survey and the page for this session. That wraps up today's EDW conference program. We hope you enjoyed all the sessions that you participated in. You are welcome to continue networking with other attendees and speakers within the SpotMe app. And we look forward to seeing you tomorrow starting at 8 a.m. Pacific time, 11 a.m. Eastern for the last day of the 2021 EDW conference. Thanks, Alisa and Dean. Thanks, Eric. You're very welcome. Thanks all for joining us.