The Whiteboard

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.

Washington Department of Labor: Referral Tracking 

We were retained by the Washington Department of Labor & Industries to determine if it  was feasible to design and build an “Enterprise Referral Tracking System.” One of the first challenges was to figure out what constituted a referral. After a few straw man definitions and a lot of polling, we came up with a short list of about 60 different types of referrals,  which were being independently managed in over a dozen major, and about as many minor, systems throughout the agency. 

The agency already has a great deal of expertise in this particular functionality. Of the dozen or so systems described above with referral tracking functionality built in, three  (RTS1, RST2 and RTS3) were explicitly aimed at potentially broad-based referral functionality. It had proved harder than it would sound to grow any of these good starting  points into an enterprise-wide system, partly because of best practices and partly because  of agile development.  

The best practices angle was that they had a great deal of experience with traditional application development, where it is far easier to build functionality around local database instances. This has the side effect of causing the system to have an increasingly larger footprint of shared concepts with the rest of the agency to support what was essentially  MDM functionality. The agile problem emerged because inevitably one program had been funded to create the RTS system and their needs were driving other projects throughout the agency. Because there was no guard, any additional functionality that the program needed, if it were at all related to referrals, was added to the scope. Often these additions were an impediment rather than an aid in getting other programs to adopt the system. 

We designed a truly elegant system. The cost of building it was estimated at about 10% of the initially expected cost. As it turns out, the entire project will cost more than that, but  still less than half what they had originally thought because most of the effort is in integrating legacy systems through SOA messaging. Since they have the necessary resources in-house, the incremental costs are far less. 

This was another on-time, on-budget project with a much better outcome than had been anticipated at the outset.

S&P Platts: Identity Resolution 

If you turn on the news and hear that Brent Crude is trading at $19 a barrel (did it really get to $19 dollars? Yes, it did, we’re living in strange times), it’s very likely that it was Platts that determined this price. Platts are in the “price assessment” business. If you need to strike a contract for an amount of a particular commodity to be delivered at a particular place at  

some time in the future, you need a neutral third-party arbiter to price that commodity.  That would be Platts. 

Over the years, they have amassed a library of 300,000 of these “symbols” of specific combinations of commodity, grade, location, terms, etc. It was the belief that the metadata within these symbols would unambiguously identify a symbol. 

We loaded all the symbols and all the metadata into a knowledge graph and discovered  with simple graph analytics that about a third of them were ambiguous. By leveraging knowledge graph capabilities, our consultants are improving data quality symbol representation to disambiguating metadata for all the ambiguous symbols. 

The other thing we learned in the process is that there are about a dozen different “kinds”  of symbols. Not different in the way that coal is different from natural gas (although there  are differences there), but different in the way that a symbol in a different unit of measure  or currency is different from its base, and the futures are different, which spreads even more differences. 

We are working with them to create a symbol management system that recognizes these differences and can create and edit symbols that are unambiguous and conform.

Proctor & Gamble 

Research & Development 

Procter & Gamble have over 10,000 people working in Research & Development. They believe that innovations in one part of the organization might offer inspiration to researchers in another part but communicating that is a challenge. The main challenge is that these researchers are in a great many domains, each of which literally has its own language. In addition, many researchers are approaching retirement age and there is a fear that the firm will lose a great deal of its intellectual capital. 

As part of this project, we worked with two groups of retiring scientists. Part of this work was to develop methods for eliciting knowledge and part was to find where useful knowledge was stored, how it was organized and how it might be accessed. We built an ontology to cover all of R&D with a minimal amount of information specific to any one R&D function. One of the key aspects of the ontology was its modularity. Fewer than 500 concepts covered all of R&D, and each discipline can extend the core with its own specialized nomenclature. 

Subsequently, the client turned the ontology into a semantic wiki and extended the core ontology to cover two other disciplines. 

Materials Management 

We worked with P&G to build an ontology for their Materials Management functions. This project showcased extensibility, one of the great aspects of semantic design. We started  the project with their Product Safety and Regulatory departments, but the project then  spread to all Materials Management functions. 

We built the ontology which has now become the basis for a project to replace many of their existing systems with one semantic-driven system.