# 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 2. **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`, and`ERP,` 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.


Column Name	Type	Notes
type	Char	Single character defines the type of record, `c` indicates category definition `e` indicates entity definition
parent_name	JSON Array	Name of parent category(s). When the category being defined is at root level, then leave the column empty If this is an “Entity” Define one or more categories for this entity. Such as, `[{“category”: “ABC”}, {“category”: “DEF”}]
id	Number	Id column is optional. Write the id value only if you want to preserve the id of a specific entity or category across the clusters. Use of this field is not recommended
name	String	Name is a common field. This can be the name of an entity when the type is `e` and category when type is `c`.
class	String	Name of the class that the entity OR the category belongs to. `Collaboration Software`, and `Video Conferencing` are categories of software application class `Application`. The entity `Zoom` is software application of class `Application` An entity has a parent category. The Entity and Parent must belong to same entity class.
synonym	String	A list of synonym values separated by a `comma`. This applies to both entity and category.
properties	JSON	This is a free-form JSON field that can be used to define any custom attribute for the entity or category. Currently, we use this for marking the entities as blockListed (blackListed). An example value is: `{"isBlackListed": true}`. If the entity needs to be blocklisted, then this column should be populated as indicated.
domain	String	Domain of the entity or category
disabled	String	Set to `true` if the category or entity needs to be deleted on target
reviewStatus	String	Displays the review status of the entities

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= -OfilePath= -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**. | Entity | A term that is relevant to the domain and customer use case. Generated Entities include: acronyms, nouns, noun phrases. | | -------- | ----------------------------------------------------------------------------------------------------------------------- | | Synonyms | Terms that are used interchangeably in similar language contexts. | \ 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.

Select AI Automation > Ontology in the Aisera Admin UI

2. Choose the **+ New** button at the top of the window.

3. Select **Ontology Generation**. ![](https://support.aisera.com/hc/article_attachments/36681621716365) 4. 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).

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

6. Click **View Jobs** within the Success message to see the job status.
7. When the job is complete, return to the **LLMs > Ontology** page and toggle the **Review Mode** switch to the **ON** position.

8. 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. 9. 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.