-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Production rule engine feature #170
Comments
For truth maintenance, see e.g. https://dspace.mit.edu/handle/1721.1/130767 |
We will keep the current Datalog rules as the API. However, the current implementation of rule evaluation is a top-down approach, which can be less efficient than a bottom-up Datalog evaluation strategy. In fact, the current implementation cannot handle the math genealogy benchmark task (out of memory). The top-down approach also does not mesh well with our query optimizer. So we will implement a new bottom-up rule evaluation algorithm. The progress is tracked at https://github.com/juji-io/datalevin/blob/rule/doc/rules.md |
Likely will use iterative rules application (to take advantage of fast query engine) and support truth maintenance.
The goal is to support good balance between persistence, latency and truth-maintenance.
Some notes:
In term of functionality, see TypeDB and O'Doyle Rules.
Engines in the clojure world: clara, odoyle rules, naga don't have their own db, have to do inference in memory after feteching data from other dbs. clara and naga do not support relationship among the same type objects, e.g. person1 is a friend of person2.
Engines in the java world: drools are too heavy; easyrules and rulebook have similar problems of clara and naga. TypeDB is slow, for it does not cache inference results.
Some thoughts:
Inferred facts are stored separately from original. Inferred are invertedly indexed with the original, so truth maintenance is cheap.
The text was updated successfully, but these errors were encountered: