What is Ontology? Why should we care about it? How to design a good one?

Ontology Management in Bizomics

In Bizomics, effective ontology management is crucial for contextualizing business information and deriving actionable insights. In the Business Knowledgebase that Bizomics provides, Ontology addresses the Semantic Layer of the Knowledge Graph.

This documentation provides an overview of key concepts and components involved in managing ontologies in Bizomics.

What is Ontology and Its Components

A set of concepts and categories in a subject area or domain that shows their properties and the relations between them. (Oxford Languages)

An ontology is a formal, explicit specification of a shared conceptualization of observed reality…[take a pause, read it again, think, then continue]. In the context of Bizomics, it serves as a structured framework to represent knowledge within a specific domain, enabling data interconnectivity and semantic consistency [hence, having your domain knowledge explicitly documented – structured or unstructured – is essential, so you can ingest it into your knowledge graph in the structure/schema that you have defined in your ontology. As a result, it is not only more human-readable, but also AI-ready for language models that enables contextual and much more accurate and reliable responses by AI agents].

The primary components of an ontology include:

• Concepts (Classes or Nodes): Abstract representations of entities or ideas within the domain. For example, in a retail business context, concepts might include Product, Customer, Order and Partner.
• Properties (Attributes): Characteristics or features that describe concepts. For instance, the Product concept may have properties like productName, price, and SKU.
• Links (Relationships or Edges): Associations between concepts that define how they interact. An example is the Is placed bylink connecting Order to Customer as well as Order to Partner.
• Triples: Fundamental data structures consisting of a subject-predicate-object (Order-Is placed by-Customer or Order-Is placed by-Partner) representing a single fact. For example, Order123-Is placed by-Customer456 indicates that a specific order was made by a particular customer.

Concepts & Properties

In Bizomics, concepts are the foundational elements representing entities within your business domain. Defining concepts accurately ensures a robust ontology. Each concept can have multiple properties that provide more detailed information.

Example:

• Concept: Product
  • Properties:
    • productName (e.g., “Wireless Mouse”)
    • price (e.g., 29.99)
    • SKU(e.g., “18645gth7539309jgn71”)

By defining the Product concept with these properties, Bizomics can effectively categorize and manage product-related data, facilitating seamless integration and retrieval. In Bizomics language, Instances of Concepts (i.e. that are the data Nodes in the graph database) are called Elements, e.g. “Wireless Mouse” is an Element of the Concept: “Product”.

Links and Inverse Links

Links, or relationships/edges, establish connections between concepts, illustrating how entities relate to one another. Defining inverse links enhances the ontology’s navigability and inferencing capabilities.

Example:

• Link (predicate): Is placed by
  • Source Concept (subject): Order
  • Target Concept (object): Customer
• Inverse Link (predicate): Places
  • Source Concept (subject): Customer
  • Target Concept (object): Order

In this scenario, if Order123 is linked to Customer456 via Is placed by, the inverse link Places allows Bizomics to infer that Customer456 made Order123.

Triples

Triples are the atomic units of data in an ontology, representing individual facts through a subject-predicate-object structure (or in Bizomics language: “source concept – link – target concept”). They enable the construction of a knowledge graph that Bizomics leverages for data interconnectivity.

Example:

• Triple: (Product789, Purchased by, Customer836)

This triple asserts that a specific product is purchased by a particular Customer, allowing Bizomics to group and analyze products efficiently.

Requirements: Mandatory and Optional

When defining properties and links, it’s essential to specify their necessity:

• Mandatory: Properties or Links that must be present for a concept.
• Optional: Properties or Links that may or may not be present.

Example:

For the Product concept:

• Mandatory Properties:
  • productName
  • price
• Optional Properties:
  • discount
  • manufacturer

Clearly defining these requirements ensures data integrity and consistency within Bizomics.

Status: Draft, Active, Archive

Managing the lifecycle of ontology components is vital for maintaining an up-to-date and relevant knowledge base. Bizomics categorizes the status of components as:

• Draft: Newly created components under development. No Elements (aka Instances) can be created against a Concept while the Concept is in Draft Status.
• Active: Components currently in use and considered authoritative.
• Archive: Deprecated or obsolete components retained for historical reference. Though, users have no access nor visibility to them while in Archive Status. From end user perspective they are like “deleted”.

Rules

• Archiving an Ontology component (Concept, Property, Link or Triple) will archive all the Elements (or Instances) of that component.
• To Archive a Link, user must have archived all the Triples which that Link is used in those Triples. Once there is no Triple in the Ontology that uses that Link, then the user can Archive the Link.
• There is no need to remove all the Elements (or Instances) from the knowledge graph to be able to Archive Concepts, Properties or Triples.

Example:

A concept called “Vendor” initially is in the Draft stage becomes active once finalized. If Vendor is not needed anymore (e.g. merged/replaced by “Supplier” or “Partner”), its status may change to Archive.

Cardinality: n:1, 1:1, n:1, 1:n

Cardinality defines the numerical constraints of relationships between concepts, specifying how many instances of one concept can be associated with instances of another.

• 1:1 (One-to-One): A single instance of Concept A relates to a single instance of Concept B.
  • Example: Each Product has one unique SKU (Stock Keeping Unit).
• 1:n (One-to-Many): A single instance of Concept A relates to multiple instances of Concept B.
  • Example: A Customer can place multiple Orders.
• n:1 (Many-to-One): Multiple instances of Concept A relate to a single instance of Concept B.
  • Example: Multiple Products can belong to one Category.
• n:m (Many-to-Many): Multiple instances of Concept A relate to multiple instances of Concept B.
  • Example: Products can be associated with multiple Suppliers, and Suppliers can provide multiple Products.

Understanding and defining cardinality constraints in Bizomics ensures accurate data modeling.