On encoding relational dynamics in GnoPonEmacs

Continuing on from my last babble, I'd like to think about the different kinds of encoding I'm working on - but not withot a tip-of-the-hat toward overcoding.

If I try and just babble on it, a big part of what I'm trying to do is, under it, overcode the universe, so that each node of relational dynamics has a way to be necoded, fingerprinted, etc.

While I recognize that's an unrealistic goal, it's the method that interests me: starting from the existing mapped network of relations and differentiating new relations by describing their differences.

I want to do this in a way that is compatible with:

1. The way I've come to ontologize, as critical of that way as I am. What I've called relational dynamics or tekodynamics, elsewhere.
2. Org-roam nodes
   1. I want them to be publishable as static interlinking HTML docs, so I can provide a rendition of the map to the public.
   2. This one will require translation from my relational grammar to Emacs, Org-mode and Org-roam grammar. This might require translating them first into standard computer terms.
3. My own codebase, probably Fennel
   1. This requires translation into Fennel/Lua ideas, which will probably be simpler than Org-mode and Org-roam, in some ways, but trickier in others because I'll have to make it up, not map it to an existing system like Org-roam, no matter how janky it is.

From here, it seems critical to pin down certain things, such as:

• Every Org-mode file and Org-mode subtree with an Org-mode ID property is a Org-roam node
  • This means it is a relational node, in our grammar.

At this point, that's all the system assumes: notably, a file with an ID does not need a title to be in the Org-roam database, (it'll show up as a blank string, if you search for it), but if you end up with more than one untitled node, only the most recent one will be findable.

So, it seems necessary as a next step to establish titling - naming, as the first act of differentiation that occurs to relational nodes, within the GnoponEmacs framing.

I'm inclined to shift my babbling toward how that is, in some ways, perhaps anthropocentric or even colonial, but, I knew that this whole endeavor is going to be kyriarchist.

So, everything with an ID must have a title. From a software perspective, the primary use of the title is searching for a node. I could probably - and might end up - writing a whole thing on, "Titling Relational Nodes in GnoponEmacs," but for now, that seems like the thing to make important:

• ID is an automatically assigned unique alphanumeric identifier.
• TItle is a user-assigned identifier
  • It doesn't have to be unique
  • But then searching for nodes will need to show a node attribute that isn't just the title
    • The only attribute we know exists is the ID, so showing the first and last three of that would be enough, if a person learned "slate 123…def" was Teraumi slate and "slate 432…afd" was Terran slate.

Which is enough of a resolution of that issue, for now - I can get back to the question of giving relational nodes their Org-mode title.

A title needs to say what a thing is, but may also have any assortment of adjectives and adverbs that say how it does what it is, and where it does it.

These are things that might also be in the node's properties, and currently, wouldn't have any way of being synced - that's one thing that is a hangup, I'm realizing: there are multiple forms of encoding I'm working with, and no form of encoding is firmly established yet. So I feel this pressure to write some like, linter… but in thinking about it, I'm realizing that because I'm using Emacs as my interface, Org-mode and Org-roam should be the "primary" encoding, since I can more easily script stuff to go through the database and tweak the properties of the files, than I can tweak the Fennel code blocks inside a node. And, I'm realizing, can use Org-mode Elisp stuff to like, put the title into the Fennel code block, automatically.

So, that gives me a few things more firmly established:

• Anything with an ID is a node, in Org-roam, and thus a relational node.
  • Anything with an ID needs a title.
• This ID and title are the canonical version of a relational node.

I've just checked, and nodes linked in a file's properties show up in the Org-roam backlinks list, by default, so that's cool.

And I should be able to do :var data=(org-entry-get nil "FOO" t) to grab the FOO property, for populating source blocks… so that actually all works pretty well!

For rendeirng text, Org-mode macros will let me reference properties and insert them into the file on export/publishing.

On that note, addressing another concern a brief look shows that something like the following, set as the function being pointed to by :preparation-function in my Org-publish project's configuration, will let it skip anything that doesn't have a :PUBLISH: property set to t.

(defun gpe/skip-if-not-publish (plist)
(unless (string= (org-entry-get nil "PUBLISH" t) "true")
  (error "Skipping file: PUBLISH property not set to true")))

I'll still need to explore how to render the ID when I'm searching for Org-roam nodes, but other than that, this addresses a lot of the concerns I had about making just, blank-ish nodes.

My next order of consideration is, what information should be considered the first thing that needs to go into a node, and I had the idea earlier that every node can basically describe itself as a form of some other node - assuming we start with a few nodes like acts, conditions, and structures.

This describing thus is the second act of node formation, after titling, and should say the form a thing is derived from, and how it is differentiated.

I'm not quite sure how this grammar maps onto texts like essays - an essay is clear a form of essay, and I guess its content is how it is differentiated from the combination of author, genre, register, and topic that give it form.

Okay, that makes that clear enough. I'm realizing I listed three things - acts, conditions, and structures, but not forms themselves!

There, after all that babbling, I feel like I've corrected course toward a more reasonable approach. Currently I have things in subdirectories which just leaves me struggling as to where to put a node, and this gives me a way to make a node whose description is still reasonable, in the language of the system: "This is a node that has been referenced, but not described."

Which shows us a third act of relating, within the GnoponEmacs system: titling, referencing, and describing. You can't describe or reference until you've titlted, but referencing provides a title in a way that describing doesn't.

Which highlights that lots of nodes will be created by referencing them, and they'll likely be referenced as a way of pointing out some form of difference.

Which at this point is just me babbling to affirm the system as reasonable, within its own senses. I'll have some tweaks to make to the GnoponEmacs code in the morning, starting with creating a template for creating an undescribed node, and then working on the code for publishing.

A note to myself, I want to remember to make sure that Backlinks are attached to published files, but only those Backlinks that are marked, themselves, with a :PUBLISH: tag.

So, "A node is a form of relation differentiated from others by action, condition, or structuration."

"A music listening log entry is a form of log entry differentiated by focusing on logging music listening log events" is a shitty sentence, but it says what I mean: A music listening log entry is a form of log entry, which is a result of the act of logging (more properly log entering or inputing), but where the input content is music listening events.

Implicit is that logs take log entries, music listening is a form of event, etc. etc., which all needs to get sketched out. A lot of effort, but some of these will get referenced over and over and over - like "event," which'll be part of what log event is derived from.

But the benefit will be that I'll have a node of relations - and how they relate - that'll be a great foundation for the type of Internet software I want to make - what I call a "MUD" out of habit. I can imagine and speculate what a functional representation of "overcoding" would look like, but it would need to make a lot of assumptions about the system it functioned within. By taking the time to do this coding, I might be able to find a function of overcoding that emerges derivationally from the encoded relations.

Which sounds ambitious, but I remember a time when computers were for doing ambitious things.