Michael Atkin

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. 

S&P Platts: Data Aggregation 

The commodity world has its own way of carving the world into manageable regions. We are accustomed to thinking that counties are in states, states in countries and countries in continents. Even that has its exceptions. In the world of commodities (natural gas versus sugar beets, versus solar power), this is the case.  

Furthermore, each industry that divides up the world is often at odds with the way politics has carved up the world. Oil comes from some of the strangest places, such as the North  Sea, which rarely shows up in ISO descriptions of geo regions. Additionally, different commodities carve up the world mostly based on how easy it is to move products around.  So, oil thinks the Mediterranean is a region, and is not bothered by the fact that Libya, Italy,  and Israel are in three different continents. They consider them to be in the same region  (and not in the region with Nigeria, Germany, and Kazakhstan even though each of those share a continent with at least one of the Mediterranean countries. 

The problem becomes more acute when you realize there are cross over points and opportunities for arbitrage. For instance, power can be made from oil, or natural gas (or hydro or wind or solar) and yet each of these commodities has divided up the world in ways that make it hard to do cross commodity comparison. 

We built a clever way to have the best of both worlds by leveraging the existing Ontology symbol representation. We allow commodity specific rollups but recognize any time two rollups have shared a node. Because this information is stored in a graph it makes it straightforward to combine and aggregate information across commodities in regions that might coincide at some levels but be distinct at others. 

Schneider-Electric Product Catalog 

Schneider-Electric employs 160,000 employees in 140 countries. They make over 1 million industrial scale electric devices. We were retained to help them get more value out of their  product catalog. We built a high-level version of their enterprise ontology to make sure the  

work on the catalog would fit in with other initiatives. We interviewed producers and consumers of the catalog data and extended the enterprise ontology in this area to handle the specifics of complex electrical devices.  

After we had fleshed out the specifics to support all physical and electrical characteristics,  the conformance to electrical standards, and information to support pricing and promotions in 140 countries we loaded all their product data into a knowledge graph. We then ran a query to find out what portion of the ontology was being used to support this domain. Of the 300 or so concepts in the ontology the product catalog was able to be represented in 46 classes and 36 properties. Compare this to the existing product catalog  that had 700 tables and 7000 attributes. This was almost a 100:1 reduction in complexity – yet all the data was present at the required levels of distinction. The power of simplicity further showed up in three subsequent initiatives: 

• eCl@ss alignment – eCl@ss is a product definition standard that many companies use to determine compatible products across a supply chain. eCl@ss is complex, consisting of over 10,000 classes. But having a simple ontology (coupled with a taxonomy that made many of the more fine-grained distinctions) the task of mapping their product catalog to eCl@ss was a matter of a couple of months, rather than years.  

• Clipsal – Schneider acquired an Australian manufacturer of residential electric products.  Clipsal had their own product catalog, and while not as complicated as Schneider’s, was  complex and structured quite differently. We interviewed the Clipsal product data managers, added a few items about aesthetics that were missing from our model and  were able to define all the rest of the complex electrical products in the Clipsal product  with the same 46 classes and 36 properties we modeled for Schneider.  

• Product Compatibility – Electrical product compatibility is very complex and mistakes can burn down buildings and kill people. The existing process necessitated  downloading of the products and all their specifications into large spreadsheets.  Electricians would then work through a very complex set of templates to determine which products were compatible with other products being sold in various countries.  We initially tried to re-create their existing process until we discovered from interviews with product designers the characteristics that made products compatible. Turns out there were just a few dozen rules, most of which could be driven off the data we already had about electrical characteristics. 

• System Enhancements – We added the additional data and wrote the rules. The big win was the system was able to calculate which products were compatible with which others before they were offered for sale in each country, so the decision to offer them could be contemporaneous with their release.  

Each of these use cases demonstrates another way to leverage an elegant data model.  What is perhaps most interesting is these were all emergent, in that the use case arose after the data was designed and loaded. 

Harvard Pilgrim: Canonical Modeling

Harvard Pilgrim is a major healthcare insurance company in New England. We had done some training and high-level design with them. When they began designing their SOA  messages, they asked us to help them select tools to enable this. We prepared requirements unique to their situation, scouted for and found all the products that could help with this. At the time, Message Modeling was not a vendor product category. 

After reviewing the vendors’ purported capabilities, we narrowed the field down to three  and led a “bake off.” We constructed a representative scenario and had each vendor model it and demonstrate the production and maintenance of messages based on it. 

Management Consulting: Privacy 

Every firm has a privacy problem. The advent of regulations such as GDPR and CCPA are bringing this to the forefront. 

Our client has a great reputation for helping their clients with these issues on an advisory basis, but they believe there is a much bigger play in building the starting point of a system that would organize the extent of a clients.  

We built an ontology that can tie specific paragraphs of regulation to specific application systems, databases, and fields to resolve privacy requests at the record level. The secret to being able to do this is draconian simplification of the facets that make up the regulations,  which provides a tractable level that makes it feasible to tie applications, databases, and fields to a small set of categories. 

We worked with their development team who were building a sample dashboard to show how a hypothetical company would organize their response to the GDPR and CCPA  regulations. We loaded the triple store with data from the “real world” regulations themselves as well as synthetic data that was created by anonymizing surveys and profiles taken from existing clients. 

We were able to help them build a prototype of a system that could go into a client,  harvest, and organize their data and cross reference it to the regulations that pertained.  Our collective goal would be to uncover a joint client to implement. 

Sentara Healthcare: Enterprise Ontology

Sentara Healthcare is an integrated healthcare organization, including hospitals, clinics,  home health, assisted living and health insurance. They employ 23,000 people, primarily in  Southern Virginia. We worked with them to build what we believe to be the first integrated ontology for healthcare delivery. 

After building the ontology we worked with them and 3 Round Stones to build a proof of concept mash up for asthmatics. This proof of concept took data from their EMR systems on asthmatic hospital admissions and combined it with data from other sources. The admission data was real, but anonymized. A full roll out would have essentially the same functionality, but would need strict security to ensure that only the patient had access to this data. The mash up brought data from EPA collection sites on detailed composition of the chemicals in the air. The mash up allowed patients to review exactly what was going on with the air in their neighborhood on the day of their admission.

Washington Department of Labor: Web Services

One of the shared services we designed in the Department of Labor & Industries’ long-term  plan was “Web Facing Services.” When it was time to implement this, they asked us to help them define the requirements and select a software product on which to base the service. 

Our original concept featured a service that would consume SOA messages off their message bus and compose them into a browser. This was essentially the design of a mash-up service, long before the term had been coined. We created a set of requirements and helped them select and configure the Plumtree product (which was essentially a portal product) to do what we intended.

Washington Department of Labor: Security

The Department of Labor & Industries, like most organizations, has implemented security separately for each of its applications. The more applications you get, the more  redundancy is introduced, and the more likely it is that you are inconsistently applying the  law and your own internal policy. 

We began this project with an exercise we called the “exegesis.” In this case, it was an exegesis of all the laws, regulations, and policies that applied to data security within the Department. In addition to a lot of reading and excerpting, this required semantic analysis,  as each of the laws had a different aspect. Some of the laws (such as HIPAA) discuss patients’ rights. A special subclass of workers, injured workers who have been treated by medical professionals, are patients under this definition. There were dozens of such nuanced distinctions. 

From this we constructed a set of rules that needed to be implemented in order for the applications to comply. This was also at a time when the State was beginning to open up its system to the general constituency, and therefore the number of users was about to go from 3,000 mostly internal users to up to 3,000,000 total users (workers, employers, and providers in the State). 

We built a set of requirements and brought in all the usual security software suspects. At the time, the business models of these companies did not allow them to separate  Authentication from Authorization (they priced their products based on number of authenticated users). However, the State was mandating the use of its own Authentication service. We found no vendor who could solve the Authorization requirements we had without including a redundant Authentication service. While we were disappointed, one of the analysts on this project was elated. “In the past we would have selected one anyway  and dealt with the fact that couldn’t handle our requirements separately.” 

As a result of our findings, we designed a custom shared security service, which was then let to an implementation company in a competitive bid. In our original design the service would have relied on a rules engine to evaluate the authorization rules. Perhaps because we had done such a good job on the exegesis and significantly reduced the number of rules, the implementation team hard-coded the rules. The service has been in use for over five years; all new applications use it, and existing systems are being retrofitted to it.