From f98dbbee3f770c770908797797ba9addc88d2b68 Mon Sep 17 00:00:00 2001
From: RieksJ <rieks.joosten@tno.nl>
Date: Thu, 29 Oct 2020 14:41:17 +0100
Subject: [PATCH] minor updates

---
 README.md                                   |  2 +-
 docs/functional-architecture.md             |  6 +++---
 docs/terminology-plugin-instructions.md     |  2 +-
 docs/terms/business-transaction.md          | 12 ++++++++++++
 docs/terms/digital-communication-channel.md |  4 ++--
 docs/terms/transaction-proposal.md          |  4 ++--
 docs/terms/transaction.md                   |  6 +++---
 7 files changed, 24 insertions(+), 12 deletions(-)
 create mode 100644 docs/terms/business-transaction.md

diff --git a/README.md b/README.md
index cd7a4c7..abeefc2 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 9415534..588c7ac 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 f37ff78..93d4366 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 0000000..fb3c682
--- /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 05a77a6..972b564 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 2b05bae..c2949c7 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 0c968f6..7b03ca4 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.
-- 
GitLab