Merge branch 'terminology-rieks' into 'master'

Terminology rieks = update (still wip)

See merge request !9

README.md

@@ -139,7 +139,7 @@ e.g. `./docs/terms/party.md`. You can use the following syntax to reference
 this term in your documentation page:
 
 ```
-Some content that wants to reference the %%Party|party%% term
+Some content that wants to reference the %%party|party%% term
 ```
 
 When the script runs, this will be replaced as follows:

docs/functional-architecture.md

@@ -5,8 +5,6 @@ sidebar_label: Functional Architecture
 scopeid: essifLab
 ---
 
-import useBaseUrl from '@docusaurus/useBaseUrl';
-
 ## Purpose
 
 It is the intention of the eSSIF-Lab project to develop this functional architecture into a generic, and common basis that parties from different backgrounds can use e.g. for:

docs/governance.md

@@ -5,15 +5,13 @@ sidebar_label: Governance
 scopeid: essifLab
 ---
 
-import useBaseUrl from '@docusaurus/useBaseUrl';
-
 ## Purpose
-The [eSSIF-Lab functional architecture](functional-architecture) identifies and describes a variety of generic SSI functions (capabilities), such as %%holder|holder%%, %%verifier|verifier%%, %%issuer|issuer%%, %%wallet|wallet%%, and more. An %%actor|actor%% that can provide such (generic) capabilities can only _actually_ provide them for a %%party|party%% if it knows how to to comply with the %%rules, working-instructions and other guidance|policy%% of that party. 
+The [eSSIF-Lab functional architecture](functional-architecture) identifies and describes a variety of generic SSI functions (capabilities), such as %%holder|holder%%, %%verifier|verifier%%, %%issuer|issuer%%, %%wallet|wallet%%, and more. An %%actor|actor%% that can provide such (generic) capabilities can only _actually_ provide them for a %%party|party%% if it knows how to to comply with the %%rules, working-instructions, preferences and other guidance|policy%% of that %%party|party%%. 
 
 **Governance** is the process by which %%parties|party%% decide how to make decisions, how %%actors|actor%% that work on their behalf are to behave and operate, and ensure this guidance ends up in some document which we will call a %%policy|policy%%.
 
 ## Governance processes and Policies
-Within the context of eSSIF-lab, pretty much every function/capability that is defined also mentions a corresponding %%(digital) policy|digital-policy%% that is the place where rules, working-instructions and other guidance (e.g. preferences) are expected to be specified for the correct functioning of a technical component that may provide such a capability.
+Within the context of eSSIF-lab, pretty much every function/capability that is defined also mentions a corresponding %%(digital) policy|digital-policy%% that is the place where rules, working-instructions, preferences and other guidance (e.g. preferences) are expected to be specified for the correct functioning of a technical component that may provide such a capability.
 
 The structure of these %%digital policies|digital-policy%% depends on the design of the technical component, as different kinds of technical components that (still) implement the same capability may have limitations or additional features regarding that capability.
 

docs/project.md

@@ -4,7 +4,7 @@ title: The eSSIF-Lab Project
 sidebar_label: eSSIF-Lab Project
 ---
 
-The European Self-Sovereign Identity Lab ([eSSIF-Lab](https://essif-lab.eu/)) views itself as an ecosystem of parties 
+The European Self-Sovereign Identity Lab ([eSSIF-Lab](https://essif-lab.eu/)) views itself as an ecosystem of %%parties|party%% 
 that work together to make existing (and new) Self-Sovereign Identity (SSI) technology into 
 a scalable and interoperable infrastructure that businesses can use very easily
 for conducting (business) transactions with other businesses and individuals alike.

docs/terminology-contributions.md

@@ -5,8 +5,6 @@ sidebar_label: Contributing to the Terminology Effort
 scopeid: essifLab
 ---
 
-import useBaseUrl from '@docusaurus/useBaseUrl';
-
 :::info **UNDER CONSTRUCTION**
 TNO to provide further contents
 :::

docs/terminology-plugin-instructions.md

@@ -2,7 +2,7 @@
 id: terminology-plugin-instructions
 title: Terminology & Glossary plugin docs
 ---
-import useBaseUrl from '@docusaurus/useBaseUrl';
+import useBaseUrl from '@docusaurus/useBaseUrl'; // All other .md files get this statement automatically added.
 
 ### How it works
 
@@ -40,7 +40,7 @@ e.g. `./docs/terms/party.md`. You can use the following syntax to reference
 this term in your documentation page:
 
 ```
-Some content that wants to reference the %%Party|party%% term
+Some content that wants to reference the %%party|party%% term
 ```
 
 When the script runs, this will be replaced as follows:
@@ -96,7 +96,6 @@ and running, you can visit the test example on the `/docs/replacement-test` page
 
 <img alt="replacement-test" src={useBaseUrl('images/replacement-test.png')}/>
 
-
 ## Generate the glossary page
 
 If everything works well with the above procedure, you can then generate a
@@ -115,4 +114,4 @@ 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:
 
- <img alt="glossary-page" src={useBaseUrl('images/glossary-page.png')}/>
+ <img alt="glossary-page" src={useBaseUrl('docs/essifLab-glossary.md')}/>

docs/terms/action.md

@@ -5,17 +5,17 @@ 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
-An **Action** is something that is actually done/executed by a %%actor|actor%% in some context (i.e. in a specific place, at a specific time). During the time interval in which the action is executed, the actor may still execute other actions in other execution-contexts (multi-tasking). An action is executed for, or on behalf of, a specific %%party|party%%, which means that the primary guidance for executing the action, e.g. how to execute it, boundary conditions within which the execution must take place, etc., comes from a %%policy|policy%% that this party has established for actions of that kind. The actor is assumed to have appropriate access to that policy.
+An **Action** is something that is actually done/executed by a %%actor|actor%% in some context (i.e. in a specific place, at a specific time). During the time interval in which the action is executed, the actor may still execute other actions in other execution-contexts (multi-tasking). An action is executed for, or on behalf of, a specific %%party|party%%, which means that the primary guidance for executing the action, e.g. how to execute it, boundary conditions within which the execution must take place, etc., comes from a %%policy|policy%% that this %%party|party%% has established for actions of that kind. The actor is assumed to have appropriate access to that policy.
 
 ### Purpose
-The ability to distinguish between (non)actions allows one to determine which (kinds of) %%actors|actor%% are capable of executing actions (e.g. by establishing that they have the competences required by the party), and as a consequence may be permitted and/or required to execute them. Also, this ability enables parties to determine the execution-policy, i.e. the set of rules and other guidance that actors should obey or comply with when exeucting an action on its behalf.
+The ability to distinguish between (non)actions allows one to determine which (kinds of) %%actors|actor%% are capable of executing actions (e.g. by establishing that they have the competences required by the %%party|party%%), and as a consequence may be permitted and/or required to execute them. Also, this ability enables %%parties|party%% to determine the execution-policy, i.e. the set of rules, working-instructions, preferences and other guidance that actors should obey or comply with when exeucting an action on its behalf.
 
 ### Criterion
-An **Action** is something that is done by an actor, can be considered a single operation, and is performed in a specific context, for or on behalf of a specific party, i.e. in accordance with the policy rules that this party has established for such actions.
+An **Action** is something that is done by an actor, can be considered a single operation, and is performed in a specific context, for or on behalf of a specific %%party|party%%, i.e. in accordance with the policy rules that this %%party|party%% has established for such actions.
 
 ### Examples
 - filling in a form and submitting it.

docs/terms/agent.md

@@ -9,14 +9,14 @@ hoverText: "Agent (of a Party): an Actor that is executing an Action for, or on
 ---
 
 ### Short Description
-An **Agent** is an %%actor|actor%% that is executing an action %%action|action%% for, or on behalf of some %%party|party%% (which we call the %%principal|principal%% of that agent). During the time interval in which the action is executed, the actor may execute other actions in other execution-contexts, on behalf of the same or another party. However, for the execution of a single %%action|action%%, the actor is an agent for precisely one principal. It is assumed that the principal provides its agents with the %%policies|policy%% that provide the agents with the rules, working-instructions and/or other guidance that they need to comply with when exeucting the action.
+An **Agent** is an %%actor|actor%% that is executing an action %%action|action%% for, or on behalf of some %%party|party%% (which we call the %%principal|principal%% of that agent). During the time interval in which the action is executed, the actor may execute other actions in other execution-contexts, on behalf of the same or another %%party|party%%. However, for the execution of a single %%action|action%%, the actor is an agent for precisely one principal. It is assumed that the principal provides its agents with the %%policies|policy%% that provide the agents with the rules, working-instructions, preferences and other guidance that they need to comply with when exeucting the action.
 
 ### Purpose
 The ability to distinguish between (non)agents is relevant in many situations, including:
 - electronic communication: the agent 
 
 ### Criterion
-An **Agent** is a role that an %%actor|actor%% fulfills with respect to some %%party|party%% when that actor is executing some %%action|action%% for, or on behalf of that party.
+An **Agent** is a role that an %%actor|actor%% fulfills with respect to some %%party|party%% when that actor is executing some %%action|action%% for, or on behalf of that %%party|party%%.
 
 ### Examples
 

docs/terms/assertion.md

+---
+id: assertion
+title: "Assertion"
+scopeid: essifLab
+type: concept
+typeid: assertion
+stage: draft
+hoverText: "Assertion: a declaration/statement, made by a specific Party, that something is the case."
+---
+
+:::info Editor's note
+TNO (or others) to provide further content of this file.
+The content should describe that the Party is the (only) authority to dereference any identifiers used in the Assertion.
+:::
+
+### Short Description
+An **Assertion** is a declaration/statement that is made by one specific %%party|party%% (which we refer to as its %%owner|owner%%)[^1]. Such a statement may or may not reflect what that %%party|party%% holds or %%knows|knowledge%% to be true - %%parties|party%% may lie.
+
+The simplest kind of assertions come in the form ('subject', 'predicate', 'object'). For example, the triple ('John', 'is married to', 'Jill') says 'John is married to Jill'. Note that 'subject', 'predicate' and 'object' are all %%identifiers|identifier%% or other representations of the %%knowledge|knowledge%% to the assertion's %%owner|owner%%, and may not be dereferenceable in other contexts.
+
+### Purpose
+The ability to distinguish between assertions and non-assertions, and particularly to know its %%owner|owner%%, is prerequisite for properly interpreting it (to establish its meaning), determining its trustworthiness, deciding whether or not to (re)act, and if so, what that reaction would be.
+
+### Criterion
+An **Assertion** is any declaration/statement that is made by one specific %%party|party%%.
+
+-----
+[^1]: we postulate that 'Nature' is the %%jurisdiction|jurisdiction%% in which the associated %%ownership relation|ownership%% exists; so one might also call this 'natural ownership'.
\ No newline at end of file

docs/terms/business-transaction.md

@@ -5,22 +5,23 @@ scopeid: essifLab
 type: concept
 typeid: business-transaction
 stage: draft
-hoverText: "Business Transaction: the exchange of goods, services, funds, or data between some Parties (called ‘participants’ of the transaction)"
+hoverText: "Business Transaction: the exchange of goods, services, funds, or data between some Parties (called ‘participants’ of the 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|business-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|business-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 the content of this file.
+TNO (or others) to provide further content/revisions.
 :::
 
 :::info Editor's note
-Explanation required about 'commitment decisions' (i.e. 'promise' decisions in [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations)).
+Explanation required about '%%commitment decision|commitment-decision%%' (i.e. 'promise' decisions in [DEMO](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations)).
 :::
 
 ### High Level Example
 
-In its simplest form, this may be envisaged as one party (requestor) that requests another party (provider) to provide some product, e.g. a parking permit, by using his web-browser to navigate to the web-server of the provider (e.g. his municipality) where he is prompted to fill in a form to provide the details of his request (such as name, address, plate number, etc.). When the form is submitted, the provider decides whether or not to service the request (provide the parking permit) based on the data in the form, and take actions accordingly.
+In its simplest form, this may be envisaged as one %%party|party%% (requestor) that requests another %%party|party%% (provider) to provide some product, e.g. a parking permit, by using his web-browser to navigate to the web-server of the provider (e.g. his municipality) where he is prompted to fill in a form to provide the details of his request (such as name, address, plate number, etc.). When the form is submitted, the provider decides whether or not to service the request (provide the parking permit) based on the data in the form, and take actions accordingly.
 
 In order for this to work, the provider must design the form such that when a requestor submits a completed form, it can actually decide whether or not to service the request. This has two parts: first, the provider must specify the argument (i.e. the way of reasoning) that it uses to reach this decision - i.e. provide the parking permit. Doing so implicitly specifies the kinds of data that the form will ask for. Secondly, the provider must decide for each of the data it receives, whether or not it is valid to be used in that argument - the process of deciding this is called ‘validation’. Common criteria that help to make this distinction include whether or not the data is presented in the expected format, whether or not it is true (not so easy), whether it is not outdated, or whether or not it satisfies validation rules (in the example, the municipality may require that the specified license plate belongs to a car owned by the person that requests the permit). Validation is important, because reasoning with invalid data may result in wrong conclusions and cause damage.
 
@@ -35,9 +36,9 @@ The figure below is a high-level visualization of the filling in and validation
 
 *Figure 1. High-level visualization of the filling in and validation of a form.*
  
-The transaction that is envisaged here is the issuing of a parking permit. Participants are a person (requestor) that requests such a permit, and an organization (provider) that can issue such a permit. The requestor has one electronic agent, *the Requestor Agent (RA)*, i.e. an SSI-aware app on their mobile phone that can access a secure storage that contains ‘credentials’, i.e. data that is digitally signed by some third party, thus attesting to the truth of that data. The provider has two agents: one is an SSI-aware component *Provider Agent (PA_* that works with the web-server that presents the form, and the other is a person *P* whose task is to validate any data (on behalf of the provider) that is not validated electronically. The form itself contains a means, e.g. a QR-code or a deep-link, that allows *RA* and *PA* to set up a secure communication channel (e.g. SSL, [DIDComm](https://openssi.github.io/peer-did-method-spec/)) and agree on the specific form that needs to be filled in.
+The transaction that is envisaged here is the issuing of a parking permit. Participants are a person (requestor) that requests such a permit, and an organization (provider) that can issue such a permit. The requestor has one electronic agent, *the Requestor Agent (RA)*, i.e. an SSI-aware app on their mobile phone that can access a secure storage that contains ‘credentials’, i.e. data that is digitally signed by some third %%party|party%%, thus attesting to the truth of that data. The provider has two agents: one is an SSI-aware component *Provider Agent (PA_* that works with the web-server that presents the form, and the other is a person *P* whose task is to validate any data (on behalf of the provider) that is not validated electronically. The form itself contains a means, e.g. a QR-code or a deep-link, that allows *RA* and *PA* to set up a secure %%communication channel|communication-channel%% (e.g. SSL, [DIDComm](https://openssi.github.io/peer-did-method-spec/)) and agree on the specific form that needs to be filled in.
 
-After the *RA* and *PA* have established a communication channel and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy[^1]. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a ‘clean’ form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data.
+After the *RA* and *PA* have established a %%communication channel|communication-channel%% and agree on the form to be filled in, *PA* informs *RA* about the information it needs to fill in the form, and the requirements that this information should satisfy[^1]. *RA* then checks its data store to see whether or not such data is available, sends such data to *PA*, which subsequently validates it and uses it to fill in (appropriate parts of) the form. Finally, *P* validates the remaining data, which either results in a ‘clean’ form, i.e. a form that contains valid data that can subsequently be used to decide whether or not to provide the parking permit, or a message to the requester informing him about missing and/or invalid data.
 
 When the transaction has been completed, both participants can issue a credential that attests to the results of the transaction. For example, the provider could issue a credential stating that the requestor has obtained a parking permit for a car with a specific plate number (and other attributes). The requestor can store this credential and from that moment on use it in new electronic transactions.
 

docs/terms/commitment-decision.md

+---
+id: commitment-decision
+title: "Commitment Decision"
+scopeid: essifLab
+type: concept
+typeid: commitment-decision
+stage: draft
+hoverText: "Commitment Decision (of a Party regarding a Business Transaction): the decision of that Party regarding whether or not to commit to that Business Transaction, i.e. (promise) to fulfill the obligations that the associated Business Transaction Agreement assigns to that Party."
+---
+
+:::info Editor's note
+TNO (or others) to provide the content of this file.
+:::

docs/terms/credential.md

@@ -5,12 +5,31 @@ scopeid: essifLab
 type: concept
 typeid: credential
 stage: draft
-hoverText: "Credential: data, representing a set of statements (claims, assertions) made by one Party (the author of the credential)."
+hoverText: "Credential: data, representing a set of statements (claims, assertions), authored and signed by, or on behalf of, a specific Party."
 ---
 
-:::info Editor's note
-TNO (or others) to provide the content of this file.
-:::
+### Short Description
+A **credential** is a set of (related) %%assertions|assertion%% (also referred to as claims, or statements), to which metadata is added (e.g. date of issuing), and a number of proofs, which typically include a  proof of provenance (i.e. proof that it was created by, or on behalf of, a specific %%party|party%%), and a proof of integrity (i.e. proof that the data hasn't changed since it was issued). 
+
+In physical credentials, such as drivers licenses and passports, proofs of integrity usually apply to the physical document itself. They come in a variety of forms, such as the structure of the paper, holograms, watermarks, or (embedded) chips. The proof of provenance usually consists of the form-format of the credential and %%assertions|assertion%% about the document issuer.
+
+In digital credentials, such as (digital) certificates or %%verifiable credentials|verifiable-credential%%, the basic proofs (of provenance and integrity) usually consist of a digital signature of some kind. It therefor only 'works' for as long as the associated private/secret key actually remains a secret of the issuing %%party|party%%.
+
+Credentials whose %%assertions|assertion%% refer to some %%entity|entity%%, e.g. a person, an organization, an animal, a shipment, etc. In such cases, it must be possible for arbitrary %%parties|party%% to identify that %%entity|entity%%, and/or verify an %%assertion|assertion%% by some other %%party|party%% that identifies that %%entity%%. To this end, credentials may contain %%assertions|assertion%% about characteristics of that %%entity|entity%%, the idea being that if a %%party|party%% establishes that some %%entity|entity%% has (a sufficient number of) these characteristics, that %%entity|entity%% is the one bound to the credential. Attributes typically include one or more names, various dates, a photograph, etc. Other attributes might include biometrics, RFID-codes, bar-codes, etc.
+
+
+The signature on a credential may have other meanings. For example, a %%party|party%% may choose to only sign the credential data if it is convinced of the truth of the statements, in which case the credential 'payload' can be seen as an excerpt of the %%knowledge|knowledge%% of that %%party|party%%.
+
+Anyone can create any kind of credential containing any statement about anyone or anything. The mere fact that a statement comes in the form of a credential (i.e. with a signature) doesn't imply that it is true.
+
+### Purpose
+A **credential** serves to provide assurances regarding the provenance and integrity of data as it is being transferred between %%parties|party%%. Specializations of the generic credential concept may be created for the purpose of providing additional assurances.
+
+### Criteria
+A **credential** is the composition of
+- a non-empty set of arbitrary statements (claims, %%assertions|assertion%%) that originate from a single %%party|party%%;
+- a set of metadata (data about the credential itself);
+- a set of proofs, which includes at least proofs of provenance and integrity.
 
 ### Related Concepts
 - %%verifiable credential|verifiable-credential%%

docs/terms/definition.md

@@ -10,7 +10,7 @@ hoverText: "Definition: a text that helps Parties deeply/truly understand the me
 
 ### Short Description
 <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
-A **Definition** is a text that helps parties truly understand the meaning of a %%term|term%% as it is used in a communication. Because [terms are scoped](terminology), this 'truly understanding' of one another isn't trivial. Therefore, we insist that the explanatory text be a criterion that parties are expected to use in the same way in some %%scope(s)|scope%%, allowing them to establish whether or not they make the same determination as to whether or not something qualifies to be refered to by that term in a way that is independent of whether or not the (alledged) meaning is relevant for the purposes they pursue within that scope.
+A **Definition** is a text that helps %%parties|party%% truly understand the meaning of a %%term|term%% as it is used in a communication. Because [terms are scoped](terminology), this 'truly understanding' of one another isn't trivial. Therefore, we insist that the explanatory text be a criterion that %%parties|party%% are expected to use in the same way in some %%scope(s)|scope%%, allowing them to establish whether or not they make the same determination as to whether or not something qualifies to be refered to by that term in a way that is independent of whether or not the (alledged) meaning is relevant for the purposes they pursue within that scope.
 
 ### 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/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. 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)."
+hoverText: "Digital Policy: a machine-readable Policy (i.e. a file that contains rules, working-instructions, preferences and 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/entity.md

@@ -18,7 +18,7 @@ This term enables us to refer to anything, or to postulate the existence of some
 Something, anything, that some %%party|party%% knows to exist
 
 ### Related Concepts
-- a %%legal entity|legal-entity%% is an entity that is known by (i.e. registered in the %%knowledge|knowledge%% of) a %%party|party%% that operates the %%legal-system|legal-system%% of a %%jurisdiction|jurisdiction%%. (Details are in the %%Jurisdictions pattern|pattern-jurisdiction%%)
+- a %%legal entity|legal-entity%% is an entity that is known by (i.e. registered in the %%knowledge|knowledge%% of) a %%party|party%% that operates the %%legal system|legal-system%% of a %%jurisdiction|jurisdiction%%. (Details are in the %%Jurisdictions pattern|pattern-jurisdiction%%)
 
 ### Background
 The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.

docs/terms/essif-glue.md

@@ -5,16 +5,16 @@ scopeid: essifLab
 type: concept
 typeid: essif-glue
 stage: draft
-hoverText: "eSSIF-Glue: interface layer that allows components with Data Collector and/or Data Discloser functionality to use the Wallet, Holder, Issuer and Verifier functionalities."
+hoverText: "eSSIF-Glue: interface layer that allows components with Transaction Data Collector and/or Transaction Data Discloser functionality to use the Wallet, Holder, Issuer and Verifier functionalities."
 ---
 
 ### Short Description
-The **eSSIF-Glue** is an interface layer that consists of a documented set of APIs between the %%Data Collectordata-collector%% and %%Data Discloser|data-discloser%% on the one hand, and the Wallet, Holder, Issuer and Verifier (WHIV) components on the other hand. 
+The **eSSIF-Glue** is an interface layer that consists of a documented set of APIs between the %%Transaction Data Collector|transaction-data-collector%% and %%Transaction Data Discloser|transaction-data-discloser%% on the one hand, and the Wallet, Holder, Issuer and Verifier (WHIV) components on the other hand. 
 
- Ultimately, we would like to see these APIs standardized. Having such APIs allows different Parties to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. Parties can then select such WHIV components as they see fit.
+ Ultimately, we would like to see these APIs standardized. Having such APIs allows different %%parties|party%% to create their own version of the WHIV components, supporting the SSI technologies as they see fit, and shrinking or expanding functionalities as they feel appropriate. %%parties|party%% can then select such WHIV components as they see fit.
 
 ### Purpose
-The purpose of the essif-Glue APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%Data Collectordata-collector%% and %%Data Discloser|data-discloser%%
+The purpose of the essif-Glue APIs is to make calling the WHIV functions as simple as possible, given the functions of the %%Transaction Data Collector|transaction-data-collector%% and %%Transaction Data Discloser|transaction-data-discloser%%
 
 ### Criterion
 The set of API's described at https://gitlab.grnet.gr/essif-lab/tno-ssi-service/developer-docs.

docs/terms/governance.md

@@ -9,16 +9,16 @@ hoverText: "Governance: the act or process of governing or overseeing the contro
 ---
 
 ### Short Description
-**Governance** is the act (executed by, or behalf of some %%party|party%%) or process (of some %%party|party%%) of governing or overseeing the control and direction of something ([Merriam-Webster](https://www.merriam-webster.com/dictionary/governance)). Governance is about establishing the ways in which a party makes its decisions; they are 'meta-decisions': decisions about decision-making.
+**Governance** is the act (executed by, or behalf of some %%party|party%%) or process (of some %%party|party%%) of governing or overseeing the control and direction of something ([Merriam-Webster](https://www.merriam-webster.com/dictionary/governance)). The governance of a %%party|party%% is embodied by the set of processes by which it decides how to make (other) decisions, how %%actors|actor%% that it %%employs|employee%% are to behave and operate, and ensure this guidance ends up in documents (which we will call %%policies|policy%%).
 
-As parties interact with one another, i.e. conduct %%business transactions|business-transaction%%, they need to decide whether or not to commit to a transaction proposal. Deciding about how to make such a decision is one of the subjects of the governance process of that party: it is establishing the kind of argument that may be used to make this decision.
+As %%parties|party%% interact with one another, i.e. conduct %%business transactions|business-transaction%%, they need to decide whether or not to commit to a transaction proposal. Deciding about how to make such a decision is one of the subjects of the governance process of that %%party|party%%: it is establishing the kind of argument that may be used to make this decision.
 
 Within eSSIF-Lab, governance is pretty much limited to the governance of various %%policies|policy%%.
 
 ### Purpose
-The purpose for a %%party|party%% of having a **governance** process is that it enables him to reflect on the ways that it makes decisions. A typical topic for governance is the maintenance of the set of rules, working-instructions and other guidance that %%actors|actor%% are supposed, or required to use when executing specific %%actions|action%% on behalf of that %%party|party%%. 
+The purpose for a %%party|party%% of having a **governance** process is that it enables him to reflect on the ways that it makes decisions. A typical topic for governance is the maintenance of the set of rules, working-instructions, preferences and other guidance that %%actors|actor%% are supposed, or required to use when executing specific %%actions|action%% on behalf of that %%party|party%%. 
 
-For %%digital-actors%% such guidance consists of %%digital policies|digital-policy%%. A %%party|party%% whose governance process maintains a %%policy|policy%% will be called the %%governor|policy-governor%% of that policy.
+For %%digital-actors|digital-actor%% such guidance consists of %%digital policies|digital-policy%%. A %%party|party%% whose governance process maintains a %%policy|policy%% will be called the %%governor|policy-governor%% of that policy.
 
 ### Background
 The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides an overview of how this concept fits in with related concepts.
@@ -28,8 +28,8 @@ The %%Parties, Actors and Actions pattern|pattern-party-actor-action%% provides
 - %%Governor|policy-governor%%
 - %%Policy|policy%%
 - %%Digital Policy|digital-policy%%
-- %%Data Discloser Policy|data-collector-policy%%
-- %%Data Collector Policy|data-collector-policy%%
+- %%Transaction Data Discloser Policy|transaction-data-collector-policy%%
+- %%Transaction Data Collector Policy|transaction-data-collector-policy%%
 - %%Verifier Policy|verifier-policy%%
 - %%Issuer Policy|issuer-policy%%
 - %%Holder Policy|holder-policy%%

docs/terms/holder.md

@@ -25,7 +25,7 @@ A **Holder** is a component in the [eSSIF-Lab functional architecture](../functi
 
 Typically, a Holder component would access its %%owner|owner%%'s Wallet to check if it has a credential that it can use to construct a Presentation (i.e. response) that satisfies the received request.
 
-It may happen that the Wallet does not have such a credential. However, for every (credential, issuer) pair, the request should specify the URI that is capable of issuing such a credential. If or when the Holder Policy/Preferences permit this, the Holder then requests its Owner’s Data Collector to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Owner’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Owner’s Wallet.
+It may happen that the Wallet does not have such a credential. However, for every (credential, issuer) pair, the request should specify the URI that is capable of issuing such a credential. If or when the Holder Policy/Preferences permit this, the Holder then requests its Owner’s Transaction Data Collector to initiate a new transaction that will get the credential from that issuer, for which a clean transaction form would then consist of one that contains said credential. The Holder would then store it in its Owner’s Wallet, and then proceed to service the presentation request as if it had obtained that credential from its Owner’s Wallet.
 
 It may also happen that the Wallet has multiple credentials that satisfy the request, in which case the Holder must choose the one to use for constructing the presentation. Again, the Holder Policy/Preferences will specify how this choice needs to be made, and whether or not this can be done automatically by the Holder. If not, the Holder will need to provide for an interaction with a human Colleague that will make such decisions.
 

docs/terms/identifier.md

+---
+id: identifier
+title: "Identifier"
+scopeid: essifLab
+type: concept
+typeid: identifier
+stage: draft
+hoverText: "Identifier: a character string that is being used for identification purposes (yet may refer to 0, 1, or more Entities, depending on the context within which it is being used)."
+---
+
+### Short Description
+An **Identifier** is a character string that is being used for identification purposes (by a specific %%party|party%%).[^1] This includes names and labels, as they are (obviously) used for such purposes.
+
+Note that while an identifier is used for identification purposes, <u>this does not automatically imply that it actually identifies (singles out) anything</u>. It also depends on what [RFC 3986](https://tools.ietf.org/html/rfc3986) calls the 'scope of identification', or what [Pfitzmann and Hansen](https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf) refer to as an 'identifiability set', which are relevant for explaining whether or not (and if so: what) an identifier actually identifies (singles out) in a given context. See the [Discussion](./identifier#discussion---scope-of-identification) below.
+
+### Purpose
+%%Parties|party%% have a need to reason about %%things|entity%% they %%know|knowledge%% to exist, which requires them to have a conscious representation of such things, as well as the ability to identify (single) out individual entities. One way to do that is to tag an entity with a character string (label, name), that would then qualify as an identifier. 
+
+Also, identifiers may serve identification purpose in communications between different %%parties|party%%, the idea being that when one %%party|party%% mentions an identifier (that identifies some %%entity|entity%% for this %%party|party%% ) to another %%party|party%%, the latter would be able to determine the %%entity|entity%% that the first is talking about. See the [Discussion](./identifier#discussion---scope-of-identification) below.
+
+### Criterion
+An **Identifier** is a character string that is being used for identification purposes by a specific %%party|party%%.
+
+### Examples
+The following strings are examples: 'localhost', 'https://localhost/', 'Trust over IP community', 'the mayor of New York', 'guardianship', 'my mother', 'did:sov:2wJPyULfLLnYTEFYzByfUR', 'did:sov:2wJ', 'issue #24', etc., etc.
+
+### Discussion - Scope of Identification
+[RFC 3986, Section 1.1.](https://tools.ietf.org/html/rfc3986#section-1.1) states _"an identifier embodies the information required to distinguish what is being identified from all other things within <u>its</u> **scope of identification"**_. This statement suggests that identifiers (URIs) have a single scope, supposedly specified by "_the URI schemes and naming authority (if any)_". However, there is no such requirement, and there is nothing in place to guarantee this (apart from IANA, many other (sometimes even very commonly used) URI schemes exist). [Pfitzmann and Hansen](https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf) (section 13.2) use the term 'identifiability sets' rather than 'scope of identification', and describe how 'attackers' - but that could equally well have been regular users - each have, or construct their own scope, and use contextual information to do so.
+
+The criterion that makes a text string qualify as an identifier doesn't seem to cut it, as only _using_ a text for identification purposes doesn't make it have (what we will call) the 'identification property', i.e. the property that it _actually_ identifies something. It may only have that property in combination with an associated (single) scope of identification, which may depend on the context in which it is being used. [RFC 2986, page 6](https://tools.ietf.org/html/rfc3986#page-6) illustrates this using the identifier "http://lcoalhost/".
+
+The lack of (identifying) scopes of identification becomes an issue when a %%party|party%% (say Alice) sends the identifier (e.g. `my car`) to another %%party|party%% (say Bob), expecting that Bob will then be able to identify the same %%entity|entity%% that she identifies with it (presumably some specific car).
+
+If Bob had just met Alice for the first time, and hadn't seen her coming in a car, then Alice must acquaint Bob with the existence of the %%entity|entity%% that she refers to with `my car`, e.g. by pointing her finger to it, or describing the make, brand and license plate or some other characteristic that allows Bob to single out her car (in the context of their meeting one another). Then, Bob can 'register' the existence of that car in his %%knowledge|knowledge%% (optionally tagging it with an identifier of his own, e.g. `Alice's car`), and associate it with the attribute (party='Alice', identifier='`my car`'). It is important to have the "party='Alice'" part in there, because other parties, (e.g. Carol) may also use an identifier `my car`, which would and should then refer to another car. This shows that the scope of interpretation for an identifier has to do with the (%%knowledge|knowledge%% of) %%parties|party%% that use it, and that understanding the intended meaning requires a proper identification of that scope.
+
+-----
+[^1]: This is the definition of [RFC 3986, Section 1.1.](https://tools.ietf.org/html/rfc3986#section-1.1) but without the requirement of complying with URI syntax constraints. Note that there is consensus in the literature about this. For example, [(Allen, 2016)](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html) defines ‘Identifier’ as “A name or other label that uniquely identifies an identity.”. [Pfitzmann and Hansen, 2010](https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf) say (in footnote 57): “A name or another bit string”. The [DID-core specification](https://www.w3.org/TR/did-core/) of W3C [defines ‘decentralized identifiers’ as specializations of URIs](https://www.w3.org/TR/did-core/#dfn-decentralized-identifiers). 
+
+[^2]: While Pfitzmann and Hansen talk about 'attackers', it is trivial to also include 'non-attackers', i.e. your average user.
+
+[^3]: 

docs/terms/issuer.md

@@ -5,7 +5,7 @@ scopeid: essifLab
 type: concept
 typeid: issuer
 stage: draft
-hoverText: "Issuer (functional component): the capability to construct Credentials from data objects, according to the rules of its Principal's issuer-policy (specifically regarding the way in which the Credential is to be digitally signed), and pass it to the Wallet-component of its Principal allowing it to be issued."
+hoverText: "Issuer (functional component): the capability to construct Credentials from data objects, according to the content of its Principal's Issuer-Policy (specifically regarding the way in which the Credential is to be digitally signed), and pass it to the Wallet-component of its Principal allowing it to be issued."
 ---
 
 :::info Editor's note
@@ -13,7 +13,7 @@ TNO (or others) to provide additional content of this file.
 :::
 
 ### Short Description
-An **issuer** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that structures sets of (related) statements/claims (e.g. as produced by the %%Data Discloser|data-discloser%%) in a package, adds metadata which includes e.g. a timestamp at which this was done, ensures that it is digitally signed on behalf of its %%owner|owner%% (so that third %%parties|party%% can prove its provenance and integrity). Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer.
+An **issuer** is an (architectural) function (a functional component in the [eSSIF-Lab functional architecture](../functional-architecture)) that structures sets of (related) statements/claims (e.g. as produced by the %%Transaction Data Discloser|transaction-data-discloser%%) in a package, adds metadata which includes e.g. a timestamp at which this was done, ensures that it is digitally signed on behalf of its %%owner|owner%% (so that third %%parties|party%% can prove its provenance and integrity). Another function of the issuer is to handle revocation (and (un)suspension) of credentials that it has issued. For such tasks, it relies on functions that are made available by the SSI Protocols and Crypto Layer.
 
 ### Purpose
 The purpose of the Issuer function is.
@@ -25,13 +25,13 @@ A **Issuer** is a component in the [eSSIF-Lab functional architecture](../functi
 
 The purpose of the Issuer component is to issue ‘credentials’, i.e. digital constructs that contain
 
--   sets of (related) statements or claims (e.g. as produced by the Data Discloser)
+-   sets of (related) statements or claims (e.g. as produced by the Transaction Data Discloser)
 -   metadata (e.g. type of credential, date of issuing and expiration, endpoints, e.g. for revocation checking, credential definition, credential advertisements, credential enforcement policy, etc.)
--   proofs (e.g. a digital signature by which third Parties can prove its provenance and integrity.
+-   proofs (e.g. a digital signature by which third %%parties|party%% can prove its provenance and integrity.
 
 Another purpose that an Issuer might serve is to provide a means that allows any other Agent that somehow has obtained a copy or presentation of a credential, to verify whether or not the data therein is conformant to the business administration of its Owner. We will use the term ‘revocation service’ to refer to such means. Whether or not an Issuer provides such a service, and what kind of revocation service is provided (e.g. a revocation list, an online revocation status protocol, etc.), is a decision that its Owner should make, and specify in the Issuer Policies/Preferences.
 
-An Issuer component may issue credentials in various formats, e.g. as a Verifiable Credential (VC), an Attribute-Based Credential (ABC), an OpenID Connect/JWT token, etc. The issuing Party must specify credential-types in such a way that if the same credential is issued in different formats, it is possible for an arbitrary %%verifier|verifier%% to determine whether or not two credentials that have different formats, are in fact the same. One way of doing this is that the Issuer generates an identifier for every credential that it constructs (before expressing it in a specific format).
+An Issuer component may issue credentials in various formats, e.g. as a Verifiable Credential (VC), an Attribute-Based Credential (ABC), an OpenID Connect/JWT token, etc. The issuing %%party|party%% must specify credential-types in such a way that if the same credential is issued in different formats, it is possible for an arbitrary %%verifier|verifier%% to determine whether or not two credentials that have different formats, are in fact the same. One way of doing this is that the Issuer generates an identifier for every credential that it constructs (before expressing it in a specific format).
 
 After the issuer has created a credential (in one or more formats), it checks the wallet to see if it contains a credential of the same type for the same subject. If (one or more formats) are there, and their contents are the same as the newly created credential, the existing ones are revoked, deleted and/or archived/tombstoned.<sup>[Issuer.1]</sup> Then, the newly created credential is added to the wallet (in one or more formats). Thus, at any point in time, the wallet will contain an actual set of all credentials that have been issued.<sup>[Issuer.2]</sup>
 

docs/terms/jurisdiction.md

@@ -30,7 +30,7 @@ the composition of one %%scope|scope%%, one %%legal system|legal-system%% and on
 The %%Jurisdictions pattern|pattern-jurisdiction%% provides an overview of how this concept fits in with related concepts.
 
 ### Notes
-<!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
+The case can be made for Nature to qualify as a jurisdiction, postulating that this jurisdiction has a universal scope, its %%party|party%% would be 'Nature' itself (which can be argued to qualify as a %%party|party%%), and the %%legal system|legal-system%% that Nature operates are the 'laws of nature' (which Nature defines, enforces and settles disputes in). If one adopts this view, then people become (natural) %%owners|owner%% of e.g. %%assertions|assertion%%, their %%knowledge|knowledge%% etc. Also, natural resources (e.g. rivers) would be %%legal entities|legal-entity%% in that jurisdiction, since they are 'known, and recognized to exist' by Nature.
 
 <!--
 ---

docs/terms/knowledge.md

@@ -14,12 +14,12 @@ hoverText: "Knowledge: The (intangible) sum of what is known by a specific Party
 We limit the scope of a Knowledge to a %%party|party%% so as to allow for the existence of multiple such Knowledges, where each of them is internally consistent, yet may be inconsistent with other Knowledges.
 
 ### Purpose
-We need a term to refer to the (intangible) sum of what is known, the familiarity, awareness or understanding of someone or something of a %%party|party%%, because this is what allows the party to reason, and make decisions. When a party can successfully share (parts of) its knowledge, i.e. communicate it such that when another party interpret it, the intension is preserved, mutual understanding is achieved, which is prerequisite for doing business transactions and/or collaborating. 
+We need a term to refer to the (intangible) sum of what is known, the familiarity, awareness or understanding of someone or something of a %%party|party%%, because this is what allows the %%party|party%% to reason, and make decisions. When a %%party|party%% can successfully share (parts of) its knowledge, i.e. communicate it such that when another %%party|party%% interpret it, the intension is preserved, mutual understanding is achieved, which is prerequisite for doing %%business transactions|business-transaction%% and/or collaborating. 
 
 ### Criterion
-The intangible sum of what is known to some %%party|party%%, as well as the familiarity, awareness or understanding of someone or something by that party.
+The intangible sum of what is known to some %%party|party%%, as well as the familiarity, awareness or understanding of someone or something by that %%party|party%%.
 
 ### Notes
-- 'A knowledge' is 1-1 associated with a %%party|party%% (in a way, each knowledge defines that party).
-- a knowledge includes the rules that its party has decided constitutes valid [Logics](https://en.wikipedia.org/wiki/Logic) (i.e. rules for reasoning). Such logics are usually not [formal](https://en.wikipedia.org/wiki/Formal_system), or [mathematical logics](https://en.wikipedia.org/wiki/Mathematical_logic).
+- 'A knowledge' is 1-1 associated with a %%party|party%% (in a way, each knowledge defines that %%party|party%%).
+- a knowledge includes the rules that its %%party|party%% has decided constitutes valid [Logics](https://en.wikipedia.org/wiki/Logic) (i.e. rules for reasoning). Such logics are usually not [formal](https://en.wikipedia.org/wiki/Formal_system), or [mathematical logics](https://en.wikipedia.org/wiki/Mathematical_logic).
 - In order for reasoning with, or transferring Knowledge, it must be made explicit, e.g. in writing, speech, digitally or otherwise. The mapping of knowledge onto such representations is called ‘[semantics](https://en.wikipedia.org/wiki/Semantics)’. Every %%party|party%% determines which semantics it chooses to use.

docs/terms/legal-system.md

@@ -10,7 +10,7 @@ hoverText: "Legal-system: a system in which rules are defined, and mechanisms fo
 
 ### Short Description
 <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
-A **Legal System** is a system in which rules are defined ([legislature](https://en.wikipedia.org/wiki/Legislature)) and a mechanism for their enforcement is implicitly or explicitly defined ([executive](https://en.wikipedia.org/wiki/Executive_(government))), as well as a mechanism for conflict resolution ([judiciary](https://en.wikipedia.org/wiki/Judiciary)). A legal system is designed and governed by a single %%party|party%%. A legal system can be operationalized by assigning it a scope within which enforcement and conflict resolution are implemented. The associated operational tasks may be mandated or delegated to other parties. Depending on the individual legal system, ‘rules’ may be called ‘laws’, ‘regulations’, ‘directives’, ‘policies’, ‘working instructions’, etc. Other terms exist for specializations of these terms, e.g. ‘order’, ‘mandate’, and others.
+A **Legal System** is a system in which rules are defined ([legislature](https://en.wikipedia.org/wiki/Legislature)) and a mechanism for their enforcement is implicitly or explicitly defined ([executive](https://en.wikipedia.org/wiki/Executive_(government))), as well as a mechanism for conflict resolution ([judiciary](https://en.wikipedia.org/wiki/Judiciary)). A legal system is designed and governed by a single %%party|party%%. A legal system can be operationalized by assigning it a scope within which enforcement and conflict resolution are implemented. The associated operational tasks may be mandated or delegated to other %%parties|party%%. Depending on the individual legal system, ‘rules’ may be called ‘laws’, ‘regulations’, ‘directives’, ‘policies’, ‘working instructions’, etc. Other terms exist for specializations of these terms, e.g. ‘order’, ‘mandate’, and others.
 
 ### 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/objective.md

@@ -9,16 +9,16 @@ hoverText: "Objective: Something toward which a Party directs effort (an aim, go
 ---
 
 ### Short Description
-**Objectives** drive %%parties|party%% as they make their goals explicit, the primary one of which is also referred to as the **mission** of that party. A party's objectives are part of its %%knowledge|knowledge%%. When made available to %%agents|agent%% of that party, these agents can do the work that is needed to reach these goals (realize the party's objectives).
+**Objectives** drive %%parties|party%% as they make their goals explicit, the primary one of which is also referred to as the **mission** of that %%party|party%%. A %%party's|party%% objectives are part of its %%knowledge|knowledge%%. When made available to %%agents|agent%% of that %%party|party%%, these agents can do the work that is needed to reach these goals (realize the %%party's|party%% objectives).
 
 ### Purpose
-The ability to distinguish between (non)objectives is relevant as objectives are the drivers behind the reasoning and decisions that %%parties|party%% make, the policies and working instructions that they specify so that its %%agents|agent%% know what to do, when to do it, and how to do it. Moreover, objectives are 1-1 associated with risks (i.e. the level of uncertainty that the party experiences regarding whether a specific objective is going to be appropriately realized). Finally, objectives must be known in order to obtain (personal) data according to the [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj).
+The ability to distinguish between (non)objectives is relevant as objectives are the drivers behind the reasoning and decisions that %%parties|party%% make, the policies and working instructions that they specify so that its %%agents|agent%% know what to do, when to do it, and how to do it. Moreover, objectives are 1-1 associated with risks (i.e. the level of uncertainty that the %%party|party%% experiences regarding whether a specific objective is going to be appropriately realized). Finally, objectives must be known in order to obtain (personal) data according to the [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj).
 
 ### Criterion
 A text representing something toward which a %%party|party%% directs its efforts: an aim, goal, or end of action.
 
 ### Examples
-- generically: 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%%).
+- generically: 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%%).
 - most people have the objective 'stay alive'.
 - the equivalent in organizations is 'continuation of its existence' (many operate 'business-continuity processes' to realize this, and to identify and mitigate any associated risks).
 

docs/terms/owned.md

+---
+id: owned
+title: "Owned"
+scopeid: essifLab
+type: concept
+typeid: owned
+stage: draft
+hoverText: "Owned (by an Owner, in some Jurisdiction): an Entity over which another Entity (its Owner) has the power to enjoy it, dispose of it and control it; the power is limited to (the scope of) that Jurisdiction."
+---
+
+see: %%ownership|ownership%%
+
+### Related Concepts
+- %%Ownership relation|ownership%%
+- %%Owner|owner%%
\ No newline at end of file

docs/terms/owner.md

@@ -5,37 +5,25 @@ scopeid: essifLab
 type: concept
 typeid: owner
 stage: draft
-hoverText: "Owner (of an Entity): the role that a Party performs when it is exercizing its legal or rightful title to control that Entity."
+hoverText: "Owner (of an Entity): the role that a Party performs when it is exercizing its legal, rightful or natural title to control that Entity."
 ---
 
 ### Short Description
 <!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
-An **Owner** is a role that a %%Party|party%% performs when it is exercizing its legal or rightful title to control some %%entity|entity%%. We interpret 'legal' and 'rightful' as terms that apply to _any_ %%Jurisdiction|jurisdiction%% (that is: not just %%legal/national jurisdictions|legal-jurisdiction%%, but also those of other %%organizations|organization%% (%%parties|party%%).
+An **Owner** is a role that a %%party|party%% performs when it is exercizing its legal, rightful or natural title to control some %%entity|entity%%. 
 
-### 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?-->
-
-### 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.-->
-A %%Party|party%% is said to be the **owner** of some %%entity|entity%% if and only if the party and the entity are %%legal entities|legal-entity%% in some %%jurisdiction|jurisdiction%%, within the scope of which that party has the legal or rightful title to control the entity.
-
-### 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.-->
+We interpret 'legal' and 'rightful' as terms that apply to _any_ %%jurisdiction|jurisdiction%% (that is: not just %%legal/national jurisdictions|legal-jurisdiction%%, but also those of other %%organizations|organization%% (%%parties|party%%).
 
-### Related Concepts
-<!--Link to any concepts that are similar but distinct, with a note about the relationship.-->
+We take 'natural' as a title that is provided by nature, as in 'the owner of an %%assertion|assertion%%'.
 
-### Domains
-<!--In which general knowledge ecosystems or mental model families does this concept play a role?-->
+For futher details, see %%ownership|ownership%%.
 
-### Tags
-<!--Add hash tags here that allow us to group concepts in useful ways.-->
+### Purpose
+The ability to distinguish between (non)owners of an %%entity|entity%% enables one to identify the %%party|party%% and the duties (and rights) it has regarding the %%owned|owned%%. One may want to do so either to establish whether or not the %%owned|owned%% %%entity|entity%%, e.g. if it is an %%actor|actor%%, can be trusted to behave according to its %%owner's|owner%% %%policies|policy%%. Or, one may want to do this in order to settle a dispute it has.
 
-### 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.-->
+### Criteria
+A %%party|party%% is said to be the **owner** of some %%(legal) entity|legal-entity%% in some %%jurisdiction|jurisdiction%% if and only if an %%ownership relation|ownership%% exists with that %%jurisdiction|jurisdiction%%.
 
-### Notes
-<!--This (optional) section is the place to put anything for which there is no other good place to put it.-->
\ No newline at end of file
+### Related Concepts
+- %%Ownership relation|ownership%%
+- %%Owned|owned%%

docs/terms/ownership.md

+---
+id: ownership
+title: "Ownership"
+scopeid: essifLab
+type: concept
+typeid: ownership
+stage: draft
+hoverText: "Ownership (of an Entity over another in a Jurisdiction): the rights and duties, as defined and enforced in that Jurisdiction, of that Entity to enjoy, dispose of, and control the other Entity."
+---
+
+### Short Description
+<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
+**Ownership** is a relationship between two %%entities|entity%% in which one of these %%entities|entity%% (called the %%owner|owner%%) is entitled to enjoy, dispose of, and control the other %%entity|entity%% in an pretty much absolute (sovereign) fashion. Any ownership relationship is grounded in ((the rules of) the %%legal system|legal-system%% of) a specific %%jurisdiction|jurisdiction%%, that maintains and enforces these rules, and that has means to resolve any disputes arising from that. To do this, both %%entities|entity%% must be %%legal entities|legal-entity%% in that %%jurisdiction|jurisdiction%%.
+
+We may use the phrase %%natural ownership%% to refer to an ownership relation that exists in the %%jurisdiction|jurisdiction%% 'Nature' (see the notes of %%jurisdiction|jurisdiction%%). This enables us to talk about things as 'the (natural) ownership of an %%assertion|assertion%%'.
+
+### Purpose
+**Ownership** is a means by which %%jurisdictions|jurisdiction%% provide assurances to %%parties|party%% (within its scope) that they can enjoy, dispose of and control in pretty much any way they like. The %%legal system|legal-system%% of the %%jurisdiction|jurisdiction%% specifies these rights, and provides ways in which the %%owner|owner%% can exercize them (that provides the assurance).
+
+### Criteria
+An **ownership** is a relationship between two %%legal entities|legal-entity%% (called the %%owner|owner%% and the %%owned|owned%%) within a single %%jurisdiction|jurisdiction%%, whose %%legal system|legal-system%% defines and enforces (a) rules that recognize the power of the %%owner|owner%% to enjoy, dispose of and control the %%owned|owned%% in an absolute (sovereign) fashion, and (b) rules that limit the absoluteness of that power.