added terms/figures such that we can actually see some difference in the...

added terms/figures such that we can actually see some difference in the architecture and other documents

docs/essif-lab-functional-architecture.md

@@ -20,6 +20,7 @@ In order to serve such purposes, we have found out that it is necessary that to
 In order to serve such purposes, we have found out that it is necessary that to make a strict and consequent distinction between people and Organizations that are capable of making decisions and bearing responsibility/accountability (we will use the term ‘%%Party|party%%’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘%%Actor|actor%%’ for that). This means that an Organization is always a Party, whereas we consider a person to be a Party at one time and an Actor at another time, and computers/robots (and SSI components) are always an Actor.
 >>>>>>> minor changes to demonstrate how it should work
 
+<<<<<<< HEAD
 <<<<<<< HEAD
 This distinction is necessary because Actors do things that Parties are accountable for. In order to know which Party is accountable for what actions, we need the ability to link Parties and Actors. When an Actor acts and a (single) specific Party is accountable for that, we say that the Actor is an ‘<Term popup="Agent (of a Party): Actor that is currently working on behalf of a Party." reference="agent">_Agent_</Term>’ for or of that Party (at that particular point in time). We say that this Actor acts ‘**on behalf of**’ that Party. Note that both humans and (running) applications may serve as Agents (human Agent or digital/electronic Agent respectively). A digital Agent that has one or more of the SSI functionalities we describe further down will be called an \`<Term popup="Agent that provides SSI services." reference="ssi-agent">_SSI-Agent_</Term>\`, and we say that the Party on whose behalf it operates is the ‘<Term popup="a Party that has the legal or rightful title to control something." reference="owner">_Owner_</Term>’ of that Agent. Also, we use the term \`**(digital/electronic or human) Colleague (of an Agent)**\` to refer to any other (electronic or human) Agent that acts on behalf of the same Party as this Agent.
 
@@ -36,6 +37,11 @@ This distinction is necessary because Actors do things that Parties are accounta
 
 Given these definitions, it is obvious that Parties are not necessarily capable of acting. However, we also would like to be able to generically use phrases such as ‘Party X does Y’. To this end we introduce the term \`%%Organization|organization%%\` as the collection of one specific Party and its Agents. When we say ‘Party X does Y’, this should be understood as that there is an Agent that does Y, where that Agent belongs to the same Organization as the specified Party.
 >>>>>>> docs stuff that should work with terminology engine v1
+=======
+This distinction is necessary because Actors do things that Parties are accountable for. In order to know which Party is accountable for what actions, we need the ability to link Parties and Actors. When an Actor acts and a (single) specific Party is accountable for that, we say that the Actor is an ‘%%Agent|agent%%’ for or of that Party (at that particular point in time). We say that this Actor acts ‘**on behalf of**’ that Party. Note that both humans and (running) applications may serve as Agents (human Agent or digital/electronic Agent respectively). A digital Agent that has one or more of the SSI functionalities we describe further down will be called an \`%%SSI-Agent|ssi-agent%%\`, and we say that the Party on whose behalf it operates is the ‘%%Owner|owner%%’ of that Agent. Also, we use the term \`**(digital/electronic or human) Colleague (of an Agent)**\` to refer to any other (electronic or human) Agent that acts on behalf of the same Party as this Agent.
+
+Given these definitions, it is obvious that Parties are not necessarily capable of acting. However, we also would like to be able to generically use phrases such as ‘Party X does Y’. To this end we introduce the term \`%%Organization|organization%%\` as the collection of one specific Party and its Agents. When we say ‘Party X does Y’, this should be understood as that there is an Agent that does Y, where that Agent belongs to the same Organization as the specified Party.
+>>>>>>> added terms/figures such that we can actually see some difference in the architecture and other documents
 
 We caution that the notions of being an ‘Agent’, ‘Owner’, ‘Colleague’, and being part of an ‘Organization’ are dynamic; they may frequently change over time and are never self-evident.
 
@@ -47,6 +53,7 @@ Figure 1 shows the initial *functional* eSSIF-Lab architecture, and its scope, c
 
 Please be aware that *functional* capabilities, components, Agents, etc. do not necessarily coincide with *technical* capabilities, components, Agents, etc. The technical components can be deployed (downloaded, installed, run), whereas a functional component is a provider of a specified set of capabilities/functionalities an implementation of which can be made part of a technical component. So it is conceivable that a technical component contains an implementation of wallet, holder and verifier functional components as well as other functionalities that are not described here, e.g. related to UX, setting preferences, and more. In this functional architecture, the default type of components, Agents etc. are *functional*.
 
+<<<<<<< HEAD
 <<<<<<< HEAD
 <<<<<<< HEAD
 Since the participants of a business transaction are different Parties, the negotiation, commitment and execution of that transaction will be done by Agents of these different Parties. Assuming that a single transaction has two such Parties, we will use the term ‘<Term popup="(Peer Party of a Party): the other Party that is a participant in a transaction of that Party." reference="peer-party">_Peer Party (of a specific Party, in the context of a single transaction)_</Term>’ to refer to the participating Party in that transaction that is not the specific Party itself.
@@ -62,6 +69,11 @@ Since the participants of a business transaction are different Parties, the nego
 
 When an Agent is involved in such a transaction, it will be communicating with a component that it assumes to be an Agent of the Peer Party of its Owner (the Agent may obtain further assurances for that, but that's outside the scope for now). We will use the term ‘%%Peer Agent (of a specific Agent, in the context of a single transaction)|peer-agent%%’ to refer to an Actor with which the specific Agent has a communications session. Note that establishing whether or not an Actor is a Peer Agent does not necessarily require knowing who the Peer Party actually is.
 >>>>>>> docs stuff that should work with terminology engine v1
+=======
+Since the participants of a business transaction are different Parties, the negotiation, commitment and execution of that transaction will be done by Agents of these different Parties. Assuming that a single transaction has two such Parties, we will use the term ‘%%Peer Party (of a specific Party, in the context of a single transaction)|peer-party%%’ to refer to the participating Party in that transaction that is not the specific Party itself.
+
+When an Agent is involved in such a transaction, it will be communicating with a component that it assumes to be an Agent of the Peer Party of its Owner (the Agent may obtain further assurances for that, but that's outside the scope for now). We will use the term ‘%%Peer Agent (of a specific Agent, in the context of a single transaction)|peer-agent%%’ to refer to an Actor with which the specific Agent has a communications session. Note that establishing whether or not an Actor is a Peer Agent does not necessarily require knowing who the Peer Party actually is.
+>>>>>>> added terms/figures such that we can actually see some difference in the architecture and other documents
 
 The figure below is an overview of the most important *functional* components that any Party needs to conduct electronic business transactions.
 
@@ -81,6 +93,7 @@ The top layer (in the red rounded rectangle) has the functions of actual busines
 
 The lower business layer contains two functional components, one for initiating transactions and the other for stating transaction results (as per the [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) method), each of which with an associated business policy that contains business-specific policies/preferences.
 
+<<<<<<< HEAD
 <<<<<<< HEAD
 <<<<<<< HEAD
 The task of the <Term popup="transaction-validation-engine" reference="transaction-validation-engine">_Transaction Validation Engine_</Term> (or <Term popup="<Text that pops up when the user hovers over a reference to this concept>" reference="tve">_TVE_</Term>) is to handle and initiate requests from/to Peer Agents to engage in some kind of transaction, by negotiating and exchanging data (through one or more, physical or electronic communication channels), and to produce a transaction form whose contents are complete and valid, enabling an appropriate Colleague to decide whether or not to engage in the transaction. Note that negotiating a transaction has two parts: requesting a Peer Agent to provide data that its Owner needs, and providing data on behalf of its Owner that a Peer Agent requests. After all, a business transaction can only start after all Parties have decided to commit, which they can only do after each of them has obtained the information it (subjectively) needs to do so. Also note that data that the TVE must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels.
@@ -96,6 +109,11 @@ The task of the %%Transaction (Validation) Engine|transaction-validation-engine%
 
 The task of the %%Transaction Result Dispatcher|transaction-result-dispatcher%% (or %%TRD|trd%%) is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. Since such state-data may change, issuing data that supersedes an earlier state implies the revocation of such a state.
 >>>>>>> docs stuff that should work with terminology engine v1
+=======
+The task of the %%Transaction (Validation) Engine|transaction-validation-engine%% (or %%TVE|tve%%) is to handle and initiate requests from/to Peer Agents to engage in some kind of transaction, by negotiating and exchanging data (through one or more, physical or electronic communication channels), and to produce a transaction form whose contents are complete and valid, enabling an appropriate Colleague to decide whether or not to engage in the transaction. Note that negotiating a transaction has two parts: requesting a Peer Agent to provide data that its Owner needs, and providing data on behalf of its Owner that a Peer Agent requests. After all, a business transaction can only start after all Parties have decided to commit, which they can only do after each of them has obtained the information it (subjectively) needs to do so. Also note that data that the TVE must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels.
+
+The task of the %%Transaction Result Dispatcher|transaction-result-dispatcher%% (or %%TRD|trd%%) is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. Since such state-data may change, issuing data that supersedes an earlier state implies the revocation of such a state.
+>>>>>>> added terms/figures such that we can actually see some difference in the architecture and other documents
 
 Note that both components are within scope of eSSIF-Lab architecture, but NOT in scope of the eSSIF-Lab infrastructure, as they are too business-specific.
 

docs/terminology-plugin-instructions.md

@@ -113,6 +113,6 @@ Done in 1.53s.
 This will generate a file in `./docs/glossary.md` where every term that has been
 mentioned above, will be populated in the `glossary.md` page.
 
-When the project is up and running, you can visit the glossary on the `/docs/essifLab-glossary` page:
+When the project is up and running, you can visit the glossary on the `/docs/essif-lab-glossary` page:
 
  <img alt="glossary-page" src={useBaseUrl('images/glossary-page.png')}/>

docs/terms/action.md

@@ -4,7 +4,7 @@ title: "Action"
 scopeid: essifLab
 type: concept
 typeid: action
-hoverText: "hovertext for 'action'"
+hoverText: "something that is done by an actor"
 ---
 
 ## Criterion:

docs/terms/agent.md

@@ -8,7 +8,7 @@ hoverText: "Agent (of a Party): Actor that is currently working on behalf of a P
 ---
 
 ## Short Description
-An %%Actor|actor%% that is executing on action on behalf of some %%Party|party%%, which means that the execution of that action is subject to the conditions and other guidance set by that Party, then we say the Actor acts as an Agent of that Party. A Person, that is both an Actor and a Party can hence be seen as its own Agent. Agency is further detailed in the ['Party-Action' pattern|essifLab-pattern-party-action].
+An %%Actor|actor%% that is executing on action on behalf of some %%Party|party%%, which means that the execution of that action is subject to the conditions and other guidance set by that Party, then we say the Actor acts as an Agent of that Party. A Person, that is both an Actor and a Party can hence be seen as its own Agent. Agency is further detailed in the ['Party-Action' pattern|pattern-party-action].
 
 ## Criterion:
 %%Actor|actor%% that is momentarily executing an action on behalf of a %%Party|party%%.

docs/terms/concept-party.mdx

----
-id: party
-title: "Party"
-scopeid: essifLab
-type: concept
-typeid: party
-hoverText: "Entity that has knowledge about what exists, ways to reason with that knowledge, and ways for making decisions in a Self-Sovereign fashion."
----
-
-## Criterion:
-Entity that has knowledge about what exists, ways to reason[^1] with that knowledge, and ways for making decisions in a Self-Sovereign[^2] fashion.
-
-## Examples:
-People obviously qualify. Enterprises, governments, and other organizations also qualify as they can be seen as having their own knowledge (e.g. in their registrations, databases etc.), ways to reason with that knowledge (business rules, exercised by their employees or IT systems), and making decision. 
-
-Stones, pictures, ideas, etc. do not qualify. Also, electronic components do not qualify[^3].
-
-### xxx:
-to be elaborated
-
----
-[^1]: Reasoning means: inferring conclusions from data, regardless of the kind of logic that is being used, or whether the reasoning is coherent, or consistent.
-
-[^2]: This means that the party can do this all by itself. For humans, the rights for this are laid down e.g. in the [ECHR](https://www.echr.coe.int "European Convention of Human Rights") ([ECHR articles 9-11](https://www.echr.coe.int/Documents/Convention_ENG.pdf))
-
-[^3]: While the case can be made that (some) electronic components can reason, they do not do so in a self-sovereign fashion as intended by this definition. We do not want to discuss AI-equipment here.
\ No newline at end of file

docs/terms/entity.md

@@ -4,13 +4,12 @@ title: "Entity"
 scopeid: essifLab
 type: concept
 typeid: entity
-hoverText: "Something that is known to exist"
+hoverText: "something that is done by an actor"
 ---
 
 ## Criterion:
-Something that is known to exist within some %%knowledge|knowledge%%
 
 ## Criterion:
 Something, anything, that some %%party|party%% knows to exist
 
-### Xxx:
+### Background:

docs/terms/jurisdiction.md

@@ -4,7 +4,7 @@ title: "Jurisdiction"
 scopeid: essifLab
 type: concept
 typeid: jurisdiction
-hoverText: "jurisdiction - popuptext"
+hoverText: "jurisdiction - popuptext t.b.d."
 ---
 
 ## Short Description

docs/terms/knowledge.md

@@ -4,45 +4,11 @@ title: "Knowledge"
 scopeid: essifLab
 type: concept
 typeid: knowledge
-hoverText: "knowledge - popuptext"
+hoverText: "knowledge popover text"
 ---
 
-## Short Description
-<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
+## Criterion:
 
-## Purpose
-<!--Describe why the concept is needed. What purposes does it serve? What can you do with it that you cannot do (as well) without it? What objectives does it help realize? Why is this concept relevant within its scope of definition?-->
+## Examples:
 
-## Criteria
-<!--REQUIRED--How is this concept different from related ideas? What are essential characteristics that must be true? This is where you specify the [intensional definition](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions) of the concept, i.e. the necessary and sufficient conditions for when the term should be used. This makes that the concept becomes crystal clear. In the case of nouns, this is equivalent to specifying the properties that an object needs to have in order to be counted as a referent of the term.-->
-
-## Examples
-<!--Provide a few sentences in which you give examples that obviously qualify as instances of `<New Term>`, and that do NOT obviously qualify. Also, provide examples that are not (so) obvious, but help users to better understand its intension.-->
-
-## Related Concepts
-<!--Link to any concepts that are similar but distinct, with a note about the relationship.-->
-
-## Domains
-<!--In which general knowledge ecosystems or mental model families does this concept play a role?-->
-
-## Tags
-<!--Add hash tags here that allow us to group concepts in useful ways.-->
-
-## Use-cases
-<!--This (optional) section specifies an (optional) introductory paragraph, and a level-3 (i.e. `###`) subsection for every use case it describes. Every such use-case SHOULD
-- describe the situation/context of the use-case;
-- show how to apply `<New Term>` to/in that situation;
-- shows the relevance of having `<New Term>` for the use-case as opposed to not having it.-->
-
-## Notes
-<!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
-
-<!--
----
-## Footnotes
-
-[//]: # This (optional) section contains any footnotes that may have been specified in the text above.
-
-[^1]: the text for footnote [^1] goes here.
-
--->
+### Xxx:

docs/terms/objective.md

@@ -14,4 +14,4 @@ Something toward which effort is directed: an aim, goal, or end of action ([Merr
 Anything that, according to a %%Party|party%% c.q. its way of thinking, is important to be realized, qualifies as an Objective (and identifies its owner as that %%Party|party%%)
 
 ### Xxx:
-The %%Knowledge|knowledge%%/judgements of a %%Party|party%% are what makes something an %%Objectiv%%e (owned by that %%Party|party%%).
+The %%Knowledge|knowledge%%/judgements of a %%Party|party%% are what makes something an %%Objective (owned by that Party|party%%).

docs/terms/pattern-jurisdictions.md

@@ -2,14 +2,15 @@
 id: pattern-jurisdictions
 title: "Pattern: Jurisdictions (Scope: eSSIF-Lab)"
 scopeid: essifLab
-patternid: jurisdictions
-hoverText: "pattern-jurisdictions - hovertext"
+type: pattern
+typeid: jurisdictions
+hoverText: "jurisdiction pattern - popuptext t.b.d."
 ---
 <!-- A pattern captures/describes a set of concepts, relations between them, and rules or constraints that (instances) thereof comply with. As such, it is a concise and possibly formal description of a coherent set of ideas, a mental model if you will, that can be used to facilitate one's thinking about/with these concepts.
 Please fill in the placeholders in this file as follows:
-- `<existing-scopeID>`: machine readable text that identifies the scope in which this pattern is defined;
+- `<ExistingScopeID>`: machine readable text that identifies the scope in which this pattern is defined;
 - `<Existing Scope>`: human readable text that identifies the scope in which this pattern is defined;
-- `<NewPatternID>`: machine readable text that identifies this pattern within <existing-scopeID>;
+- `<NewPatternID>`: machine readable text that identifies this pattern within <ExistingScopeID>;
 - `<New Pattern>`: human readable text that identifies this pattern within <Existing Scope>;
 -->
 

docs/terms/pattern-mental-model.md

 ---
-id: pattern-mental-model
+id: essifLabTerminology-pattern-mental-model
 title: "Pattern: Mental Models (Scope: essifLabTerminology)"
 scopeid: essifLabTerminology
 type: pattern
@@ -33,4 +33,4 @@ Different terms can be used to identify the same concept. Car and Automobile are
 
 [^1]: the text for footnote [^1] goes here.
 
--->
\ No newline at end of file
+-->

docs/terms/pattern-party-action.md

@@ -2,7 +2,8 @@
 id: pattern-party-action
 title: "Pattern: Party-Action (Scope: eSSIF-Lab)"
 scopeid: essifLab
-patternid: party-action
+type: pattern
+typeid: party-action
 hoverText: "This pattern captures the foundational concepts and relations that we need for thinking about people (human beings), organizations, and how they interact with one another in a decentralized, self-sovereign way - which means that each of them decides for itself whether or not to interact with others, how to conduct such interactions, etc., thereby only taking external influences into account if they want, or have some need to do so."
 ---
 
@@ -18,15 +19,15 @@ TL;DR: This pattern models that %%Parties|party%% (humans, organizations) perfor
 
 The essential characteristic of %%Parties|party%% is their 1-1 link with %%Knowledge|knowledge%%, which they continually update and use e.g. for reasoning, decision making, and determining e.g. what to do, when, and with whom. %%Knowledge|knowledge%% not only includes (observable) facts, but also opinions, e.g. regarding the %%Entities|entity%% it knows to exist, relations between them, and rules (constraints, [logic](https://en.wikipedia.org/wiki/Logic)[^1]) that can be used to classify and reasoning about them, and for making decisions.
 
-Perhaps the most important idea in this pattern is that our %%Party|party%% concept is not considered to (be able to) act, and they need %%{{Actors|actor%%:Actor}} (i.e. %%Entities|entity%% that _can_ act) to act on their behalf and thus make them perform. This does, however,  not preclude having %%Entities|entity%% that are both %%Party|party%% and %%Actor|actor%% - e.g. humans - and that such %%Entities|entity%% can act on their ‘own’ behalf. And we can continue to use the commonly used form of speech in which a %%Party|party%% performs some %%Action%%, by realizing that this means that there is (at least) one %%Actor|actor%% that is actually executing that %%Action%%.
+Perhaps the most important idea in this pattern is that our %%Party|party%% concept is not considered to (be able to) act, and they need %%Actors|actor%% (i.e. %%Entities|entity%% that _can_ act) to act on their behalf and thus make them perform. This does, however,  not preclude having %%Entities|entity%% that are both %%Party|party%% and %%Actor|actor%% - e.g. humans - and that such %%Entities|entity%% can act on their ‘own’ behalf. And we can continue to use the commonly used form of speech in which a %%Party|party%% performs some Action  by realizing that this means that there is (at least) one %%Actor|actor%% that is actually executing that %%Action|action%%.
 
-In this pattern, %%Knowledge|knowledge%% takes center stage. %%Knowledge|knowledge%% contains %%Objectives|objective%% to be realized and managed. This not only triggers all sorts of %%Actions|action%% to be performed, but also guides their execution in terms of when an %%Action%% should start, when it terminates, which %%Actors|actor%% qualify for executing it, etc. Everything that is specific for a %%Party|party%% is reflected in its %%Knowledge|knowledge%%.
+In this pattern, %%Knowledge|knowledge%% takes center stage. %%Knowledge|knowledge%% contains %%Objectives|objective%% to be realized and managed. This not only triggers all sorts of %%Actions|action%% to be performed, but also guides their execution in terms of when an Action should start, when it terminates, which %%Actors|actor%% qualify for executing it, etc. Everything that is specific for a %%Party|party%% is reflected in its %%Knowledge|knowledge%%.
 
 This works well for human beings, which are both a %%Party|party%% and an %%Actor|actor%%. So a human being can act, implying itself as an %%Actor|actor%%, and using its personal %%Knowledge|knowledge%% as guidance. The model also works when a human being (as a %%Party|party%%) may hire someone else (as an %%Actor|actor%%), e.g. to fill in his tax return form. This other is guided by the %%Knowledge|knowledge%% of the human being that hired him, and uses its own %%Knowledge|knowledge%% for the details of filling in the tax form.
 
 It also works well for organizations, which are typically companies, enterprises, governments or parts thereof, i.e. groups of human beings and possibly other %%Actors|actor%% that, as a group, fit the criteria for being a %%Party|party%%. This group of %%Actors|actor%% would typically work to realize the organization’s %%Objectives|objective%%, being guided by the organization’s %%Knowledge|knowledge%% (registrations, policies, etc.). Like human beings, an organization may (have an appropriate %%Actor|actor%%) decide to hire or fire %%Actors|actor%% for longer or shorter periods.
 
-%%Parties|party%% set %%Objectives|objective%% that they seek to achieve, the most basic of which perhaps is its mission, or its ‘raison d'être’, to the realization of which all of its %%Actions|action%% are (ultimately) aimed. Every %%Objective%% is owned by a single %%Party|party%% (we do not consider ‘shared objectives’[^2]).
+%%Parties|party%% set %%Objectives|objective%% that they seek to achieve, the most basic of which perhaps is its mission, or its ‘raison d'être’, to the realization of which all of its %%Actions|action%% are (ultimately) aimed. Every Objective is owned by a single %%Party|party%% (we do not consider ‘shared objectives’[^2]).
 
 ## Notations
 <!--This (optional) section specifies the notations that are used, or refers to such a specification.-->

docs/terms/ssi-agent.md

 ---
-id: peer-agent
-title: "Peer Agent"
+id: ssi-agent
+title: "SSI Agent"
 scopeid: essifLab
 type: term
-typeid: peer-agent
+typeid: ssi-agent
 conceptref: essifLab:Agent
-hoverText: "(Peer Agent of a Agent): the other Agent with whom this Agent is communicating in the context of a transaction."
+hoverText: "Agent that provides SSI services."
 ---
 
 ## Purpose
 <!--State the purpose(s) for which it is necessary (or at least: desirable) to define <New Term>.-->
-%%Parties|party%% that participate in a (business) transaction may use %%Agents|agent%%, e.g. for conducting communications, exchanging information, etc. We need a term that can be used in the context of an Agent of such a Party to refer to an Actor with which that Agent communicates, and of which it has been established that it is actually an Agent of a %%Peer Party|peer-party%% of the Party for which it is communicating.
+
 
 ## Notes
 <!--Usually, the meaning of a term will not be _exactly_ the same as that of the concept to which it refers. Often, there are slight differences in meaning, or the term may emphasize specific characteristics of the concept, so as to accommodate specific needs of the scope in which it is defined. Please describe such deviations/emphasized characteristics in this section, and which needs that helps accommodate.-->

docs/terms/term.md

@@ -20,7 +20,7 @@ Understanding words or phrases uttered by others requires that we are able to 't
 
 ## Criteria
 <!--How is this concept different from related ideas? What are essential characteristics that must be true? This is where you specify the [intensional definition](https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions) of the concept, i.e. the necessary and sufficient conditions for when the term should be used. This makes that the conceptomes crystal clear. In the case of nouns, this is equivalent to specifying the properties that an object needs to have in order to be counted as a referent of the term.-->
-A Term MUST be a word or phrase that is linked to at least one %%context|scope%% and refers to precisely one %%concept|concept%%. 
+A Term MUST be a word or phrase that is linked to at least one %%context|scope%% and refers to precisely one %%concept|concept%%.
 
 ## Examples
 <!--Provide a few sentences in which you give examples that obviously qualify as instances of `Term`, and that do NOT obviously qualify. Also, provide examples that are not (so) obvious, but help users to better understand its intension.-->

docs/terms/terminology.md

@@ -28,11 +28,11 @@ This chapter reflects the learnings of eSSIf-Lab with respect to what such addit
 
 ## Context
 
-People use %%words and phrases (terms)|term%% to (tangibly) refer to the (intangible) %%ideas and thoughts (concepts)|concept%% they have, e.g. about what exists in the world, judgements they have, etc.<sup>[semantics]</sup>  This mapping of terms and concepts, which we call '[semantics](https://en.wikipedia.org/wiki/Semantics)', that is unique for each %%person or organization|party%%, enables them to reflect on their thoughts, and to convey such thoughts to others. Good communication however requires that the semantics of the communicating parties is sufficiently the same, so that the recipient of a communication will interpret it such that it means (sufficiently) the same to him as the communication means to its sender.
+People use %%words and phrases (terms)|term%% to (tangibly) refer to the (intangible) %%ideas and thoughts (concepts)|concept%% they have, e.g. about what exists in the world, judgements they have, etc.<sup>[semantics]</sup>  This mapping of terms and concepts, which we call '[semantics](wikipedia/semantics)', that is unique for each %%person or organization|party%%, enables them to reflect on their thoughts, and to convey such thoughts to others. Good communication however requires that the semantics of the communicating parties is sufficiently the same, so that the recipient of a communication will interpret it such that it means (sufficiently) the same to him as the communication means to its sender.
 
 The Concepts and Terminology part of eSSIF-Lab aims helps eSSIF-Lab community participants understand one another at whatever level of precision they need. This chapter presents a number of aids we will develop/maintain to serve that purpose.
 
-[semantics]: we use the term semantics|semantics%% to refer to the mapping between terms|term%% and %%concepts|concept%%. We use the term %%scope|scope%% ([OED](https://www.lexico.com/definition/scope)) to refer to the extent of the area or subject matter that a semantics is relevant and/or being used. From this definition, it seems obvious that every %%party|party%% has - and maintains - its own (subjective) semantics. The (erroneous) assumption that people (automatically) share a semantics is the cause of many misunderstandings. 
+[semantics]: we use the term semantics|semantics%% to refer to the mapping between terms|term%% and %%concepts|concept%%. We use the term %%scope|scope%% ([OED](https://www.lexico.com/definition/scope)) to refer to the extent of the area or subject matter that a semantics is relevant and/or being used. From this definition, it seems obvious that every %%party|party%% has - and maintains - its own (subjective) semantics. The (erroneous) assumption that people (automatically) share a semantics is the cause of many misunderstandings.
 
 ## Concepts, Terminologies, Glossaries, Dictionaries, etc.
 

docs/terms/trd.md

@@ -4,7 +4,7 @@ title: "TRD - Transaction Result Dispatcher"
 scopeid: essifLab
 type: concept
 typeid: trd
-hoverText: "trd - popuptext"
+hoverText: "trd - popuptext t.b.d."
 ---
 
 ## Short Description

docs/terms/tve.md

@@ -4,7 +4,7 @@ title: "TVE - Transaction Validation Engine"
 scopeid: essifLab
 type: concept
 typeid: tve
-hoverText: "tve - popuptext"
+hoverText: "tve - popuptext t.b.d."
 ---
 
 ## Short Description