Commit fdbd51c0 authored by Rieks Joosten's avatar Rieks Joosten

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.
parent 1ba919ca
Pipeline #16177 passed with stage
in 2 minutes and 4 seconds
......@@ -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
......@@ -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
......
......@@ -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
......
---
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.
:::
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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?-->
......
---
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.
:::
......@@ -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?-->
......
---
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.
:::
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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
......@@ -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
......
---
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
......@@ -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
......
......@@ -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
......
......@@ -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
......
......@@ -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.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment