Ontology

Ontology is a structured representation of knowledge that includes a taxonomy of categories and their associated entities along with their properties.

The Aisera Gen AI platform ontology helps the virtual agent understand, classify, and respond to user queries more effectively by organizing information hierarchically and semantically. The ontology associated with your agent is a formal representation of a set of concepts within a domain and the relationships between those concepts. This ontology is used to model domain knowledge in a structured and interoperable way, enabling both humans and machines to understand and utilize the data.

View the Ontology for Your Bot

To view the ontology for a specific bot:

1. Choose LLMs > Ontology.

From the Ontology window, you can:

• Change the application or bot you're viewing

• View all Entity Classes

• View Entities by Status (All, Active, or Inactive)

• Add a New Entity

• Add a New Sort Filter

• Edit Entities

• Merge Entities

• Delete Entities

• Import Entities

• Export Entities

Components of Ontology

1. Classes (or Concepts): The primary building blocks of an ontology, representing a group of entities that share common characteristics. For example, in a computer hardware ontology, Computer, Laptop, and Mac are classes.

2. Instances (or Individuals): Specific objects or entities that are members of classes. For example, MacBook Pro 15 and MacBook Air are instances of the class Mac.

3. Properties (or Attributes): Characteristics or features of classes and instances. Properties can be of two types:

   • Datatype Properties: These link individuals to data values (e.g., a Laptop has a screenSize property with a value like 15 inches).

   • Object Properties: These link individuals to other individuals (e.g., a Laptop has a hasKeyboard property that links to a Keyboard class).

4. Relations: Define how classes and instances relate to each other. Common types of relationships include:

   • Hierarchical (is-a): Represents subclass relationships (e.g., Laptop is a subclass of Computer).

   • Associative (part-of): Represents part-whole relationships (e.g., a Keyboard is part of a Laptop).

Based on it's functionality, the ontology can be 1 of 2 types:

1. Global Ontology

• Global ontology for the Aisera Gen Ai platform is built from various sources.

• Global ontology is maintained by Aisera, and categories and entities are added as they become useful for Aisera tenants in various domains such as IT, HR, ITSM, CSM etc.

• The Aisera platform supports a multi-level hierarchical taxonomy.

• Aisera entity zoo entities ( ez_entities ) are migrated into ai_entities through the AI Learning schema, these entities are children of categories in the global taxonomy

• Tenant Functionality

  • Global ontology is visible to all tenants

  • Tenants can not alter global taxonomy or ontology, but can add new entitiies and augment categories under the nodes in the taxonomy tree.

  • Tenant can import into local ontologies

• Any alterations of global ontology are immediately visible to all tenants

1. Local Ontology

• Local ontology is built using local taxonomy + tenant local entities

• The example below shows global ontology and then modified local ontology

Ontology Data Import

The Aisera Ontology has a complex but powerful format because it supports entities, categories and multi level hierarchy of entity categories.

Before we create the file for several categories and entities, it is important to understand the terms Entity Class and Entity Category. From a UI perspective, the Entity Class is a term that includes both class_name and category_name. Where ever you see the word entity_class or class_name that refers to the original definition of an Aisera entity 'zoo class'. Zoo Class is the term for Aisera default ontology classes. An Entity Category refers to the classification or categorization of the entities.

Entity classes should be used very sparingly. An entity class definition defines the attributes OR properties for the class. For example, entity class Building can have properties like Name, Square Feet, and Location. Another example is, Conference Room , a conference room entity must be defined with room capacity, whether it has a projector, and whether is has whiteboard. You can create a new class or sub-class for Conference Room, or you can use the class Building. Another very common example is Application. All software applications can use the attributes Name, Version, and Platform where the platform is Mac/Windows/Linux. This class can be used for millions of software applications. You don’t need to create new class for each set of applications categorized by their function. Categories are the objects that classify the entities of a certain class. When you group the software applications Commerce, Customer Service, Development, andERP, you are classifying the nature or function of the application. But you may not need any addition attributes to define the software application outside the class Application. A specific entity class can have thousands of categories.

Tenant ontology is application specific, so export APIs need your bot id as one of the input parameters.

Description of format:

• Note that the separator currently defined for this format is : avoid include : in the values of the columns.

• The order of definition matters. Define all Categories and Sub-Categories for the Entities first. Entities definitions come last.

• Category definition should start from the root. Define the root category first, then the next level .. then the next. The ontology should follow top-down order in the hierarchy.

• Define all Categories first through parent-child relationships and lastly define Entities, with parent category name along with class names.

An Ontology import is not integrated into the REST endpoint, but the file can be loaded into the specified tenant from the command-line operation from job-server. Copy the ontology file on the job-server pod in to the home directory, that will be /opt/aisera/bin. Run the following command to upload the file.

Each Ontology is application specific. So we need the bot id in the import API command:

#./migration-tool -Ooperation=import -OtenantId=ai_test1 -ObotId=<botid> -OfilePath=<csv file> -OlookupGlobal=false

Ontology Discovery

The following examples will outline some of the steps to run the Ontology Discovery job using the Aisera Administration application (Aisera Admin UI).

Brief overview of business logic

1. This model is capable of identifying both Entities and Synonyms.

2. It discovers entities from KB article titles. The model validates these on KB article content, but net new entities are only discovered from titles.

3. Synonyms are discovered from KB titles, content, ticket title, and description (using all possible sources).

4. It excludes entities which are already present in the app from where we are triggering the job

Pre-requisites

1. Ensure you have a valid KB Data Source set up

2. Ensure you have a valid Ticket Data Source set up

3. Ensure KGNER is trained against the latest local ontology for your specific bot.

Steps to run the code

1. The code can be found under Settings → System Jobs → Generic Jobs → New Job → Ontology Discovery

1. Choose Ontology Discovery as the Job Type from the pull-down list.

1. Fill in the config as necessary. If you have multiple KB Data Sources or Ticket Data Sources, enter them in a comma separated fashion, like 9,12,14.

NOTE: Do not use any spaces between the numbers or commas The last option in the Config is to discover Error Messages or error codes. For customers like VMWare, the KB titles have certain error messages in them, like “Command not found”. If the tenant has KBs with embedded error messages like this, set the discover-error-codes-messages field to True, otherwise leave it at False.

Below is a sample config:

1. The final results will show up in the ontology under a class called Generated. All entities under this class will be inactive. Internal teams should review these results and activate the entities once done.

Ontology Discovery is comprised of two main components, Entity discovery and Synonym discovery

Entity Discovery

• Entities will only be discovered from KB article titles at this stage.

• This process leverages noun chunks in the KB article title to extract potential entities since most entities are either Proper or Common Nouns

• We also apply some post-processing to clean up the entities such as:

  • Removing determinants in the entity name

  • If it is a single word entity, it has to be a Proper Noun

  • Removing stopwords from entities

  • Getting rid of additional allowspaces (whitespaces)

  • De-duplicating the candidate entities

Synonym Discovery

• The Aisera Gen AI platform leverages tickets and conversations to extract potential synonyms, since these are created by end-users. This allows the platform to expand the ontology coverage to cover as many synonyms as possible

• Synonym discovery detects base entities from two sources:

  • Entities present in the existing ontology

  • Entities identified by the Entity Discovery job

• Using these entities as a base, the Aisera Gen AI platform applies heuristics on top of these to extract entities from tickets

• For each base entity, the Aisera Gen AI platform generates candidate synonyms using the following steps:

  • Entities that have more than 2 words and less than 6 (this is to avoid super long entities from being considered such as error messages) are shortened using the first letter from each word, for example, Amazon Web Services will be shortened to AWS, Zscaler Client Connector will be reduced to ZCC.

  • Entities are sorted by variant forms of the same word (lemmatized) and their plural forms are also appended to the list of candidates

  • The Aisera platform then determines the permutations of entity names that are greater than 1 word and less than 6 words. For example, the Aisera Gen AI platform designates Amazon Services Web, Web Amazon Services, and other similar word groupings as candidate synonyms. (NOTE: These are just candidates at this stage. The platform will only determine that they are valid synonyms if they appear in Tickets. This allows for a high level of precision.)

  • In the final step, the platform scans for overlapping entities and substitutes the synonyms for overlapping entities. For example, if there are 2 entities: Zscaler Client Connector and Zscaler Client Connector Portal, Zscaler Client Connector is the overlapping entity. The Aisera platform substitutes the synonyms of the former into the latter. In other words, Zscaler Client Connector Portal would have a candidate synonym like ZCC Portal.

• Once all candidate synonyms are generated for an entity, the platform scans tickets to determine the frequency of these candidates. If the frequency is above a threshold, the platform recognizes it as a valid synonym.

Based on these 2 approaches, the platform generates potential entities and synonyms, that you can review manually and approve for use by the system.

Generating an Ontology from KB Articles

You can generate an ontology from the Knowledge Base Articles that you have ingested as data into your Aisera tenant, after adding a Data Source to your application/bot.

You can generate domain-specific Ontology Entities from specific data sources (the body text of documents in private KB Articles) as well as Synonyms (synonymous terms) for these Entities.

There are two scenarios for generating Ontologies:

1. You have created an application/bot that is not associated with the IT, CS, or HR Domains.

2. You have created an application/bot and chosen an IT, CS, or HR Domain during the creation process. In this case, your bot is using a default ontology from the specified domain.

In either use case, the process for running an Ontology Generation job is the same.

To Generate an Ontology from KB Articles:

1. Navigate to the LLMs > Ontology menu item in the Aisera Admin UI.

1. Choose the + New button at the top of the window.

1. Select Ontology Generation.

1. Create a Name for your Ontology Generation Job and specify the Data Source. Enter both the Domain (if you didn’t choose one when creating your bot), and a Description of the Use Case(s) for your application/bot in the Use Cases field.

1. Click the OK button. Now you will see a Success message that tells you the Ontology Generation Job has begun.

   
2. Click View Jobs within the Success message to see the job status.

3. When the job is complete, return to the LLMs > Ontology page and toggle the Review Mode switch to the ON position.

   
4. Now you can see the new Entities and their associated Synonyms at the top of the page. On each line of the results, choose the Green (left) dot to Accept the new Entity, choose the Red (right) dot to Reject the new Entity, or choose the pencil icon to Edit the new Entity.