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 Global Commodity Insights (formerly known as Platts) provides benchmark price assessments for the physical commodities markets. As we have noted before, if you hear  on the news that Brent Crude is trading at $100 a barrel, it’s likely that S&P Global  determined this price. 

The price of a given commodity – be it coal, crude oil, or steel – depends on several factors,  and in large part it depends on the commodity’s chemical characteristics. Crude oil, for  example, comes in a variety of “grades.” A quick look at this periodic table of crude oil grades will give a sense of how much variety there really is. If you hover around and click on some of the boxes, you will see that each crude oil grade is associated with a technical specification related to characteristics like sulfur concentration and API Gravity. These characteristics determine whether crude oil is “sweet” or “sour” (depending on its sulfur concentration) and whether it is “heavy” or “light” (depending on its API Gravity). 

While crude oils have other characteristics, the market has determined sulfur concentration and API Gravity to be the most important for the purposes of price assessments. The same thing holds for other types of commodities—there are “key market characteristics” for any commodity that will be important for pricing purposes. 

While this knowledge about commodities is commonplace at S&P, pinning down the  precise meaning of “commodity grade” turned out to be a significant challenge internally to  define. This is one place where Semantic Arts was able to provide value. We identified and analyzed the various concepts underpinning the idea of a commodity and produced a clear definition. 

One might think of a commodity grade as a “leaf” in the hierarchy of commodity types.  Crude oil is the general type, while the Saharan Blend is a specific grade at the bottom of the hierarchy. This is a good first pass definition, but it fails to get at the essence of what a commodity grade really is. 

To make headway in clarifying the definition, our strategy was to learn from subject matter experts about how the concept is used in practice. A key question was: When people talk  about commodity grades at S&P, what are they truly talking about? 

It turns out that whatever else people might mean by a commodity grade, it always includes the specification having features that the market cares about. Additionally, it is specific enough to be priced in the marketplace (by S&P or anyone else). With the hindsight of this analysis, we were able to create a clear and formal definition of the concept of a commodity grade using semantic standards (W3C) to express. 

This was the first step. It provided the basis for deeper data quality checks. This becomes critical to Commodity Insights; whereby S&P’s core business is selling accurate data under constantly changing conditions. 

The second step was to create a means for validating S&P’s data that commodity grades had specifications for the relevant key market characteristics. For example, any crude oil  grade should have a specification indicating an acceptable range of sulfur concentration.  To achieve this, we developed a solution using SPARQL & SHACL that returned validation  

reports to indicate which grades might be missing specifications for certain characteristics.  This semantic method proved significantly more efficient than using Excel spreadsheets,  manual entry (mistake prone) processes. 

While we used crude oil as an example to illustrate this idea, the framework we developed can be applied to all commodities. Most importantly, it instilled automation, data interoperability and consistent meaning across multiple teams that previously interpreted commodity grade with a different lens. The solution offers easier value change implementation saving countless man hours in aggregating spreadsheets with greater data integrity and traceability. 

There were a few important takeaways. First, it can take years of working on a project to  determine what something means with confidence. Delivering a semantic layer brings data reusability and data centric principles is solving a core challenge of dissolving data silos. 

Second, it’s possible to live with an unclear definition but once you’ve cracked the semantic code puzzle across the enterprise … efficiency and accuracy of knowledge reaches new realization. A tangible benefit of being confident by knowing exactly what something means is that problems arising due to the persistence of ambiguity will be a thing of the past. It’s  now built into the standard S&P operating procedures inherently with a data-centric,  semantic driving solution. 

With a successful 200-year track record in developing extensive and diverse product lines by leveraging chemistry and science, this global innovator was embarking on a new era of discovery to shape a better world. 

Categorization of products and the relationships between those named entities were difficult to describe in traditional taxonomies and “systems of systems”. Over the course of  2 centuries massive amounts of complex information had been arrogated, however it didn’t give a full picture. The patterns of data intersection for decision-making were lost within the siloed systems. For greater predictable business insights based not only on structured data but unstructured documents the need for easier access and interoperability was a primary goal. 

A CoE (Center of Excellence) was formed to accelerate R&D development, analytics and  finding of data to advance innovation with greater speed and reliability. A secondary mission was to socialize this capability to the broader community. Ontology development and tools to harmonize information were a foundational part of this data enrichment strategy, but in-house skills and data-centric modeling expertise were insufficient. It was necessary to develop as a core competency. 

Semantic Arts consultants were engaged to bridge this critical ontology and semantic capabilities gap. Our strategic advisory service offering brought over 25 years of practical implementation learnings and educational workshops to deliver a series of focused topics that met broad expectations of a teaching library. Recorded videos are now available on  the company’s enterprise intranet to traverse the complexities of information silos by enabling knowledge graphs, ontologies, and data-centric thinking. 

Topics include – Introducing Semantic Technologies and Ontologies, Introduction to OWL,  Introduction and Hands-on with Protégé and Property Rules, Understanding Class Relationships,  Expressions, and Property Restrictions, Semantic Triple Visualizations, Ontology vs. Taxonomy,  Topic Extraction and Weak Signals, and UI Visualization with Knowledge Graphs 

In parallel Semantic Arts are engaged with a division focused more on enriching and unifying 19 different data repositories into an ontology. The goal is to model relationships between the concepts, substances, and components for describing the products in a disambiguous manner to eliminate data duplication, increase metadata clarity, and eventually incorporate ML and NLP capabilities. We’re collaborating with the client to structure a roadmap for implementation. A projected iterative, agile approach by using our  predictable (rinse and repeat), Think Big / Start Small methodology will be employed to  guide and instruct in this digital evolution.

This effort to interconnect information assets for discovery complements and aligns with the broader digital transformational for bringing “miracles of science” to realization.

On a previous project we worked with Sallie Mae to build an enterprise ontology for their loan business. After the ontology was complete, they decided to outsource a new line of loans to a third-party SaaS vendor. Shortly after making that decision, they realized that the new system would have completely different screens, and completely different messages and APIs from their existing systems. 

Their existing loan servicing systems had, collectively, about 50,000 attributes. The enterprise ontology we had previously designed had 1,500 concepts. They decided to use their ontology as a unifying principle to conform the old and new messages such that their customer-facing systems would not look schizophrenic. They had mature service-oriented  architecture but had not done much to unify or rationalize their messages. 

We helped them select the DXSI toolkit from Progress Software. We created a set of programs that converted the ontology into a form that DXSI could consume. (There were  many issues around translating multiple inheritance to single and converting many fully expressed notions from the ontology into flatter representations.) 

Much of our work for the remainder of this project involved discovering at a very specific level of detail: exactly what each of the fields in each of the new system’s messages actually meant. In many cases this required extensions to the original ontology, but for the most part the extensions were consistent with the original design. In the end we extended the enterprise ontology by only about 10%. 

The new system was implemented on time with a set of conformed messages that allowed a single presentation to the customer.

We were retained by the leading provider of Student Loans to build an enterprise ontology. 

We conducted over a dozen workshops and facilitated brainstorming sessions and many  dozen more one-on-one interviews, and reviewed reams of documentation. In the end we built an Ontology that represented the complexity of their business in just over 1,000 concepts, including classes and properties. This is a dramatic reduction in complexity from the data models of the systems being used to run their business which have far in excess of 50,000 tables and attributes. 

The value of this reduction in complexity is a great strategic asset. Going forward, it means that new systems built to conform to the shared model will automatically be in conformance with each other. Integrating existing systems to each other can be done through the lens of the shared ontology, which, besides being much simpler, has the benefit of not being tied to legacy concepts. This truly is building a data bridge to the future. 

One of the open questions with something as broad as an enterprise ontology is: does it really cover the breadth of the organization and does it have sufficiently granular data to represent all the details that are involved with the many applications that it represents?  Our original test case was to be a document management system that was being implemented in parallel with our Ontology. The idea was that if the tags that were going to  be implemented in document management were aligned with the concepts in the ontology  that primarily described data in the structured systems, it would then be possible to  achieve one of the holy grails in this business: the integration of structured and  unstructured data. 

Unfortunately, the document management project was cancelled before we could test the  theory, but as we describe in another use case, another project came along and provided a  different use case: use the enterprise ontology as the basis for alignment of SOA messages  between legacy systems and a newly outsourced service. 

As we describe in the SOA case study, we were able to use the enterprise ontology to drive down to field-level detail for the SOA messages. It required about a 20% increase in the core ontology (mostly in creating a bit more detail for specific financial transaction codes and the like) and we added two other lower-level ontologies, one specifically for mapping to the legacy systems, and one to help describe concepts that only occur in the SOA layer  (message headers and the like).

Semantic Arts worked with PwC to improve Verizon’s data privacy capabilities. 

Prior to the engagement, as applications evolved many of the process steps required to stay in compliance with privacy regulations and policies were performed manually using  multiple data sources. Our goal was to provide a knowledge graph as a single source of privacy metadata (information about data classified as private). 

Early in the engagement, we identified the key components of the data privacy landscape,  summarized in this diagram: 

The data set loaded into the knowledge graph identifies which applications and third parties are involved in each kind of privacy data processing: data collection, analysis,  modification, transfer, storage, etc. 

We modeled most of the privacy concerns implied by the diagram, including: legal rights of  a data subject, agreements with third parties, details of data processing relevant to privacy  concerns, data lineage, data retention, data catalogs, impact assessments, privacy-related  processes and tasks 

We also created an extensive taxonomy that allowed key distinctions to be made while the core model remained simple and straight-forward. Finally, we created generic configurable queries to perform a range of data validations. 

The result is a consolidated view of data from multiple sources that allows greatly improved management of application compliance with privacy data policies and regulations.

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).

Investment Bank Risk and Controls

We worked with a large investment bank who are embarking on a series of projects to further automate their back office. One of their first tasks was to understand in greater detail what all the 5,000 people in the back office were doing. They built an “Economic Architecture” that was essentially the equivalent of a continually running Activity Based Costing project. They asked managers to estimate the percentage of time each of their reports spent on a standard list of activities. However, the activity list was not stabilizing, and many managers had difficulty deciding which of the many activities they should use. As this was slated to eventually become part of the reporting and perhaps eventually the charge back to the front office for the activities performed to settle some of these very complex instruments.

We were called in to create a rational basis for the activity taxonomy. We ended up decomposing the working list of 800 or so activities into a set of orthogonal facets. What was fascinating was that the facets were far, far simpler than the long complex list of activities. Once someone knew the facets (such as financial product, market, as well as a simple set of verbs and modifiers) they would know what all the activities were, as they were just concatenations of the facets. More interestingly we discovered as we performed this that the facets provided a level of categorization that it would be possible to instrument in the workflow and source systems. (The list of 800 activities were too arbitrary to allow for automation, but he facets were closely aligned with primitive concepts found in most systems).

We completed the redefinition and got agreement on the new activities. The new activities are in production, and they are looking at applying this concept beyond the back office operations.

Email: [email protected]
Phone: (970) 490-2224

Investment Bank: Economic Architecture

We worked with a large investment bank who are embarking on a series of projects to further automate their back office. One of their first tasks was to understand in greater detail what all the 5,000 people in the back office were doing. They built an “Economic  Architecture” that was essentially the equivalent of a continually running Activity Based  Costing project.  

They asked managers to estimate the percentage of time each of their reports spent on a standard list of activities. However the activity list was not stabilizing, and many managers  had difficulty deciding which of the many activities they should use. As this was slated to  eventually become part of the reporting and perhaps eventually the charge back to the  front office for the activities performed to settle some of these very complex instruments. 

We were called in to create a rational basis for the activity taxonomy. We ended up  decomposing the working list of 800 or so activities into a set of orthogonal facets. What was fascinating was that the facets were far simpler than the long complex list of activities.  Once someone knew the facets (such as financial product, market, as well as a simple set of verbs and modifiers), they would know what all the activities were, as they were just concatenations of the facets.  

More interestingly we discovered as we performed this that the facets provided a level of categorization that it would be possible to instrument in the workflow and source systems.  The list of 800 activities was too arbitrary to allow for automation, but the facets were closely aligned with primitive concepts found in most systems. 

We completed the redefinition and got agreement on the new activities. The new activities are in production, and they are looking at applying this concept beyond the back-office operations.