The Whiteboard

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.

Chemical and Science Manufacturer 

Capturing interrelations of information for relevance can be difficult, even with NLP. More often companies will seek to work in taxonomy space in their journey toward richer implementations of knowledge graphs for automation adoption. Our consulting services leveraged this approach to provide a foundation stepping stone as the company sought to bring inherent knowledge graph capabilities into their business. 

This global manufacturer had a sluggish system in place to comb through internet publications and look for key terms that might mark articles of interest to its divisions for competitive intelligence as a spawning point for innovative ideas. However, processes remained heavily manual and cumbersome. They realized that strong text matching and analysis was a missing component and decided to turn to taxonomies to mitigate and improve the process. 

Semantic Arts quickly discovered that the key to success was faceted taxonomies. We  worked with SMEs to determine what areas contained specific controlled vocabularies and  specialized terminology. As a starting point, Semantic Arts created a series of taxonomies  for each area for improved automation. Areas included: 

The tight focus of each facet allowed for SMEs and division experts to create very specific lists of terms. By using preferred labels and alternate labels (synonyms) for each, SA  enabled what could be recognized and matched in a desired internet corpus. Initial  implementation of the facets showed a higher level of matching to recognized terms of  interest than an NLP algorithm achieved, created a higher confidence in the significance of  the match, and left out many common or “stop” terms that the original method still picked  up. A start of efficiency was realized.

Semantic Arts developed a more extended road map with the manufacturer to first refine  and bulk up the taxonomy lists based on continued implementation and analysis. By implementing, the client’s intent will be to apply a simple semantic layer to relate and interconnect the taxonomy facets. This ontology model will allow even richer inferencing  and matching of results based on relationships between terms (i.e., an article about a  specific product will imply the involvement of certain manufacturers even if they are not  explicitly mentioned). 

In this case, a small step in a focused step into taxonomy re-classification is helping to open more understanding about the broader benefit while allowing for faster delivery of more pin-pointed research answers. In addition, building innovation pipelines of connected unstructured information are consistent with organizational goals of harmonizing data for greater strategic value. Although at initial phase, divisions in other parts of the enterprise have taken notice. Furthermore, interest has been expressed to leverage the unique reusability and interoperability semantic capabilities enable after this initial pilot.

Colorado Child Support Enforcement 

We have done a series of projects with Colorado Child Support Enforcement to help them understand, at a high level, how their future systems might look when they are partitioned,  when they incorporate an SOA architecture and when they conform to a common semantic model. 

We are currently working with COCSE to help them create a strategic alternative to the conundrum many agencies face. They are being encouraged to implement a “transfer system” which is software that has been developed at another State’s Child Support  Division. While the software price tag of $0 is tempting, the implementation price tags are quite steep. Most states are spending in the $100M to $150M range to implement systems which are arguably only marginally better than the ones they are replacing.

Major Credit Card Processor 

In their migration to the cloud, this Credit Card Processor turned full-service bank, decided to tackle the problem that many large firms face – achieving an integrated view of their customer. 

We helped them define, semantically, what characteristics made someone a customer. It turned out that each part of the business had a different set of characteristics. One set of characteristics revolved around the kind of account you had with the firm. Certainly, if you have a credit card you are a customer. However, it also revolved around the kind of relationships. For instance, you might have an account. In some parts of business being a guarantor on an account makes you a customer, but in others, being a beneficiary is the distinguisher. Furthermore, non-financial accounts (e.g., access to your credit score, which involves no obligation on either party) were considered a customer in some parts of the firm and not others. 

But the interesting differences of opinion came at the problem from two extremes. The marketing group felt that anyone we could contact was a customer. The KYC (Know Your  Customer) group needed to have a much narrower definition of customer, as everyone that fit those criteria was subject to a rigorous due diligence process. 

We were able to build simple formal models of all these definitions of customer. Later, we were able to show, based on attributes, properties, and types of accounts, how they were related to one another. By enabling the inherent capabilities in a semantic Ontology, the model could infer a given person or business into one of the many customer categories. As  in “real life”, one person can simultaneously be considered a customer in many ways. 

A set of Venn diagrams were built by our team to show how these sets visually overlapped and what that meant for their effort to unify their platform.