How is an org brain stored and manipulated?

[borgauf]

I'm a rank beginner/dabbler with elisp code, but I take it you're "reading in" an org brain directory -- all the file and heading entries -- and creating a big cache or hash or something in live memory, right? Could you point this code out and/or explain what's happening and your general data management idea here? Lisp is the world of data as code and lists -- which is mind blowing sometimes.

[swhalemwo]

it mostly relies on org-brain internal functions (org-brain-children/org-brain-friends, look at where they are called in obvz.el) to construct an alist of the nodes and links to visualize, which is then send to python; so it doesn't build a cache in memory. The rationale behind this is to rely on existing org-brain functionality as much as possible (I do have a custom cache for org-brain though to speed up org-brain queries in general, as org-brain queries read a lot from files, which is slow).

I don't really use obvz tho, it didn't turn out to be really useful to me as the graphs I'm drawing now require a lot of custom annotations/clusters/labels, so I just write the dot code manually; therefore also org-brain doesn't work well as a "backend" since little information is shared across graphs.

[borgauf]

Yes, AFAICT the nodes/entries are only JIT-crawled, and the brain is not really stored or held in live memory as a query-able entity. True? org-brain seems to have only the "visualize" capability and its buffer display and no real querying capability, correct? I've been very interested in getting org-mode's capabilities joined with graph database management, a la best of both worlds. org-roam doesn't go far enough either with no real edge knowledge. The best would be to have org-mode's services wedded to an triplet-RTF-like, fully query-able system. Or am I going about this all wrong? Your thoughts, please, on getting org-mode (agenda, Babel, etc.) and graph data management together?

…

On Tue, Mar 19, 2024 at 4:12 AM swhalemwo ***@***.***> wrote: it mostly relies on org-brain internal functions (org-brain-children/ org-brain-friends, look at where they are called in obvz.el) to construct an alist of the nodes and links to visualize, which is then send to python; so it doesn't build a cache in memory. The rationale behind this is to rely on existing org-brain functionality as much as possible (I do have a custom cache for org-brain though to speed up org-brain queries in general, as org-brain queries read a lot from files, which is slow). I don't really use obvz tho, it didn't turn out to be really useful to me as the graphs I'm drawing now require a lot of custom annotations/clusters/labels, so I just write the dot code manually; therefore also org-brain doesn't work well as a "backend" since little information is shared across graphs. — Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABA73W4WOGU6TYJGPRXYOEDYY76PNAVCNFSM6AAAAABE4WIINGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBWGQZTCOBVHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA ***@***.***

[swhalemwo]

i'm not quite sure what you're trying to get at. obvz is "just" visualization of org-brain. org-brain is not read into memory, but can be be queried via its API (org-brain-children/parents/friends) to get edge information. I don't use org-roam, I tried it a couple of times but found it confusing, perhaps because I never could get backlinks to work; and org-brain does everything that I hear org-roam can do.

I also tried triplet stores (RDF) and graph databases for some projects, but they turned out to be unnecessarily complex and I ended up using RDMBS instead. I also don't see why they should be linked to org-agenda or babel, which work fine for me they way they are. This is largely unrelated to obvz though; if you want to discuss some ideas I think reddit/SE/mailing lists are better places.