terminate headings with at least 2 newlines

Signed-off-by: Rieks <RieksJ@users.noreply.github.com>

README.md

@@ -48,6 +48,7 @@ The Terminology Engine v2 (TEv2) uses additional header fields. These are define
 The `sidebars.js` file contains the basic mechanism for [distributing content among sections](https://v2.docusaurus.io/docs/docs-introduction#sidebar) and is self-explanatory (compare with the sidebar appearing [here](https://essif-lab.github.io/framework/docs/essifLab-project)). Subsections within the `.md` file (that is, tagged with `##`) will appear at the right part of the page (see for example [here](https://essif-lab.github.io/essif-lab/docs/infrastructure)).
 
 ## Inserting Images in docs
+
 <!-- **DEPRECATED** Images must be put inside the directory `static/images` and developers must refer to them using _relative_ urls.
 Example: ![eSSIF-Lab logo](../images/essif-lab%20logo.png)
 Docusaurus knows that the `../images` directory is inside the `static` directory, and thus process correctly.

docs/essifLab-collaborative-understanding.md

@@ -58,3 +58,4 @@ Here are some characteristics of the tools being supplied:
 - The glossary will be automatically updated as contributions to the Corpus of Terminology are being merged into the master branch.
 
 ## References
+

docs/essifLab-objectives.md

@@ -8,12 +8,15 @@ date: 20210601
 ---
 
 ## Purpose
+
 The purpose of the eSSIF-Lab is to specify, develop and validate technological and non-technological (e.g. [governance](@)) means that support people, businesses and governments to think about, design, adapt, and operate their (information) processes such that they can negotiate and conduct [business transactions](transaction@) with one another using the electronic support provided by the various SSI technologies.
 
 ## Objectives
+
 For this purpose, eSSIF-Lab has set the following [objectives](@) to realize:
 
 ### Empower European and other citizens
+
 The results of the work done in eSSIF-Lab should contribute to provide individuals with means that help them to electronically negotiate and conduct [transactions](@) in the widest sense of the word. Such means make it easier for them to participate in transactions, both on the Internet and in physical life.
 
 Criteria to determine that the [objective](@) is fulfilled include:
@@ -23,6 +26,7 @@ Criteria to determine that the [objective](@) is fulfilled include:
   - people find the provided means helpful as they seek to exercise their rights under privacy acts such as the [GDPR](https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_en).
 
 ### Empower European and other organizations and governments
+
 The results of the work done in eSSIF-Lab should contribute to provide [organizations](@) (e.g. enterprises, governments) with means that help them to electronically negotiate and conduct [transactions](@) in the widest sense of the word. Such means make it easier for them to participate in transactions, both on the Internet and in physical life.
 
 Criteria to determine that the [objective](@) is fulfilled include:
@@ -31,6 +35,7 @@ Criteria to determine that the [objective](@) is fulfilled include:
    - the efforts of satisfying the requirements regarding their duties under privacy acts such as the [GDPR](https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_en), and showing [compliance](@), is significantly reduced.
    - *new business ecosystem paradigms* materialize, with thousands of new jobs, many new job categories and new business opportunities for existing and new European companies.
 ### Design and Develop an SSI Infrastructure
+
 The [SSI-Infrastructure](@)* is the 'hard' (IT) Infrastructure that we need to generically support [parties](@) (enterprises, governments, individuals, ...). The result of the work done in eSSIF-Lab should contribute to the creation (and maintenance) of components that are fitting in an [SSI Infrastructure](@).
 
 Criteria to determine that the [objective](@) is fulfilled include:
@@ -39,6 +44,7 @@ Criteria to determine that the [objective](@) is fulfilled include:
 - 'documentation interoperability', i.e. ensuring/facilitating that documentation of the infrastructural (and perhaps other) components can use a single, well-defined [terminology](@) that is based on validated [mental models](pattern@).
 
 ### Design and Develop SSI Assurance Communities
+
 [SSI Assurance Communities](ssi-assurance-community@) (ACs) is the 'soft' Infrastructure that complements the (hard) [SSI Infrastructure](@). The result of the work done in eSSIF-Lab should contribute to the creation (and maintenance) of [communities](@) that provide [governance](@), [management](@) and optionally technical components and or services that facilitate the adoption of SSI and transformation of its members internal organization, processes and IT, such that it can start, or continue to use the [SSI infrastructure](@) and reap its projected benefits.
 
 Criteria to determine that the [objective](@) is fulfilled include:

docs/essifLab-pattern-list.md

@@ -30,59 +30,75 @@ Most changes of perspective do not have such large effects. If he had proposed t
 These are models that are mature (stable). They have been applied during several years in various circumstances, and have shown to be valid (when consistently and consequently applied). Therefore, they are proposed for widespread use (and further evaluation/validation).
 
 ### [Parties, Actors and Actions](party-actor-action@)
+
 The [Parties, Actors and Actions pattern](party-actor-action@) captures the foundational [concepts](@) and relations that we need for thinking about how things get done. It answers questions such as: 'Who/what does things?', 'How are their actions being guided/controlled?', 'Who [controls](controller@) whom/what?', 'Who/what may be held accountable?'.
 
 ### [Jurisdictions](pattern-jurisdiction@)
+
 The [Jurisdictions pattern](pattern-jurisdiction@) captures the [concepts](@) and relations that explain what a generic [jurisdiction](@) consists of, and relates it to [parties](@) and [legal entities](legal-entity@).
 
 ### [Guardianships](pattern-guardianship@)
+
 The [Guardianship pattern](pattern-guardianship@) captures the [concepts](@) and relations that explain what a generic guardianship consists of, and how it relates to [guardians](@), [dependents](@), [jurisdictions](@), etc.
 
 ## Models under review
 
 These are models that we think go a long way to being mature, but may contain flaws we haven't detected yet.
 ### [Terminology](pattern-terminology@)
+
 The [eSSIF-Lab Terminology Pattern](pattern-terminology@) will describe the relations between [terminology](@) artifacts such as '[concept](@)', '[term](@)', '[pattern](@)', '[mental model](pattern@)', '[glossary](@)' etc.
 
 ### [Identity](pattern-identity@)
+
 The [eSSIF-Lab Identity Pattern](pattern-identity@)
 - discusses difficulties that exist with the various/numerous meanings of the term 'identity',
 - postulates a [definition for identity](identity@) that relates to what a person or another entity actually _is_,
 - shows that it is comprised of [partial identities](partial-identity@) that are the actual artifacts we need to focus on in [SSI contexts](self-sovereign-identity@), and
 - shows how this relates to (attributes in) [credentials](@).
 
 ### [Identification](pattern-identification@)
+
 The [eSSIF-Lab Identity Pattern](pattern-identification@) will describe the concepts and relations that help to explain the mechanisms that a [party](@) uses to [identify](@) [entities](@), and mechanisms for communicating with another party such that both parties can identify an entity and know whether or not they identify the same entity.
 
 ### [Identifiers](pattern-identifier@)
+
 The [eSSIF-Lab Identity Pattern](pattern-identifier@) will describe the conceptual nature of [identifiers](@). Note that [identifiers](@) are very different from [identities](@).
 
 ### [Party Representation](party-representation@)
+
 The [Party Representation pattern](party-representation@) will capture the foundational concepts and relations that we need for thinking about how [parties](@) can represent one another in various circumstances, and answering questions such as 'in what ways can [parties](@) be represented?', 'what kind(s) of [entities](@) can represent [parties](@)', 'how can we deal with representation constraints, i.e. provide guarantees that the represented [party](@) isn't completely at the mercy of the one representing it?'.
 
 ### [Governance and Management](pattern-governance-and-management@)
+
 The [Governance and Management Pattern](pattern-governance-and-management@) will explain how [parties](@) organize that [their](owner@) [objectives](@) are realized, either by doing the associated work themselves, or by arranging for other [parties](@) to do that. The contribution of this pattern is to show how this is done, based on the idea that every [objective](@) has a single [party](@) that [owns](@) the [objective](@).
 
 ### [Decentralized Governance, Risk Management and Compliance (GRC)](pattern-decentralized-grc@)
+
 The [Decentralized GRC pattern](pattern-decentralized-grc@) will describe how [parties](@) can set objectives, and pursue them to be successful. The latter means that the party must be capable of assessing and managing the risks associated with not realizing them. In a decentralized world, this means that it needs to depend on other parties, that may or may not be too reliable. Also, it means that the party must be able to set and realize objectives to satisfy requirements of other parties ([compliance](@)).
 
 ## Envisaged Models
 
 These are placeholders for models that we think we could document, but haven't come around to doing.
 
 ### [eSSIF-Lab World Model](pattern-world-model@)
+
 The [eSSIF-Lab World Model](pattern-world-model@) will describe the basic [concepts](@), relations between them ([patterns](@)), and principles (that are the starting point for eSSIF-Lab's thinking) that eSSIF-Lab proposes as a basis for designing, implementing and deploying architectures, processes and technologies that aim to support (autonomous, [self-sovereign](self-sovereignty@)) [parties](@) as they negotiate and execute electronic [transactions](@) with one another.
 
 ### [Trust](pattern-trust@)
+
 The [eSSIF-Lab Trust Pattern](pattern-trust@) will describe the conceptual nature of [trust](@) - limited to SSI contexts
 ### [Mandates, Delegation and Hiring](pattern-mandates-delegation-hiring@)
+
 The envisaged [Mandates, Delegation and Hiring pattern](pattern-mandates-delegation-hiring@) will capture the ideas behind Mandating, Delegating, Hiring and their relations. It will extend the [Parties, Actors and Actions pattern](party-actor-action@) with concepts that describe how the [ownership](@) and `works for` relations between [parties](@) and [actors](@) are to be (de)populated, and how to determine for [party](@) the [actor](@) is working as it executes an [action](@).
 
 ### [Duties and Rights](pattern-duties-and-rights@)
+
 The [Duties and Rights pattern](pattern-duties-and-rights@) will describe the relations between [jurisdictions](@), [legal entities](legal-entity@) and the duties and rights they have within them. This pattern will be based on the [theory of Hohfeld](https://plato.stanford.edu/entries/rights/#FormRighHohfAnalSyst).
 
 ### [Decision Making](pattern-decision-making@)
+
 The [Decision Making pattern](pattern-decision-making@) will describe how [parties](@) would, could, or should reason in order to reach good conclusions and make good decisions. This can be used as a basis for understanding the information needs of  [parties](@) as they need to decide e.g. whether or not to commit to a [transaction](@) proposal, or whether or not data is [valid](validate@) for some purpose. The pattern is based on [Toulmin's model for reasoning](https://www.cambridge.org/core/books/uses-of-argument/26CF801BC12004587B66778297D5567C) (of which a pragmatical text can be found [here](https://owl.purdue.edu/owl/general_writing/academic_writing/historical_perspectives_on_argumentation/toulmin_argument.html)).
 
 ### [Semantics](pattern-semantics@)
+
 The [Semantics pattern](pattern-semantics@) describes the relations between (intangible) concepts that are part of a Party's Knowledge, and how they are (tangibly) represented. This mapping between what is known (yet is intangible) and what can actually be obtained, stored, processed and transmitted (because it is tangible) is otherwise known as a [semantics](@).

docs/essifLab-vision.md

@@ -24,6 +24,7 @@ Another fundamental category is called [actor](@), which is defined as an [entit
 
 A third fundamental category is called [jurisdiction](@), which is a foundational concept for organizing collaborations between [parties](@), e.g. in [communities](@) or [ecosystems](@). Basically, a jurisdiction acts as an [authority](@) that has mechanisms for defining and maintaining rules, enforcement thereof, and a mechanism for resolving conflicts within its [scope of control](@). More details can be found in the [jurisdictions pattern](pattern-jurisdiction@).
 ## Scope
+
 In order to enable [interactions](transaction@) between different [parties](@), as described in the [eSSIF-Lab vision](essifLab-vision), eSSIF-Lab focuses on the exchange and administration of relevant [data](@), with a particular focus on the [qualifications](qualified-data@) and other assurances that are provided and/or needed. This makes its results particularly relevant for administrative organizations such as governmental bodies, financial institutions and the like. However, *every* party will have use-cases in which it needs to (digitally) interact with other parties, so for them, the eSSIF-Lab work is relevant as well.
 
 A party usually cannot realize its objectives on its own. To do this, it needs to get itself organized, e.g. by defining the kinds of [actions](@) that might help to further the objectives, purchasing/hiring [actors](@) to do the work, managing the [policies](@) that specify how such actors should operate (making the policies appropriately accessible and interpretable). We use the term [governance](@) to refer to the activities/process that gets a party organized. The governance activities that are in scope of eSSIF-Lab relate to specifying the work, and maintaining the associated artifacts, that is related to the needs of parties as they (digitally) interact with one another.

docs/functional-components/functional-component-template.md

@@ -20,22 +20,27 @@ NOTE: This file contains further explanations in comments. You may need to edit
 -->
 
 ## Summary
+
 <!-- provide a text that summarizes the *functionality* of the component. This is a sort of TL;DR-section. -->
 
 ## Context Diagram
+
 <!-- insert a figure here that shows how your component relates to the other functional components, so that readers get an idea of where it belongs. You may want to add a few lines explaining the purpose of these relations. -->
 
 ## Functional Description
+
 <!-- describe the functionality of the component in all details that a reader may want to be informed about, e.g. for the purposes of
   - deeply understanding the component's function;
   - designing a technical component that implements the functionality;
   - designing a technical component that relates to this component (learning what this component can do for him/her)
 -->
 
 ## Functional API specification
+
 <!-- identify the various APIs, and provide a subsection `API xxx` for each of them -->
 
 ### API 'xxx'
+
 <!-- specify the following items for the API:
   - the purpose(s) (what objective(s) does (using) the API realize). We need this to establish whether or not the API is fit for such purpose(s).
   - a high-level protocol flow that allows people to understand its working at a functional level.

docs/notations-and-conventions.md

@@ -9,9 +9,11 @@ import useBaseUrl from '@docusaurus/useBaseUrl'
 This document provides an overview of the notations and conventions being used within eSSIF-Lab.
 
 ### RFC 2119
+
 We use keywords such as “shall”, “should”, “may” etc. as defined by [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
 ### Capitalization of words in mid-sentence
+
 A word in mid-sentence that is capitalized is a [term](@) that has a [definition](@) in the [Corpus of Terminology](corpus@). This allows readers to distinguish between the more colloquial meanings of words (by not capitalizing them) and those that are actually defined. We appreciate any feedback regarding our (im)proper use of this kind of capitalization of words.
 
 :::note

docs/saf.yaml

@@ -1,10 +1,17 @@
 #
+
 # This is a Scope Administration File that can be used in conjunction with TEv2.
+
 #
+
 # The first section defines meta-data concerning the scope itself, both for technical use and human use.
+
 # It shows where directories and files live that ar part of the scope, and also
+
 # ways in which people can contribute, raise issues, see what's going on, discuss, etc.
+
 #
+
 scope:
   scopetag: essiflab # identifier that curators have determined for this terminology
   scopedir: https://github.com/essif-lab/framework/tree/master/docs # URL of the scope-directory
@@ -23,18 +30,28 @@ scope:
       id: rieks.joosten
       at: tno.nl
 #
+
 # The second section contains a mapping between scopetags that are used within the scope, and the associated scopedirs.
+
 # This enables tools to find the [SAF](@) of these [scopes](@), and from there all other directories, files etc.
+
 # that live within them, e.g. to use/import their data.
+
 #
+
 scopes:  #
 - scopetag: tev2 # definition of (scope) tag(s) that are used within this scope to refer to a specific terminology
   scopedir: https://github.com/tno-terminology-design/tev2-specifications/tree/main/docs # URL of the scope-directory
 #
+
 # The third section specifies the versions that are actively maintained by the curators.
+
 # For each version, the set of terms is selected that constitute the terminology.
+
 # See the Glossary Generation Tool (GGT) for details about the syntax and semantics.
+
 #
+
 versions:
   - vsntag: default # this version contains all terms that are curated by essiflab
     altvsntags: [ latest, documentation, terms ] # alternative verstiontags

docs/terminology-config.yaml

@@ -1,15 +1,18 @@
 # TNO Terminology Design tools configuration file (yaml)
 
 ## General
+
 scopedir: docs # path of the scope directory where the SAF is located
 onNotExist: warn # the action in case a `vsntag` was specified, but wasn't found in the SAF
 output: . # (root) directory for output files to be written to
 
 ## Machine Readable Glossary Tool
+
 mrgt:
   vsntag: # versiontag for which the MRG needs to be (re)generated. Leave empty to process all versions
 
 ## Human Readable Glossary Tool
+
 hrgt:
   interpreter: basic
   converter: |+
@@ -20,6 +23,7 @@ hrgt:
     - "docs/glossary.md"
 
 ## Term Reference Resolution Tool
+
 trrt:
   interpreter: # type of interpreter, either: a regex, "alt", or "basic"
     (?:(?<=[^`\\])|^)\[(?=[^@\]]+\]\([#a-z0-9_-]*@[:a-z0-9_-]*\))(?<showtext>[^\n\]@]+)\]\((?:(?<id>[a-z0-9_-]*)?(?:#(?<trait>[a-z0-9_-]+))?)?@(?<scopetag>[a-z0-9_-]*)(?::(?<vsntag>[a-z0-9_-]+))?\)

docs/terminology-design/manuals/authoring.md

@@ -2,6 +2,7 @@
 id: authoring
 sidebar_label: Authoring
 # displayed_sidebar:terminologyDesignSideBar
+
 scopetag: termdsn
 date: 20230111
 ---

docs/terminology-design/manuals/contributing.md

@@ -2,6 +2,7 @@
 id: contributing
 sidebar_label: Contributing
 # displayed_sidebar:terminologyDesignSideBar
+
 scopetag: termdsn
 date: 20230111
 ---

docs/terminology-design/manuals/curating.md

@@ -2,6 +2,7 @@
 id: curating
 sidebar_label: Curating
 # displayed_sidebar:terminologyDesignSideBar
+
 scopetag: termdsn
 date: 20230111
 ---

docs/terminology-design/methods.md

@@ -16,6 +16,7 @@ export const mark = ({text}) => ( <span style={{ color:'black', backgroundColor:
 />
 
 ## Summary
+
 The (high-level) process that we call **Terminology Design** aims to establish and maintain [terminologies](@) for various [contexts](@) that are suitable for, e.g.:
 - creating and maintaining e.g.,:
   - a common understanding between a group of people that work together as they pursue specific objectives;