diff --git a/README.md b/README.md
index cd7a4c73129402e77958c0b0403fa14ba6b3c2a1..abeefc2a9c1defb5a821a2e65a07120774ed876d 100644
--- a/README.md
+++ b/README.md
@@ -161,7 +161,7 @@ and it needs to consist of the following structure:
 ---
 id: term
 title: Term page
-hoverText: This hover text will appear in the documentation page that you reference this term
+hoverText: "This hover text will appear in the documentation page that you reference this term."
 ---
 
 ### Term explanation
diff --git a/docs/functional-architecture.md b/docs/functional-architecture.md
index 94155346347f42a3d304df81b0c2c2a45582e5b4..588c7aca7c332b0cb2f04168474ce267d98f4c2e 100644
--- a/docs/functional-architecture.md
+++ b/docs/functional-architecture.md
@@ -26,11 +26,11 @@ Figure 1 shows the initial *functional* eSSIF-Lab architecture, and its scope, c
 
 Please be aware that *functional* capabilities, components, %%agents|agent%%, etc. do not necessarily coincide with *technical* capabilities, components, %%agents|agent%%, 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 %%issuer|issuer%%, %%wallet|wallet%%, %%holder|holder%% and %%verifier|verifier%% functional components as well as other functionalities that are not described here, e.g. related to UX, setting %%preferences|policy%%, and more. In this functional architecture, the default type of components, %%agents|agent%% etc. are *functional*.
 
-Since the %%participants|participant%% of a %%business transaction|transaction%% are different %%parties|party%%, the negotiation, commitment and execution of that %%transaction|transaction%% will be done by %%agents|agent%% of these %%parties|party%%. Assuming that a single %%transaction|transaction%% has two such %%parties|party%%, we will use the term '%%Peer Party|peer-party%% (of a specific %%party|party%%, in the context of a single %transaction)' to refer to the participating %%party|party%% in that %%transaction|transaction%% that is not the specific %%party|party%% itself.
+Since the %%participants|participant%% of a %%(business) transaction|transaction%% are different %%parties|party%%, the negotiation, commitment and execution of that %%transaction|transaction%% will be done by %%agents|agent%% of these %%parties|party%%. Assuming that a single %%transaction|transaction%% has two such %%parties|party%%, we will use the term '%%Peer Party|peer-party%% (of a specific %%party|party%%, in the context of a single %transaction)' to refer to the participating %%party|party%% in that %%transaction|transaction%% that is not the specific %%party|party%% itself.
 
 When an %%agent|agent%% is involved in such a %%transaction|transaction%%, it will be communicating with a component that it assumes to be an %%agent|agent%% of the %%peer party|peer-party%% of its %%principal|principal%% (the %%agent|agent%% may obtain further assurances for that, but that's outside the scope for now). We will use the term '%%peer agent|peer-agent%% (of a specific %%agent|agent%%, in the context of a single %%transaction|transaction%%)' to refer to an %%actor|actor%% with which the specific %%agent|agent%% has a communication session. Note that establishing whether or not an %%actor|actor%% is a %%Peer Agent|peer-agent%% does not necessarily require knowing who the %%peer party|peer-party%% actually is.
 
-The figure below is an overview of the most important *functional* components that any %%party|party%% needs to conduct electronic %%business transactions|transaction%%.
+The figure below is an overview of the most important *functional* components that any %%party|party%% needs to conduct electronic %%(business) transactions|transaction%%.
 
 <img
   alt="eSSIF-Lab Single Party Functional Architecture Overview"
@@ -47,7 +47,7 @@ The remainder of this chapter describes the layers and their components at a hig
 
 At the top of the figure are two business-related layers. Both are within the scope of the eSSIF-Lab project/architecture, yet they are outside the scope of the eSSIF-Lab infrastructure/architecture - that is because they are too business-specific.
 
-The top layer (in the red rounded rectangle) has the functions of actual %%business transactions|transaction%%: it starts with a %%transaction form|transaction-form%%, the data of which is valid, consistent and complete, from which the (business) decision can be made whether or not to engage in a %%business transaction|transaction%%, and that has everything necessary to actually execute that %%business transaction|transaction%%. The (administrative) results of such a %%business transaction|transaction%% are then stored in business data stores. We have put this layer in the eSSIF-Lab architecture for the single purpose of showing how the components of the bottom layer contribute to conduct %%business transactions|transaction%%.
+The top layer (in the red rounded rectangle) has the functions of actual %%transactions|transaction%%: it starts with a %%transaction form|transaction-form%%, the data of which is valid, consistent and complete, from which the (business) decision can be made whether or not to engage in a %%transaction|transaction%%, and that has everything necessary to actually execute that %%transaction|transaction%%. The (administrative) results of such a %%transaction|transaction%% are then stored in business data stores. We have put this layer in the eSSIF-Lab architecture for the single purpose of showing how the components of the bottom layer contribute to conduct %%transactions|transaction%%.
 
 The lower business layer contains two functional components, one for initiating %%transactions|transaction%% and the other for stating %%transaction|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|policy%% that contains business-specific %%policies|policy%%.
 
diff --git a/docs/terminology-plugin-instructions.md b/docs/terminology-plugin-instructions.md
index f37ff788e17670fbbcccd9c8eab4f9a6d4d61c0b..93d436662fa07533256b4ac4c766e829e8dae709 100644
--- a/docs/terminology-plugin-instructions.md
+++ b/docs/terminology-plugin-instructions.md
@@ -63,7 +63,7 @@ and it needs to consist of the following structure:
 id: term
 title: Term page
 stage: draft
-hoverText: This hover text will appear in the documentation page that you reference this term
+hoverText: "This hover text will appear in the documentation page that you reference this term."
 ---
 
 ### Term explanation
diff --git a/docs/terms/business-transaction.md b/docs/terms/business-transaction.md
new file mode 100644
index 0000000000000000000000000000000000000000..fb3c682ee44a52bcc2f76ed888ac9b937989f539
--- /dev/null
+++ b/docs/terms/business-transaction.md
@@ -0,0 +1,12 @@
+---
+id: business-transaction
+title: "Business Transaction"
+scopeid: essifLab
+type: concept
+typeid: business-transaction
+stage: draft
+hoverText: "Business Transaction: a Transaction that constitutes business of its participating Parties."
+glossaryText: "See: %%transaction^transaction%%)."
+---
+
+See: %%transaction^transaction%%
diff --git a/docs/terms/digital-communication-channel.md b/docs/terms/digital-communication-channel.md
index 05a77a629ef60d5e611370d24bd21f840f338ec4..972b564bc2a0f566f81ec45a57924288e6a14248 100644
--- a/docs/terms/digital-communication-channel.md
+++ b/docs/terms/digital-communication-channel.md
@@ -5,8 +5,8 @@ scopeid: essifLab
 type: concept
 typeid: digital-communication-channel
 stage: draft
-hoverText: "Digital Communication Channel: a digital means by which two Digital Actors can exchange messages with one another"
-glossaryText: "a digital means by which two %%digital actors^digital-actor%% can exchange messages with one another"
+hoverText: "Digital Communication Channel: a digital means by which two Digital Actors can exchange messages with one another."
+glossaryText: "a digital means by which two %%digital actors^digital-actor%% can exchange messages with one another."
 ---
 
 :::info Editor's note
diff --git a/docs/terms/transaction-proposal.md b/docs/terms/transaction-proposal.md
index 2b05bae731880f4ce90dd4fa89fa9c93c27a8209..c2949c72c76f714a072f01e2a3b0a4d407100d85 100644
--- a/docs/terms/transaction-proposal.md
+++ b/docs/terms/transaction-proposal.md
@@ -5,8 +5,8 @@ scopeid: essifLab
 type: concept
 typeid: transaction-proposal
 stage: draft
-hoverText: "Transaction (Agreement) Proposal: a Transaction Agreement that is 'in-the-making' (ranging from an empty document to a document that would be a Transaction Agreement if it were signed by all Participants)"
-glossaryText: "a %%transaction agreement^transaction-agreement%% that is 'in-the-making' (ranging from an empty document to a document that would be a %%transaction agreement^transaction-agreement%% if it were signed by all %%participants^participant%%)"
+hoverText: "Transaction (Agreement) Proposal: a Transaction Agreement that is 'in-the-making' (ranging from an empty document to a document that would be a Transaction Agreement if it were signed by all Participants)."
+glossaryText: "a %%transaction agreement^transaction-agreement%% that is 'in-the-making' (ranging from an empty document to a document that would be a %%transaction agreement^transaction-agreement%% if it were signed by all %%participants^participant%%)."
 ---
 
 :::info Editor's note
diff --git a/docs/terms/transaction.md b/docs/terms/transaction.md
index 0c968f6d2913722710d4a68c06efb36fe0a25ea4..7b03ca49e3b98ef3da7a59662876d403e256ef17 100644
--- a/docs/terms/transaction.md
+++ b/docs/terms/transaction.md
@@ -1,18 +1,18 @@
 ---
 id: transaction
-title: "(Business) Transaction"
+title: "Transaction"
 scopeid: essifLab
 type: concept
 typeid: transaction
 stage: draft
-hoverText: "(Business) Transaction: the exchange of goods, services, funds, or data between some Parties (called Participants of the Transaction)."
+hoverText: "Transaction: the exchange of goods, services, funds, or data between some Parties (called Participants of the Transaction)."
 glossaryText: "the exchange of goods, services, funds, or data between some %%parties^party%% (called %%participants^participant%% of the %%transaction^transaction%%)."
 ---
 
 import useBaseUrl from '@docusaurus/useBaseUrl'
 
 ### Short Description
-A **business transaction** is an exchange of goods, services, funds, or data between some %%parties|party%%. These %%parties|party%% are called the %%participants of the transaction|participant%%. A typical %%business transaction|transaction%% consists of three phases. In the first phase, a %%transaction agreement|transaction-agreement%% is negotiated between the participants. That phase ends when either participant quits the negotiation, or all participants commit to the transaction, which basically is a promise to the other participants that it will keep up its end of the %%transaction agreement|transaction-agreement%%. In the second phase, the participants work to fulfill their promise. That phase ends when they deliver the results, and inform their peers of that they're done. In the final phase, participants check whether or not they have received what was promised, and that it conforms the criteria in the transaction agreement. This may lead to some discussion and possible rectifications. The final phase ends either when one of the participants escalates (e.g. goes to court), or all results are accepted. This way of looking at %%business transactions|transaction%% has been described extensively in the [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) transaction model.
+A **transaction** is an exchange of goods, services, funds, or data between some %%parties|party%%. These %%parties|party%% are called the %%participants of the transaction|participant%%. A typical %%business transaction|transaction%% consists of three phases. In the first phase, a %%transaction agreement|transaction-agreement%% is negotiated between the participants. That phase ends when either participant quits the negotiation, or all participants commit to the transaction, which basically is a promise to the other participants that it will keep up its end of the %%transaction agreement|transaction-agreement%%. In the second phase, the participants work to fulfill their promise. That phase ends when they deliver the results, and inform their peers of that they're done. In the final phase, participants check whether or not they have received what was promised, and that it conforms the criteria in the transaction agreement. This may lead to some discussion and possible rectifications. The final phase ends either when one of the participants escalates (e.g. goes to court), or all results are accepted. This way of looking at %%business transactions|transaction%% has been described extensively in the [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) transaction model.
 
 :::info Editor's note
 TNO (or others) to provide further content/revisions.