
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:
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:
Together, these layers create a flexible yet structured data architecture that supports analytics, AI tools, and evolving datasets.

Architecture overview capturing Raw Data → SAV tables → Ontologies → Databricks One
Architecture Overview: The architecture follows a layered approach:
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:
This approach dramatically simplifies the underlying data architecture.
1. Structural Simplicity:
2. Flexible Schema Evolution:
3. Standardized Naming:
4. Multilingual Data Support:
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:
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:
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:
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:
Knowledge Graph Exploration:

Knowledge Graph Exploration
Natural Language Queries with AI:
Integration with Databricks:
Benefits of the Architecture: Combining SAV storage, relational views, and an ontology layer produces several advantages.
Conclusion: Modern data platforms must support both schema flexibility and semantic understanding. The architecture presented in this article achieves this by combining:
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.