| > Datalog type dialect would be more appropriate I assume because datalog is more about composing queries from assertions/constraints on the data? Nicely, queries can be recursive without having to create views or CTE's (common table expressions). Often the data for datalog is modeled as fact databases (i.e., different tables are decomposed into a common table of key+record+value). So I could see training an LLM to recognize relevant entity features and constraints to feed back into the memory query. Less obliviously, data analytics might feed into prevalence/relevance at inference time. So agreed: It might be better as an experiment to start with a simple data model and teachable (but powerful) querying than the full generality of SQL and relational data. Is that what RelationalAI has done? Their marketecture blurbs specifically mention graph data (no), rule-based inference (yes? backwards or forwards?) As an aside, their rules description defies deconstruction: bringing knowledge and semantics closer to your data,
reduce your code footprint by 10x,
improve accuracy, and
drive consistency and reusability across your organizations
with common business models understood by all
So: rules built on ontologies? |
The key thing with them is it's designed for querying very large cloud backed datasets, high volumes of connected data. So maybe it's not as relevant here as I originally suggested.
Re: marketing ... much of their marketing has shifted over the last two years to emphasizing the fact that it's a plugin thing for Snowflake, which wasn't their original MO.
(There's an CMU DB talk they did some years ago that I thought was pretty brilliant and made me want to work there)
My proposal about a datalog (or similar more high level declarative relational-model system) being useful here has to do with how it shifts the focus to logical propositions/rules and handles transitive joins etc naturally. It's a place an LLM could shove "facts" and "rules" it finds along the way, and then the system could join to find relationships.
You can do this in SQL these days, but it isn't as natural or intuitive.