Ontology Models and Inheritance
Intended audience: END-USERS ANALYSTS DEVELOPERS ADMINISTRATORS
AO Platform: 4.3
Overview
When configuring an Ontology there are a few core models to consider if you are a solution developer:
Creating a single ontology - this is the common way where an ontology is created to support a single organization.
Creating multiple ontologies - this is the model recommended for implementation teams where repeatability and productivity are critical, using a “parent-child” relationship allowing for inheritance to avoid duplications, - and improving the manageability of ontologies when dealing with multiple organizations.
AO Common Ontology - this ontology included in the AO Platform is considered a system-level ontology and is generally used to support MSO Property configurations by providing consistent definitions and data structures for common properties, such as address, date/time, amount, document, etc…
Creating a Solution from a Single Ontology
If the task is to create an ontology as the data structure for a single organization in support of an Easy Answers solution, then simply create the ontology representing the domain of the organization. The domain is typically either “vertical” or “horizontal” in nature.
Vertical - this is a generic way of describing all functions of an organization in an industry or sector, such as Utility, Telecom, Healthcare, Finance, Transportation, Retail, Manufacturing, Education, etc…
Horizontal - this is a generic way of describing a specific, typical second-level function of an organization, such as Legal, Procurement, HR, Operations, etc…
The Easy Answers solution will be associated with the ontology and all data and enrichments will be retrieved from and associated with this single ontology.
Creating a Solution from an Ontology with One or More Referenced Ontologies
In contrast to the Single Ontology model described above, there are significant benefits to an implementation team using the referenced ontologies model if the goal is to create solutions for different organizations that have a common domain structure, yet also feature some unique data and/or enrichment requirements.
The benefits include:
A shared parent or base ontology can be created that will cover the majority of the data structure and enrichment for all organizations with a common domain structure, eg. a Utility ontology.
Other supplemental and often generic ontologies can be created and shared by multiple organizations, eg. a Weather ontology.
Maintenance will be lowered for common functionality and enrichment.
Company-specific ontologies can be extended as required.
MSOs, Insights, and Public Dashboards… can be inherited from a parent/base ontology.
Data Sources can be remapped as required.
Ontologies can be cloned easily avoiding starting from scratch for each organization. See Saving Ontology As.
Solutions can be cloned easily. See Solution - Options Menu.
Such parent/base and supplemental ontologies can be referenced by the company-specific ontologies (see Ontology - Referenced Ontologies, - think 80-20 rule. 80% of the data structure and enrichment can be done in a single parent/base ontology, and the 20% unique and specific to a given organization will be done in the company-specific ontology.
AO Common Ontology
The AO Common Ontology included in the AO Platform is considered a system-level ontology. It’s not required to add the AO Common Ontology as a Referenced Ontology. See Ontology - Referenced Ontologies.
MSOs available in the AO Common Ontology can be considered more as “utility” MSOs linked to by regular MSOs in a company-specific ontology. For instance, to ensure that all customer addresses, vendor addresses, asset locations, etc… are presented in a common data structure, simply create a property in each of the Customer, Vendor, and Asset MSOs called eg. Address, - and connect this property with the Address MSO from the AO Common Ontology, then map the data source columns with the address information to the Address MSOs properties.
A similar approach can be used with many other “data type” MSOs from the AO Common Ontology, such as Amount, Date, Time, Organization, Audit, Document, etc…
Inheritance from Referenced Ontologies
The prerequisites for using Inheritance between different Ontologies is to have at least one parent/base ontology and one child (customer-specific) ontology, configured as per the Ontology - Referenced Ontologies page.
The following sections describe where different objects can be configured relative to either a parent/base ontology or in a child ontology, and some recommendations.
MSO > Properties
The main page that shows the outcome of an MSO having inherited configurations from a parent/base ontology is the MSO Properties page in the child ontology. By enabling the Parent toggle icon in the header of the properties list, those properties that have been configured in the parent/base ontology will also be shown on the list.
MSO > Linguistics
BoW & Synonyms – can be created in both base and child ontologies. Configurations are additive which means that no matter where the BoW and Synonyms are configured, they will all be available in the customer-specific ontology.
Value Synonyms & Rule Synonyms – shall generally only be configured in child ontologies as these synonyms relates to data, and data is customer-specific (in sourcing). That said, some specific use cases exist where common masterdata can be configured in base ontology in case such masterdata is shared amongst multiple customer-specific projects. If both base and child ontology configurations exist, they are additive.
Curation – it’s recommended to configure as many as possible in the base ontology and only the unique customer-specific curations should be configured in the child ontology. Configurations are additive.
Traits – it’s recommended to configure as many as possible in the base ontology and only the unique customer-specific curations should be configured in the child ontology. Configurations are additive.
Curation Words – it’s recommended to configure as many as possible in the base ontology and only the unique customer-specific curations should be configured in the child ontology. Configurations are additive.
Trait Words – it’s recommended to configure as many as possible in the base ontology and only the unique customer-specific curations should be configured in the child ontology. Configurations are additive.
MSO > Settings > Default Criteria
Default Criteria - if a default criteria is configured for child ontology, then it will override any default criteria from base ontology.
MSO > Settings > Easy Answers
Parent MSO Views - this section allows the user to enable two specific properties. Also see Easy Answers > Parent MSO Views.
Apply Parent MSO Traits - if enabled, a Parent MSO Trait will be used in a child ontology in responses to Easy Answers questions.
Show Parent MSO Curation Views - if enabled, will include Parent MSO Curations MSOs in responses to Easy Answers questions.
Other Settings across all Easy Answers sections (eg. General, App View, Detail Views, Graph Views, etc…) – same as the Default Criteria above, but be careful not to change any child ontology Easy Answers Settings if any base ontology Easy Answers Settings have been configured and are intended to be used. Once a child ontology Easy Answrs Settings have been configured, then all child ontology Easy Answers Settings will be used and no base ontology Easy Answers Settings will be considered. If making changes, we recommend only configuring Easy Answers Settings in child ontology.
Ontology > Settings > Text2SQL
Use LLM Content from Parent MSO – the following options are available for this property and will be considered when the user selects to Generate LLM Content in the Ontology Options menu > Advanced submenu (or in the MSO Options menu > Advanced submenu). This should be done in the child ontology.
Copy - all LLM Content from base ontology is copied to the child ontology.
Ignore - recommended - no LLM Content from base ontology is copied to the child ontology. This is the recommended option as LLM Descriptions will take into considerations data values that come from generated Statistics and as Statistics is customer-data-specific (from sourcing), ignoring LLM Content from base ontology is the best way forward to ensure LLM Content is generated from the customer-specific ontology and data.
Use - this option will use a combination of LLM Content from both base and child ontologies. Only very special use cases can use this, so generally not recommended.
The following Ontology > LLM Content configurations will depend on the above Use LLM Content from Parent MSO configuration!
LLM Descriptions & Priority
Prompts
Quick Insights
The prerequisites for using Inheritance for Quick Insights is to have at least one parent/base ontology and one child (customer-specific) ontology, configured as per the Ontology - Referenced Ontologies page - on the Quick Insights tab. The objective is the same as for the Referenced Ontology objects to be able to share common Quick Insights across multiple customer-specific projects. This saves time, ensures consistency, and reducing manual efforts.
Any and all Quick Insights configurations can be done in parent/base ontology as per normal workflow. See Editing an Insight.
In the child ontology, the configurations for inheriting Quick Insights from a parent/base ontology are done in the Ontology Composer > Referenced Ontologies on the Quick Insights tab. See Ontology - Referenced Ontologies | Quick-Insights.
The focus when configuring the child ontology is on which Quick Insights to inherit from the parent/base ontology, and the user Roles to be used.
Include all Quick Insights - on/off toggle - if enabled, all Quick Insights are inherited from parent/base ontology. If disabled, the user can select the individual Quick Insights to be inherited.
Roles - use the dropdown and selection options to select Roles just like when adding Runtime Profiles for Quick Insights in the Insights Composer.
Secondly, when a Quick Insight is scheduled for automatic generation, a checkbox is available on the Settings tab to Run Insights for All Referenced Ontologies. Check the checkbox for the Quick Insight in the parent/base ontology to keep both parent/base and child Quick Insights up-to-date based on the configured schedule. The Roles specified at parent/base ontology will be used across all connected ontologies.
Inheritance from Referenced Solutions
Similar to the option for Referenced Ontologies in the Ontology Composer, Solutions in the Solution Composer also has a page for Referenced Solutions. The objective is the same, ie a parent/base solution can contain common solution elements, such as Public Dashboards, which in turn can be referenced by child (customer-specific) solutions. When this is done, a customer specific Easy Answers solution will have a new dashboard section shown for the referenced Public Dashboards all of which have view-only permissions. Any Filters created in the customer specific solution will be private to the user, whereas the referenced Public Dashboard will be view-only.
See Editing a Solution | Referenced-Solutions for configuration details.