technical terms. They can describe “is-ness” and “about-ness”—this is a contract, it is about a services engagement, it is also about this vendor, for example. Ontologies can also support advanced capabilities to drive intelligent virtual assistants (bots). They can form the basis for inference engines—mechanisms to essentially answer a question that has not been preprogrammed into the bot. Bots powered by ontologies are faster to deploy, more scalable, and more cost-effective. Every aspect of business requires contextualized knowledge. The role of AI is to use the ontology to assist with this contextualization.
Here’s an example scenario. Imagine a bot that answers questions about support problems.2 For this to work, the bot needs to understand “intent”—the thing that the customer is trying to achieve. According to P.V. Kannan’s AI book The Age of Intent, intent is the fundamental concept that drives all intelligent virtual agents. As Kannan defines it, “Intent is a determination of what a customer wants from an interaction with a company.”3 Once an AI determines that, it can supply an appropriate answer.
For example, a customer may not be able to connect a printer to the network. The troubleshooting bot can determine the customer’s intent by first extracting the elements of the problem from the customer statement (called the utterance). “I cannot connect my printer to the network” contains the entity “printer” and “network” and the symptom “cannot connect.” These elements are captured in the ontology along with synonyms and variations such as “unable to connect” or “not connecting.” The intent, which the bot determines from this information, is “fix printer connection problem.” Having determined the intent, the bot can walk the user through steps to solve the problem.
There is also a relationship between the symptom and a solution. The solution may require more information, which the bot can request from the customer. If the customer is logged in, the bot can look up information from the list of equipment they own. With this knowledge, the system can better identify and present the appropriate troubleshooting steps.
Each of these elements and the relationships that associate them form the knowledge graph—that is, a knowledge structure that contains related elements. You may be familiar with graphs of relationships from Facebook, where you may find new friends via different connections and follow those connections to another group of acquaintances based on factors like school, group membership, or interests. The movie database IMDb shows a similar set of graph relationships—you can choose a movie and look up the actors and directors to see which other movies they were in and which other actors they costarred with (useful for the game Six Degrees of Kevin Bacon4). The ontology becomes a knowledge graph for your organization, with the ability to answer a limitless number of questions over time.
How Ontologies and Taxonomies Worked at Applied Materials
In the case of Applied Materials, the taxonomies described every aspect of the chip manufacturing process, including these concepts:
| Account | Geography | Partner | Solution |
| Application | Code | Platform | Status |
| Assembly | Security | Process | Subject |
| User | IP | Equipment | Technology |
| User Interest | Owner | Product | Units of Measure |
| Division | Language | Published To | Substrate |
| Document Type | Business Unit | Region | Sub-assembly |
| Plant | Configuration | Severity |
(Representative list of vocabularies. Concepts and names changed or omitted for confidentiality.)
More than 30 taxonomies described Applied Materials’ world, and each taxonomy had a relationship to others—for example, Platform to Process, Assembly to Product, Partner to Region, Solution to Plant, or Severity to Status. These knowledge relationships could be mapped across content processes, allowing automated “reference librarians”—AI—to suggest resources and answers. These embedded relationships enriched the ontology to create a conceptual representation of a domain of knowledge. Taken together, all these taxonomies and all of their tens of thousands of terms and hundreds of thousands of relationships represent the semiconductor fabrication world: the knowledge domain of semiconductor fabrication equipment and methodologies.
These various organizing systems and vocabularies allowed all 14 different knowledge, content, and data systems to be unified under a semantic layer that translated inconsistent information structures into a common framework. This information architecture (or knowledge architecture) also guided the development of the technicians’ experience: in this case, a search interface that let technicians navigate and retrieve their desired content using their mental model of how they thought about the problem.
This allowed many different types of users with different problems to locate what they needed in the context of their problems. Taxonomies functioned as navigational filters and provided “see also” constructs to guide technicians to their answer. They consolidated multiple information sources from disparate systems using terminology that was mapped through the ontology.
But the ontology did more than organize content and make queries more effective. It allowed the business to use AI approaches to classify content, identify security and IP issues, and automate some aspects of relationships among parts. The same ontology allows for analysis of anomalies, powers predictive maintenance, and identifies reliability issues and field usage patterns. The data it generates feeds upstream design and manufacturing processes to further improve products and innovate in semiconductor manufacturing—and to sustain Applied Materials’ leadership in that space.
To Be a Source of Truth, Ontologies Must Be Comprehensive and Architectural
The ontology becomes a reference point for the organization that provides consistent naming, structures, and standards for applications and new technologies. It becomes a source of truth.
The ontology represents knowledge of the information structures and processes that drive information flows throughout the organization. The ontology is representative of products, services, processes, problems, tasks, intents, interests, user types, roles, content, data types, reference architectures, navigational structures, security classifications, applications, and every other entity, whether virtual or physical, in the enterprise. Any entity that someone interacts with can be part of the ontology.
But it’s not just the elements of the data that count. The ontology reflects the architecture of that data. Data fundamentally has an architecture. It has to. Financial systems have charts of accounts. They have to. Algorithms can do a great deal with messy or missing data, but they must have a reference point containing the labels and information as a basis to find patterns. Pattern matching is inherently about classification, and the ontology forms the core structure for classifications of all sorts. Data dictionaries are part of the ontology; product catalogs are part of the ontology; financial charts of accounts are part of the ontology. The ontology represents the knowledge domain of the enterprise.
Before
