📕 subnode [[@Jayu/canonical meta]] in 📚 node [[canonical-meta]]

Canonical Meta

What is a Meta?

Meta is how I call:

  • The way a [[personal knowledge base]] I've made works.
    • i.e. its data model, and all the workflows that help maintaining its data.
  • A description made for myself (and others) of how a personal knowledge base I've made works.
    • i.e. the documentation of its data model and all the workflows that help maintaning its data.

In short: it's my own nickname for something quite banal. But doing it makes my [[digital garden]]s comfier for myself.

Principles of a Meta

  • Translatability
    • Metas must strive to be easily translatable.
      • A well-defined Meta is easier to translate.
  • Modularity
    • Each Meta must be able to develop its own solutions for its own particular problems.
  • *Formalization
    • Metas must be both readable and amenable to formalization.
      • No compromises: maximal readability must co-exist alongside maximal formalization.
  • Flexibility
    • Metas must strive to be flexible both synchronycally and diachronycally.
      • Multiple structures must coexist inside a Meta.
        • Metas must have both vertical and horizontal structures.
          • No compromises: maximal verticality must co-exist alongside maximal horizontality.
      • Metas must be able to change throughout time without imploding.
        • Metas must be able to productively die and lend themselves and their data to be consumed by other Metas, if necessary.
  • Forgiveness
    • No Meta can promise itself, let alone others, to perfectly follow its own principles.

What is a canonical Meta?

There are advantages to having multiple personal knowledge bases, public or private. However, one particular and nasty disadvantage is not having the same data model and/or a way to translate different models. This is why some [[Zettelkastener]]s defend maintaining a single, unified knowledge base for your entire life.

Nonetheless, I've found a way to avoid this problem for myself by making a default data model upon which all my personal knowledge bases build themselves, and which they translate back to. That's what I call my canonical Meta.

The structure of a Meta

Garden

A garden is a small world embedded into a digital or analog medium. It contains inhabitants.

Inhabitants

A garden's inhabitants can be:

  • Gardeners, conscious and non-conscious subjects of any kind who build a garden.
    • i.e. people, tools used for building a garden, AI, and possibly a few alien species.
  • Environment, the data that exists inside a garden.
  • Handbooks, the consensus between gardeners on how to structure an environment.
  • Neighbors, everything that exists outside of a garden.
    • i.e. the entire Universe, sans my gardens.

From the point of view of a garden, everything that inhabits it is an entity composed of data.

Environment

An environment is a structure which can only see and work with itself. It is the job of gardeners to translate neighbors into its data model. An environment has its own life, producing data of its own

An environment is composed of sets. Reified sets are called elements. Any other set is a non-reified set.

A set's status as an element is a matter of perspective.

Classes and singulars

Sets can be instantiated. An instance that can also be instantiated is a class, and if they're an instance of a class, they're a subclass. An instance that can't be instantiated is a singular.

Elements

An element is a set composed by:

  • Content, a set of data.
    • e.g. the content of an article, a picture, an encylopedia's entry, other elements.
  • Attributes, a set of metadata.
    • e.g. an URI, an identifier, creation date.

An element whose content is partially or fully composed by other elements is an composite element.

Non-reified sets

Non-reified sets are divided into three main classes:

  • Links, unordered n-tuples whose function is to emphasize some sort of connection between elements.
  • Sequences, posets whose function is to emphasize some sort of hierarchy between elements.
  • Discourses, categories whose function is to emphasize some sort of meaning about a set and its elements for gardeners and neighbors.

Links

Links are classified according to their sizes, their functions, and the kinds of elements they can contain:

  • Wikilinks, n-ary relations whose function is to signal non-specific connections between elements.
  • Transclusions, intersections whose function is to make elements exist simultaneously in two or more sets.
  • External links, n-ary relations whose function is to signal non-specific connections between regular elements and elements that represent data outside an environment.

Sequences

Sequences are classified according to their sizes, their topologies, their functions, and the kinds of elements they can contain:

  • Folgezettel, n-tuples whose function is to signal non-specific continuities/hierarchies between elements.
  • Indexes, n-tuples whose function is to signal hierarchies between composite elements.
    • e.g. Wikipedia's categories.

Discourses

Discourses are classified according to their sizes, their topologies, the meanings they convey, and the kinds of elements they can contain:

  • Tags, sets whose function is to convey that its elements are non-specifically related to something.
  • Schemas, structures whose function is to assign meaning to sets and elements through a modeling language.
    • e.g. entity-relationship models, ologs, database schemas.

Handbooks

Handbooks are all workflows utilized by gardeners to build and maintain an environment.

  • i.e. how are titles capitalized, what backend should be used to visually represent wikilinks between elements, formatting rules for content, controlled vocabularies, etc.

Default subclasses

Similar Metas may require similar subclasses. The canonical Meta offers default subclasses that may be freely used or ignored by other Metas.

Elements

  • Concepts, whose content pertains to describing an object existing outside a garden.
    • e.g. Wikipedia's entries.
  • Propositions, whose content pertains to a statement and its justification.
    • e.g. Andy Matuschak's note titles, aphorisms, Argdown.
  • Comments, whose content pertains to a specific resource existing outside a garden.
    • e.g. Marginalia, reading notes, a movie review.
  • Scratchpads, whose content is purposefully unorganized.
    • e.g. A daily note.
  • Productions, whose content is not organized according to the Meta.
    • e.g. A poem, an essay, a draft for a paper one wishes to publish.
  • Catalogs, whose content is composed of references to resources.
    • e.g. A library catalog, a Zotero library.
  • Projects, whose content is composed of plans, goals, tasks, and other similar things.
    • e.g. Research project, chore list, GTD.
  • Documentation, whose content describes handbooks and Metas.
    • e.g. You're reading a Documentation right now. Wikipedia's Information pages are also a good example of this.
"Concept" default handbook
A Concept should have the following Content:
- A definition of the object being described, readable by both humans and machines.
- A series of descriptions about the object.
	- Descriptions can be divided into sections.
		- Sections should be ordered alphabetically.
		- For public gardens, it's good to follow well-known conventions for naming sections. Wikipedia's ones are good ones.
"Proposition" default handbook
A Proposition should have the following Content:
- A thesis.
- A series of arguments.
"Comments" default handbook
Comments should have the following Content:
- Annotations that are structured according to the referenced resource's original structure.
- Annotations that follow their own structure.
"Scratchpad" default handbook
A Scratchpad's Content is fully arbitrary.
"Production" default handbook
A Production's Content is fully arbitrary.
"Catalog" default handbook
A Catalog should have the following Content:
- A set of metadata about a resource.
- If feasible on the garden's medium, the resource itself, embedded or linked to.```

##### "Project" default handbook

```markdown
A Project should have the following Content:
- A definition of the project.
- Arbitrary content pertaining to the project.```

##### "Documentation" default handbook

```markdown
A Documentation should have the following Content:
- A Meta/handbook definition.
- Arbitrary content pertaining to the Meta/handbook.```
📖 stoas
⥱ context