[cmrdporcupine]

The relational model is built on first order / predicate logic. While SQL itself is kind of a dubious and low grade implementation of it, it's not a surprise to me that it would be useful for applications of reasoning and memory about facts generally.

I think a Datalog type dialect would be more appropriate, myself. Maybe something like that RelationalAI has implemented.

[w10-1]

> 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?

[cmrdporcupine]

RelationAI effectively has a kind of datalog as a commerical product, and it runs inside Snowflake (something they implemented since I worked there). It's marketed as "graph" database but they mean by that that they have modeled graphs as binary relational data, really. It's a purely relational system, with a friendly query language ("Rel") which is vaguely Datalogish, but a bit more flexible.

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.

[alpinesol]

Using an obscure derivative of an obscure academic language (prolog) is never appropriate outside of a university.