Schneider Electric is a very large (150,000 employees) manufacturer of industrial electrical components. They operate in 140 countries and manufacture and sell over 1 million products.
We built an ontology of electrical parts. As is our usual starting point, the ontology is a specialization of gist, and we built the beginning of an enterprise ontology for Schneider Electric in order to put the product information in context. The Schneider Electric enterprise ontology consisted of 157 classes and 164 properties.
Electrical product specifications are quite complex. Most parts have dozens to hundreds of physical and electrical properties as well as information on conformance to electrical standards throughout the world. The existing product catalog, which contained all the specifications, as well as information on pricing and availability worldwide, was internally developed and consisted of 700 tables and approximately 7000 columns.
We used the Ultrawrap product from Capsenta to define R2RML maps from the relational database to the ontology. We loaded all the relevant specification, availability and offering information from the existing catalog. The only category of data that we intentionally left behind was the product taxonomy for the website, as we were in the process of building a taxonomy based on electrical function.
What surprised us was when the knowledge graph was fully loaded, the extracts of all the product data populated contained just 46 classes and 36 properties. The first thing that will seem odd, to those steeped in relational design, is how can you have fewer properties than classes? In the semantic world, there is no relational database that has fewer columns than tables. This is an emergent property of semantic design. Properties are reusable, and a good design takes advantage of that capability.
The other thing of note was the existing product catalog system had 7,700 concepts (the 700 tables and each of the 7,000 columns represented a separate column. Every one of those 7,700 concepts had to be learned and mastered to query this system successfully. The knowledge based in the Ontology we created used 82 concepts (46 classes + 36 properties) to cover the same domain. This is nearly a 99% reduction in complexity, with no loss in fidelity or scope. As we demonstrated in the next project, all the information was present and represented all the products, in all the languages, and supported with full specification.
A highly important side benefit of this approach emerged later. They had acquired another firm in Australia that also made electrical components, but mostly focused on the residential market. They, too, had a product catalog. Not nearly as complex as the parent companies’ previous catalog, but still highly complex. By looking at the data ingestion problem with the lens of our ontology, we could see the similarities. And the differences. It turned out the main difference was the need to support aesthetic packages and patterns. In other words, think, interior design. People care about whether you can put an ecru face plate with an ivory receptacle. So, we added some classes to model these aesthetic issues, and loaded the data. It was remarkable how straightforward marrying the data together became.
It was later learned that this integration has been postponed for over 10 years because it was too complex. The task to shoehorn the subsidiary data into the previous catalog would have been costly due to the complexity. By simplifying product representation in an Ontology, the complex migration proved quite do-able by understanding and quickly analyzing those differences and similarities.
