Merge branch 'main' into documentation/directory

README.md

@@ -17,32 +17,17 @@ Vanuit het Open Catalogi stelsel gaan we er vanuit dat een gebruiker bij een int
 
 ![UML Diagram van OpenCatalogi](https://raw.githubusercontent.com/OpenCatalogi/.github/main/docs/handleidingen/components_simple.svg "UML Diagram van OpenCatalogi")
 
-Als we vervolgens inzoemen op een catalogus bestaad die feitenlijk uit vier functionele delen (Beheer UI, Gebruikers UI, Beheer API, Zoeken API) en 2 opslag componenten (Zoekindex en Oojecten opslag). Daarbij is het interactie vlak van de API's gedefineerd in de Open Catalogi standaard([OAS]()) en het gedrag in [architectuur]().
-
-![UML Diagram van OpenCatalogi](https://raw.githubusercontent.com/OpenCatalogi/.github/main/docs/handleidingen/components_matrix.svg "UML Diagram van OpenCatalogi")
-
-Het is aan applicaties zelf om hier vervolgens invulling aan te geven. Vanuit de Open catalogi community leveren we een aantal componenten die hier invulling aan geven. Hierbij hebben we er voor gekozen om de componenten in twee varianten te ontwikklen. 
-
-- **Iedere component in een eigen container** Bedoeld voor grote organisaties die graag alles op kubernetes draaien
-- **Alle componenten op één gemeenschappenlijk framework** Bedoeld voor kleine en middelgrote organisaties die gebruik amken van een (viruteel) linux serverpark of azure.
-- **Alles in één applicatie** Bedoeld voor locale ontwikkeling en testen, niet bedoeld voor productie doeleinden. 
-
-Om dit te realiseren is de onderlinggende code opgedeeld in meerdere libaries die door de verschillende verschijningsvormen worden gedeeld.
-
-![UML Diagram van OpenCatalogi](https://raw.githubusercontent.com/OpenCatalogi/.github/main/docs/handleidingen/components.svg "UML Diagram van OpenCatalogi")
-
 Voor een uitgebreide opzet over de interne werking van catalogi kunt u kijken in de [architectuursectie](/docs/handleidingen/Architectuur.md). 
 
 ## Landelijke diensten
 Vanuit de gedachte van een federatief stelsel is iedere deelnemer verantwoornlijk voor zijn/haar eigen inbreng aan installaties en interfaces. Toch is het handig als er zo nu en dan al een en ander draaid om op terug te vallen. Vanuit de Open Catalogi community worden daarom de volgende diensten ook als achtervang aangeboden.
 
-1. Op [opencatalogi.nl]() draaid een instantie van de interface waarmee gezocht kan worden in het federatief netwerk. Hiermee maken we de data visueel en is het makenlijk te controlleren of je publicaties goed doorkomen. Het is echter een uitgangspunt dat iedere organisatie haar eigen publicaite voorziening treft.
+1. Op [opencatalogi.nl](https://opencatalogi.nl/) draaid een instantie van de interface waarmee gezocht kan worden in het federatief netwerk. Hiermee maken we de data visueel en is het makenlijk te controlleren of je publicaties goed doorkomen. Het is echter een uitgangspunt dat iedere organisatie haar eigen publicaite voorziening treft.
 2. Op [opencatalogi.nl/catalogi]() geven we een visuele representatie van de landelijke directory zodat inzichtenlijk is welke catalogi bechickbaar zijn.
 3. Vanuit de landelijke instantie draaien we een catolgus [github]() de gekopeld is aan github (voor het automatisch inzichtenlijk maken van open source projecten).
 4. Vanuit de landelijke instantie draaien we een catolgus [gitlab]() de gekopeld is aan gitlab (voor het automatisch inzichtenlijk maken van open source projecten).
 4. Vanuit de landelijke instantie draaien we een catolgus [opencatalogi]() waarmee we [metadata formats]() beschickbaar stellen voor hergebruik.
 
-
 Wat OpenCatalogi uniek maakt, is dat de frontend serverless (via GitHub) kan draaien, waardoor deelnemende organisaties OpenCatalogi niet zelf hoeven te installeren om het te kunnen gebruiken. Zowel de frontend als de gegevens kunnen worden gehost op GitHub.
 
 ## Snelle Start

docs/handleidingen/Architectuur.md

@@ -4,6 +4,32 @@ OpenCatalogi biedt een manier om meerdere catalogi samen te laten werken als é
 
 In de zin van GEMMA/NORA architectuur geeft OpenCatalogi hiermee invulling aan het concept generieke publicatievoorziening.
 
+
+![UML Diagram van OpenCatalogi](https://raw.githubusercontent.com/OpenCatalogi/.github/main/docs/handleidingen/components_simple.svg "UML Diagram van OpenCatalogi")
+
+Als we vervolgens inzoemen op een catalogus bestaad die feitenlijk uit vier functionele delen (Beheer UI, Gebruikers UI, Beheer API, Zoeken API) en 2 opslag componenten (Zoekindex en Oojecten opslag). Daarbij is het interactie vlak van de API's gedefineerd in de Open Catalogi standaard([OAS]()) en het gedrag in [architectuur]().
+
+![UML Diagram van OpenCatalogi](https://raw.githubusercontent.com/OpenCatalogi/.github/main/docs/handleidingen/components_commonground.svg "UML Diagram van OpenCatalogi")
+
+Het is aan applicaties zelf om hier vervolgens invulling aan te geven. Vanuit de Open catalogi community leveren we een aantal componenten die hier invulling aan geven. Hierbij hebben we er voor gekozen om de componenten in twee varianten te ontwikklen en een derde aan te bieden voor development en test doeleinden. 
+
+- **Iedere component in een eigen container** Bedoeld voor grote organisaties die graag alles op kubernetes draaien
+- **Alle componenten op één gemeenschappenlijk framework** Bedoeld voor kleine en middelgrote organisaties die gebruik amken van een (viruteel) linux serverpark of azure.
+- **Alles in één applicatie** Bedoeld voor locale ontwikkeling en testen, niet bedoeld voor productie doeleinden. 
+
+Om dit te realiseren is de onderlinggende code opgedeeld in meerdere libaries die door de verschillende verschijningsvormen worden gedeeld. Aan de hand van bovenstaande kunnen we redenlijk snel tot een applicatie weergave komen voor de gemiddelde overheid waarbij de volgende uitgangs punten doen:
+
+- Componenten voor laag 5 (interatie), 4 (Logica), en 2 (API)  hosten we op kubernetes
+- 1 (data) hosten we een dataplatform
+- Externe catalogi hebben de seach API nodig voor zoeken en directory uitwisseling
+- We hebben een synchronysaite service nodig die gegevens uit bron systeemen inleest
+- De gebruikersgroepen zijn Burger (inwoner, journalist, onderzoeker of raadslid), Medewerker en Beheerder
+- De gemidelde overheid is een kleine overheid, dan zetten we nextcloud in om gemakenlijk te hosten
+
+Dan komen we tot de volgende architectuurplaat
+
+![UML Diagram van OpenCatalogi](https://raw.githubusercontent.com/OpenCatalogi/.github/main/docs/handleidingen/components.svg "UML Diagram van OpenCatalogi")
+
 ## Basisconfiguratie
 
 Het basisobject van OpenCatalogi is een catalogus. Elke catalogus is een verzameling publicaties. Publicaties vertegenwoordigen 'iets' dat moet worden gepubliceerd. Wat dat 'iets' is, wordt gedefinieerd door een metadatabeschrijving (gedefinieerd door een [schema.json](https://json-schema.org/)). Catalogi kunnen publicaties van verschillende typen bevatten (bijv. datasets van de [WHO](https://www.who.int/data/sets), verzoeken van de [WOO](https://www.rijksoverheid.nl/onderwerpen/wet-open-overheid-woo#:~:text=Is%20de%20informatie%20die%20je,dat%20aan%20je%20worden%20gemeld.), of repositories van [publiccode](https://docs.italia.it/italia/developers-italia/publiccodeyml-en/en/master/index.html)). Publicaties MOETEN bij ÉÉN catalogus horen, en elke catalogus MOET bij ÉÉN organisatie horen, wat betekent dat publicaties traceerbaar zijn naar organisaties via hun catalogus.

docs/handleidingen/components.puml

@@ -26,18 +26,18 @@ package "Bronnen" {
 
 cloud "Kubernetes"{
 
-package "Layer 5 (interaction)" {
-package "React NL Design" {
- [User Interface]  as userUi
+package "Layer 5 (interactie)" {
+package "Publicatie platform" {
+ [React NL Design]  as userUi
 }
 
-package "Vue NL Design" {
- [Admin Interface]  as adminUi
+package "Beheer Interface" {
+ [Vue NL Design]  as adminUi
 }
 }
 
 
-package "Layer 4 (Logic)" as layer4 {
+package "Layer 4 (logica)" as layer4 {
  [Synchronysations]  as service
 }
 
@@ -46,11 +46,11 @@ package "Layer 2 (API)" as layer2 {
 
 
 package "Next Cloud framework"{
-package "Search API" {
+package "Zoeken API" {
  [Open Index] as searchAPI
 }
 
-package "CRUD API" {
+package "Beheer  API" {
  [Open Registers] as objectsAPI
 }
 }

docs/handleidingen/components_commonground.puml

@@ -0,0 +1,30 @@
+@startuml
+title: Open Catalogi
+footer: Open Catalogi | Components
+header: Matrix
+
+
+package "Layer 5 (interactie)" {
+ [Beheer Interface] as adminUI
+ [Publicatie platform] as userUi
+}
+
+
+package "Layer 2 (api)" {
+ [Gebruikers API] as objectsAPI
+ [Zoeken API] as searchAPI
+}
+
+package "Layer 1 (data)" {
+database "Search index" as elastic
+database "Objecten opslag" as ORC
+}
+
+adminUI .down.> objectsAPI: Opslaan
+userUi <.down. searchAPI: Opzoeken
+objectsAPI .down.> ORC: Opslaan
+searchAPI <.down. elastic: Zoeken
+ORC .left.> elastic: Updaten
+
+
+@enduml

docs/handleidingen/components_matrix.puml

@@ -4,10 +4,10 @@ footer: Open Catalogi | Components
 header: Matrix
 
 
- [Admin Interface] as adminUI
- [User Interface] as userUi
- [CRUD API] as objectsAPI
- [Search API] as searchAPI
+ [Beheer Interface] as adminUI
+ [Publicatie platform] as userUi
+ [Gebruikers API] as objectsAPI
+ [Zoeken API] as searchAPI
 
 
 database "Search index" as elastic