I haven't held any hangouts online for years, although I'd consider restarting them if there is interest.
We do have a monthly call of miniKanren/OCanren researchers from around the world, where someone presents on their research. If you are interested, please send me an email!
Alas, you'd still need the knowledge graphs. I hope the licensing issues for at least some of the KGs will be resolved soon. It's a tricky issue. Even some of the ontologies and controlled vocabularies in biomedicine can't be released publicly due to copyright restrictions (for example, full SemMedDB uses UMLS which uses SNOMED).
mediKanren's source code is under MIT license, and is on GitHub. Alas, the knowledge graphs we use for mediKanren aren't produced by us, and often have very complex licenses (one KG might include knowledge from 80 or 100 databases, each with a different license). As a result, we can't just release the KGs that are needed to actually use mediKanren. Also, creating high-quality queries that take into account all the nuances and quirks of the KGs is tricky, and changes as the KGs and the Biolink standard evolve. As a result, mediKanren requires some expertise to use effectively, along with access to the KGs.
An application that uses mediKanren as a back-end (along with other reasoners) is the NIH NCATS Biomedical Data Translator:
Please keep in mind that both Translator and mediKanren are designed for researchers and for biomedical research, not for patient care or treatment recommendations.
Interesting comment. Would you mind expanding on that observation? Are there any references you'd suggest looking at that help make the connection more clear? Thank you!
Much of the success of miniKanren has been due to it not trying to be an Everything Language.
The most pragmatic variant of miniKanren, core.logic in Clojure, was popular because it didn't try to replace Clojure's behavior in general. Clojure programmers don't want to write a web server or financial application in a logic language, but might want just a bit of miniKanren-like reasoning in part of their application.
As pointed out by @giraffe_lady, pragmatic core.logic-like small embedded domain-specific language implementations in other popular languages would be useful.
The original motivation for miniKanren was to have a small, simple, easy to learn/teach/hack implementation of logic programming that could be taught to students learning functional programming in Scheme. microKanren in particular seems to have nailed this, especially since you can wrap macros around microKanren primitives to get miniKanren, and since microKanren can easily be implemented an almost any language. Once again, the fact that miniKanren and microKanren don't try to do everything is probably a key reason for their success from a teaching standpoint.
I agree that core.logic seems to have found a sweet spot as a pragmatic embedded domain-specific language. If core.logic had tried to replace more of the Clojure functionality, or had tried to be a stand-alone Everything Language, I doubt it was have been attractive to Clojurers.
I also agree that having something similar to core.logic in many other languages would be useful.
Most miniKanren implementations in most languages were created in order for the implementor to better understand miniKanren or logic programming, or because the implementor wanted to experiment with miniKanren-related reseach ideas.
This split between a pragmatic implementation versus a small, simple to implement/understand/teach/hack implementation may be another legacy of miniKanren coming from the Scheme community, which has struggled with this dichotomy for decades.
One success story of core.logic was its use in Threat Grid's software, which apparently ran core.logic on a cluster. Threat Grid was bought out by Cisco for an undisclosed--but apparently large--amount of money.
The Clojure community is very pragmatic, and uses (or used?) core.logic more like an embedded Prolog than for purely relational programming like in most of the miniKanren research. The fact that core.logic doesn't try to do everything is a benefit in the eye of Clojure programmers, I believe.
I don't know to what extent core.logic is still used in the Clojure community. Datomic uses Datalog as a query language. I don't know if there any any projects that combine Datomic and core.logic; certainly both could be used in the same application.
https://github.com/namin/inc