Logseq/Entity/Hierarchy/Discussion create an analysis dated to today that begins a discussion of a "theory" of how this should work, informed by and hopefully consistent with other existing hierarchical entity relationships currently expressed in Logseq/Entity. It should gesture towards building a cohesive entity system that can express Software/Inheritance relationship with respect to page attributes, or possibly a relationship inspired by CSS, that an AI agent or another person would be able to clearly interpret. I expect this page to have entries that are dated. It will be a living discussion.
In my Knowledge Gardens we are seeking something akin to a knowledge grammar expressed with knowledge garden pages. This should, in the scope of the garden replace most Agent/Skills with declarative descriptions of what entities exist as well as pointers to any operations that must be taken to keep those entity models healthy, relationally vivid and vibrant in the garden.
A Logseq/Entity/Definition may have child definitions expressed in child namespaces. In general, my expectation is that we should honor My/Principle/Simplify/Don't Repeat Yourself DRY, so that common expectations (whether about page shape or "behavior") should be in the parent entity, and be "overridden" in the child pages, so the child pages mainly only articulate the deviations from the standard implied in the parent page.
Right now there are some ambiguities and decisions to make.
When a page is attributed with an entity, and that entity has a child, when is there an expectation that the page should be literally attributed with both the child and the parent? Is it permitted? My sense is that it shouldn't. My hypothesis is that the best design for this system is one in which Software/Inheritance/Multiple is supported in the sense of a single page having an "is a" relationship with more than one logical entity, but it would be counterproductive and an anti-pattern for any page to have more than one entity with the same "entity ancestry," (there's got to be a better term for that!)
It wouldn't make sense for a single page to contain both Logseq/Entity/Podcast and Logseq/Entity/Podcast/Episode, because one entity isn't both of those things. They actually are separate things in the universe; it's means something different to say "I listen to Cal Newport's Deep Work podcast" than to say "The other day I listened to episode 439 on Andrew Huberman's podcast."
How should entities articulate behavior that is particular to the intersection between two entities?
For example, when a page has an Software/Inheritance/Is-A relationship to both a Logseq/Entity/Podcast/Episode and Logseq/Entity/YouTube, how might the "grammar" of the entities system define behavior specific to certain combinations of entities? Analyze the design space, considering that most podcasts are "moving to" youtube in the sense that they can be consumed without a video player but have key video or screenshot elements that need to be visually transcribed or pulled into the garden, and "are" both going forwards from 2026.
Using Readwise/CLI, find my Snipd snipd highlights related to this.
take a look at Person/Gergely Orosz/Pod/26/09 Design Engineering with Maggie Appleton and similar pages in the garden that explicitly or implicitly model both a youtube video and a podcast episode, in which I worked with the AI to develop a design for how youtube transcripts should be correlated and triangulated with my highlights. That will inform the work today. Keep in mind that not all pages that should be considered are explicitly attributed with youtube video or podcast episode; get creative with your searches. In particular, look for signs of a youtube video.