Organized folders, edited metadata note

This commit is contained in:
Richard Kranendonk 2026-06-02 16:49:20 +02:00
parent df038765c0
commit e806e6764b
56 changed files with 113 additions and 55 deletions

View file

@ -1,37 +1,97 @@
# Corpus Metadata
- All notes in this Obsidian vault need 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, can be inferred from other 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 metadata
## General properties
### Notetype
**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`: for original standard texts, dictionaries, terms and definitions.
- `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.
- `other`: for all notes that, by there content, cannot be placed in one for the previous categories.
- `iso27diyGIS`: notes that belong to the ISO27DIY Guided Implementation System (GIS).
Note:
- Notes in the iso27DIY-gis/guide folder and subfolders are typically of the `guide` type.
- Notes in iso27DIY-gis/reference and subfolders are typically of the `explanation` or `application` type.
**Language**
### Language
For the `language` property we use the language code as defined in ISO 639-1.
- For the `language` property we use the language code as defined in ISO 639-1.
**Isotags**
### Status
As of yet, the only value defined for the `status` property is `active`.
## 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.
## Metadata for ISO 27001 and 27002 Original Standard Texts
- The original texts of the ISO 27001 and ISO 27002 standards can be found in the OST folder and subfolders.
- These notes are tagged with “sourcetext”.
- The body of these notes must never be changed!
- Specific properties for ISO 27002 OST notes are deduced from chapter 4 of the standard ("Themes and Attributes"). They are: `theme`, `control_type`, `information_security_properties`, `cybersecurity_concepts`, `operational_capabilities`, and `security_domains`.
- For the possible values of these properties, see [themes-and-attributes-in-iso-27002](themes-and-attributes-in-iso-27002.md).
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 Publications
- publications can be found in `iso27diy-corp/Marketing/publications` and are of `notetype` `publication`
```
---
title: "" # post title
series: "" # series title
series-slug: "" # series title as a slug, e.g. "access-control-basics"
series-part: 1 # position within the series; omit if standalone
theme: "" # broader topic cluster, e.g. "ISO27001 myths"
channels: # list — a post can go to multiple channels
- linkedin
- newsletter
- blog
status: draft # draft | ready | scheduled | published
publish-dates: # ISO 8601, e.g. 2026-06-10; can be a list if channels differ
linkedin: 2026-06-10
newsletter: 2026-06-17
blog: 2026-06-17
published-urls: # fill in after publishing; one per channel
linkedin: ""
blog: ""
content-type: "" # post | article | newsletter-section | thread
source-notes: # vault notes this was drawn from
- "[[path/to/note]]"
tags: []
notetype: publication
isotags:
iso-id
audience
---
```

View file

@ -4,43 +4,36 @@ From [claude chat](https://claude.ai/share/614ce436-307d-4740-a79f-40225461e743)
```
---
title: ""
series: "" # slug for the series this belongs to, e.g. "access-control-basics"
title: "" # post title
series: "" # series title
series-slug: "" # series title as a slug, e.g. "access-control-basics"
series-part: 1 # position within the series; omit if standalone
theme: "" # broader topic cluster, e.g. "ISO27001 myths"
channel: # list — a post can go to multiple channels
channels: # list — a post can go to multiple channels
- linkedin
- newsletter
- blog
status: draft # draft | ready | scheduled | published
publish-date: # ISO 8601, e.g. 2026-06-10; can be a list if channels differ
publish-dates: # ISO 8601, e.g. 2026-06-10; can be a list if channels differ
linkedin: 2026-06-10
newsletter: 2026-06-17
blog: 2026-06-17
published-url: # fill in after publishing; one per channel
published-urls: # fill in after publishing; one per channel
linkedin: ""
blog: ""
content-type: "" # post | article | newsletter-section | thread
source-notes: # vault notes this was drawn from
- "[[path/to/note]]"
tags: []
notetype: publication
isotags:
iso-id
audience
---
```
### Folder structure to go with it
```
Content Factory/
Publishing/
Series/
access-control-basics/
part-1.md
part-2.md
Standalone/
some-one-off-post.md
```
Or if you prefer tag-based grouping over folders, skip the subfolders and rely on `series` + Dataview to surface series views.
---
@ -57,8 +50,3 @@ SORT publish-date ASC
---
### Issues to flag
- If you're already using front matter on content notes, check for conflicts with any existing `status` or `tags` fields before rolling this out.
- `published-url` will stay empty a lot. That's fine — it's a record, not a requirement.
- If posts get repurposed significantly between channels (not just reformatted), they probably deserve separate notes rather than one note with multiple channels listed.