Skip to content

Commit

Permalink
fixing broken links
Browse files Browse the repository at this point in the history
Signed-off-by: Rieks <[email protected]>
  • Loading branch information
RieksJ committed Feb 5, 2024
1 parent 3d36f66 commit e721bad
Show file tree
Hide file tree
Showing 5 changed files with 5 additions and 5 deletions.
2 changes: 1 addition & 1 deletion docs/essifLab-collaborative-understanding.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ The following summary needs to be worked into this page:

[^1]: Agredo-Delgado, V., Ruiz, P.H., Mon, A. et al. Applying a process for the shared understanding construction in computer-supported collaborative work: an experiment. Comput Math Organ Theory 28, 247-270 (2022). https://doi.org/10.1007/s10588-021-09326-z

In the context of [eSSIF-Lab](essifLab) we expect people from such various backgrounds (and cultures) to work together in order to realize the [eSSIF-Lab](essifLab) [objectives](essifLab-Objectives). Because of their 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](@) that reduce the likelihood of them occurring, and resolve problems/disputes that may occur around [terms](@) and [definitions](@).
In the context of [eSSIF-Lab](essifLab) we expect people from such various backgrounds (and cultures) to work together in order to realize the [eSSIF-Lab](essifLab) [objectives](essifLab-objectives). Because of their 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](@) that reduce the likelihood of them occurring, and resolve problems/disputes that may occur around [terms](@) and [definitions](@).

Using these mechanisms, the authors of this website have been able to generate this website in such a way that [terms](@) that have been defined for the [context](scope@) of eSSIF-Lab are highlighted. A term shows its [definition](@) when a user hovers over it. And when clicked on, it redirects to the page that explains the term in more detail. It is not compulsory to use these mechanisms. However, their use is strongly encouraged as the feedback we have received shows that they *do* contribute to a better understanding.

Expand Down
2 changes: 1 addition & 1 deletion docs/saf.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ versions:
- vsntag: default # this version contains all terms that are curated by essiflab
altvsntags: [ latest, documentation ] # alternative verstiontags
termselection:
- [concept,property,relation,pattern,semantic-unit]@tev2
- term[concept,property,relation,pattern,semantic-unit]@tev2
- term[glossary,dictionary,terminology,vocabulary]@tev2
- term[semantics,term,define,definition]@tev2
- termid[pattern:terminology]@tev2
Expand Down
2 changes: 1 addition & 1 deletion docs/terms/credential-catalogue.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,4 +20,4 @@ Additional content is needed here.

### Short Description

A *Credential Catalogue* is a functional component that has the [](capability-of-an-actor@) to register and advertise the information about Credential Types that their respective [Governing Parties](governance@) have decided to disclose so as to enable other Parties to decide whether or not it is beneficial for them to use Credentials of such types.
A *Credential Catalogue* is a functional component that has the [capability](capability-of-an-actor@) to register and advertise the information about [credential types](@) that their respective [governing parties](governance@) have decided to disclose so as to enable other [parties](@) to decide whether or not it is beneficial for them to use [credential](@) of such types.
2 changes: 1 addition & 1 deletion docs/terms/onboarding.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ Similarly a bank will onboard a customer by doing a Know-Your-Customer (KYC) che

Note that the banking app, once installed on the customer's mobile phone, is also an [actor](@) that is expected to work for the bank, and hence must be onboarded. This consists the app contacting the banks business service that runs the onboarding process. This process will then electronically establish that the app is what the bank expects of it (step 1), "sign a contract" (step 2) which is basically the registration of some information which would include the customer that is expected to operate the app, and then provide the app with what it further needs to operate within the (electronic) context of the bank.

Your typical SSI wallet app that is deployed on a mobile phone is said to work for the [person](human-being@) that operates the wallet app (which is different from the banking app in the previous paragraph). While this may be different for the various wallet apps, we expect that the [person](human-being@) would first go and shop around to see which wallet app has the features it likes (step 1). The contract (step 2) is implicit: the rights and duties are defined by the [](capability-of-an-actor@) of the wallet app. When the user installs the app on its mobile phone (step 3) onboarding is complete. The process in which the user provides the app with rights (e.g. to the phone's storage, NFC [](capability-of-an-actor@), etc.), or retracts such rights, is outside the scope of the onboarding process.
Your typical SSI wallet app that is deployed on a mobile phone is said to work for the [person](human-being@) that operates the wallet app (which is different from the banking app in the previous paragraph). While this may be different for the various wallet apps, we expect that the [person](human-being@) would first go and shop around to see which wallet app has the features it likes (step 1). The contract (step 2) is implicit: the rights and duties are defined by the [capabilities](capability-of-an-actor@) of the wallet app. When the user installs the app on its mobile phone (step 3) onboarding is complete. The process in which the user provides the app with rights (e.g. to the phone's storage, NFC, or other [capabilities](capability-of-an-actor@), etc.), or retracts such rights, is outside the scope of the onboarding process.

### Purpose

Expand Down
2 changes: 1 addition & 1 deletion docs/terms/pattern-world-model.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl'
## eSSIF-Lab World Model

The **eSSIF-Lab World Model** consists of
- the set of [concepts](@), as listed in the [Glossary](../essifLab-Glossary),
- the set of [concepts](@), as listed in the [Glossary](../essifLab-glossary),
- relations between these concepts, as explained in the various concept-descriptions, and in the various [patterns](@), as listed in the [Patterns List](../essifLab-pattern-list), and
- a set of [Principles](../essifLab-principles) that we take as starting points for our thinking.

Expand Down

0 comments on commit e721bad

Please sign in to comment.