Commit 259f33ce authored by Rieks Joosten's avatar Rieks Joosten
Browse files

Merge branch 'main' into 'master'

Main - readers are informed of change to Github

See merge request !41
parents 4c933c2c 91195d6d
Pipeline #49358 passed with stage
in 1 minute and 57 seconds
......@@ -78,7 +78,7 @@ The workflow in the framework repository, has the following jobs:
These checks run on all the branches but `master`
- `gh-release` [job](https://github.com/essif-lab/framework/blob/master/.github/workflows/framework.yml#L25): takes care of the deployment
The release job runs **only** when another branch gets merged to `master` and the changes affect the artifact of the deployment
> :exclamation: The branch that the website will be deployed to, defaults to `gh-pages`. The result of the release job (`build` directory)
......@@ -91,37 +91,37 @@ In order to deploy a new version of the website, follow the procedure below:
</summary>
1. Create locally a new branch from `master` (ex. `feature-gh-branch` branch)
2. Add and commit your changes locally
3. Push your changes to the remote `feature-gh-branch` branch
4. To create a Pull Request to `master`, go to the repository's page on Github, in the [Pull requests tab](https://github.com/essif-lab/framework/pulls), and click `New pull request`
5. In the `compare:` dropdown list, choose the branch you want to merge with `master` (in this case with `feature-gh-branch`), and review the changes
![Github compare branches](static/images/github/github-compare-branches.png)
Then, click `Create Pull Request` button to proceed
6. You will get prompted to the pull request page, where the *checks* of the PR are launched automatically, as part of the workflow
![Github PR checks](static/images/github/github-pr-checks.png)
When the PR passes all the checks and it has no conflicts with the `master` branch, you can click the `Merge pull request` button, to merge the changes
![Github PR page](static/images/github/github-pr-page.png)
Once the merging is over, the PR will change status from *Open* to *Merged*
![Github PR merged](static/images/github/github-merged-branch.png)
7. In the [Actions page](https://github.com/essif-lab/framework/actions) you can review all the running workflows.
![Github PR merged](static/images/github/github-workflows.png)
Now that the `feature-gh-branch` got merged to `master`, the release job started running, to update the website.
![Github PR merged](static/images/github/github-release-workflow.png)
</details>
......
......@@ -8,8 +8,8 @@ date: 20210601
import useBaseUrl from '@docusaurus/useBaseUrl'
:::info Editor's note
*This section is work in progress.*
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-fw-bus-arch).
:::
## 1. Purpose
......
......@@ -8,8 +8,8 @@ date: 20210601
import useBaseUrl from '@docusaurus/useBaseUrl'
:::info Editor's note
*This section is work in progress.*
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-fw-func-arch).
:::
## 1. Purpose
......
......@@ -8,6 +8,10 @@ date: 20210601
import useBaseUrl from '@docusaurus/useBaseUrl'
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-fw).
:::
:::info Editor's note
*This section is work in progress.*
:::
......
......@@ -7,6 +7,10 @@ hoverText: "The purpose of the eSSIF-Lab is to specify, develop and validate tec
date: 20210601
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-objectives).
:::
## Purpose
The purpose of the eSSIF-Lab is to specify, develop and validate technological and non-technological (e.g. governance) means that support people, businesses and governments to think about, design, adapt, and operate their (information) processes such that they can negotiate and conduct %%business transactions|transaction%% with one another using the electronic support provided by the various SSI technologies.
......
......@@ -6,6 +6,10 @@ scopeid: essifLab
date: 20210908
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-pattern-list).
:::
Within eSSIF-Lab, we maintain a set of [mental models](https://en.wikipedia.org/wiki/Mental_model), which we also call %%patterns|pattern%%, which are descriptions, both casual and formal, of sets of %%concepts|concept%% (ideas), relations between them, and constraints, that together form a coherent and consistent 'viewpoint', or 'way of thinking' about a certain topic. They have been crafted so that they may serve as a basis for architecting, desiging, and implementing IT components and their governance processes.
One might think that everyone has their own mental models, and uses them to make decisions, make sense of the world, etc. Any mental model that helps a person cope in the world is ok. For example, the ancient Greeks had a mental model that said [the earth is at the center of the universe](https://oxfordre.com/planetaryscience/view/10.1093/acrefore/9780190647926.001.0001/acrefore-9780190647926-e-46#acrefore-9780190647926-e-46-div2-2), and the sun and planets somehow revolve around it. Further development of the model allowed them to compute planetary positions, which played a role in fortune telling and therefore was considered important. Doing this is [very complex](https://www.nature.com/articles/s41598-021-84310-w). In the 16th century, [Copernic revolutionized science](https://www.britannica.com/topic/Copernican-Revolution) by stating that the sun, rather than the earth, was at the centre of the universe. It wasn't like he changed the universe itself - he only changed the frame of reference, the perspective, i.e. the mental model that he used to look at, reason with, and explain the universe. Copernic showed in a dramatic way that changing one's perspective can have very profound consequences.
......
......@@ -8,6 +8,10 @@ date: 20210601
import useBaseUrl from '@docusaurus/useBaseUrl'
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-principles).
:::
The dialogue about what Self-Sovereign Identity (SSI) really is, that was started in the blog "[The Path to Self-Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html)" by Christopher Allen in 2016, has not resulted in a consensus today. While some see the ten principles of SSI that Allen proposed as the definition of SSI, they have been formulated as "a departure point to provoke a discussion about what's truly important".
From the [perspective of eSSIF-Lab](essifLab-vision) this "what's truly important" relates to electronically supporting %%parties|party%% as they negotiate and execute %%(business) transactions|transaction%%. From this perspective, it seems reasonable to have the term %%SSI|self-sovereign-identity%% refer to all concepts/ideas, architectures, processes and technologies that aim to support (autonomous) %%parties|party%% as they negotiate and execute electronic %%(business) transactions|transaction%% with one another.
......
......@@ -24,6 +24,10 @@ The eSSIF-Lab project [seeks to fund (EU) SME's](https://essif-lab.eu/open-calls
The eSSIF-Lab project also contributes to the design, maintenance and validation of the [eSSIF-Lab framework](essifLab-fw), its [Business architecture](essifLab-fw-bus-arch) and its [Functional architecture](essifLab-fw-func-arch).
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-project).
:::
## Background
The current situation (2020/2021) is that electronic support for such transactions is very limited. In most cases, people have to type in data, most of which already exists in electronic form but isn't readily available for (re)use. People may need to copy data from papers, or scan papers and upload these scans. On the provider side, this data has to be %%verified|verify%% and %%validated|validate%%, which takes time and effort, often from human employees.
......
......@@ -6,6 +6,10 @@ scopeid: essifLab
date: 20210601
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-terminology).
:::
When %%parties|party%% from various backgrounds (and cultures) work together, it is inevitable that misunderstandings occur, i.e. texts (written or spoken) are easily interpreted in ways other than what the author intended. More often than not, such misunderstandings go undetected, and rightfully so, as in most cases it doesn't cause serious problems.
In the context of [eSSIF-Lab](essifLab) we expect people from such various backgrounds (and cultures) to work together in order to realize its [objectives](essifLab-Objectives). Because of its nature, we must expect misunderstandings to become problematic. In order to prevent them, and also to efficiently and effectively resolve those that do occur, we provide mechanisms to detect such misunderstandings, develop %%terminologies|terminology%% that reduce the likelihood of them occurring, and resolve problems/disputes that may occur around %%terms|term%% and %%definitions|definition%%. Using these mechanisms is not compulsory - they may be used (or not) as participants like.
......
......@@ -10,6 +10,10 @@ The European Self-Sovereign Identity Lab ([eSSIF-Lab](essifLab)) views itself as
In its pursuit of this aim, [eSSIF-Lab](essifLab) is developing a [way of thinking and reasoning](essifLab-pattern-list) for the purpose of making it easier to determine what artifacts are needed, how to design them, etc. In the descriptions we provide, we use the eSSIF-Lab %%terminology|terminology%% as provided in the [eSSIF-Lab Glossary](essifLab-glossary). As the meaning of these terms has been [carefully defined](./terms/terminology), they should not be interpreted in another way than as they are %%defined|definition%%. %%Terms|term%% that are defind in the context of eSSIF-Lab are highlighted, and hovering over them shows you their definitions. If you want to dive deeper into the its meaning, just click it.
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-vision).
:::
## Context - the eSSIF-Lab World Model
The basic concepts that you as a reader need to be aware of in order to understand what the eSSIF-Lab vision and [its framework](essifLab-fw) are about, are those that describe the %%eSSIF-Lab world model|pattern-world-model%%, and constitute its context.
......
......@@ -6,6 +6,10 @@ scopeid: essifLab
date: 20210601
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab).
:::
The European Self-Sovereign Identity Lab ([eSSIF-Lab](https://essif-lab.eu/)) views itself as an %%ecosystem|ecosystem%% of %%parties|party%% that work together to make existing (and new) %%Self-Sovereign Identity (SSI)|self-sovereign-identity%% technology into a scalable and interoperable %%infrastructure|ssi-infrastructure%% that businesses can use very easily for negotiation and execution of %%(business) transactions|transaction%% with other organizations and individuals alike, as further described in the [eSSIF-Lab Vision](essifLab-vision).
To learn more, we have a description on the following topics:
......
......@@ -6,6 +6,10 @@ scopeid: essifLab
date: 20210601
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab-governance).
:::
## Purpose
The [eSSIF-Lab functional architecture](essifLab-fw-func-arch) 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%%.
......
......@@ -6,6 +6,10 @@ date: 20210601
import useBaseUrl from '@docusaurus/useBaseUrl'
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/essifLab).
:::
This document provides an overview of the notations and conventions being used within eSSIF-Lab.
### RFC 2119
......@@ -20,27 +24,46 @@ We are working towards deprecating this convention, as we now have better ways o
### Pattern diagram notations
%%Pattern|pattern%% diagrams will be visualized in this document using a UML-like notation. The following diagram represents the %%jurisdiction pattern|pattern-jurisdiction%%, which shows most of the notations we use:
%%Pattern|pattern%% diagrams will be visualized in this document using a notation that is very similar to that used by [UML](https://www.uml-diagrams.org/). The following diagram shows the various notations that we will be using that are basically taken from [UML](https://www.uml-diagrams.org/). There are a few exceptions, that are not shown in the figure; they are explained at the end.
<br/><br/>
<img
alt="Notations and conventions"
src={useBaseUrl('images/essif-lab-notations-and-conventions.png')}
/>
<br/><br/>
A **rectangle**, e.g. 'Person', represents a (named) %%concept|concept%%, or [entity-class](https://www.uml-diagrams.org/class.html). The (operational) extension of a %%concept|concept%% is the sets of its instances (for 'Person', the extension consists of the set of actual people of flesh and blood tha are in the scope of the model). The extensions of different concepts are disjunct (do not overlap), unless there is an 'ISA' relation between them (see below).
A **solid line with a closed arrowhead**, e.g. 'owns', represents a (named) relation/[association](https://www.uml-diagrams.org/association.html) between the two %%concepts|concept%% it connects. The concept at the arrowhead ('House') is called the 'target %%concept|concept%%' (TGT) for that relation; the other ('Person') is called the 'source %%concept|concept%%' (SRC). The relation is labeled such that `<SRC> <relation label> <TGT>` (Person owns House) suggests the phrase that descibes the intension(al definition) of that relation. The (operational) extension of a relation embraces all pairs (SRC,TGT) for which the relation holds. In the example, it consists of all pairs (P,H), where P is a Person and H is a House, such that the phrase 'P owns H' is true.
A **green name** at either [end of a relation/association](https://www.uml-diagrams.org/association.html#association-end) is what UML calls 'role'; this name may be used to refer to (an instance of) the %%concept|concept%% at which the name is placed as it performs its/this role in this relation. In the figure, `owner` is the role that a Person fulfills in the relation 'owns'. If we assert that a Person (P) is the owner of a specific House (H), or that House H is owned by Person P, this means that (P,H) is an element of the extension of the relation 'owns'.
A **solid line with an open arrowhead**, represents a [generalization relation](https://www.uml-diagrams.org/generalization.html). It can be read as `<SRC> is a <TGT>`, and is therefore also referred to as an ISA-relation. The SRC of the relation is the specialization (subclass) of the TGT (which in turn is a generalization of SRC). This means that SRC satisfies all constraints that TGT satisfies, and also that SRC has all attributes (properties, characteristics) that TGT has. The figure shows 'Self Employed Retailer is a Person' as an example.
A **line with a solid diamand** at one end represents a [composition](https://www.uml-diagrams.org/composition.html) relation. The element at the 'diamond-end' is called the 'parent', or the 'whole'. The other element is called the 'child' or the 'part'. A 'part' in a composition relation cannot be part of more than one 'whole'. Normally, if a 'whole' in a composition relation ceases to exist, then so do all of its composite parts. In the figure, at least one Bedroom and precisely one Living Roomn are parts of a (every) House. Obviously, if a House ceases to exist, then so do these rooms.
A **line with a hollow diamand** at one end represents an [aggregation](https://www.uml-diagrams.org/aggregation.html) relation. The element at the 'diamond-end' is called the 'parent', or the 'whole'. The other element is called the 'child' or the 'part'. A 'part' can be a part in multiple aggregation relations, and hence be part of multiple 'wholes'. If a 'whole' in an aggregation relation ceases to exist, the parts typically continue their existence. In the figure, 'Documentation' (about a Building Type) is an aggregation of a 'User Manual' and at least one 'Technical Document'. Obviously, if the Documentation ceases to exist, then the 'User Manual' and 'Technical Documents' typically continue to exist.
- A **dashed line** with a pointed arrow (`>`) represents a [dependency](https://www.uml-diagrams.org/dependency.html), where the SRC concept somehow depends on the TGT concept. The kind of dependency is specified by a `<<text>>`. In the figure, we see a dependency relation relation `<<instance>>`, indicating that 'House' is a specific instance of 'Building Type'.
- A **[n..m]** structure represents a [multiplicity](https://www.uml-diagrams.org/multiplicity.html). When it appears
- **at the TGT end of a relation**, it means that for every SRC element there must be at least *n* and at most *m* TGT elements in the relation. For example, the [0..n] multiplicity in the 'owns' relation in the figure means that for every 'Person' element, there must be at least 0 and at most *n* (i.e. any number) 'House' elements. Effectively, this says that every Person can own any number of Houses.
- **at the SRC end of a relatipon**, it means tha tfor every TGT element there must be at least *n* and at most *m* SRC elements in the relation. For example, the [0..1] multiplicity in the 'owns' relation in the figure means that for every 'House' element, there must be at least 0 and at most 1 'Person' elements. Effectively, this means that every House can be owned by at most 1 Person.
- is typically of any of the following forms (altough there may be others, e.g. [1..2]):
[0..1]: at most one;
[1..1]: precisely one;
[0..n]: any number - as this is not a constraint, this is the default multiplicity and may be omitted;
[1..n]: at least one.
Note that the term *multiplicity* is distinct from *cardinality*, the difference being that a cardinality states the *actual* number of SRC/TGT elements that a specific TGT/SRC element has in a relation, whereas a multiplicity states the *possible* number of such elements. In short, the multiplicity is the set of all possible cardinalities in a relation. We note this becaus it is common practice for people to use the term 'cardinality' where 'multiplicity' is intended.
### Notational Exceptions
The following notational conventions are not used by [UML](https://www.uml-diagrams.org/), but are specific to our use.
We use a **coloring convention** to distinguish between what is 'officially' part of the eSSIF-Lab models, and parts that are not.
- **blue** is used to color the lines and other symbols that are part of the 'official' models. Typically, they are explicitly defined or otherwise explained, e.g. in a %%mental model|pattern%%. Their definitions/meanings may differ from 'common knowledge'.
- **red** is used to color the lines and other symbols that are part of our 'common knowledge', and hence need not be explicitly defined. They appear to explain where eSSIF-Lab models link to these commonly known/used concepts. We think of them as necessary in order to bridge possible gaps between 'common understanding' and the eSSIF-Lab ways of thinking. Whenever a 'red concept' is nevertheless defined, this is for the purpose of conveying what we conceive the 'common knowledge' to be.
- Objects (lines, rectgangles, etc.) can be colored
- in **blue**, in which case they are properly defined (in a meaning that may deviate from what casual readers might expect).
- in **red**, in which case their meaning is expected to be part of 'common knowledge'. Their meaning may not be defined, yet if it is, the definition is an attempt to make this 'common knowledge' explicit. Red objects are used to bridge possible gaps between 'common understanding' and the eSSIF-Lab ways of thinking, that deviates in various respects.
- Lines can be drawn
- **solid**, in which case they are part of the %%model|pattern%% that is shown in a figure, or
- **dashed**, in which case they are (better) explained in other %%models|pattern%%.
- A **rectangle** represents a (named) %%concept|concept%%, examples of which include %%entity|entity%%, %%legal entity|legal-entity%% and %%party|party%%. %%Concepts|concept%% serve as entity-classes. Their (operational) extensions, i.e. the respective sets of (runtime) instances, are disjunct, unless there is an 'ISA' relation between them (see below).
- A **line with a closed arrowhead** represents a (named) relation/association between the two %%concepts|concept%% it connects. We may refer to the concept at the arrowhead as the 'target %%concept|concept%%' (TGT) for that relation. Similarly, the %%concept|concept%% at the other end will be referred to as the 'source %%concept|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. For example, `operates` is a relation that has `Jurisdiction` as its `<SRC>`, and `Legal System` as its `<TGT>`. It may be read as `Jurisdiction operates Legal System`.
- A **line with an open arrowhead** represents an 'ISA' (pronounce as 'is a') relation, which can be read as `<SRC> is a <TGT>`. It means that SRC *is a* specialization of TGT (which in turn is a generalization of SRC). It means that SRC satisfies all constraints that TGT satisfies, and also that it has all attributes (properties, characgteristics) that TGT has. An example from the figure is: 'Jurisdiction is a Party'.
- A **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 element at the 'diamond-end' of the line (the 'whole'); if the 'whole' ceases to exist, then its 'parts' also cease to exist. In the figure, we see that %%knowledge|knowledge%% is 'part of' a %%party|party%% (the fact that it can also be part of a %%jurisdiction|jurisdiction%% follows from the fact that a %%jurisdiction|jurisdiction%% ISA %%party|party%%). Note that if the %%party|party%% ceases to exist, then so does the associated %%knowledge|knowledge%%. We say that %%party|party%% is 'the whole' in the relation, and %%knowledge|knowledge%% is a 'part' in the relation.
- A **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 element at the 'diamond-end' of the line (the 'whole'); if the 'whole' ceases to exist, then its 'parts' do not necessarily cease to exist, but may 'live on'. In the figure, we see that 'legislation', 'enforcement' and 'juridicary' are all parts of a %%legal system|legal-system%%. If the %%legal system|legal-system%% ceases to exist, then it is possible that the 'legislation', 'enforcement' and 'juridicary' may continue their existence.
- 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|concept%% at which the name is placed as it performs its/this role in this relation. In the figure, `governor` is the role that a %%party|party%% (or %%jurisdiction|jurisdiction%%) is said to be in as it governs its %%knowledge|knowledge%%.
- 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. This isn't shown in the figure.
- **Multiplicities** (or: **cardinalities**) use the [n..m] notation. When a multiplicity is omitted, [0..n] is intended. A [multiplicity](https://www.uml-diagrams.org/multiplicity.html) specifies the minimum (*n*) and maximum (*m*) of possible instances of the concept where it is specified in a relation. Here are a few examples from the figure:
- the [1..1] multiplicity in the relation 'controls' must be read as "Every jurisdiction controls exactly one Scope of Control"
- the [1..n] multiplicity in the relation 'owns' reads: "Every party owns one or more (or: at least one) objectives".
- a multiplicity at the SRC of a relation can be read by first reversing the relation. For example, the [1..1] multiplicity at the SRC of relation 'owns' results in "Every objective *is owned by* precisely one party".
We use a **line typing convention** within a diagram, as follows:
- **solid lines** are used for lines and other symbols that are part of the %%model|pattern%% that is represented by the diagram;
- **dashed lines** are used for lines and other symbols that are (authoritatively) defined elsewehere.
For example, the concept %%party|party%% is authoritatively defined in the %%party, actor and action pattern|pattern-party-actor-action%%, so the diagram there shows a solid (blue) line fo rthat concept. It also appears in other diagrams, e.g. in the %%jurisdiction pattern|pattern-jurisdiction%%, where the concept is represented with a (blue) dashed line.
\ No newline at end of file
......@@ -10,6 +10,10 @@ glossaryText: "something that is actually done/executed - by a single %%actor^ac
date: 20210601
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/terms/action).
:::
### 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 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.
......
......@@ -9,6 +9,11 @@ hoverText: "Actor: Entity that can act (do things), e.g. people, machines, but n
glossaryText: "Entity that can act (do things), e.g. people, machines, but not %%organizations^organization%%."
date: 20210601
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/terms/actor).
:::
### Short Description
An **Actor** is someone or something that can actually do things, such as people or machines. Actors will generally do things, i.e. execute %%actions|action%% in different ways, depending on the context, or the %%party|party%% for whom they do this.
......
......@@ -10,6 +10,10 @@ glossaryText: "an %%actor^actor%% that is executing an %%action^action%% on beha
date: 20210601
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/terms/agent).
:::
### Short Description
An **Agent** is an %%actor|actor%% that is executing an action %%action|action%% 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.
......
......@@ -10,6 +10,10 @@ glossaryText: "a declaration/statement, made by a specific %%party^party%%, that
date: 20210601
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/terms/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.
......
......@@ -10,6 +10,10 @@ glossaryText: "%%Data^data%%, that represents a characteristic that a %%party^pa
date: 20210821
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/terms/attribute).
:::
### Short Description
An **Attribute** is %%data|data%%, that represents a characteristic that a %%party|party%% (the %%owner|owner%% of the %%attribute|attribute%%) has attributed to an %%entity|entity%%. An attribute is a form of %%assertion|assertion%% (or claim), that states the attribution of that characteristic to its %%subject|subject%%.
......
......@@ -10,6 +10,10 @@ glossaryText: "a %%party^party%% of which certain decisions, ideas, rules etc. a
date: 20210601
---
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/terms/authority).
:::
### Short Description
An **Authority** is a %%party|party%% of which certain decisions, ideas, rules etc. are followed by other %%parties|party%%. We distinguish between two kinds of authority:
- centralized authority, also known as the power or right to give orders, make decisions that other parties must follow, and enforce obedience. This kind of authority ignores the natural autonomy of other %%parties|party%%.
......
......@@ -14,6 +14,10 @@ date: 20210601
TNO (or others) to provide the content of this file.
:::
:::caution
This page has been moved to the [eSSIF-Lab Framework on Github](https://essif-lab.github.io/framework/docs/terms/colleague).
:::
### Purpose
The ability to distinguish between (non) colleagues allows us to reason and communicate about the set of (digital and non-digital) %%actors|actor%% that are %%agents|agent%% for a **principal|principal%%. This is relevant in situations where different %%agents|agent%% excute %%actions|action%% in a single %%business transaction|transaction%% on behalf of the same %%principal|principal%%
......
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