In this blog our chief architect, Aniket Dalal, explores what an ontology is, how it is relevant in machine learning based enterprise solutions and provides an insight into some helpful tools available for creating one.
SECTION 1: INTRODUCTION TO ONTOLOGY
What exactly is an Ontology anyway?
An ontology is an explicit specification of conceptualization. In other words, it's a formal naming and definition of the types, properties, and interrelationships of the entities that fundamentally exist for a particular domain of discourse. Some of the important objectives of an ontology are representing knowledge, sharing knowledge, and reusing knowledge for semantic inferencing.
Ontologies are represented in terms of nodes with attributes connected to other nodes, which establish a relationship with constraints between them. This simple schema enables describing any domain knowledge in a format consumable by computation devices.
To create a simple example, let’s use “familial relationships” as our domain of discourse. One node will be the original person. That person will have a “father” node, and a “mother” node. They might have sisters, brothers, cousins, aunts, uncles, grandparents. These are all types of relationships that can be captured in an ontology. They might come with additional domain specific information as well – there might be information tied to what a “fatherly” relationship is, or a “sisterly” relationship.
Predii’s domain of discourse is customer service – specifically the repair of equipment. Largely, the most important relationships in our domain are complaint, cause, and correction. These each have their own aspects, such as the equipment, systems, sub-systems, components, sensors, fluids, and more. Another aspect is behavior: normal operation, abnormal operation, failures. The corrections themselves have complexities – labor operations, parts replacements, calibrations and more.
The business use of a repair ontology is to map expected behavior. A poor ontology is generalist. A quality ontology captures the expertise of the domain – for example, this precise symptom is tied to this cause and then tied to a specific resolution. This can be used to process incoming and historical information and empower workers with data-driven prescriptive guidance.
The Right Technology for the Job
An ontology allows for the representation of vastly complex domain knowledge in a structural graphical form. This in turn raises challenges related to creation, management and interpretation. To achieve this, technology has adapted itself by providing frameworks for languages and tools.
Representational Language: Describing and consuming an ontology requires a formal representation. Such a representation can then be used for encoding the concepts in a concrete format. There are several representation standards which have been created to build language syntax and semantics. Some of the popular ontology languages include OWL (developed over RDF & RDFS), DOGMA, and Cyc. There are several other public and proprietary languages developed for specific goals.
Building & Editing an Ontology: Ontologies are used by domain experts for creating a visual representation of a knowledge graph. On the contrary, it can be quite challenging for those who aren’t domain experts to interpret the language of an ontology. To bridge the gap, a variety of ontology building and management tools are available that make this process easy and efficient. Popular ones include Protege, HOZO, and NeOn. These tools provide a simple user-interface that can be used by those who may have little knowledge of ontology language syntax and semantics.
Ontology Visualization: A good ontology would have millions of entities, attributes and relations. An obvious challenge is the ability to visually consume such a large data representation. There are some great ontology visualization tools available which enable searching, traversing, and the portrayal of selective regions. Some useful tools for this are NetworkViz and Protege. There are several custom tools too, developed for specific objectives.
Ontology Processing using AI: An end-goal of ontologies is the ability to be consumed by a computation device that can make sense of it all and use the knowledge graph for interpretation, learning and forecasting. Automated Reasoners are specifically developed for this purpose and they play a vital role in the discovery of complex inferences. Pellet, FaCT++ and ELK are some helpful automated reasoners that can work on axioms written in OWL which facilitate reasoning.
SECTION 2: THE SIGNIFICANCE OF AN ONTOLOGY IN REPAIR INTELLIGENCE
Artificial Intelligence capabilities can be enhanced with a proper ontology. An ontology assists artificial intelligence in process interpretation, content mining, enrichment and semantic disambiguation; it helps lessen complexity and it organizes information.
Repair intelligence refers to a melding of extensive service knowledge with connected sensors and telemetry data to create new insights for repair and maintenance. Repair intelligence is augmented by domain specific ontology to discover and derive inferences of causality between automotive problem codes, vehicle symptoms and corrective labor actions. The simple schematic of such an ontology is represented below:
A Breakdown of the Ontology Schematic for Repair Intelligence
The repair intelligence ontology schematic is multi-layered and consists of sub-ontologies. These ontologies are interconnected to create a meta-ontology which is driven by . The above diagram is color-coded to depict this relationship.
System-Sub-System Ontology: The System ontology compartmentalizes the complexity of the machinery or automobile. The System ontology provides a framework to capture this organizational structure and provides the ability to create a System Sub-System hierarchical relationship of any depth. A system ontology is at the heart of repair intelligence as it drives the symptom and trouble code behavior. It is also the driving force behind the creation of the Component-Labor ontology.
Component-Labor Ontology: The Component-Labor ontology is an extension of the System-Sub-System ontology. The key differentiator between the two is that the Component ontology represents real world entities (components), whereas the System-Sub-System ontology provides logical organizational structure. In the context of repair intelligence, component semantics are always interpreted in conjunction with the labor operation performed (eg. spark plug replaced, wheels balanced etc.). This bipartite association is crucial to the capture of invalid conjunctions like “balancing” “spark plug”. The Component-Labor ontology complements the System ontology because it provides organizational and comprehension capability to repair intelligence.
Symptom Ontology: The Symptom ontology captures observed incidents or events. Therefore, it does not have a simple organizational structure shared by both the Component-Labor and the System Sub-System ontologies. The Symptom ontology is represented in terms of multiple facets. It is anchored to a component, system, or machine/vehicle and has facets such as:
Spatial: under, behind, above, below
Temporal: intermittently, at certain RPM, in the morning
Contextual: when cold, when driving, when stopping
Type: noise, smell, vibration, feel
The Symptom ontology is defined by a complex connection of these attributes. Not all permutations of the links among these nodes have a semantic sense – they must be validated. Symptom ontology discoveries along with System-Sub-System and Component-Labor ontologies help in deriving causality inferences between the problem and the solution.
Trouble Code Ontology: The Trouble Code Ontology is associated with internet of things (IoT) data processing which connects the relationship between various parameter IDs (PIDs) and their connections with diagnostic trouble codes. Similar to the Symptom ontology, the Trouble Code ontology, works with the System-Sub-System and Component-Labor ontologies to help in deriving causality inferences between the problem and the solution.
The significance of an ontology is multifaceted: it provides a backbone for the domain, adds specifications of relationships between entities, and provides a set of inferencing rules and associated actions. A thorough understanding of the objective for developing the ontology and a focus on defining processes for maintaining ontologies is very important if you want to avoid undesired outcomes.
SECTION 3: CHALLENGES IN ONTOLOGY DEVELOPMENT
You will encounter challenges when developing ontologies – this is a guarantee.
Challenges you may face:
Building from Scratch: Ontologies are rare and precious. For most domains, including repair intelligence, public ontologies do not exist. If it is available, the public domain is either not complete or it does not reach the benchmark for quality, or it is modelled to solve problems pertaining to a specific application. In other words, most of the time, ontologies have to be built from scratch with few existing resources to jump-start the process.
Scale & Complexity: Ontologies are massive in scale and can have millions of entities, each with 10s to 100s of attributes. To add to this, there are interconnections among entities, creating a densely intertwined network. With the ever-increasing scale of demands for ontology, the proper technology is needed to efficiently manage and process them.
Quality: Any inconsistencies in ontology have repercussions on inferences drawn by the algorithm using it. As the complexity of ontologies increases, it is very important to maintain precision and consistency within the ontology in order to avoid causing a “spiral of decline.” This in turn demands strict processes for editing, reviewing, and validating ontologies which are being modified concurrently.
Algorithm & Interpretation: There is a lot of hard work done to ensure that the ontology encapsulates domain knowledge, but the only thing that matters in the end is: Does it all make sense? That's why custom algorithms need to be built in order to draw a connection between the data and the domain specific knowledge graph. There is not one single answer to solve all problems that may be associated with developing an ontology. As a result, problem-specific algorithms must be developed, that will use the information encoded in the ontology and enrich the interpretation of the data.
The development of a proper ontology for repair intelligence is significant to the success of the project. There need to be “outcome limits” determined for development of ontology-based technology – that is, once the outcome that suits the business need is reached, the development does not need to proceed into further complexity (because it always can).
That being said, once enterprises begin to deploy products and processes based on a quality ontology, they tend to get addicted! At that point, you might encounter technical debt. This is why it is important to take the time to develop a good strategic road map.
Comments