Ontology

The Ontology module of the Aisera platform is designed to help the Virtual Agent understand, classify, and respond to user queries more effectively by explicitly adding semantic structure to Domain knowledge. The Ontology associated with your Agent is a representation of a set of Entities (concepts) within a Domain and the relationships between those Entities. This Ontology is used to model Domain knowledge in an interoperable way enabling both humans and machines to understand and utilize the data.

View the Ontology for Your Application/Bot

To view the Ontology for a specific bot:

1. Choose LLMs > Ontology.

From the Ontology window, you can:

• Change the application/bot you're viewing

• View all Entity Classes in the left panel

• View all Entities by Status (All, Active, or Inactive) in the right panel

• 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

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 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 a Domain (e.g., IT, HR).

2. You have created an application/bot and chosen an available Domain during the creation process. In this case, your bot is using a default Ontology for 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 unique Name for your Ontology Generation Job and specify the Data Source. Enter a description of the Use Case(s) for your application/bot in the Use Cases field. In the Use Cases description you should provide basic information about the Domain of your application/bot, the customer profile including products and services relevant to the application/bot as well as (example) key topics as reflected in the selected Data Source (KB Articles).

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 at the top of the page. The Status of the generated Entities is by default set to Inactive as these Entities need to be reviewed and approved for use by the system. On each line of the results, choose the Approve button to approve the new Entity, choose the Reject button to reject the new Entity, or choose the Pencil icon to edit the new Entity. Once an Entity is approved its Status is set to Published. When you toggle the Review Mode switch to the OFF position all approved Entities will be visible in the Ontology of your application/bot.

5. Once you have reviewed the generated Ontology ensure kgner is trained against the latest Ontology in your application/bot. Navigate to Settings → System Jobs. Locate kgner in the Models Tab and click on the Edit Job button.

In the Edit Model Job pop-up add the bot_id under Input Config and press OK.

Click on the Play button to train kgner for the new Ontology to be used by the system.