Introduction to Ontology Modeling

Ontology modeling is a method for adding meaning to data by structuring it into concepts and relationships. Unlike simple data schemas, ontologies enable the creation of rich semantic models, where data elements are connected in ways that reveal context, enhance discoverability, and support more intelligent data operations.

In this guide, we cover methods for building and refining an ontology model, focusing on ease of use, flexibility, and long-term adaptability. The first sections explain ontology design principles in general terms; later sections show how to apply them in Blindata.

What is Ontology Modeling?

Ontology modeling defines data elements as concepts (entities) with attributes and relationships. Concepts can represent significant entities in a domain—such as Customer, Product, or Order—and are often structured hierarchically. Relationships between these concepts, such as “Order contains Product” or “Customer places Order,” clarify how each concept connects to others.

In this context, it is important to differentiate between ontology schema and instances:

• Ontology Schema: The schema defines the overall structure of the ontology, outlining the concepts, their relationships, and the attributes that characterize them. It acts as a blueprint for how data is organized and how different entities interact.

• Instances: Instances are specific representations of the concepts defined in the ontology schema. For example, if Customer is a concept, an instance might be a specific customer named “John Doe.” Instances provide the actual data that populates the ontology.

In Blindata, the primary focus is to provide an ontology schema that supports effective data governance and management. This schema clarifies data relationships, helps enforce data quality and compliance standards, and enables organizations to leverage their data assets more effectively across applications.

Ontology vs Taxonomy vs Data Model vs Knowledge Graph

These terms are often used interchangeably, but they serve different purposes. Understanding the distinction helps you choose the right level of structure for your organization.

Blindata’s Business Glossary supports all four maturity levels: you can start with a flat list of terms, grow into taxonomies, model full ontologies with relationships, and connect those concepts to physical data to build an enterprise knowledge graph.

How Blindata Approaches Ontology Modeling

Blindata is designed for business-first ontology modeling. In the platform UI—including the Ontology Graph Editor —you work with namespaces, concepts, attributes, predicates, and relations using familiar business language. You do not need to write RDF triples or manage semantic syntax to model your domain.

Under the hood, Blindata maps these elements to standard semantic constructs (for example, concepts correspond to rdfs:Class, attributes to datatype properties, and relations to object properties). This mapping powers interoperability, but it stays invisible during day-to-day modeling.

When you need to exchange models with external semantic tools or reuse existing vocabularies, Blindata provides RDFS Turtle import and export at the namespace level. From a namespace detail page you can upload or download a .ttl file; the namespace identifier in the file must match the namespace you import into. Blindata also supports CSV import/export and the API for bulk or automated changes. See Namespaces, Concepts, Attributes and Predicates for step-by-step instructions.

Ontology Building Blocks: Statements and RDF Examples

Ontologies are structured through statements that describe knowledge in a specific domain. Each statement connects data points using a subject-predicate-object structure, forming a triple.

In RDF (Resource Description Framework), this triple structure is fundamental:

• Subject: The entity or concept being described.
• Predicate: The property or relationship that applies to the subject.
• Object: The value or entity linked to the subject through the predicate.

For example, the statement “Customer John Doe has the email ‘customer@example.com ’” would be represented as:

ex:JohnDoe rdf:type ex:Customer .
ex:JohnDoe ex:hasEmail "customer@example.com"^^xsd:string .
ex:Order123 rdf:type ex:Order .
ex:JohnDoe ex:placesOrder ex:Order123 .

The related schema for those triples:

ex:Customer rdf:type rdfs:Class .
ex:Order rdf:type rdfs:Class .

ex:hasEmail rdf:type rdf:Property ;
            rdfs:domain ex:Customer ;
            rdfs:range xsd:string .

ex:placesOrder rdf:type rdf:Property ;
               rdfs:domain ex:Customer ;
               rdfs:range ex:Order .

In Blindata you would model the same schema by creating Customer and Order concepts, a hasEmail attribute on Customer, and a placesOrder relation from Customer to Order, without writing Turtle unless you choose to import or export the namespace.

Anatomy of an Ontology: Classes, Relationships and Attributes

Before building an ontology, it is essential to understand its core components:

• Class: A type of entity in the model. In Blindata, these are called concepts.

  Schema example:

  ex:Customer rdf:type owl:Class .
  ex:Product rdf:type owl:Class .
  ex:Order rdf:type owl:Class .
  

  Instance example:

  ex:JohnDoe rdf:type ex:Customer .
  ex:ExampleProduct rdf:type ex:Product .
  ex:Order123 rdf:type ex:Order .
  

• Relationship: Links between classes (also called object properties). In Blindata, these are relations defined with predicates.

  Schema example:

  ex:placesOrder rdf:type owl:ObjectProperty ;
                 rdfs:domain ex:Customer ;
                 rdfs:range ex:Order .
  
  ex:contains rdf:type owl:ObjectProperty ;
              rdfs:domain ex:Order ;
              rdfs:range ex:Product .
  

  Instance example:

  ex:JohnDoe ex:placesOrder ex:Order123 .
  ex:Order123 ex:contains ex:ExampleProduct .
  

• Attribute: Literal properties of a class (also called datatype properties). In Blindata, these are attributes.

  Schema example:

  ex:hasEmail rdf:type owl:DatatypeProperty ;
              rdfs:domain ex:Customer ;
              rdfs:range xsd:string .
  
  ex:hasPrice rdf:type owl:DatatypeProperty ;
              rdfs:domain ex:Product ;
              rdfs:range xsd:decimal .
  

  Instance example:

  ex:JohnDoe ex:hasEmail "customer@example.com"^^xsd:string .
  ex:ExampleProduct ex:hasPrice "29.99"^^xsd:decimal .
  

RDFS and OWL: Standards Context

Most enterprise ontologies are expressed using RDFS (RDF Schema) and OWL (Web Ontology Language):

• RDFS covers classes, subClassOf hierarchies, domains, ranges, and basic properties. Blindata Turtle import/export is centered on RDFS constructs such as rdfs:Class, rdfs:subClassOf, rdfs:label, and rdfs:comment.
• OWL adds richer constraints: equivalent classes, disjoint classes, cardinality, and boolean class expressions. Blindata’s RDF importer supports OWL constructs where applicable, but the Business Glossary UI does not expose OWL reasoning or constraint editing directly.

When importing an external ontology, start with the constructs your use case requires. A glossary-focused model often needs only classes, inheritance, attributes, and relations; advanced OWL axioms are most relevant when exchanging models with dedicated ontology tools.

Scoping Your Ontology with Competency Questions

Before adding concepts, write 10–20 competency questions (CQs), concrete questions the ontology should help answer. CQs keep scope manageable and give stakeholders a shared success criterion.

Examples for a retail domain:

1. Which customer placed a given order?
2. What products does an order contain?
3. Is a business partner a customer, a supplier, or both?
4. Which attributes define a product versus a product category?
5. How do we distinguish an employee from a contractor?

Review each candidate concept against the CQs: if a concept does not help answer any question, defer it. If a CQ cannot be answered with your current model, you have a modeling gap to close.

This “minimum viable ontology” approach—one domain, a focused question set, iterate based on feedback—works well alongside Blindata namespaces, which let you scope models by business area without forcing everything into a single monolithic vocabulary.

Identifying Core Concepts

Defining core concepts lays the foundation for meaningful data relationships. Concepts represent domain objects or entities that encapsulate specific meanings and attributes.

Selecting a Use Case or Business Domain

A well-defined use case or business domain guides concept identification by narrowing focus to specific data interactions and objectives. By choosing a concrete business scenario, such as “Customer Support” or “Inventory Management,” you clarify scope and prioritize concepts that directly impact that area.

Blindata namespaces are useful for segregating models by domain, allowing clearer organization and scalability. Create one namespace per bounded context (for example, Sales, Logistics, Finance) rather than mixing unrelated concepts in a single namespace.

Concept Discovery Techniques

Bottom-Up Approach

This method starts by examining existing data structures—database schemas, data models, or catalog metadata—to identify patterns that signify key concepts. If multiple datasets reference customer_id or order_number, those fields suggest primary concepts. This approach grounds the ontology in what the organization already stores and is a natural fit when linking catalog assets to glossary concepts later.

Top-Down Approach

The top-down approach starts with overarching domain concepts. Define high-level categories first, then break them into sub-concepts. In e-commerce, you might start with “Products” and “Orders,” then add “Electronics” or “Clothing” under “Products.” This provides structure but requires validation against real data to avoid abstract models that do not match operational reality.

Combined Approach: Middle-Out Method

The middle-out approach blends both techniques. Start with a few high-impact concepts aligned to your business domain, then examine current data structures to refine them and discover sub-concepts or attributes. In healthcare, you might anchor on “Patient,” then review datasets to uncover “Patient Record,” “Diagnosis,” and “Medication.”

This approach balances strategic alignment with practical insights from actual data structures.

Tips for Identifying Core Concepts

• Collaboration: Involve domain experts and stakeholders. Their insights reveal concepts that are not obvious from schemas alone.
• Documentation: Record the rationale behind each concept. Use Blindata’s Documentation tab and the description field on each object.
• Flexibility: Adapt concepts as business needs evolve. The ontology should be a living model.

Defining Relationships between Concepts

Once core concepts are identified, establish how they interact. This section covers inheritance, schema properties (relations between concepts), and descriptive statements (metadata-level constraints).

Inheritance

Inheritance establishes hierarchical connections among concepts, allowing child concepts to inherit attributes and relations from parent concepts.

Parent-child relationships: A parent concept shares properties with its children. For example, a parent concept “Vehicle” might have attributes such as “has wheels.” Child concepts “Car” and “Truck” inherit those attributes and add their own.

Example:

• Vehicle: has wheels, can transport goods or people.
• Car: inherits from “Vehicle,” plus “has four doors.”
• Truck: inherits from “Vehicle,” plus “has cargo space.”

In Blindata, define inheritance from the concept detail page or the Graph Editor. See How to define Concept Hierarchies for UI steps.

Substitution principle: Instances of a child concept should be usable wherever the parent is expected. If a process requires a “Vehicle,” a “Car” instance should qualify. Use this test when deciding whether inheritance is appropriate: if substitution does not hold, prefer an association instead.

Guidelines for using inheritance:

• When to use inheritance:

  • Multiple concepts share significant common properties or behaviors (for example, types of “Vehicle”).
  • A child concept logically fits under a broader parent and meaningfully inherits its properties.

• When not to use inheritance:

  • Concepts interact but do not share substantial structure (for example, “Customer” and “Product”).
  • You only want to reuse an attribute—link a shared attribute instead.
  • Concepts are related by workflow or association, not by “is-a” semantics.

Schema Object Properties

Schema object properties define how instances of one concept connect to instances of another. In Blindata, model these as relations with predicates.

Examples:

• Invoice → payingCustomer → Customer: Each invoice is associated with a paying customer.
• Order → hasProduct → Product: Each order links to one or more products.

Predicates can be registered in the predicates registry for reuse, or applied directly when creating a relation. See Predicates .

Descriptive Statements

Descriptive relationships operate at the metadata level—they define how concepts relate as types, not how individual records link.

Equivalent class relationships: Indicate two classes are synonymous. If “Customer” and “Client” represent the same business concept, treat them as equivalent rather than maintaining duplicate definitions.

Disjoint classes: Specify that classes cannot overlap. “Employee” and “Contractor” might be disjoint if an individual cannot hold both roles simultaneously.

Boolean combinations: Unions, intersections, and complements represent composite concepts (for example, “Premium Customer” as a intersection of customer segments). These are advanced OWL constructs; use them when exchanging models via Turtle import, not as a starting point for glossary design.

Identifying Attributes

Attributes define literal characteristics of concepts—names, dates, amounts, identifiers. In Blindata, attributes correspond to datatype properties.

Note: Attributes capture literal values; relations (object properties) connect concepts to other concepts.

Techniques for Defining Attributes

1. Domain analysis: Identify key literal attributes per concept, aligned with industry standards where they exist.
2. Stakeholder input: Confirm which attributes matter for daily work and reporting.
3. Existing data models: Review schemas and catalog metadata for fields that should map to glossary attributes.

Reusing Attributes with Inheritance

Define shared attributes on a parent concept so children inherit them. If “Author” has name and birthdate, a child concept “Writer” inherits those attributes automatically.

Reusable and Specialized Attributes

Attributes can be created within a concept or as standalone entities linked to multiple concepts—useful when “Address” applies to “Customer,” “Supplier,” and “Office” alike.

In semantic terms, specialization can be expressed with subPropertyOf (for example, workContact as a specialization of hasContactInformation). In Blindata, linking a shared attribute to several concepts achieves similar reuse without requiring you to manage RDF property hierarchies in the UI.

End-to-End Example: Retail Order Domain

The following walkthrough ties together the sections above. Model it in Blindata using the Graph Editor or namespace UI; the Turtle fragment shows what an export might look like.

Competency questions addressed:

• Who placed an order?
• What does an order contain?
• What identifying attributes does each concept need?

Concepts and hierarchy:

• Person (base concept)
  • Customer (inherits from Person)
  • Employee (inherits from Person)
• Product
• Order

Attributes:

• Person: fullName, email
• Product: sku, unitPrice
• Order: orderDate, status

Relations:

• Customer — placesOrder → Order
• Order — contains → Product

Corresponding Turtle schema (export/interchange format):

@prefix ex: <http://example.org/retail#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:Person a rdfs:Class ;
    rdfs:label "Person" .

ex:Customer a rdfs:Class ;
    rdfs:subClassOf ex:Person ;
    rdfs:label "Customer" .

ex:Employee a rdfs:Class ;
    rdfs:subClassOf ex:Person ;
    rdfs:label "Employee" .

ex:Product a rdfs:Class ;
    rdfs:label "Product" .

ex:Order a rdfs:Class ;
    rdfs:label "Order" .

ex:placesOrder a rdf:Property ;
    rdfs:domain ex:Customer ;
    rdfs:range ex:Order .

ex:contains a rdf:Property ;
    rdfs:domain ex:Order ;
    rdfs:range ex:Product .

After modeling, link catalog tables and columns to these concepts so physical data inherits business meaning. See Linking Catalog Assets To Business Glossary .

Common Anti-Patterns

Avoid these frequent mistakes when modeling in Blindata or any ontology tool:

Naming and Namespace Conventions

Consistent naming reduces confusion across teams and makes Turtle import/export reliable.

• Namespaces: Use one namespace per domain. Set a stable URI identifier (for example, http://example.org/retail#) and keep it consistent between Blindata and exported Turtle files.
• Concepts: Prefer singular nouns (Customer, not Customers). Use PascalCase or your organization’s established convention consistently.
• Attributes: Use descriptive literal names (dateOfBirth, unitPrice). Avoid embedding table or column prefixes from source systems.
• Predicates / relations: Use verb phrases (placesOrder, hasInvoice, isPartOf). Register frequently reused predicates in the predicates registry.
• Documentation: Fill in descriptions and the Documentation tab, future you (and external importers) depend on them.

Linking Your Ontology to Physical Data

An ontology delivers the most value when connected to the Data Catalog. Blindata supports:

• Manual linking of physical entities and fields to glossary concepts and attributes.
• Semantic paths on field links, defining the chain of concepts and relations between a source entity and a target attribute.
• Automated linking through the Data Classification module and, for JDBC crawls, bulk semantic links on metadata import.

Semantic linking turns the ontology from a standalone vocabulary into an operational governance layer: policies, quality rules, and data products can reference concepts that are grounded in real assets. See Linking Catalog Assets To Business Glossary and Enhancing Physical Field-to-Attribute Links with Semantic Paths .

Integrating External Ontologies

You may already have ontologies in Protégé, industry standards, or partner vocabularies. Blindata supports integration through namespace-level Turtle import and export—not by editing RDF inside the Graph Editor.

Import workflow

1. Create or select a namespace whose identifier matches the @prefix IRI in your Turtle file.
2. From the namespace detail page, use the import action to upload the .ttl file.
3. Review imported concepts, attributes, and relations in the UI or Graph Editor.
4. Link imported concepts to your catalog assets and refine descriptions for your organization.

Export workflow

Export a namespace to Turtle when you need to share the model with semantic tools, archive a version, or align with an external governance process. Viewers can export; administrators can import.

Alignment tips

• Map, do not duplicate: If an external ontology already defines Product, import it into a dedicated namespace rather than re-creating the same class manually.
• Extend locally: Keep industry or standard vocabularies in their namespace; add organization-specific concepts in a separate namespace and link across them with relations.
• Validate after import: Check inheritance, orphaned attributes, and naming collisions. Adjust in the UI or fix the source Turtle and re-import.
• OWL vs RDFS: Confirm which constructs your source file uses. RDFS imports map cleanly to Blindata concepts and relations; advanced OWL axioms may not have a direct UI equivalent.

Governance and Iteration

Ontologies are never “finished.” Plan for ongoing care:

• Ownership: Assign stewards per namespace or domain. Use Stewardship & Responsibilities to track who maintains each area.
• Change process: Document when to add concepts, when to deprecate them, and who approves changes. Use Blindata descriptions and the Documentation tab as your change log narrative.
• Versioning: Export Turtle or CSV snapshots before major refactors. Namespace-scoped exports make rollback and diffing practical.
• Review cadence: Revisit competency questions periodically. Retire concepts that no longer answer real questions.
• Impact analysis: Before renaming or merging concepts, check catalog links, data products, and policies that reference them.

Ontology Modeling Checklist

Use this checklist when starting or reviewing a namespace:

1. Scope: Define the business domain and write competency questions.
2. Namespace: Create a namespace with a stable identifier.
3. Concepts: Identify core concepts (middle-out); avoid system-specific names.
4. Inheritance: Add parent-child relationships only where substitution holds.
5. Relations: Connect concepts with clear predicates.
6. Attributes: Add literal properties; reuse shared attributes where possible.
7. Documentation: Describe every concept, attribute, and predicate.
8. Catalog links: Connect physical entities and fields to glossary elements.
9. Validation: Walk through competency questions with domain experts.
10. Export: Archive a Turtle or CSV snapshot; plan the next review date.

Applying This in Blindata

The table below maps ontology design steps to Blindata features:

Recommended workflow for most teams:

1. Write competency questions and pick a namespace scope.
2. Model concepts, inheritance, relations, and attributes in the Graph Editor or UI.
3. Link catalog assets to validate the model against real data.
4. Export Turtle if you need to share with external ontology tools or partners.
5. Iterate: refine based on stakeholder feedback and new data sources.

Frequently Asked Questions

Do I need RDF or OWL skills to model ontologies in Blindata?

No. The Business Glossary and Graph Editor use business terms—concepts, attributes, predicates, and relations. RDF and Turtle are optional interchange formats for import and export, not daily modeling syntax.

What is the difference between an ontology and a business glossary?

A business glossary lists and defines terms. An ontology adds structure: typed relationships, inheritance, and reusable predicates. Blindata supports both; you can start with terms and grow into a full ontology within the same platform.

When should I use inheritance versus a relation?

Use inheritance when a child concept is a specialized type of the parent and can substitute for it. Use a relation when concepts interact but are independent types (for example, Customer places Order).

Can I import an existing RDFS or OWL ontology?

Yes. Upload a Turtle file from the namespace detail page. Ensure the namespace identifier in Blindata matches the IRI used in the file. Review the imported structure in the UI and adjust as needed.

How do I connect my ontology to databases and pipelines?

Link Data Catalog entities and fields to glossary concepts and attributes. For field-level links you can specify semantic paths. JDBC metadata import can also carry semantic links into the catalog on ingest.

How do I avoid building an ontology nobody uses?

Start with a narrow domain, tie every concept to a competency question, link catalog assets early, and assign stewards. An ontology connected to real data and owned by domain experts stays relevant.

Next steps

• Business Glossary overview — entry methods, permissions, and reading order
• Namespaces, Concepts, Attributes and Predicates — platform building blocks and Turtle import/export
• Ontology Graph Editor — visual modeling
• Linking Catalog Assets To Business Glossary — semantic linking and paths