The Knowledge Exchange Grid proposition has always had searchcentricity and just-in-time content creation as priorities. For those who want the structure and implicit semantic meaning of content there is KEGML, but KEG has been expanded to include any content that anyone can make, in whatever form. This rather large change to the entire KEG approach will put the bulk of the work on the tools that gather, parse, and index the content data in whatever form, whereever it may be essentially giving each person their own ChatGPT or Google search engine. Better tools will have several methods for identifying the type of content and mapping structured parsing rules to it.
KEGML will continue to be a thing, but regarded as yet another form of content, not the definitive content that all KEG documents must follow. Removal of this stricture will allow people to write however they wish without the annoying errors (unless they want them).
Why the change?
Recently, I’ve been reminded that content is never pretty and organized because people are never pretty and organized. The average person has no idea what a linter is and would never run it anyway. After hours and hours of work to clean up our team knowledge base at work I find that people still do things incorrectly, no matter how much attention I bring to it or style guide I write, or linter I deploy.
Knowledge content is always messy and organic. This means that any system that proports to handle the knowledge of all humanity must be able to adapt to how humans create content in all forms. When there is structure, great, use it. When there isn’t, the system must do it’s best to keep up. There is no place in a human world for unforgiving knowledge management systems. Just look at all the attempts over the years to force humans to actually be organized. Hell, the English language itself is a perfect example of how humans will do whatever they fucking want. We just don’t conform, as a rule. Building any system that requires conformance instead of organic, best-guess adaptation is going to fail.
This organic approach to human content is exactly what ChatGPT AI does. It takes humans as they are and evaluates them that way. The same can be accomplished much more quickly than AI if we layer a system that allows the quick specification of certain content as it appears, which is where PEGN comes in. PEGN will allow the quick definition of any structured text content, from JSON to HTML to Markdown and anything else.
So what now?
KEGML becomes just Markdown without aggregation. First of all, my zet tool will remain a zet tool and I will be removing any and all composition syntax. KEGML will remain a simplified form of Markdown and nothing more. No aggregation will happen and I won’t be using zet itself to write books, only to contain the snippets of content that I will eventually move and maintain into other formal formats for publishing (most likely MkDocs).
The keg and zet command remains command line tool. The zet command will be only focused on zettelkasten content managment and command-line querying. It will eventually render it’s content into MkDocs and other established, searchable formats. The keg command will be for gathering, caching, and organizing content in any form that can be followed based on URL. This accomplishes the same goals of KEG originally but without any limitation on the content itself. The keg command will be expanded to include different plugins for processing different types of content and mapping it to searchable keywords and fields. The advantage is that keg will then be able to point to JSON or YAML data URLs directly and be used as a method of universal database query in such cases while still being able to index Markdown or just plain HTML. The keg tool will grow to have a rich collection of content ingesting plugins that can adapt to anything that exists now or in the future. The keg tool will depend heavily on PEGN for quickly specifying the structure of any and all structured data. Both zet and keg will get mobile apps that leverage conversational user interfaces to allow entry of content and queries by voice against a main server containing that content. The apps will be “offline first” centric so that some of all of a zettlekasten or keg cache can be stored locally on the mobile device rather than depending on the Internet.