# Corpus Metadata - All notes in `/Users/rico/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault/iso27diy-corp/Corpus` need metadata. - These metadata need to follow the [obsidian-front-matter-syntax](obsidian-front-matter-syntax.md). - Obsidian calls metadata variables 'Properties' - In this Corpus we use General properties (every note should have them) and specific properties (depending on the kind of note, which can be inferred from the `notetype` property, see below). ## General properties **Notetype** The `notetype` field will have one of the following values: - `guide`: guided, hands-on lessons, learning by doing, interactive lessons - `explanation`: background and context to the standards, paraphrases of the original standard texts, opinion, discussion, underlying principles, interpretation - `application`: steps to solve a specific, real-world problem. Implementing the standard in real world environments, implementation aids, implementation examples, templates, etc. - `reference`: secondary sources of information, like original standard texts, dictionaries, terms and definitions. - `publication`: for content created by TSW for publication, e.g. articles, eBooks, social media posts. - `overview`: meta-notes created and maintained by the Librarian; describe and index the contents of a vault folder for use by content agents. - `other`: for all notes that, by their content, cannot be placed in one of the previous categories. - `iso27diyGIS`: notes that belong to the ISO27DIY Guided Implementation System (GIS). **Language** - For the `language` property we use the language code as defined in ISO 639-1. **Isotags** The property `isotags`, of type list, allows any note to be linked to clauses and controls of the ISO 27001 / ISO 27002 standard, by the `id` property of the Original Standard Texts, found in `Corpus/Standards/ISO27x/OST/27001/EN` and `/Corpus/Standards/ISO27x/OST/27002/EN`, respectively. For example, a note that needs to be linked to ISO 27001 clause 5.2 Policy, will get a value of `C.5.2` added to its `isotags` list. Likewise, a note that needs to be linked to ISO 27002 control 5.15 Access control, will get a value of `A.5.15` added to its `isotags` list. ## Properties for ISO 27001 and 27002 Original Standard Texts Original Standard Texts are found in `Corpus/Standards/ISO27x/OST/` . *Important: the body of these notes must never be changed!* OST notes inherit the general properties, and also have the following properties: - `status`: as of yet, the only value defined for the property is `active`. I foresee a `superseded` or `replaced` status for later. - `sourcetext`: the standard name and version, e.g. `iso27001:en:2022` The OST/27002 have specific properties deduced from chapter 4 of the standard ("Themes and Attributes"). They are: - `theme` - `control_type` - `information_security_properties` - `cybersecurity_concepts` - `operational_capabilities` - `security_domains` For the possible values of these properties, see [themes-and-attributes-in-iso-27002](themes-and-attributes-in-iso-27002.md). ## Properties for the ISO27DIY Guided Implementation System - Notes in the `iso27DIY-gis` folder and subfolders are of `notetype` `iso27diyGIS`. - Notes in the `iso27DIY-gis/guide` subfolder ... - Notes in the `iso27DIY-gis/reference` subfolder ... ## Properties for Corpus Overview Notes Overview notes are created and maintained exclusively by the Librarian. They are not content notes and must not be used as source material for publications. ### Folder structure All overview notes live in `iso27diy-corp/metadata/overviews/`. They are never placed inside the folder they describe. ### Filename convention `corpus-overview-[foldername].md`, where `foldername` is the name of the vault folder being described, e.g. `corpus-overview-EN.md` for the ISO 27002 EN controls folder. ### Template ```yaml --- title: "" # human-readable title, e.g. "Corpus Overview: ISO 27002 Controls (EN)" notetype: overview covers: "" # vault path of the folder this note describes, # e.g. "iso27diy-corp/Corpus/Standards/ISO27x/OST/27002/EN" last-updated: "" # ISO 8601 date, e.g. 2026-06-02; update whenever the note is revised tags: [] --- ``` ### Rules - `covers` must be the exact vault path of the folder being described — no trailing slash. - `last-updated` must be set every time the overview note is modified. - Overview notes do not carry `isotags`, `language`, or `status` — these fields are not applicable. - The Librarian updates `last-updated` and the corpus index note (`corpus-index.md`) whenever an overview note is created or revised. ## Properties for Publications Publications are found in `iso27diy-corp/Marketing/publications` and are of `notetype` `publication`. ### Folder structure All publication notes live directly under `iso27diy-corp/Marketing/publications/posts/`. There are no audience or proposition subfolders — segmentation is handled entirely by front matter. ### Controlled vocabularies **`proposition`** — which ISO27DIY product or practice this content promotes: - `advisory` — Richard's advisory practice (ZZP) - `canvas` — the Canvas Method product - `iso27diy` — the ISO27DIY SaaS product **`audience`** — who the content is aimed at: - `leadership` — directors, board members, senior management - `msp` — managed service providers - `technical` — IT professionals, security practitioners - `general` — no specific segment **`channels`** — where the content is published: - `linkedin` - `newsletter` - `blog` **`linkedin-account`** — which LinkedIn account was used; only relevant when `linkedin` is in `channels`: - `personal` — Richard's personal LinkedIn profile - `company` — ISO27DIY company page **`content-type`** — the format of the content: - `post` - `article` - `newsletter-section` - `thread` **`status`**: - `draft` — work in progress - `ready` — approved, not yet scheduled - `scheduled` — publish date set - `published` — live ### Template ```yaml --- title: "" # human-readable post title language: "" # ISO 639-1 code: en | nl proposition: "" # advisory | canvas | iso27diy series-id: "" # short machine-readable code, e.g. s01, s02; omit if standalone series-title: "" # human-readable series name; omit if standalone series-part: # integer position within series; null if unpositioned draft; omit if standalone audience: # one or more of: leadership | msp | technical | general - leadership channels: # one or more of: linkedin | newsletter | blog - linkedin linkedin-account: personal # personal | company; omit if linkedin not in channels content-type: # one or more of: post | article | newsletter-section | thread - post status: draft # draft | ready | scheduled | published publish-dates: # ISO 8601 datetime in UTC, e.g. 2026-05-13T17:30:00Z linkedin: 2026-05-13T17:30:00Z published-urls: # fill after publishing; omit channels not yet published linkedin: "" source-notes: # optional — vault notes this was drawn from; omit if none - "[[path/to/note]]" notetype: publication isotags: [] # ISO 27001/27002 clause/control links; omit if not applicable tags: [] --- ``` ### Filename convention Publication filenames follow the pattern `{series-id}p{series-part}{language} - {title-slug}.md`, e.g. `s01p01en - IT is not going to fix your security problem.md`. Standalone posts use a plain descriptive slug with no series prefix.