Designing and Implementing Semantic Data Layers with Dave Wells

Key Takeaways

• Data Semantics Defines Assembled Meaning: Semantics defines data meaning in reports and processes, originating before data enters databases.
• Single Semantic Layers Are Insufficient: Modern enterprises need five specialised data layers: Enterprise, Domain, Integration, Enrichment, and Consumption.
• Graph Modelling Eliminates Ambiguity: Semantic data modelling uses visual graphs for subject-predicate-object triples, enhancing relational data representation.
• Taxonomy Analysis Uncovers Hidden Business Rules: Terminology analysis defines vocabulary; taxonomy analysis evaluates classifications and reveals hidden operational rules.
• Governance Requires Lineage, Provenance, and Origin: Data catalogues store definitions, while governance tracks lineage, provenance, and data origin.
• Semantic Layers Are Executable Software: Semantic layers integrate data and metadata using four patterns: Metadata-Only, Graph-Based, Federation, and API.
• Start Small and Apply Boundary Control: Successful semantic layer adoption needs clear business meanings, API enforcement, and management of semantic drift.

Webinar Details

Title: Designing and Implementing Semantic Data Layers with Dave Wells
Date: 2026-09-07
Presenter: Dave Wells
Meetup Group: Book Launch with Technics Pub x MWS
Write-up Author: Howard Diesel

What is the Importance of Data Semantics?

Data semantics defines what data elements mean when assembled into reports, dashboards, and AI models. Capturing business context must start in business processes prior to system ingestion.

What is Data Semantics?

Data semantics goes beyond individual field definitions to address meaning across assembled structures. Organisations often mistakenly assume that visualisation tools inherently provide a true semantic layer.

Without explicit semantics, linguistic ambiguity creates misinterpretation across systems. For example, in vehicle rental systems, a “terminated rental” caused by an accident differs fundamentally from a “completed rental” returned on time.

Key Takeaways

• Assembly Defines Meaning: Semantics governs how combined data elements represent real-world facts.
• Business-First Context: Semantic modelling originates in business processes before data enters software systems.
• Ambiguity Elimination: Precise definitions prevent costly operational errors.

FAQ

• Does having a BI tool mean an enterprise has a semantic layer? No; BI tools provide localised consumption views, but a true semantic layer separates business meaning from storage across the enterprise lifecycle.
• Where does data context originate? Context originates at the point of business process execution, prior to database ingestion.

Figure 1 Designing and Implementing Semantic Data Layers

Figure 2 What is Data Semantics?

What Causes Data Friction in Modern Enterprises?

Modern enterprises face severe data sprawl and data friction caused by isolated software silos and hardcoded point-to-point integrations. Traceable semantics must follow data from creation through AI consumption.

The Causes of Data Friction:

Data sprawl has expanded from legacy ERPs into disparate SaaS applications, IoT devices, and automation workflows. When systems communicate via point-to-point feeds, translation logic becomes buried in code.

This hidden translation logic creates data friction: a state where data exists but cannot produce reliable insights. Teams end up relying on chaotic shadow spreadsheets and inconsistent metrics as a result.

Key Takeaways

• Data Friction: Disconnected systems force reliance on shadow spreadsheets.
• Buried Translations: Point-to-point feeds lock business definitions inside custom code.
• End-to-End Traceability: Meaning must be tracked without gaps from transactional creation to AI consumption.

FAQ

• What is data friction? Data friction occurs when data is accessible across systems but cannot deliver reliable business outcomes due to conflicting meanings and encodings.
• Why are point-to-point interfaces problematic for semantics? They embed data translation rules directly inside software code, making definitions unmanaged and inconsistent.

Figure 3 Why Data Semantics – Common Data Management Challenges

Figure 4 Why Data Semantics – the Messy World of Data Management

What are the Three Lenses for Semantic Architectures?

Semantic data layers separate business meaning from physical data storage through three structural lenses: Purpose, Architecture, and Executable Software.

The Three Lenses & Five Layer Types:

To implement semantic architectures effectively, organisations must analyse layers across three dimensions:

1. Purpose: Decoupling meaning from storage structures.
2. Architecture: Establishing standardised rules for system interoperability.
3. Executable Software: Running active runtime translations.

Architectures require five functional layer types:

• Enterprise: Defines core shared master data (e.g., Customer, Product).
• Domain: Bounds context within functional areas (e.g., Sales vs Finance).
• Integration: Maps disparate local dialects to a common language.
• Enrichment: Captures derived metrics and AI features in stream.
• Consumption: Delivers tailored data views to human and AI consumers.

Key Takeaways

• Separation of Concerns: Business logic remains independent of physical database storage.
• Layer Specialisation: Five distinct layer types fulfil different operational roles.

FAQ

• How do Enterprise and Domain semantic layers differ? Enterprise layers govern enterprise-wide master data, while Domain layers define specific contexts like Finance or Sales.

Figure 5 What is a Semantic Data Layer?

Figure 6 Kinds of Semantic Data Layers

How do Distributed Semantic Layers Manage Data Complexity?

Modern enterprise architectures require multiple distributed semantic layers deployed across domain boundaries, data lakes, warehouses, and data products.

Distributed Semantic Architectures:

A single enterprise semantic layer cannot handle modern data complexity. Architectures must deploy dedicated semantic layers across transactional domains, MDM hubs, and analytical warehouses.

When building data products, semantic definitions are packaged directly into executable APIs. Semantic layers also embed regulatory compliance constraints and data sensitivity controls into runtime governance.

Key Takeaways

• Multi-Layer Reality: Organisations need dozens of domain and integration layers.
• API Packaging: Data products embed semantic metadata directly into API boundaries.
• Policy Governance: Semantic models enforce access controls and regulatory rules.

FAQ

• Is one semantic layer sufficient for an enterprise? No; enterprises require multiple specialised layers across domains, integration hubs, and consumption tools.
• How do semantic layers support regulatory compliance? They attach classification tags, access rules, and usage constraints directly to data concepts.

Figure 7 Semantic Layers in Data Architecture

How does Graph-based Semantic Modelling Enhance Clarity?

Graph-based semantic modelling provides an intuitive, visual framework using subject-predicate-object triples to map business concepts without ambiguity.

Modelling with Knowledge Graphs:

Graph models represent business realities using nodes (entities) and edges (relationships). Unlike traditional relational models, graph relationships can hold descriptive properties.

Effective semantic modelling follows a structured workflow:

1. Set Scope: Target specific domains or master data boundaries.
2. Identify Entities (Nouns): Define real-world business objects.
3. Identify Relationships (Verbs): Connect entities via clear predicates.
4. Identify Properties (Facts): Attach descriptive attributes to nodes and edges.
5. Formulate Definitions: Write single-sentence definitions alongside rich business descriptions.

Key Takeaways

• Triples Eliminate Ambiguity: Subject-predicate-object structures convey exact meaning.
• Property-Rich Edges: Graph relationships store contextual facts directly.
• Visual Collaboration: Graph models foster direct engagement between business and IT.

FAQ

• Why use graph models instead of entity-relationship (ER) diagrams? Graphs allow relationships to contain properties directly without creating artificial associative entities.

Figure 8 Graph Modelling

Figure 9 The Semantic Modelling Process – Concept Analysis

Figure 10 The Semantic Modelling Process – Terminology Analysis & Taxonomy Analysis

Figure 11 Ontology and Taxonomy

Figure 12 Entity, Relationship, and Properties Analysis

Figure 13 Terminology Analysis

What are Lineage, Provenance, and Origin in Data?

Complete data governance extends beyond cataloguing glossaries and technical lineage to track data provenance and origin.

Lineage, Provenance, and Origin:

While data catalogues store definitions and dataset mappings, governing complex data flows requires three distinct dimensions:

• Lineage: Tracks how data moves across systems and transformations.
• Provenance: Identifies who created the data and under what authority.
• Origin: Distinguishes observed real-world facts from algorithmic derivations and synthetic AI data.

Without capturing provenance and origin, enterprises cannot establish trust or enforce security controls.

Key Takeaways

• Beyond Glossaries: Catalogues handle definitions, but metadata layers govern runtime mappings.
• Three-Part Auditability: Governance requires lineage, provenance, and origin tracking.
• AI Trust: Identifying synthetic or derived data is critical for AI safety.

FAQ

• What is the difference between data lineage and data provenance? Lineage maps data pathways across systems, whereas provenance identifies the author, entity, and authority behind data creation.

How can Community Engagement Drive Semantic Data Adoption?

Peer discussions, interactive community events, and technical publications drive practical adoption of semantic data architectures.

Industry Knowledge Exchange:

Turning data theory into enterprise execution takes continuous community engagement. Technical webinars offer forums for practitioners to address real-world governance challenges and share architectural frameworks.

Industry literature, such as Dave McComb’s work on software-driven semantic layers, provides actionable guidelines for implementing graph models and multi-layer architectures.

Key Takeaways

• Community Learning: Interactive Q&A sessions surface shared enterprise data hurdles.
• Practical Reference: Technical texts serve as blueprints for solving architectural friction.

FAQ

• Why are peer forums valuable for semantic data architects? They allow data leaders to benchmark governance patterns and validate multi-layer implementations against real-world scenarios.

What Insights does Taxonomy Analysis Provide for Modelling?

Taxonomy analysis identifies categories, roles, and states across entities, relationships, and properties to produce fully integrated ontology models.

Uncovering Hidden Model Structure:

Taxonomy analysis evaluates classification terms like status, type, and class. Analysing state-dependent classifications uncovers new graph entities and relationships:

• Entity Taxonomy: Classifies core nouns (e.g., Reserved vs Terminated Rental).
• Relationship Taxonomy: Categorises relationship predicates (e.g., Round-trip vs One-way Rental).
• Property Taxonomy: Groups property value states (e.g., Requested vs Received Payment).

For example, classifying a “terminated rental” reveals a new “Incident” entity that causes the termination, adding valuable triples to the enterprise model.

Key Takeaways

• State Discovery: Classification keywords reveal hidden domain entities and rules.
• Ontology Integration: Combining taxonomy with ontology produces a complete semantic model.

FAQ

• How does taxonomy analysis differ from terminology analysis? Terminology analysis defines vocabulary, whereas taxonomy analysis categorises terms into hierarchical structures, roles, and states.

Figure 14 Taxonomy Analysis

Figure 15 Entity Taxonomy – Classification of Things

Figure 16 Semantic Data Model – Putting the Pieces Together

What are the main semantic layer patterns?

Semantic layers function as executable software implemented through four distinct technical patterns: Metadata-only, Graph-based, Virtualisation, and API/Contract models.

Implementation Patterns & Best Practices:

Selecting the right implementation pattern depends on architectural requirements:

• Metadata-Only: Fast, analytic-centric semantic views (e.g., BI layers).
• Graph-Based: Materialised entities and relationships stored in graph databases.
• Federation/Virtualization: Dynamic query abstraction across distributed sources.
• API & Data Contracts: Boundary enforcement using YAML contracts and data products.

Successful teams start small and focus on high-friction business domains, using standard software engineering practices to manage semantic drift.

Key Takeaways

• Executable Software: Semantic layers are active software components, not static diagrams.
• Incremental Evolution: Target specific operational trouble spots rather than attempting monolithic builds.
• Boundary Control: Enforce standardised semantics at system interfaces via data contracts.

FAQ

• How do data contracts enforce semantics? Data contracts define schemas, semantic terms, and quality constraints in executable code (such as YAML) at data product boundaries.
• What is the biggest risk in semantic layer implementations? Semantic drift, which occurs when software implementations evolve without ongoing governance and model updates.

Figure 17 Implementation Approaches – APIs, Products, and Contracts

Figure 18 Implementation Approaches – Federation/Virtualisation

Figure 19 Semantic Layer Implementation Patterns

Figure 20 Architectural Types & Implementation Patterns

Figure 21 From Concepts to Practise

Figure 22 Best Practises for Data Semantics