Skip to content

Hierarchical Address

Core Idea

A single string-shaped identifier whose substring structure encodes a path through a tree, so the identifier simultaneously names an entity and locates it within a containment hierarchy. Every prefix is itself an ancestor's address, so tree operations (parent, ancestors, descendants, lowest common ancestor) become substring operations — at the cost of fragility under restructuring.

How would you explain it like I'm…

A Name That's A Map

Think of a book chapter numbered 3.2.5: that one little label tells you it's in chapter 3, part 2, piece 5, so it names the spot and shows you how to get there at the same time. A Hierarchical Address is a name that's also a map. Just by reading it, you know where it lives.

The Path-in-a-Name

A Hierarchical Address is a single label, like 3.2.5 or a folder path like /home/photos/dog.jpg, where the pieces of the label spell out a path through a tree. The label both *names* the thing and *tells you where it sits* in the nesting. Because of that, jobs like 'find the parent' or 'list the ancestors' just become splitting and trimming the label, no separate lookup needed. The downside is that if you reorganize the tree, the old labels still describe the old shape, so they go stale, which is why systems often keep a forwarding list to point old labels to new spots.

Self-Locating Identifier

A Hierarchical Address is a single string-shaped identifier whose substring structure encodes a path through a tree, so the identifier simultaneously *names* an entity and *locates* it within a containment hierarchy. You can read it at every prefix as the name of an ancestor, and tree operations, find the parent, list ancestors, enumerate children, gather siblings, compute the nearest common ancestor, collapse into substring operations on the address itself. Four things make it work: a tree of entities, an alphabet with a separator (dots, slashes, digits), a concatenation rule where each address extends its parent's with a child-position segment, and a parsing rule that recovers the path by splitting on the separator. What distinguishes it from a plain identifier (which names but doesn't locate) or a plain hierarchy (which relates but yields no readable string) is that it *fuses identity and position into one readable token*, buying free ancestry computation at the cost of *fragility under restructuring*, when the tree changes, old addresses go stale.

 

A Hierarchical Address is a single string-shaped identifier whose substring structure encodes a path through a tree, so that the identifier simultaneously *names* an entity and *locates* it within a containment hierarchy. The address can be read at every prefix as the name of an ancestor, and the operations one wants to perform on a tree, find the parent, enumerate the ancestors, list the children, gather the siblings, compute the nearest common ancestor, collapse into substring operations on the address itself. Four structural commitments hold: a *tree* (or DAG) of entities; an *address alphabet* with a designated separator (digits, letters, dotted segments, slashes); a *concatenation rule* by which each address extends its parent's address with a child-position segment; and a *parsing rule* that recovers the full path from any address by splitting on the separator. Once those four hold, the address is *self-locating*, inspecting the identifier alone tells you where the entity sits, with no separate lookup. What makes this a distinct pattern rather than a special case of hierarchy-in-general or identifier-minting-in-general is that the address *fuses identity and position into one readable token*: the same string serves as the handle for reference and the path for navigation. That fusion is true of neither pure identifiers (an opaque key names but does not locate) nor pure hierarchies (the parent-child relation is structural but yields no readable string). The fusion buys structural facts for free, the ancestry is computable from the address, at the cost of *fragility under restructuring*: if the tree mutates, addresses that encoded the old shape become stale, the signature liability and the reason mature systems pair the address with a redirect or synonym layer.

Broad Use

  • Biomedical indexing: codes whose prefix names the ancestor categories within a classification tree.
  • Library classification: a decimal call number encoding a subject path into a shelf-mark.
  • Filesystems and URLs: a POSIX path or URL pathname extending its parent by a separated segment.
  • Network addressing: octets read against a mask to recover network → subnet → host.
  • Taxonomy: a biological binomial as a two-segment address into a taxonomic tree.
  • Administrative codes: tariff codes, industry codes, postal codes, and country-subdivision codes.
  • Documents: section numbering of long legal and technical documents.

Clarity

Converts a vague sense that "the codes encode structure" into a checklist — what is the separator, is it consistent, is the address stable under mutation, can the parent be read off the string, and is the address unique — whose answers fully characterize behaviour and failure.

Manages Complexity

Makes structural facts available from the identifier itself, collapsing a whole class of lookups: range queries become prefix scans, sorting brings siblings together, and delegated minting distributes assignment authority down the tree.

Abstract Reasoning

Places a system within a small family of identifier strategies — opaque (all lookup, maximally stable), hierarchical address (free queries, fragile), external structure (position in a separate table) — each with a known trade between stability, query-cost, and tolerated restructuring.

Knowledge Transfer

  • Filesystems → clinical coding: prefix scans and redirect layers reason about both identically.
  • Networking → medicine: an IP renumbering and an annual code revision are the same staleness-under-mutation problem.
  • Any tree: versioning, deprecation-with-redirect, and synonym layers are the same discipline whether the tree is a directory, a classification, or an org chart.

Example

A directory rename leaves every absolute path under it stale, which is precisely why filesystems layer symlinks over the raw path — a bet that the tree is stable, paid for with cheap structural queries when it holds.

Relationships to Other Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.Hierarchical Addresscomposition: HierarchyHierarchy

Parents (1) — more general patterns this builds on

  • Hierarchical Address presupposes Hierarchy — The file: a string that ENCODES A PATH THROUGH a hierarchy, fusing identity and tree-position into one self-locating token; presupposes the containment hierarchy and adds the string-encoding (and its restructuring fragility) the bare relation lacks.

Path to root: Hierarchical AddressHierarchy

Not to Be Confused With

  • Hierarchical Address is not Hierarchy because a hierarchy is the bare relation of nested containment (it can exist with no readable address) whereas the address encodes a path through it, adding the identity-position fusion.
  • Hierarchical Address is not an opaque Identifier Assignment because an opaque handle names without locating and is maximally stable whereas the address fuses name and position, buying free queries at the cost of fragility under tree mutation.
  • Hierarchical Address is not Indirection because indirection inserts a lookup level between reference and target whereas the address is self-locating — the path is readable from the token with no resolution step.