$ deps-try clj-kondo/clj-kondo
Syntax error compiling at (eval/deps_try/try.clj:106:28).
No such var: fs/xdg-data-home

Full report at:
/tmp/clojure-4707535182527186318.edn

looks like a cool app, i'm excited to try it out when i can get it working

@UEENNMX0T could you try installing again? (should become v0.3.1)

@U04V6FEES

$ deps-try
[Rebel readline] Type :repl/help for online help info
user=> :deps/try clj-kondo/clj-kondo
user=> (require '[clj-kondo.core :as clj-kondo])
Execution error (FileNotFoundException) at user/eval7264 (R

I ❤️ RDF.

And I ❤️❤️ GDB even more.

Looks pretty solid at a glance. Crazy question: is there any notification mechanism in the protocol? My reactive hack likes "push", if you will. Subscribe/notify, yadda yadda.

No there's nothing like that. This seems orthogonal to graphy behavior, or maybe I'm not clear on what you mean?

Would add-watch do the trick? https://clojure.github.io/clojure/clojure.core-api.html#clojure.core/add-watch

"add watch" would do the trick nicely. :thinking_face: Might be fun building a reactive layer around iGraph. Do you have a backend for any of Franz's DBs, such as AllegroCache and AllegroGraph? Reminds me, I once rolled my own GDB-lite atop Postgres.

No so far I've just done jena and grafter, which wraps rdf4j if IIRC (badly needs a refresher). I'm also trying to extend it to other graph architectures. So many graphs, so little time :-)

Tell me about it. I have UIs for the Web, CLJS and native JS, React, ReactNative, and now Flutter. We should start a self-help group. Anyway, next Q: are there other GDB protocols out there like iGraph? Any standards process ongoing?

Not that I know of, though it seems that datalog (following datomic's example) is the most common way of querying graphs in clojure-native implementations.

ont-app has https://github.com/ont-app/datascript-graph and https://github.com/ont-app/datomic-client, both of which are overdue for some sprucing up.

If you like SPARQLing, this is an interesting clojure-y approach: https://github.com/yetanalytics/flint

I think a low-level fact maintenance API will be the key, and I am sure you have that. My objective will be transparent persistence of reactive objects, basically just maps with individually reactive properties. I did this atop an early Franz RDF product, went well.

Do you find the igraph protocol spec (and maybe ont-app/rdf) fairly approachable? If so, I'd welcome your extending it to your Allegrograph .

... moneybags! :-)

Well, I am old enough to remember when people were able to sell software, so a proprietary DB is fine. Maybe we can get them to pay for the work. 🙂 btw, my RDF hack also made triples themselves reactive, storing formula code for eval as needed. As long as the right software was reading/writing the DB, mind you. I did that as well with Franz's old AllegroStore, a persistent CLOS solution. Very powerful. I did not stare hard at the protocol, I could tell from a distance that it was solid. 🙂 What I would do is a proof-of-concept using the simplest, working implementation and then worry about scaling to other DBs and more features.

Got a pointer to your 'hack'?

Yeah I remember Allegro CL fondly. Even paid for my own license for a while in the 00's. Actually it was a talk by Jans Aasman about AllegroGraph that got me interested in RDF

That was about the same time I found Clojure.

Had to copy TripleCells in from another project. Good thing you know Lisp. 🙂 https://github.com/kennytilton/cells/tree/main/triple-cells Maybe start with hello-world.lisp where I test that the DB is self-updating.

Btw, I had a fun moment using Gruff to inspect the TripleCells encoding of the hello-world.lisp example, including all the implementation triples used to record dependencies.