How they build it: through a visual modeler, SQL-style DDL statements, AI-generated candidates from existing schemas, LLM-assisted ERD translation, or OWL import, whichever fits. The domain expert maps business concepts to existing tables and columns. No data is moved.
Where it resides: the ontology and its mappings live in Timbr’s metadata layer as a virtual semantic model. The data stays in the source systems; Timbr stores the model and mappings and rewrites queries against the sources. It deploys cloud, on-prem, or hybrid, relevant for a regulated FS environment.
How it’s accessed and by whom: via standard SQL over JDBC/ODBC, semantic/REST APIs, BI tools, and notebooks. Timbr connects to BI tools via JDBC/ODBC and supports querying from Zeppelin and Jupyter notebooks in SQL, Apache Spark, Python, and R. Consumers are analysts, dashboards, applications, and AI agents needing governed context. (Access is through SQL, not SPARQL, that’s the core design choice.)
Time to create: scope-dependent, but because there’s no ETL/migration underneath, a focused domain ontology is typically days to a few weeks, not months.
Response time: because graph traversals run as standard SQL queries without explicitly writing joins and compile to optimized SQL pushed down to the source, runtime is essentially native-database performance, no separate ETL latency or graph-store round-trip. Semantic caching accelerates repeated and aggregated queries further.
