moved a folder
This commit is contained in:
parent
5edd29361f
commit
5906aa163f
6 changed files with 67 additions and 3 deletions
40
metadata/Corpus overview notes.md
Normal file
40
metadata/Corpus overview notes.md
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
# Create corpus overview notes
|
||||
Here's a prompt you can use. Run it once per note or cluster of notes, feeding Claude the content each time.
|
||||
|
||||
---
|
||||
|
||||
**PROMPT – Replace [X] with your folder path before running it.**
|
||||
|
||||
You have access to my Obsidian vault via MCP. Read all notes in the folder [USER MUST SPECIFY FOLDERNAME] and process them into a structured corpus overview.
|
||||
|
||||
This overview will be used by an AI content strategist and writer to plan and draft content for ISO27DIY, a B2B SaaS product that helps SMEs implement ISO27001 without hiring consultants.
|
||||
|
||||
For each note or cluster of related notes, produce an overview entry in the following format:
|
||||
|
||||
---
|
||||
|
||||
**Title:** [note title or cluster name]
|
||||
**Path:** [filename or folder path — list each note path individually for clusters]
|
||||
**Summary:** [2-3 sentences on what this note actually contains — substance, not just topic]
|
||||
**Key concepts and terms:** [main concepts, frameworks, or terminology covered]
|
||||
**ISO27001 relevance:** [how this connects to ISO27001 implementation, compliance, or cybersecurity practice]
|
||||
**ISO27DIY relevance:** [how this could support product messaging, content marketing, or user education]
|
||||
**Related notes:** [other notes in the vault this connects to, if known]
|
||||
**Content potential:** [1-2 sentences on what kind of content this could fuel — articles, newsletter topics, LinkedIn posts, forum answers, etc.]
|
||||
**Fetch priority:** [High / Medium / Low — how often the content agents are likely to need the full note]
|
||||
|
||||
---
|
||||
|
||||
Rules:
|
||||
|
||||
- Be specific. Vague summaries are useless.
|
||||
- Do not invent content that isn't in the note. If something is unclear or thin, say so.
|
||||
- Group closely related notes under one entry but list each path individually.
|
||||
- Flag any note that seems outdated, incomplete, or too thin to be useful with a [REVIEW] tag after the title.
|
||||
- Process all notes in the folder before responding. Do not stop after the first note.
|
||||
---
|
||||
**How to use it**
|
||||
|
||||
Paste the prompt, then paste the raw content of one note or a group of related notes. Run it in batches. Once you have all the entries, compile them into a single Obsidian note called something like `_corpus-overview.md` and upload that to the Project knowledge base.
|
||||
|
||||
If your notes are well-tagged or linked in Obsidian, you can also group by tag or folder and process whole clusters at once, which saves a lot of runs.
|
||||
67
metadata/Metadata - ISO 27002 Themes and Attributes.md
Normal file
67
metadata/Metadata - ISO 27002 Themes and Attributes.md
Normal file
|
|
@ -0,0 +1,67 @@
|
|||
# ISO 27002 Themes and Attributes
|
||||
|
||||
## Themes
|
||||
|
||||
In ISO 27002, controls are categorized into four main themes:
|
||||
* **Organizational** (Clause 5 - all controls numbered 5.n)
|
||||
* **People** (Clause 6 - all controls numbered 6.n)
|
||||
* **Physical** (Clause 7 - all controls numbered 7.n)
|
||||
* **Technological** (Clause 8 - all controls numbered 8.n)
|
||||
|
||||
## Attributes
|
||||
|
||||
Every control is associated with five attributes, which allow organizations to view and categorize the controls from different perspectives. The attributes and their possible values are:
|
||||
|
||||
### Information Security Properties
|
||||
|
||||
Views controls from the perspective of which characteristic of information the control contributes to preserving.
|
||||
* Confidentiality
|
||||
* Integrity
|
||||
* Availability
|
||||
### Control Type
|
||||
|
||||
Views controls from the perspective of when and how the control modifies risk regarding the occurrence of an information security incident.
|
||||
* Preventive
|
||||
* Detective
|
||||
* Corrective
|
||||
|
||||
|
||||
### 3. Cybersecurity Concepts
|
||||
|
||||
Based on the cybersecurity framework concepts defined in ISO/IEC TS 27110.
|
||||
|
||||
|**Attribute**|**Description**|**Purpose**|**Control Examples**|
|
||||
|---|---|---|---|
|
||||
|**Identify**|Activities to understand the business context, the resources that support critical functions, and the related risks.|To develop the organizational understanding to manage risk to systems, assets, data, and capabilities.|Inventory of information (5.9), Risk assessment (5.1), Identification of legal requirements (5.31).|
|
||||
|**Protect**|Safeguards to ensure the delivery of critical infrastructure services and limit the impact of a potential security event.|To prevent or contain the impact of a potential cybersecurity event.|Access control (8.3), Information encryption (8.24), Secure authentication (8.5), Physical security (7.1).|
|
||||
|**Detect**|Activities to identify the occurrence of a cybersecurity event in a timely manner.|To enable timely discovery of security events to minimize damage.|Logging (8.15), Monitoring activities (8.16), Intrusion detection (8.1).|
|
||||
|**Respond**|Actions taken regarding a detected cybersecurity incident to contain its impact.|To take action once an incident is discovered to keep it from spreading or getting worse.|Incident response planning (5.24), Reporting events (5.25), Incident management (5.26).|
|
||||
|**Recover**|Activities to restore any capabilities or services that were impaired due to a cybersecurity incident.|To restore "business as usual" and support timely resilience.|Backup (8.13), ICT readiness for business continuity (5.30), Post-incident learning.|
|
||||
### 4. Operational Capabilities
|
||||
The Operational Capabilities help practitioners understand the functional area a control belongs to.
|
||||
|
||||
|**Capability**|**Description**|
|
||||
|---|---|
|
||||
|**Governance**|Policies, frameworks, and management oversight.|
|
||||
|**Asset Management**|Identification and protection of information assets and hardware.|
|
||||
|**Information Protection**|Technical and organizational measures to keep data secure.|
|
||||
|**Human Resource Security**|Security relating to the lifecycle of employment (hiring to termination).|
|
||||
|**Physical Security**|Protecting physical premises, equipment, and facilities.|
|
||||
|**System and Network Security**|Hardening infrastructure, managing traffic, and securing connections.|
|
||||
|**Application Security**|Security within software development and business applications.|
|
||||
|**Secure Configuration**|Standardizing settings for hardware, software, and services.|
|
||||
|**Identity and Access Management**|Managing who can access what (IAM).|
|
||||
|**Threat and Vulnerability Management**|Identifying risks and patching security holes.|
|
||||
|**Continuity**|Resilience and recovery planning for disruptions.|
|
||||
|**Supplier Relationships Security**|Managing risks from third parties and the supply chain.|
|
||||
|**Legal and Compliance**|Meeting laws, regulations, and contractual obligations.|
|
||||
|**Information Security Assurance**|Auditing and monitoring to ensure controls are working.|
|
||||
|**Information Security Incident Management**|Detecting and responding to security events.|
|
||||
|
||||
### 5. Security Domains
|
||||
|
||||
Views controls from the perspective of four high-level information security domains.
|
||||
* Governance_and_Ecosystem
|
||||
* Protection
|
||||
* Defence
|
||||
* Resilience
|
||||
79
metadata/Obsidian Front Matter Syntax.md
Normal file
79
metadata/Obsidian Front Matter Syntax.md
Normal file
|
|
@ -0,0 +1,79 @@
|
|||
# Obsidian Front Matter Syntax
|
||||
|
||||
**Obsidian’s front matter follows YAML syntax**, with a few **important caveats**.
|
||||
### What works (standard YAML)
|
||||
|
||||
Obsidian uses **YAML front matter** at the top of a note, delimited by `---`. Most standard YAML features work as expected, see this short example:
|
||||
|
||||
```YAML
|
||||
---
|
||||
|
||||
title: My Note
|
||||
|
||||
tags:
|
||||
|
||||
- obsidian
|
||||
|
||||
- yaml
|
||||
|
||||
published: true
|
||||
|
||||
rating: 4.5
|
||||
|
||||
created: 2026-04-21
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
|
||||
Obsidian calls these metadata variables 'Properties'. These include:
|
||||
|
||||
- Key–value pairs
|
||||
- Lists (arrays)
|
||||
- Booleans, numbers, strings, dates
|
||||
- Nested objects
|
||||
|
||||
|
||||
### Obsidian-specific limitations & quirks
|
||||
|
||||
Although it’s YAML, Obsidian does **not support the full YAML spec equally everywhere**:
|
||||
|
||||
1. **Tabs are not allowed**
|
||||
YAML requires spaces for indentation. Tabs can break parsing.
|
||||
|
||||
2. **Advanced YAML features may not be recognized** These may technically be valid YAML but are not reliably usable in Obsidian:
|
||||
|
||||
- Anchors (`&` / `*`)
|
||||
- Complex inline objects
|
||||
- Multi-document YAML
|
||||
|
||||
3. **Everything is treated as metadata, not logic** Obsidian doesn’t “execute” YAML — it just reads values for:
|
||||
|
||||
- Properties panel
|
||||
- Search
|
||||
- Filters
|
||||
- Plugins (e.g., Dataview)
|
||||
|
||||
4. **Some plugins impose their own expectations** For example:
|
||||
|
||||
- `tags` should usually be a list of strings
|
||||
- Dates may need to be ISO-like (`YYYY-MM-DD`) for queries to work
|
||||
|
||||
5. **Inline formatting is treated as plain text** Links or markdown inside front matter are just strings:
|
||||
|
||||
`author: "[[Richard Kranendonk]]"`
|
||||
``
|
||||
|
||||
### ✅ Best practice
|
||||
|
||||
Think of Obsidian front matter as:
|
||||
|
||||
> **“Well-behaved, simple YAML meant for metadata, not configuration logic.”**
|
||||
|
||||
Stick to:
|
||||
|
||||
- Scalars (strings, numbers, booleans)
|
||||
- Lists
|
||||
- Simple nesting
|
||||
- Spaces (not tabs)
|
||||
|
||||
37
metadata/_Corpus-metadata.md
Normal file
37
metadata/_Corpus-metadata.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
# Corpus Metadata
|
||||
|
||||
- All notes in this Obsidian vault need metadata.
|
||||
- These metadata need to follow the [Obsidian Front Matter Syntax](Obsidian%20Front%20Matter%20Syntax.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)
|
||||
|
||||
## General metadata
|
||||
|
||||
### 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.
|
||||
- `other`: for all notes that, by there content, cannot be placed in one for the previous categories.
|
||||
|
||||
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
|
||||
For the `language` property we use the language code as defined in ISO 639-1.
|
||||
|
||||
### 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 [Metadata - ISO 27002 Themes and Attributes](Metadata%20-%20ISO%2027002%20Themes%20and%20Attributes.md).
|
||||
|
||||
64
metadata/front-matter-for-marketing-posts.md
Normal file
64
metadata/front-matter-for-marketing-posts.md
Normal file
|
|
@ -0,0 +1,64 @@
|
|||
# Front matter for marketing posts
|
||||
|
||||
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"
|
||||
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
|
||||
- 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
|
||||
linkedin: 2026-06-10
|
||||
newsletter: 2026-06-17
|
||||
blog: 2026-06-17
|
||||
published-url: # 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: []
|
||||
---
|
||||
```
|
||||
|
||||
### 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.
|
||||
|
||||
---
|
||||
|
||||
### Dataview query to check what's scheduled
|
||||
|
||||
dataview
|
||||
|
||||
```dataview
|
||||
TABLE series, channel, publish-date, status
|
||||
FROM "Content Factory/Publishing"
|
||||
WHERE status != "published"
|
||||
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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue