Commit 8db153c6 authored by fmerg's avatar fmerg

Remove unnecessary imports fron .mdx files

parent 75bbad45
Pipeline #15650 passed with stage
in 1 minute and 56 seconds
......@@ -4,8 +4,6 @@ title: eSSIF-Lab Functional Architecture
scopeid: essifLab
---
import { Term } from '../src/components'
The purpose of the functional architecture and its views is to
- **provide mental models** that all of its stakeholders interpret in sufficiently the same way, so as to be able to talk, think and discuss about what it is we try to achieve and ways to achieve this;
......@@ -14,7 +12,7 @@ The purpose of the functional architecture and its views is to
## 1. Basic Terminology
In order to serve such purposes, we have found out that it is necessary that to make a strict and consequent distinction between people and Organizations that are capable of making decisions and bearing responsibility/accountability (we will use the term ‘%%Party|party%%’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘%%Actor|actor%%’ for that). This means that an Organization is always a Party, whereas we consider a person to be a Party at one time and an Actor at another time, and computers/robots (and SSI components) are always an Actor.
In order to serve such purposes, we have found out that it is necessary that to make a strict and consequent distinction between people and Organizations that are capable of making decisions and bearing responsibility/accountability (we will use the term ‘<Term popup="Party: Entity that has knowledge about what exists, ways to reason with that knowledge, and ways for making decisions in a Self-Sovereign fashion." reference="terms/party">Party</Term>’ for that) and people and ‘things’ that are capable of acting/doing things (we will use the term ‘<Term popup="Actor: Entity that can act (do things), e.g. people, machines, but not organizations." reference="terms/actor">Actor</Term>’ for that). This means that an Organization is always a Party, whereas we consider a person to be a Party at one time and an Actor at another time, and computers/robots (and SSI components) are always an Actor.
This distinction is necessary because Actors do things that Parties are accountable for. In order to know which Party is accountable for what actions, we need the ability to link Parties and Actors. When an Actor acts and a (single) specific Party is accountable for that, we say that the Actor is an ‘<Term popup="Agent (of a Party): Actor that is currently working on behalf of a Party." reference="agent">_Agent_</Term>’ for or of that Party (at that particular point in time). We say that this Actor acts ‘**on behalf of**’ that Party. Note that both humans and (running) applications may serve as Agents (human Agent or digital/electronic Agent respectively). A digital Agent that has one or more of the SSI functionalities we describe further down will be called an \`<Term popup="Agent that provides SSI services." reference="ssi-agent">_SSI-Agent_</Term>\`, and we say that the Party on whose behalf it operates is the ‘<Term popup="a Party that has the legal or rightful title to control something." reference="owner">_Owner_</Term>’ of that Agent. Also, we use the term \`**(digital/electronic or human) Colleague (of an Agent)**\` to refer to any other (electronic or human) Agent that acts on behalf of the same Party as this Agent.
......
......@@ -13,15 +13,15 @@ We shall use keywords such as “shall”, “should”, “may” etc. as defin
## Capitalization of words in mid-sentence
Also, we capitalize words in mid-sentence whenever it is used in the meaning as provided by a corresponding Definition. This allows us to also use the more colloquial meanings of words (by not capitalizing them). We appreciate any feedback regarding our (im)proper use of this kind of capitalization of words.
We are working towards deprecating this convention, as we now have better ways to refer to %%definitions|definition%%.
We are working towards deprecating this convention, as we now have better ways to refer to <Term popup="Definition: A Definition is a text that helps parties truely understand the meaning of a term." reference="terms/definition">definitions</Term>.
## Pattern diagram notations
%%Pattern|pattern%% diagrams will be visualized in this document using a UML-like notation, as follows:
<Term popup="Pattern: A limited set of concepts (ideas), relations between them, and constraints, such that together they form a coherent and consistent whole." reference="terms/pattern">Pattern</Term> 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. Concepts serve as entity-classes. Their (operational) extensions, i.e. the respective sets of (runtime) instances, are disjunct.
- a **solid line with a closed arrowhead** represent a (named) relation/association between the two concepts it connects. The concept at the arrowhead is called the ‘target concept’ (TGT) for that relation. The concept at the other end is called 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 **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.
- **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
- 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.
......@@ -7,6 +7,7 @@ typeid: conceptID
stage: draft
hoverText: "ConceptID: popuptext for 'conceptID' (tbd)."
---
<!--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. This file specifies the idea(s) that, within the scope of `<existing-scopeID>` will be referred to using `<New Term>`.
Please fill in the placeholders in this file as follows:
- `<existing-scopeID>`: machine readable text that identifies the scope in which this term is defined;
......@@ -31,7 +32,7 @@ Please fill in the placeholders in this file as follows:
<!--Link to any concepts that are similar but distinct, with a note about the relationship.-->
## Background:
<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: The %%terminology pattern|pattern-terminology%% provides an overview of how this concept fits in with related concepts.-->
<!--Mention and link to the patterns in which this concept plays a (significant) role (possibly explaining the reason/purpose if appropriate), e.g.: The <Term popup="The eSSIF-Lab Terminology Corpus pattern (further text remains to be written)." reference="../terms/pattern-terminology">terminology pattern</Term> provides an overview of how this concept fits in with related concepts.-->
## Domains
<!--In which general knowledge ecosystems or mental model families does this concept play a role?-->
......@@ -56,4 +57,4 @@ Please fill in the placeholders in this file as follows:
[^1]: the text for footnote [^1] goes here.
-->
\ No newline at end of file
-->
......@@ -6,8 +6,6 @@ termid: concept
hoverText: "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."
---
import { Term } from '../../src/components'
## Short Description
<!--REQUIRED--in 1-3 sentences that describe the concept to a layperson with reasonable accuracy.-->
A Concept tries to capture the idea behind a classification of entities[^1], allowing us to reason about everything in the class as if it were one thing. For example, the ideas ([mental representations](https://en.wikipedia.org/wiki/Mental_representation)) you have when processing the sentences "I can drink beer from a beer glass' and 'I can drink beer from a coffee mug' shows that the concepts that are behind 'beer glass' and 'coffee mug' differ. Note that in order to communicate about this idea, we also need a word or phrase (i.e.: a termat we can use to refer to (instances of) this idea.
......
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