popup texts revised; added a few terms - all for the purpose of making readers...

popup texts revised; added a few terms - all for the purpose of making readers better understand texts.

docs/notations-and-conventions.md

@@ -20,10 +20,12 @@ We are working towards deprecating this convention, as we now have better ways o
 
 %%Pattern|pattern%% diagrams will be visualized in this document using a UML-like notation, as follows:
 
-- a **rectangle** represents a (named) concept. Concepts serve as entity-classes. Their (operational) extensions, i.e. the respective sets of (runtime) instances, are disjunct. 
+- a **rectangle** represents a (named) concept that is explicitly defined. Concepts serve as entity-classes. Their (operational) extensions, i.e. the respective sets of (runtime) instances, are disjunct. 
+- A **rectangle that is coloured red(dish)** represents a (named) concept that is commonly used ‘in the wild’ (and hence needs not be defined here), relates to one or more concepts that are explicitly defined yet is not the same. We include such ‘red concepts’ to help readers identify and subsequently bridge gaps between commonly held thoughts and the (sometimes subtly) different meanings we need in our model.
 - a **solid line with a closed arrowhead** represent a (named) relation/association between the two concepts it connects. We may refer to the concept at the arrowhead as the ‘target concept’ (TGT) for that relation. Similarly, the concept at the other end will be referred to as the ‘source concept’ (SRC) for that relation. Names are chosen such that `<SRC> <relation name> <TGT>` is a phrase that suggests the intension(al definition) of that relation.
 - a **green name** at either end of a relation/association is what UML calls 'role'; this name may be used to refer to (an instance of) the concept at which the name is placed as it performs its/this role in this relation.
 - a **dashed line** signifies that its intension is created by combination the intensions of other relations (it is a ‘shorthand’ for a path of other relations).
-- an **open-ended arrow** is an ‘ISA’ relation, which can be read as `<SRC> ISA <TGT>`. It means that SRC is a specialization of TGT (which is a generalization of SRC). Thus, SRC must satisfy all constraints that TGT must satisfy, and has all attributes (including properties) that TGT has.
+- an **open-ended arrow** is an ‘ISA’ relation, which can be read as `<SRC> ISA <TGT>`. It means that SRC is a specialization of TGT (which in turn is a generalization of SRC). This implies that SRC must satisfy all constraints that TGT must satisfy, and also that it has all attributes (including properties) that TGT has.
+- a **solid line with a solid diamand** at one end is a composition; the element at the 'non-diamond-end' of the line is 'part of' (the 'part') the element at the 'diamond-end' of the line (the 'whole'); if the 'whole' ceases to exist, then its 'parts' also cease to exist.
+- a **solid line with a hollow diamand** at one end is an aggregation; the element at the 'non-diamond-end' of the line is 'part of' (the 'part') the element at the 'diamond-end' of the line (the 'whole'); if the 'whole' ceases to exist, then its 'parts' usually do not cease to exist, but 'live on'.
 - **Multiplicities** use the [n..m] notation. When a multiplicity is omitted, [0..n] is intended.
-- A **concept that is coloured red(dish)** represents a notion that is commonly used ‘in the wild’ (and hence needs not be defined here), relates to one or more concepts we need for the pattern, yet is not the same. We include such ‘red concepts’ to help readers identify and subsequently bridge gaps between commonly held thoughts and the (sometimes subtly) different meanings we need in our model.
\ No newline at end of file

docs/terms/action.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: action
 stage: draft
-hoverText: "Action: something that is actually done/executed (by a single Actor, as a single operation, for a given Party within a specific context)."
+hoverText: "Action: something that is actually done/executed - by a single Actor, as a single operation, for a given Party within a specific context."
 ---
 
 ### Short Description

docs/terms/agent.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: agent
 stage: draft
-hoverText: "Agent (of a Party): an Actor that is (at that point in time) executing an Action for, or on behalf of a Party (called the Principal of that Actor)."
+hoverText: "Agent (of a Party): an Actor that is executing an Action for, or on behalf of a Party (called the Principal of that Actor)."
 ---
 
 ### Short Description

docs/terms/author.md

+---
+id: author
+title: "Author"
+scopeid: essifLab
+type: concept
+typeid: author
+stage: draft
+hoverText: "Author (of data/document/file/...): the Party, on whose behalf that data/document/file/... has been created or updated."
+---
+
+:::info Editor's note
+TNO (or others) to provide the content of this file.
+:::
+

docs/terms/business-transaction.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: business-transaction
 stage: draft
-hoverText: "Business Transaction: the electronic exchange of goods, services, funds, or data between parties (called‘participants’ to the transaction)"
+hoverText: "Business Transaction: the exchange of goods, services, funds, or data between some Parties (called ‘participants’ of the transaction)"
 ---
 
 :::info Editor's note

docs/terms/colleague.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: colleague
 stage: draft
-hoverText: "Colleague (of an Agent): any other Agent that has the same Principal (i.e. Party on whose behalf they exeucte Actions)."
+hoverText: "Colleagues: two or more Digital Agents that all have the same Principal (i.e. Party on whose behalf they exeucte Actions)."
 ---
 
 :::info Editor's note

docs/terms/communication-channel.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: communication-channel
 stage: draft
-hoverText: "Communication Channel: a (digital or non-digital) means by which two Actors can exchange messages with one another"
+hoverText: "Communication Channel: a (digital or non-digital) means by which two Actors can exchange messages with one another."
 ---
 
 :::info Editor's note

docs/terms/concept.md

@@ -5,7 +5,7 @@ scopeid: essifLabTerminology
 type: concept
 typeid: concept
 stage: draft
-hoverText: "Concept: A Concept tries to capture the idea behind a classification of entities, allowing us to reason about everything in the class as if it were one thing."
+hoverText: "Concept: the ideas/thoughts behind a classification of Entities (what makes Entities in that class 'the same')."
 ---
 
 ### Short Description

docs/terms/credential.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: credential
 stage: draft
-hoverText: "Credential: data, representing a set of statements (claims) made by one Party (the author of the credential)."
+hoverText: "Credential: data, representing a set of statements (claims, assertions) made by one Party (the author of the credential)."
 ---
 
 :::info Editor's note

docs/terms/data-collector.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: data-collector
 stage: draft
-hoverText: "Data Collector: a functional component that collects sufficient and validated data for deciding whether or not a request (typically for a product or a service) is to be serviced."
+hoverText: "Data Collector: a functional component that collects sufficient and Validated Data for deciding whether or not a request (typically for a product or a service) is to be serviced."
 ---
 
 ## Short Description

docs/terms/definition.md

@@ -5,7 +5,7 @@ scopeid: essifLabTerminology
 type: concept
 typeid: definition
 stage: draft
-hoverText: "Definition: a text that helps Parties deeply/truly understand the meaning of a Term."
+hoverText: "Definition: a text that helps Parties deeply/truly understand the meaning of, or Concepts behind, a Term."
 ---
 
 ### Short Description

docs/terms/dictionary.md

@@ -5,7 +5,7 @@ scopeid: essifLabTerminology
 type: concept
 typeid: dictionary
 stage: draft
-hoverText: "Dictionary: an alphabetically sorted list of Terms and explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)."
+hoverText: "Dictionary: an alphabetically sorted list of Terms with various meanings they may have in different contexts."
 ---
 
 ### Short Description

docs/terms/digital-agent.md

@@ -6,7 +6,7 @@ type: term
 typeid: digital-agent
 conceptref: ":Agent"
 stage: draft
-hoverText: "Digital Agent: an Actor in the digital world (e.g. a running app, or a web-server) that is executing an Action for a specific Party (its Principal)."
+hoverText: "Digital Agent: an Agent in the digital world (e.g. a running app, or a web-server that is executing an Action for a specific Party (its Principal))."
 ---
 
 ### Purpose

docs/terms/digital-colleague.md

@@ -6,7 +6,7 @@ type: term
 typeid: digital-colleague
 conceptref: ":Colleague"
 stage: draft
-hoverText: "Digital Colleague (of an Agent): any (other) Digital Agent that has the same Principal (i.e. Party on whose behalf they exeucte Actions)."
+hoverText: "Digital Colleagues: two or more Digital Agents that all have the same Principal (i.e. Party on whose behalf they exeucte Actions)."
 ---
 
 ### Purpose

docs/terms/digital-policy.md

@@ -6,7 +6,7 @@ type: concept
 typeid: digital-policy
 conceptref: ":Policy"
 stage: draft
-hoverText: "Digital Policy: a machine-readable Policy (i.e. document that contains rules, working instructions or other guidance for Agents that can interpret such documents, so as to enable them to execute Actions on behalf of the Policy's author)."
+hoverText: "Digital Policy: a machine-readable Policy (i.e. a file that contains rules, working instructions or other guidance for Agents that can interpret such documents, so as to enable them to execute Actions on behalf of the Policy's Governor)."
 ---
 
 ### Short Description

docs/terms/employee.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: employee
 stage: draft
-hoverText: "Employee (of a Party): an Actor for whom/which it is realistic that it might execute Actions on behalf of that Party."
+hoverText: "Employee (of a Party): an Actor for whom/which it is realistic that it might execute Actions on behalf of that Party (called the Employer of that Actor)."
 ---
 
 :::info Editor's note

docs/terms/employer.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: employer
 stage: draft
-hoverText: "Employer (of an Actor): a Party on whose behalf this Actor might execute Ations."
+hoverText: "Employer (of an Actor): a Party on whose behalf this Actor (called an Employee of that Party) might execute Ations."
 ---
 
 :::info Editor's note

docs/terms/glossary.md

@@ -5,12 +5,12 @@ scopeid: essifLabTerminology
 type: concept
 typeid: glossary
 stage: draft
-hoverText: "Glossary: an alphabetically sorted list of Terms with explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s)."
+hoverText: "Glossary: an alphabetically sorted list of Terms with the (single) meaning it has in (at least) one context."
 ---
 
 ### Short Description
 <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
-A **glossary** is an alphabetically sorted list of %%terms|term%% with explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in some context(s). However, a glossary may also be created for the purpose of being included in other glossaries (as a construction aid to such glossaries), or for still other purposes.
+A **glossary** is an alphabetically sorted list of %%terms|term%% with explanations, usually aimed to help people understand texts around a certain (set of) topic(s) in (at least) one context. A glossary may also be created for the purpose of being included in other glossaries (as a construction aid to such glossaries), or for still other purposes.
 
 ### 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 conceptevant within its scope of definition?-->

docs/terms/jurisdiction-governor.md

+---
+id: jurisdiction-governor
+title: "Governor (of a Jurisdiction)"
+scopeid: essifLab
+type: concept
+typeid: jurisdiction-governor
+stage: draft
+hoverText: "Governor (of a Jurisdiction): the Party that operates the Legal System of that Jurisdiction."
+---
+
+:::info Editor's note
+TNO (or others) to provide the content of this file.
+:::
+

docs/terms/jurisdiction.md

@@ -5,12 +5,12 @@ scopeid: essifLab
 type: concept
 typeid: jurisdiction
 stage: draft
-hoverText: "Jurisdiction: a Legal System (legislation, enforcement thereof, and conflict resolution) that is operated by a Party in a certain Scope."
+hoverText: "Jurisdiction: a Legal System (legislation, enforcement thereof, and conflict resolution) that is governed by a Party in a certain Scope."
 ---
 
 ### Short Description
 <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
-A **Jurisdiction** is the composition of one %%scope|scope%%, one %%legal system|legal-system%% and one %%party|party%% that operates the legal system within that scope. While most people are familiar with what we call %%legal jurisdictions|legal-jurisdiction%%, please observe that %%organizations|organization%% habitually will have rules (business policies) in place, enforce them (to some extent), and have ways of resolving conflicts, and therefore qualify as a jurisdiction. Specifically, multi-national organizations are known to operate multiple jurisdictions, aliging the scopes with the scopes of other (often legal) jurisdictions for the purpose of preventing situations in which conflicting rules apply, which would lead to many effort-intensive conflict-resolution cases.
+A **Jurisdiction** is the composition of one %%scope|scope%%, one %%legal system|legal-system%% and one %%party|party%% (called the %%Governor of the Jurisdiction|jurisdiction-governor%%) that operates the legal system within that scope. While most people are familiar with what we call %%legal jurisdictions|legal-jurisdiction%%, please observe that %%organizations|organization%% habitually will have rules (business policies) in place, enforce them (to some extent), and have ways of resolving conflicts, and therefore qualify as a jurisdiction. Specifically, multi-national organizations are known to govern multiple jurisdictions, aliging the scopes with the scopes of other (often legal) jurisdictions for the purpose of preventing situations in which conflicting rules apply, which would lead to many effort-intensive conflict-resolution cases.
 
 ### 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?-->

docs/terms/knowledge-governor.md

+---
+id: knowledge-governor
+title: "Governor (of a Knowledge)"
+scopeid: essifLab
+type: concept
+typeid: knowledge-governor
+stage: draft
+hoverText: "Governor (of a Knowledge): the Party that is 1-1 associated with that knowledge."
+---
+
+:::info Editor's note
+TNO (or others) to provide the content of this file.
+:::
+

docs/terms/legal-jurisdiction.md

@@ -6,7 +6,7 @@ type: term
 typeid: legal-jurisdiction
 conceptref: essifLab:jurisdiction
 stage: draft
-hoverText: "Legal Jurisdiction: a Jurisdiction that is operated by a governmental body."
+hoverText: "Legal Jurisdiction: a Jurisdiction that is governed/operated by a governmental body."
 ---
 
 ### Purpose

docs/terms/objective.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: objective
 stage: draft
-hoverText: "Objective: Something toward which effort is directed: an aim, goal, or end of action (Merriam-Webster)."
+hoverText: "Objective: Something toward which a Party directs effort (an aim, goal, or end of action)."
 ---
 
 ### Short Description

docs/terms/party.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: party
 stage: draft
-hoverText: "Party: Entity that has Knowledge about what exists, ways to reason with that knowledge, and ways for making decisions in a Self-Sovereign fashion."
+hoverText: "Party: an Entity that has Objectives, Knowledge about what exists, rules that (should) apply, and some capability that allows it to reason, make decisions, generate and maintain Knowledge etc. in a Self-Sovereign fashion."
 ---
 
 ### Short Description

docs/terms/policy.md

@@ -26,9 +26,9 @@ The purpose of **policies** is to enable %%parties|party%% to provide its %%agen
 ### Criterion
 A **policy** is 
 - a (set of) rules, working instructions and/or other guidance for the execution of one or more kinds of %%actions|action%%;
-- is authored by a single %%Party|party%% (the author or %%owner|owner%% of the policy);
-- may have multiple representations of the rules, working instructions and/or other guidance, which are derived from the policy itself, in such a way that that any %%actor|actor%% that has a right or duty to execute an %%action|action%% on behalf of the policy's author can do so according to its intentions; 
-- is accessable to, and must be complied with by an %%agent|agent%% of that policy's author when it executes an action of the kind to which the policy applies.
+- governed by a single %%Party|party%% (the %%Governor|policy-governor%% of the policy) that decides what goes in the policy and what does not;
+- may have multiple representations of the rules, working instructions and/or other guidance, which are derived from the policy itself, in such a way that that any %%actor|actor%% that has a right or duty to execute an %%action|action%% on behalf of the  %%policy's governor|policy-governor%% can do so according to its intentions; 
+- is accessable to, and must be complied with by an %%agent|agent%% of that %%policy's governor|policy-governor%% when it executes an action of the kind to which the policy applies.
 
 ### Background
 The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file

docs/terms/presentation-request.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: presentation-request
 stage: draft
-hoverText: "Presentation Request: a (signed) digital message that a Verifier component sends to a Holder component asking for data from one or more Verifiable Credentials."
+hoverText: "Presentation Request: a (signed) digital message that a Verifier component sends to a Holder component asking for specific data from one or more Verifiable Credentials that are issued by specific Parties."
 ---
 
 :::info Editor's note

docs/terms/presentation.md

+---
+id: presentation
+title: "Presentation"
+scopeid: essifLab
+type: concept
+typeid: presentation
+stage: draft
+hoverText: "Presentation: a (signed) digital message that contains data derived from one or more Verifiable Credentials (that have been issued by Agents of one or more Parties), as a response to a specific Presentation Request of a Verifier component."
+---
+
+## Short Description
+
+## Purpose
+
+## Criteria
+
+
+## References
+- W3C has a [definition of verifiable presentation](https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations).
\ No newline at end of file

docs/terms/risk.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: risk
 stage: draft
-hoverText: "Risk: the deviation of the expected realization (e.g. results) of an Objective of a Party."
+hoverText: "Risk (of a Party's Objective): the deviation of the expected realization (e.g. results) of that Party's Objective."
 ---
 
 :::info Editor's note

docs/terms/validated-data.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: validated-data
 stage: draft
-hoverText: "Validated Data: data of which some Party has established that it is valid, and hence can be used, for some specific purpose(s)."
+hoverText: "Validated Data: data of which some Party has established that it is valid, and hence suitahble to be used for some specific purpose(s)."
 ---
 
 :::info Editor's note

docs/terms/verified-data.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: verified-data
 stage: draft
-hoverText: "Verified Data: data of which some Party has established that it is a truthful representation of what its author intended it to mean when the data was created."
+hoverText: "Verified Data: data of which some Party has established that it is a truthful representation of what its Author intended it to mean when the data was last created/updated."
 ---
 
 :::info Editor's note

docs/terms/verifier.md

@@ -26,7 +26,7 @@ The purpose of the Verifier component is to support the Data Collector by provid
 
 Typically, the Data Collector would ask the Verifier to provide a credential that it can use to fill in a (coherent set of) field(s) in the transaction form. It is realistic to think that credentials from different issuers - trusted by the Verifier’s Owner - can be used for this purpose. However, it is also realistic that such credentials will not use the same credential definition - they might well use different schemes to provide such data. Therefore, the Data Collector should specify a list of pairs (credential-type, issuer) instances of which could all be used to provide the data it needs - which it can obtain from the Data Collector policy.
 
-Then, the Verifier needs to know the address and protocol that it can use to reach a Holder component owned by the Party that its Owner is trying to negotiate the transaction with. The Data Collector specifies this as part of the request - and it can do so because it has received the original request, and does all communication channel handling.
+Then, the Verifier needs to know the address and protocol that it can use to reach a Holder component owned by the Party that its Owner is trying to negotiate the transaction with. The Data Collector specifies this as part of the request - and it can do so because it has received the original request, and does all communications channel handling.
 
 Verifiers are not expected to handle every kind of credential (e.g. VC’s, ABC’s, etc.) that exists, but rather a specific subset. For (at least one of) the credential types, the Verifier can construct a so-called presentation request, i.e. a message that is specific for the credential type and/or associated protocol, which it can then send to the Holder’s address.