Logseq/Entity/Hierarchy/Discussion/Analysis/Opus/26/10/01/0611 ET Mark each page with the most specific entity in each lineage
Mark each page with the most specific entity in each lineage
- Each page should list only its most specific entities. A musician who is also a knowledge gardener lists Logseq/Entity/Person/Musician and Logseq/Entity/Person/Knowledge Gardener and leaves out Logseq/Entity/Person, because each of those is already a kind of person. Musician, then Person, is one lineage: an entity followed by each entity it is a kind of. This narrows the hypothesis codekiln wrote in the 2026-10-01 Thu journal: the rule covers only a child entity that is a kind of its parent, and it lets one page carry two sibling entities. The Musician, Knowledge Gardener and User Guide definition pages currently say to mark each instance with the parent entity as well.
A child entity is either a kind of its parent or a part of it
- A child segment under
Logseq/Entity/ sometimes names a kind of the parent and sometimes names a part of it. - Is-a. Every instance of the child is also an instance of the parent: Logseq/Entity/Article/Blog, Logseq/Entity/Repo/Awesome, the Logseq/Entity/Book/Section levels, Logseq/Entity/Person/Musician, Logseq/Entity/Person/Knowledge Gardener, Logseq/Entity/Book/User Guide.
- Part-of. The child is a different thing that belongs to the parent: Logseq/Entity/Podcast/Episode in a show, Logseq/Entity/Forum/Post in a forum, Logseq/Entity/Trade-Off/Component in a trade-off. Logseq/Entity/YouTube/Playlist runs the other way: a playlist contains videos.
- Some segments under
Logseq/Entity/ have no definition page and serve only as a namespace. Logseq/Entity/AI is one, so Logseq/Entity/AI/Model has no parent entity. - Listing a child entity together with its parent is redundant for an is-a child and false for a part-of child. A page carrying Logseq/Entity/Podcast and Logseq/Entity/Podcast/Episode would claim to be a show and one of its episodes, and no single thing is both. Instance paths already express part-of: Hard Fork/Pod/26/09/A.I. Safety Goes Mainstream + a ‘Hard Fork’ Exit AMA files under Hard Fork/Pod.
- Only the text of a child definition page says whether the child is a kind of its parent or a part of it. codekiln proposed a frontmatter property that would make this explicit and queryable:
logseq-entity-hierarchy-type::, described on Logseq/Entity/Hierarchy/Frontmatter/Type. The Blog definition page would set it to Logseq/Entity/Hierarchy/Frontmatter/Type/extends, and the Episode definition page to Logseq/Entity/Hierarchy/Frontmatter/Type/part-of.
A name for entity ancestry
- Candidates: lineage, ancestry, entity family, branch, and Clade, the biologist's word for an ancestor together with all its descendants.
- I recommend lineage: an entity and its chain of is-a parents up to the topmost defined entity, so a musician's lineage is Musician, then Person. It is an ordinary word, it reads well in a rule ("two entities in one lineage"), and it leaves out part-of children, since an episode does not descend from a show. Clade names the group in the other direction: Person together with every entity that descends from it, Musician and Knowledge Gardener included.
Sibling entities may share a page; an entity and its own ancestor may not
- Taken literally, "more than one entity with the same entity ancestry" also forbids a person who is both a musician and a knowledge gardener, since Logseq/Entity/Person/Musician and Logseq/Entity/Person/Knowledge Gardener both descend from Person. Neither entity implies the other, so marking both carries information.
- The redundancy is between an entity and its own ancestor: Musician already implies Person. The rule I would write is that each page carries the most specific entity it has in each lineage, so a page marked Musician leaves out Person.
Musician, Knowledge Gardener and User Guide instances list the parent entity too
- Logseq/Entity/Person/Knowledge Gardener and Logseq/Entity/Person/Musician each say "Frontmatter lists both types, Person first". Logseq/Entity/Book/User Guide marks a guide with both User Guide and Book, child first.
- Eight instance pages follow those instructions: six musicians (Person/Daniel Lopatin, Person/Eduardo Ramos, Person/John Adams, Person/John Chowning, Person/Madonna, Person/Steve Reich), the knowledge gardener Person/Chris Aldrich, and the guide Microfreak/UG.
- Other children already work the way the hypothesis wants. Logseq/Entity/Book/Section says "The instance declares its most specific level". Blog and Awesome pages mark the child alone and say their shape is the same as the parent's.
- The likely reason for marking both is backlinks: the backlinks of Logseq/Entity/Person list a musician only when the musician's page links Person directly. Moving to child-only markers would mean:
- rewriting the Musician, Knowledge Gardener and User Guide definition pages to mark the child alone;
- changing
logseq-entity:: on the eight instance pages; - adding the lineage rule to Logseq/Entity, together with the statement that an instance of a child entity is an instance of every ancestor;
- listing all people with a query over Person and every entity that descends from it, because backlinks alone would miss the musicians.
- None of that is done yet.
The Podcast Episode page holds the rules for an episode that is also a YouTube video
- Logseq/Entity says combination rules live on the primary entity's definition page. Two definition pages already depart from that rule. Logseq/Entity/Concept is the primary entity of every trade-off page, yet Logseq/Entity/Trade-Off holds the combined shape, and Concept's page says so. Logseq/Entity/Series holds its own combination rules whatever entity comes first. In practice the rule sits on the page whose shape the combination changes most.
- For an episode that is also a YouTube video, the rule is on Logseq/Entity/Podcast/Episode, listed first, with a pointer from Logseq/Entity/YouTube. The episode is what codekiln listens to, and the recording is one of its sources.
- Most of the YouTube rules on the Episode page fit any YouTube video. Video seconds for every timestamp, chapters as timestamp headings, and a collapsed transcript per chapter also describe 1Password/YouTube/25/11/How 1Password Environments makes secrets management simple for developers, which is not a podcast. Only two parts need both entities: mapping Snipd's audio time onto video time, and the episode belonging to a show. My/Principle/Simplify/Not every distinction is worth recording argues for moving the general video rules up to the YouTube page and keeping a short combination section on the episode page.
CSS and class inheritance
- Class inheritance is a model for how a child entity takes rules from its parents in one lineage. A child definition page works like a subclass: it inherits the parent's page shape and states only its deviations, which is My/Principle/Simplify/Don't Repeat Yourself DRY applied to definitions. Several unrelated markers on one page are like Software/Inheritance/Multiple. When two of a page's entities give conflicting rules, whoever edits the page follows the entity listed first, the way Python looks up a method in a class's parents in the order they are listed.
- CSS class selectors are a model for how the rules of two entities on one page combine. A page's markers act like an element's classes,
class="episode youtube". Rules written for .episode and for .youtube both apply. A rule written for .episode.youtube applies only when both classes are present, and it wins over either alone because it is more specific (MDN on specificity). The combination needs no hierarchy. - CSS also has a separate inheritance along the document tree, where a child element takes some property values from its parent element (MDN on inheritance). That matches part-of. An episode can take its
created-by:: and its subject from the show it files under without being a kind of show. - Taken together: a child entity inherits from its ancestors the way a subclass does, a rule written for a combination applies the way a CSS rule for
.episode.youtube does, and an episode takes defaults from its show the way an HTML element inherits CSS properties from its parent. Pages in the garden already follow each of these: the Logseq/Entity/Book/Section levels, the Logseq/Entity/Trade-Off page shape, and episodes filed under their show. An entity system built on subclassing, CSS selectors and CSS inheritance would describe how the garden already works.
Where a combination rule can live
- On the primary entity's page. This is the current rule. There is one place to look, and Logseq/Entity already states it. The cost: which entity is primary is arbitrary for Episode and YouTube, and the rule is invisible from the other entity's definition page unless that page carries a pointer.
- On a page for the combination, the compound selector as its own definition, named like the
X/vs/Y trade-off pages: Logseq/Entity/Podcast/Episode/and/YouTube. Each of the two definition pages points to it. The cost: one more page per combination, and a third meaning for a child namespace segment beside is-a and part-of. - On trait pages. Reusable behavior such as timestamped video notes or frame transcription gets its own definition that any entity can include: a YouTube video, a recorded talk, a course lecture. The cost: a new kind of definition page, and one more page for a reader to open.
- For now, keep the rule on Logseq/Entity/Podcast/Episode with a pointer from Logseq/Entity/YouTube. Only two pages in the garden are both an episode and a video: Person/Gergely Orosz/Pod/26/09 Design Engineering with Maggie Appleton and Person/Cal Newport/Pod/26/08 Rethinking the Deep Life Stack (Again!). Make a combination page when the section grows too long for the Episode page, or when a second combination needs the same rules. Try a trait page first for the video-notes rules, since they already apply to videos that are not podcasts.
Show pages that carry the wrong marker or none
Open questions