Technical Questions

[ConstantinVasilev]

Thanks @EvgSkv for the great work!

Sharing some Qs and observations here, as the answers might be interesting for the community or for a future documentation:

1. Is there a way to get derivation/proof tree for a given fact? e.g. if we have a Cat(x) and a rule that all Cats are Mammal, we can ask for explanation of how the fact Mammal(x) was derived. Example from RDFox. Example from Prometheux
2. Similar to the above but more generic: Is there a way to get graph of predicate relationships?
3. Efficiency when increasing number of rules: Is there some limit for how big the rule base can get before it gets hard to compile or to execute as SQL? Does it depend on rule complexity, e.g. recursion. Is there a recommended way to manage this?
4. Is there a way to define predicate data model with which the data should comply? e.g. Cat(name: str, weight: float)
5. Is there a way to define unique property? e.g. there can't be two instances of Cat with the same name?
6. Is there a way to put restriction on types of relationships, e.g. one-to-many, one_to_one?
7. Why does conjunction with empty set lead to error? e.g. Mammal(name:) :- Cat(name:) | Dog(name:); when data has only Cat record: Cat(name:"Tom"); outputting Mammal gives error "no such table: Dog".
8. Found interesting bug that using SQL keywords in logica code can lead to errors which aren't handled. e.g. Credit(limit:) injects limit into the SQL without performing reserved keyword checks first.
9. I already gave 2 competitors examples in 1. Others worth checking is from Scallop in the data science direction of supporting probabilistic facts and differentials for likelihood optimisation, and lastly CozoDB supporting vector similarity search and time travelling.

[EvgSkv]

I appreticiate your kind words @ConstantinVasilev !

These are great questions! I'll prepare the answers and will reply soon.

[EvgSkv]

Let's get going, answering questions gradually :-)

Is there a way to get derivation/proof tree for a given fact? e.g. if we have a Cat(x) and a rule that all Cats are Mammal, we can ask for explanation of how the fact Mammal(x) was derived. Example from RDFox. Example from Prometheux

For now there is not way to get it automatically. It's not hard to do it manually for a simple program. Here is an example:

@Engine("duckdb");

Mammal(x, "because dog") :- Dog(x);
Mammal(x, "because cat") :- Cat(x);
Mammal(x, "because cetacean, " ++ cetacean_reason) :- Cetacean(x, cetacean_reason);

@Ground(Dog);
Dog("Baxter");
Dog("Luna");
Dog("Marley");
@Ground(Cat);
Cat("Whiskers");
Cat("Mittens");
Cat("Sable");

@Ground(Dolphin);
Dolphin("Flipper");
Dolphin("Echo");
Dolphin("Splash");

@Ground(Whale);
Whale("Willow");
Whale("Moby");
Whale("Luna");

# See https://en.wikipedia.org/wiki/Cetacea
@Ground(Cetacean);
Cetacean(x, "because dolphin") :- Dolphin(x);
Cetacean(x, "because whale") :- Whale(x);

So when we query Mammal we get the following table with the reason.

+----------+-----------------------------------+
| mammal   | reason                            |
+----------+-----------------------------------+
| Baxter   | because dog                       |
| Luna     | because dog                       |
| Marley   | because dog                       |
| Whiskers | because cat                       |
| Mittens  | because cat                       |
| Sable    | because cat                       |
| Flipper  | because cetacean, because dolphin |
| Echo     | because cetacean, because dolphin |
| Splash   | because cetacean, because dolphin |
| Willow   | because cetacean, because whale   |
| Moby     | because cetacean, because whale   |
| Luna     | because cetacean, because whale   |
+----------+-----------------------------------+

It should be straightforward to automate adding this reason column. It's not quite clear how should the reason be represented for aggregating predicates though.

Colab with the example is here.

[ConstantinVasilev]

Thanks, I'm looking for something that is implicit byproduct of how the logical reasoning is executed.

Is there some intermediate abstraction during compilation which could be output and modified additionally? This is essentially a log of which sub-statements and evaluations lead to a given fact and this must be already happening somehow when preparing the SQL.

[EvgSkv]

There are a few internal states during compilation process, which could be useful for introspection:

• Parsed syntax tree.
• Each concrete predicate is transformed into executable form, in this form all injectible predicates are injected. Basically this is form equivalent to a single SQL statement.
• Execution workflow.

Does any of these sound like what you are looking for?

[ConstantinVasilev]

Thanks, I started looking at the internal states in Logica() and I wonder if you could give me links to specific lines/obj properties that correspond to your 3 points above and which I can introspect?

[EvgSkv]

Similar to the above but more generic: Is there a way to get graph of predicate relationships?

In CoLab there is always a graph of grounded predicates displayed when a predicate is exectuted. For the example above the graph would look as follows.

[ConstantinVasilev]

If I don't want to ground only for the sake of visualisation, is there some intermediate abstraction during compilation which keeps track of predicate logical relationships regardless if they are grounded or not?

[EvgSkv]

How would you like to treat injectible predicates? I.e. say we have program:

F(x) = 2 * x;
Q(F(x)) :- T(x);

here T is the input data and F is a predicate that acts as a function. Would you like F be part of the graph?

Either way: for now no other graph is exposed, but it's there inside and it can be extracted with modest amout of work.

[EvgSkv]

Efficiency when increasing number of rules: Is there some limit for how big the rule base can get before it gets hard to compile or to execute as SQL? Does it depend on rule complexity, e.g. recursion. Is there a recommended way to manage this?

I am guessing that there is a size of the program when compilation starts taking more time then acceptible for interactive devlopment. I did not hit this limit in practice. At some point we'll need to implement the compiler in a faster language like C++, but I did not feel this need in my projects yet. It would be exciting if you grow your Logica codebase to such size. 😄

Indeed, if recursion is unfolded naively then this limit is easy to hit. But now we have "iterative" recursion mode (which is default in DuckDB). With this mode recurison is unfolded in fixed number of SQL statements, which depend on each other via a loop, so there is no need to write a lot of SQL. With this mode we can run recursion of depth of thousands with no compliation difficulty.

If compliation gets slow in any of your program, please let me know, we'll see what can be done in that particular case.

[EvgSkv]

Is there a way to define predicate data model with which the data should comply? e.g. Cat(name: str, weight: float)

There is automatic type inference in Logica activated when duckdb or psql engines are used.

E.g. for program:

Cat("Mittens", 20);
Cat("Sable", 40);
Cat(9, 10);

An error would be thrown that 9 is implied to be a string and a number.

You can also specify types of variables explicitly using ~ operator.

Cat(name, weight) :-
  name ~ Str,
  weight ~ Num,
  name = "Whiskers",
  weight = "more than it should be";  # This is an error because weight is a number.

There is a number type Num in Logica and float vs int are not differentiated by the type system.

[ConstantinVasilev]

Is this the only supported syntax, could I avoid the :- and body part and specify the property type directly in the predicate head?
Dog(name: ~ Str, weight: ~ Num)

Would this evolve at some point to have other predicates as properties or this is something unnecessary?
Dog(cat_friend: ~ Cat)

[EvgSkv]

For there is no special syntax for types, they are treated as predicates or constants. So if you want to specify types in the head you could do it with a little bit of boilerplate:

Dog(name: Str(name), weight: Num(weight))

or for the case of positional arguments simply as:

Dog(Str(name), Num(weight))

Would this evolve at some point to have other predicates as properties or this is something unnecessary?
There is no plan for emums. But you could give a name to a structure. For instance if cat is an object with a name number of lives left then you could have the following.

Cat(cat) :- cat ~ {name: Str, lives_left: Num};

And then Dog predicate with positional arguments could have a head:

Dog(name, Cat(cat_frield))

But if you are thinking of Cat being an id that occurs in some table containing all the cats of the multiverse, then I wouldn't think of it as a type, but as some other kind of value constraint, which could arrive at some point.

[EvgSkv]

5. Is there a way to define unique property? e.g. there can't be two instances of Cat with the same name?

Not yet, but this looks like a good feature to have and it would fit organically.

In particular it can be used for query optimization - if a predicate is joined by a unique column twice, then the first join can be re-used.

6. Is there a way to put restriction on types of relationships, e.g. one-to-many, one_to_one?

To me this looks exactly like 5. Once we can announce a column to be unique it will work for instances and for relationships.

[ConstantinVasilev]

This would be really nice, would it also handle cases of composite index (jointly unique) properties?

[EvgSkv]

I was thinking of introducing composite indices some time after simpler ones, but if there is a practical need for it, plans can be adjusted.

[EvgSkv]

Why does conjunction with empty set lead to error? e.g. Mammal(name:) :- Cat(name:) | Dog(name:); when data has only Cat record: Cat(name:"Tom"); outputting Mammal gives error "no such table: Dog".

Logica has a convention that any predicate that is not specified in the program is assumed to be an existing table. Hence the SQL error.

There are pros and cons of not depending on the database at compile time. In many cases it would be a better user experience to get a native Logica error - predicate undefined.

Then there can be a question - if a predicate is undefined, should it be an error, or should it be assumed empty? I am pretty sure that it should be an error: when user makes a typo, it would be extremely cryptic behavior to assume misnamed predicate to be empty.

If you want an empty predicate for some reason you can define it with a contradiction trick.

Dog("Cerberus") :- 1 = 0;  # Dogs do not exist.

[ConstantinVasilev]

This brings the question what counts as a predicate definition.

Imo as soon as you specify Mammal(name:) :- Cat(name:) | Dog(name:); you've already defined a thing which is Dog, you've already made a valid logical definition using it, hence it's not undefined, it's just that resolving it corresponds to empty set because there is no data to produce instances of it.

Connecting with the data model, if you could specify Dog(name: ~ Str) you have something similar to Pydantic data model which defines what is a valid dog instance

[EvgSkv]

I make too many unnoticed typos to want the compiler assume that I define an empty predicate every time that I query a table that doesn't exist :-)

But yes, this is a reasonable approach.

[EvgSkv]

Found interesting bug that using SQL keywords in logica code can lead to errors which aren't handled. e.g. Credit(limit:) injects limit into the SQL without performing reserved keyword checks first.

Yeah, good point. Thank you! We should fix it.

I already gave 2 competitors examples in 1. Others worth checking is from Scallop in the data science direction of supporting probabilistic facts and differentials for likelihood optimisation, and lastly CozoDB supporting vector similarity search and time travelling.

Thanks for bringing those up. It's good to know what happens around :-)

[ConstantinVasilev]

@EvgSkv these discussions make me think that a nice documentation would be a big contribution. Something like this

If you provide guidance for format and place in the repo, I can start writing as I am learning with edits and additions from your side? A lot of this already exists in your colab examples and is just a matter of organising it.

This would be also needed for teaching LLM the Logica syntax

[EvgSkv]

Hello @ConstantinVasilev ,
sorry for delay. I have published a draft of detailed documentation:
https://github.com/EvgSkv/logica/blob/main/docs/learn/logica.md

If you provide guidance for format and place in the repo, I can start writing as I am learning with edits and additions from your side? A lot of this already exists in your colab examples and is just a matter of organising it.

This is great! Please take a look at the documentation above. If you have ideas how to improve it feel free to let me know, or just set PRs editig it directly. I think it's convenient to develop it in markdown. In the future we can reformat it to something like the example that you gave.

Let me know if you have any questions or further comments.

[ConstantinVasilev]

You're one step ahead! It looks great, I will make a PR if I notice something. Btw I don't know if you already saw but I have follow-up questions in this page.

[EvgSkv]

Ah, I didn't see the follow ups! Thanks for pointing it out. Just replied to all of them.