terminology updates - wip

.gitignore

@@ -13,3 +13,5 @@ yarn-error.log*
 start_server.bat
 *.ffs_batch
 *.lnk
+docs/vscode-%%-batch-replacer.txt
+**/zzz-*

docs/functional-architecture.md

@@ -49,7 +49,7 @@ The top layer (in the red rounded rectangle) has the functions of actual busines
 
 The lower business layer contains two functional components, one for initiating transactions and the other for stating transaction results (as per the [*DEMO*](https://en.wikipedia.org/wiki/Design_%26_Engineering_Methodology_for_Organizations) method), each of which with an associated business policy that contains business-specific policies/preferences.
 
-The task of the %%Data Collector|data-collector%% (or %%Data Collectordata-collector%%) is to handle and initiate requests from/to Peer Agents to engage in some kind of transaction, by negotiating and exchanging data (through one or more, physical or electronic communication channels), and to produce a transaction form whose contents are complete and valid, enabling an appropriate Colleague to decide whether or not to engage in the transaction. Note that negotiating a transaction has two parts: requesting a Peer Agent to provide data that its Owner needs, and providing data on behalf of its Owner that a Peer Agent requests. After all, a business transaction can only start after all Parties have decided to commit, which they can only do after each of them has obtained the information it (subjectively) needs to do so. Also note that data that the Data Collector must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels.
+The task of the %%Data Collector|data-collector%% (or %%Data Collector|data-collector%%) is to handle and initiate requests from/to Peer Agents to engage in some kind of transaction, by negotiating and exchanging data (through one or more, physical or electronic communication channels), and to produce a transaction form whose contents are complete and valid, enabling an appropriate Colleague to decide whether or not to engage in the transaction. Note that negotiating a transaction has two parts: requesting a Peer Agent to provide data that its Owner needs, and providing data on behalf of its Owner that a Peer Agent requests. After all, a business transaction can only start after all Parties have decided to commit, which they can only do after each of them has obtained the information it (subjectively) needs to do so. Also note that data that the Data Collector must ensure that the transaction context is properly maintained if it chooses to exchange data through different communication channels.
 
 The task of the %%Data Discloser|data-discloser%% (or %%Data Discloser|data-discloser%%) is to state the (various, sometimes intermediary) results of transactions, by collecting data from the Business Data Stores, and creating a set of (related) statements/claims that can subsequently be issued to other Parties. Since such state-data may change, issuing data that supersedes an earlier state implies the revocation of such a state.
 

docs/notations-and-conventions.md

@@ -20,12 +20,13 @@ 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 that is explicitly defined. 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 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 **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 **solid line with an open arrowhead** represents 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). It means 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'.
+- 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** with a closed arrow (solid triangle) signifies that its intension is created by combination the intensions of other relations (it is a ‘shorthand’ for a path of other relations).
+- A **dashed line** with a pointed arrow (`>`) represents a dependency, where  the SRC concept somehow depends on the TGT concept. The kind of dependency is specified by `<<text>>`, where `text` specifies the kind of dependency. Example: `<<instance>>` says that SRC is an instance (or: instantiates) TGT.
+- **Multiplicities** (or: **cardinalities**) use the [n..m] notation. When a multiplicity is omitted, [0..n] is intended.

docs/pattern-list.md

 ---
 id: essifLab-pattern-list
-title: "eSSIF-Lab List of Patterns"
+title: "eSSIF-Lab Ways of Thinking"
 sidebar_label: Mental Models
 ---
 
-:::info Editor's note
+:::note Editor's note
 TNO to write the introduction paragraph
-Remainder of file to be generated (GRNET plugin/extension)
+Remainder of file to be generated (GRNET plugin/extension) - currently, the file is maintained 'by hand'
+:::
+
+Within eSSIF-Lab, we maintain a set of %%mental models|mental-model%%, i.e. casual and formal descriptions (patterns) of %%concepts|concept%%, relations between them, and constraints, that provide a specific 'viewpoint', or 'way of thinking' about a certain topic. 
+
+:::info Editor's note
+While some of the topics listed below are pretty much done, others are still need more work.
 :::
+
+We currently have models for the following topics:
+
+- [Guardianship relationships](./terms/pattern-guardianship): The Guardianships pattern captures the Concepts and relations that explain what a generic Guardianship consists of, and how it relates to Guardians, Dependents, Jurisdictions, etc.
+
+- [Jurisdictions](./terms/pattern-jurisdiction): The Jurisdictions pattern captures the Concepts and relations that explain what a generic Jurisdiction consists of, and relates it to Parties and Legal Entities.
+
+- [Mandates, Delegation and Hiring](./terms/pattern-mandates-delegation-hiring): The Mandates, Delegation and Hiring pattern (which remains to be documented) captures the ideas behind Mandating, Delegating, Hiring and their relations. This is a work-in-progress.
+
+- [Parties, Actors and Actions](./terms/pattern-party-actor-action): The Parties, Actors and Actions pattern captures the foundational concepts and relations that we need for thinking about how things get done. It answers questions such as: 'Who/what does things?', 'How are their actions being guided/controlled?', 'Who controls whom/what?', 'Who/what may be held accountable?'.
+
+- [Terminology:](./terms/pattern-terminology): The eSSIF-Lab Terminology Pattern describes the relations between Terminology Terms such as 'Concept', 'Term', 'Pattern', 'Mental Model', 'Glossary' etc.

docs/terms/assertion.md

@@ -24,5 +24,9 @@ The ability to distinguish between assertions and non-assertions, and particular
 ### Criterion
 An **Assertion** is any declaration/statement that is made by one specific %%party|party%%.
 
+### Notes
+- Assertions may be ambiguous (multi-interpretable), which may result in misundertandings. The authoritative meaning of an %%assertion|assertion%% is determined by (the %%semantics|semantics%% that was applied by) the %%party|party%% that has uttered/authored it.
+- Assertions may or may not be true. That is not only because 'truth' is subjective (every %%party|party%% may decide whether or not something is true), but also because the %%party|party%% that uttered/authored the %%assertion|assertion%% cannot substantiate the assertion, or lie outright.
+
 -----
 [^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/dependent.md

+---
+id: dependent
+title: "Dependent"
+scopeid: essifLab
+type: concept
+typeid: dependent
+stage: draft
+hoverText: "Dependent (of an Party in a Jurisdiction): the Entity for the caring for and/or protecting/guarding/defending of which a guardianship relationship has been established with that Entity within that Jurisdiction."
+---
+
+:::info Editor's Note
+TNO to revise all below texts.
+:::
+
+### Short Description
+
+### Purpose
+
+### Criteria
+
+### Background
+The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file

docs/terms/duties-and-rights.md

+---
+id: duties-and-rights
+title: "Duties and Rights"
+scopeid: essifLab
+type: concept
+typeid: duties-and-rights
+stage: draft
+hoverText: "Duties and Rights: this pattern describes the relations between Jurisdictions, Legal Entities and the duties and rights they have within them."
+---
+
+:::info Editor's Note
+TNO to provide content here
+:::
\ No newline at end of file

docs/terms/guardian.md

+---
+id: guardian
+title: "Guardian"
+scopeid: essifLab
+type: concept
+typeid: guardian
+stage: draft
+hoverText: "Guardian (of an Entity in a Jurisdiction): the Party that is tasked to care for and/or protect/guard/defend that Entity, for the purpose of which a Guardianship relationship has been established within that Jurisdiction."
+---
+
+:::info Editor's Note
+TNO to revise all below texts.
+:::
+
+### Short Description
+
+### Purpose
+
+### Criteria
+
+### Background
+The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file

docs/terms/guardianship-type.md

+---
+id: guardianship-type
+title: "Guardianship-type"
+scopeid: essifLab
+type: concept
+typeid: guardianship-type
+stage: draft
+hoverText: "Guardianship-type (in a Jurisdiction): a class of Guardianships (relationships) within the Jurisdiction that has defined it."
+---
+
+### Short Description
+A **Guardianship-type** is a class of %%guardianship relationships|guardianship%% within the %%jurisdiction|jurisdiction%% that has defined it. It comprises %%duty and right types|duties-and-rights%% that can be used as a template for instantiating %%duties and rights|duties-and-rights%% of %%guardianship relationships|guardianship%% that instantiate the %%guardianship-type|guardianship-type%%.
+
+A good way to think abouat a %%guardianship-type|guardianship-type%% is to see it as a template from which instances - i.e. actual %%guardianship relationships|guardianship%% can be derived.
+
+### Purpose
+A **Guardianship-type** serves as a template from which instances - i.e. actual %%guardianship relationships|guardianship%% can be derived. It allows the %%jurisdiction|jurisdiction%% within which it is defined to specify generic %%duties and rights|duties-and-rights%%, both for the %%guardian|guardian%% and the %%dependent|dependent%% in (instantiated) %%guardianship relationships|guardianship%%, without knowing which %%entities|entity%% will be(come) the %%guardian|guardian%% or the %%dependent|dependent%%.
+
+### Criteria
+An **guardianship-type** is a class of %%guardianship-relationships|guardianship%% that comprises a (non-empty) set of %%duty/right types|duties-and-rights%% for at least the %%guardian|guardian%% and/or the %%dependent|dependent%% (and perhaps other roles), the semantics of which are defined by the %%jurisdiction|jurisdiction%%.
+
+### Background
+The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file

docs/terms/guardianship.md

+---
+id: guardianship
+title: "Guardianship"
+scopeid: essifLab
+type: concept
+typeid: guardianship
+stage: draft
+hoverText: "Guardianship (of a one Party over an Entity in a Jurisdiction): the rights and duties of that Party, defined and enforced in that Jurisdiction, for the purpose of caring for and/or protecting/guarding/defending that Entity."
+---
+
+:::info Editor's Note
+TNO to revise all below texts.
+:::
+
+### Short Description
+**Guardianship** is a relationship between a %%party|party%% (which we call the %%Guardian|guardian%%) and an %%entity|entity%% (which we call the %%Dependent|dependent%%) in which the %%guardian|guardian%% 
+
+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 guardianship 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 guardianship%% to refer to an guardianship relation that exists in the %%jurisdiction|jurisdiction%% 'Nature' (see the notes of %%jurisdiction|jurisdiction%%). This enables us to talk about things as 'the (natural) guardianship of an %%assertion|assertion%%'.
+
+### Purpose
+**Guardianship** 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 **guardianship** 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.
+
+### Related Concepts
+- %%Owner|owner%%
+- %%Owned|owned%%
+
+### Notes
+- Owning something does not imply posessing it (and vice versa). For example, if you find a coin that doesn't belong to you, you possess it but do not own it. Also, its rightful owner obviously owns it, but doesn't possess it at that point in time.
+
+### Background
+The %%Guardianship pattern|pattern-guardianship%% provides an overview of how this concept fits in with related concepts.
\ No newline at end of file