TRIEDATUM
YourTrustedPartnerinAI & Data

Digital Agronomist: Semantic AI & Knowledge Graphs Integrating Timbr with Databricks

Semantic Knowledge Graph

Introduction: Modern organizations manage large volumes of data across operational systems, analytics platforms, and external sources. As systems evolve, data models often fragment into hundreds or thousands of tables with inconsistent naming conventions and schemas. This fragmentation introduces several challenges:

  • Difficult data integration across systems
  • Inconsistent naming standards
  • Limited multilingual support
  • Complexity when adapting to schema changes
  • Difficulty for AI systems to correctly interpret data

Traditional relational schemas assume relatively stable structures. However, enterprise data is constantly evolving—new attributes appear, entities change shape, and integrations between systems become more complex. Modifying relational schemas often requires migrations, ETL changes, and downstream updates.

To address these issues, the architecture described in the article combines three main components:

  • 1. Simple Attribute–Value (SAV) data model for flexible storage
  • 2. Relational views for usability and structured access
  • 3. An ontology-based semantic layer in Timbr to represent domain knowledge

Together, these layers create a flexible yet structured data architecture that supports analytics, AI tools, and evolving datasets.

Architecture Overview Diagram

Architecture overview capturing Raw Data → SAV tables → Ontologies → Databricks One

Architecture Overview: The architecture follows a layered approach:

  • 1. Raw Data Sources feed into the system.
  • 2. Data is converted into SAV tables.
  • 3. Relational views reconstruct structured schemas for users and tools.
  • 4. A domain ontology in Timbr maps entities and relationships.
  • 5. Systems such as Databricks and AI tools access the data through the semantic layer to generate insights.

This layered design separates data storage, data structure, and data meaning, making the system both flexible and easy to manage.

The Simple Attribute–Value (SAV) Model: The SAV model stores data as entity–attribute–value triples instead of traditional tables with many columns. Instead of storing attributes as fixed columns, each data point is represented as:

  • Entity – the object being described
  • Attribute – a property of the object
  • Value – the actual data

This approach dramatically simplifies the underlying data architecture.

1. Structural Simplicity:

  • The entire data system can be represented using a small set of standardized tables. Instead of designing unique schemas for each dataset, all data follows the same structure.
  • This allows operational processes such as ingestion, updates, validation, and auditing to be implemented once and reused across the platform.

2. Flexible Schema Evolution:

  • In relational systems, adding a new attribute often requires schema migrations.
  • With SAV: new attributes can be added without modifying existing tables, heterogeneous entity types can coexist, and ingestion pipelines become simpler. This flexibility makes the architecture well suited for dynamic data environments.

3. Standardized Naming:

  • One major challenge in enterprise systems is inconsistent naming conventions across teams.
  • The SAV model addresses this by storing object names, attribute names, and categorical text values as numeric identifiers linked to centralized descriptor tables. Benefits include consistent terminology across datasets, easier governance, and simplified integration.

4. Multilingual Data Support:

  • Because text descriptors are stored separately from data values, the same identifiers can support multiple language representations.
  • For example, an attribute ID may have labels in English, French, and German. This design enables global data access without duplicating datasets.

Implementing SAV in Databricks: In the architecture described in the article, the SAV model is implemented in Databricks using Delta tables within Unity Catalog. A typical ingestion workflow is:

  • 1. Raw source data lands in Bronze tables
  • 2. Transformations extract entity–attribute–value triples
  • 3. The triples are written into centralized SAV Delta tables

This approach allows the system to ingest data from many sources while maintaining a consistent storage structure.

Domain Ontology and Semantic Modeling: While the SAV model simplifies storage, it does not directly capture the meaning of the data. To address this, a semantic layer is introduced using an ontology in Timbr. An ontology formally defines:

  • Concepts (Classes) – such as Plant, Image, or Disease
  • Attributes – properties like species or color
  • Relationships – connections between entities
  • Rules or constraints – logical conditions for reasoning

This structure effectively creates a knowledge graph, allowing systems to understand how entities relate to each other. For example, in the article's plant-analysis use case: an Image may contain a Plant, the plant may have Leaves, and diseases or pests may be detected in the image. By modeling these relationships, the system can answer complex questions that would otherwise require complicated SQL queries.

Relational Views: Most tools and analysts still rely on traditional relational tables. Therefore, entity-specific relational views are built on top of the SAV store. These views:

  • Reconstruct relational schemas
  • Hide the underlying SAV complexity
  • Provide a curated representation of domain entities

They can be created by joining SAV tables, filtering relevant attributes, or pivoting attribute values into columns. Because these are views, schemas can evolve without affecting downstream systems.

Semantic Querying with Timbr: Once relational views are mapped to the ontology, Timbr enables several powerful query approaches.

SQL with Semantic Relationships:

  • Users can write SQL queries that reference relationships directly without manually performing joins. This simplifies complex analytics queries and improves readability.

Knowledge Graph Exploration:

  • Users can visually explore relationships between entities through a graph interface.
Knowledge Graph Exploration

Knowledge Graph Exploration

  • In this visualization nodes represent entities such as plants, images, or diseases, while edges represent relationships between them. This approach allows analysts to explore data relationships interactively and discover patterns.

Natural Language Queries with AI:

  • Timbr also enables LLM-based querying, where users can ask questions in natural language. The system translates the question into structured queries using the ontology.
  • Because the ontology defines entities and relationships explicitly, AI systems can ground their reasoning in the actual data structure. This significantly reduces hallucinations and improves the accuracy of AI-generated insights.

Integration with Databricks:

  • Timbr can expose the ontology back to Databricks as a foreign catalog. This allows Databricks tools to access semantically structured data while maintaining the benefits of the ontology layer.
  • For example, AI assistants like Genie can query the ontology with full contextual understanding of the data.

Benefits of the Architecture: Combining SAV storage, relational views, and an ontology layer produces several advantages.

  • Flexibility: The SAV model allows new attributes and entity types without schema changes.
  • Usability: Relational views provide familiar table structures for analysts and BI tools.
  • Semantic Understanding: The ontology captures relationships and meaning within the data.
  • Simplicity: The number of physical tables is drastically reduced compared to traditional architectures.
  • Standardization: Centralized identifier tables enforce consistent naming conventions across the organization.
  • Multilingual Support: Text descriptors can be translated without modifying the underlying data.
  • AI-Ready Data: The semantic layer enables reliable interaction with AI systems.
  • Reduced AI Hallucination: Queries generated by AI are grounded in the ontology's formal model, improving accuracy and trust in automated insights.

Conclusion: Modern data platforms must support both schema flexibility and semantic understanding. The architecture presented in this article achieves this by combining:

  • SAV for flexible data storage
  • Relational views for usability
  • An ontology-driven semantic layer in Timbr

This layered approach enables organizations to manage evolving datasets while supporting advanced analytics, knowledge graph exploration, and AI-powered querying. The result is a unified platform where raw data, structured entities, and semantic relationships coexist to deliver richer and more reliable insights.