Michael Atkin

International Monetary Fund

The IMF works to achieve sustainable growth for its approximately 200 member countries.  It carries out missions and loans funds to execute projects for the member countries. The countries’ financial situation is measured and tracked using a wide variety of economic indicators. 

The challenge: Information is stored in a wide variety of vocabulary managers, applications and databases. This makes it difficult to quickly get answers to questions required to carry out day-to-day work. For example: Who is likely to be an expert on customs; Find documents associated with countries similar to Afghanistan; What types of missions for what countries are addressing climate change? 

In each case, getting the answer requires retrieving and processing information from multiple sources. To represent the information required to answer the questions, we built an ontology that covers the core business of the IMF. The main things are: 

We created a knowledge graph composed of the ontology and RDF triples data that was created by converting taxonomies and datasets from a variety of data sources. We wrote  SPARQL queries that traverse the knowledge graph to answer the questions of interest.  This is to be the basis for an internal knowledge portal for integrating structured data (such  as GDP per country) with unstructured data (such as country-specific reports on commodity prices).

World Minerals: ERP Conversion Feasibility  

World Minerals is the largest producer of diatomaceous earth and a major producer of several other industrial materials. The infrastructure upon which their internally developed ERP system  was based had become obsolete. This included pretty much the whole stack: DEC VAX operating system, Alpha chips, the Rdb database, Cobol and green screens. 

They were contemplating implementing a packaged system when they contacted us. After a great  deal of research, we concluded: 

Because their current systems had some very complex built-in requirements that no ERP package supported, a package system would require a great deal of customization and extension. An automated conversion to modern architecture would be feasible, more cost-effective and less disruptive. 

They opted to go the conversion route. They contracted with an implementation firm who did a partially automated conversion, but who did come in close to our estimate, and they have been  using their converted systems since. 

Washington State: SOA Design 

The long-range plan at L&I called for organizing their future application initiatives around shared services and shared messages on a message bus. 

In this project we created detailed requirements specs for the dozen major shared services and created an inventory of the key messages they would need to form the backbone of their Service Oriented Architecture. 

One of the interesting early wins was with their Accounts Receivable system. They had just started an AR project, and we convinced them to think of AR as a service rather than an application. They had discovered that 23 of their 200 applications had implemented AR  functionality and this project was intended to rationalize this. The pilot application to be converted (Claims Overpayment) wanted to implement an AR message that was highly specific to claims overpayment and, therefore, would not be reusable. This was contrary to the idea of reusable messages. 

We did a bit of semantic modeling to find the commonalities and differences and constructed a common message that had variable payloads for the few fields that really needed to be specialized for each case. On a follow-up visit several years later, they  reported they have successfully converted all 23 of the satellite AR functions, which has  provided benefits including consistent revenue reporting and a single place to check to see  if someone owes the Agency money before they pay them from their Accounts Payable  systems. 

Washington State: Secretary of State 

We were engaged to perform a feasibility and requirements study for the Corporations and  Charities Division of the Office of the Secretary of State. In our proposal we included  developing a semantic model to help clarify the feasibility and requirements. Another key part of the requirements was to examine some 2,000 individual statutes to identify any rules embedded in the laws and determine if they would need to be reflected in the new system. 

If we had any regrets, it was that we hadn’t done the semantic work earlier. We believe that the explosion of schema complexity is a product of scale; most of our large clients have severely stove-piped systems which lend themselves to high levels of redundancy.  Our other operating hypothesis is that the widespread adoption of packaged systems is  another major contributing factor to schema bloat. But we found the same level of schema  complexity at the SOS, where the scope was small and there were no packages  implemented. 

Their existing systems, which were still highly paper- and manual workflow-intense, were supported by four databases which consisted of 250 tables and 3,000 attributes (columns).  We built a semantic model that unambiguously defined all their key concepts and then reduced it to a model they could implement with relational technology. Due to the language in the RFP we were precluded from doing the implementation and they were not ready to do a semantic implementation on their own. The relational version of their new system was completely online and had more functionality than their existing system and had only 20 tables and 110 unique attributes. This was a more than 25-fold reduction in complexity and was instrumental in their decision to build a custom system. 

We say we wish we could have done the semantic model first (there were other factors that dictated our sequencing) because, had we known how simple the semantic model would be, we would have been able to do the statute-to-rule exegesis straight to the semantic model terms. The extra effort we introduced with interim terms far exceeded the effort we spent in building the semantic model. 

The project finished on time and in budget, and they are now working on User Experience,  which they would like to solidify before they begin the build in earnest.

Washington State: Entity Identification

We were retained to help with this two-pronged project. One prong was to create a feasibility study to determine whether collecting additional data from employers would aid  in targeting workplace safety inspections. 

The other half of the project was to do a high-level redesign and feasibility study on how  they were tracking addresses and business locations in their many applications. It turned out that there were nearly 100 different places in applications where location and address were being maintained. This was a major issue as they were embarking on an initiative to provide customer self-service to many functions. The multitude of endpoints for potential address change was daunting. 

Through ontological design, we first helped them clarify the differences between a work location, a work site and an address. We also created a high-level design that accommodated the many different needs for addresses and locations without being overly burdensome.

Washington State: Enterprise Ontology

The Employment Security Division (ESD) manages Unemployment Insurance and Claims and have a very active program to help people get back to work. We were engaged to help them determine a strategy for integrating into what had become three major systems all geared toward getting out-of-work workers back to work. 

One system was essentially an extension of the State’s Welfare system and dealt with TANF  recipients. Another was an extension of their claims management system and the third was a system for the general public. Pretty much everything about each of these systems was different, down to what they called the person who was looking for work: in the TANF system, he or she was a ‘parent,’ in the Claims system, he or she was a ‘claimant,’ and in the public system, a ‘job seeker.’ 

We built an ontology that reconciled all these views. This project occurred just as the recession was picking up steam, and the State had put a moratorium on capital spending on software projects. To address this, we created a plan that divided what was needed into  19 small projects budgeted at a few hundred thousand dollars each. They were able to fund the initial projects out of the operations budget and were able to proceed despite the capital spending freeze. 

Investment Bank Case Study: Records and Retention Management

This major investment bank was found in contempt of court and massively fined for their incoherent approach to records and retention management. Up to this point the prevailing approach had been to allow data stewards to tag documents and systems with record classification information to aid in the process of discovery and disposition. 

Our subsequent analysis revealed what many suspected. Of the almost 10,000 application databases and over 60,000 content repositories, approximately one-half of one percent had been classified. 

Our sponsor had the intuition that context was the key to improving this problem. There  was a wealth of contextual information, but it was in various different systems,  uncoordinated and in many cases shrouded in acronyms and arcane terms. 

We extracted a great deal of contextual information. It turns out knowing who set up a repository, what department they work in, what cost center they charge it to, how they named it, and where they put it are valuable clues as to what the repository contains. But these clues can only make sense with a bit more mining. 

To begin, we harvested their financial reporting structure, the cost center structure, and all the employees. For each, we also got as much narrative as we could. We got the division  and department description and mission, the reason for setting up the cost center, and the  job description for each employee. We unpacked the acronyms. We loaded all this into a knowledge graph. 

With some very lightweight NLP we were able to get accurate classification for about 25%  of the repositories based on this information. Quite a difference from the one-half of one percent. This was enough to launch a major effort that now uses machine learning to mine  deep learning that allows knowledgeable analysts to classify with even higher degrees of accuracy and completeness.

Investment Bank: Data Meaning

Have you ever read an analyst’s report? They are full of strange turns of phrase. The phrase “we continue to overweight [stock x]” is not a reference to obesity or a lack of a weight watcher program, it means they like this stock. “… will continue to face headwinds”  is not a weather report, but a warning that this company, or more often this sector, will face higher than usual difficulties in continuing to deliver their quarterly numbers. 

This client had a chatbot that could answer simple questions: “What is IBMs closing price?”  but they wanted it to be able to answer more nuanced questions especially those that could only be answered if the chatbot understood what the analyst had written. 

We built an ontology (actually eight ontology modules, for we had to be able to distinguish such things as KPIs that are common to all businesses (net profit, earning per share, etc.)  and those that are sector specific (same store sales, revenue per square foot, fabrication yields, etc.) activities that companies might to affect these (enter new markets, develop new products, etc.). We also created an ontology of how the equity market thinks about stocks (price earnings ratios, market capitalization, etc.) and finally the kind of vocabulary that each analyst uses. 

Teaming with an NLP vendor that is very good at mapping text to bespoke ontologies, we  were able to extract and triplify all the analysts’ reports from several sectors. The same  NLP vendor also had the ability to covert textual questions (from the chatbot) into SPARQL  and query the triple store. The results have been very promising, and a longer-term, larger-scale effort is currently under way to make this broader (more sectors) and more accurate  (increase the relevant return percentage).

International Monetary Fund 

The IMF works to achieve sustainable growth for its approximately 200 member countries.  It carries out missions and loans funds to execute projects for the member countries. The countries’ financial situation is measured and tracked using a wide variety of economic indicators. 

The challenge: Information is stored in a wide variety of vocabulary managers, applications and databases. This makes it difficult to quickly get answers to questions required to carry out day-to-day work. For example: Who is likely to be an expert on customs; Find documents associated with countries similar to Afghanistan; What types of missions for what countries are addressing climate change? 

In each case, getting the answer requires retrieving and processing information from multiple sources. To represent the information required to answer the questions, we built an ontology that covers the core business of the IMF. The main things are: 

We created a knowledge graph composed of the ontology and RDF triples data that was created by converting taxonomies and datasets from a variety of data sources. We wrote  SPARQL queries that traverse the knowledge graph to answer the questions of interest.  This is to be the basis for an internal knowledge portal for integrating structured data (such  as GDP per country) with unstructured data (such as country-specific reports on commodity prices).

Dun & Bradstreet 

Dun & Bradstreet sell data about company’s credit worthiness and their contact information. Every dataset and every API is its own “product” complete with its own metadata. With this approach for managing information comes excessive complexity. They did a massive analytic project to inventory all the elements that were part of at least one of their “products” and the inventory consisted of 160,000 unique data elements. 

It turned out they were having trouble mapping one product to another. Migrating clients to newer products was becoming increasingly problematic. 

In this case, after studying the problem, it turned out that the people that understood these complex systems were in short supply and high demand. Just getting access to one for a brief bit of time was a challenge. To map two of these products to each other required getting two of these experts together long enough to negotiate an alignment. 

We created an ontology of their end game, but they had more immediate problems that needed to be solved. Our end game ontology highlighted the problem that they discovered on a previous attempt to address this problem. The problem of mapping cardinality being so high as to be useless. Many of the elements in their inventory were attributes of  “address.” But when you mapped lots of elements to the concept of address, you had so many inbound links there was nothing useful you could do with this information. While  90,000 of the 160,000 elements had something to do with an address, there are not really  90,000 distinct address attributes. Spoiler alert, there are only dozens. 

What these tens of thousands of elements represented were different contexts around addresses. This isn’t your address, it’s the court address of the bankruptcy of your ultimate domestic parent. 

Armed with that, we built a system that allowed them to classify the 160,000 elements in a  way that they could be simply, unambiguously, and with low cardinality mapped to the  source “products.” The system was an interactive web-based system that relied on a series of orthogonal facets to guide the mapping process.