Dokument - Benutzerbeiträge [de]

Drupal

2026-08-18T16:42:33Z

Thorsten: /* Content Sync */

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
==Konfiguration exportieren (YAML)==
Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:
<pre>
drush config:export --destination=/pfad/zum/backup/config
</pre>

==Inhalts Backup==
===Inhalte als CSV/XLSX===
Modul Views Data Export (drush en views_data_export). Du legst eine View auf Inhalte an, fügst eine Anzeige „Data Export" hinzu, wählst CSV/JSON/XML und die gewünschten Felder. Ergebnis ist ein Download-Pfad, den du auch per Cron automatisiert schreiben lassen kannst.
===Inhalte auf eine andere Drupal-Site übertragen===
====Default Content====
Modul: <pre>drush en default_content</pre>
Exportiert Nodes samt referenzierter Entitäten (Taxonomiebegriffe, Medien, …) als YAML/JSON-API-Dateien, ideal um Inhalte mit einem Modul/Install-Profil auszuliefern.
* Export: <pre>drush default-content-export node <nid></pre> bzw. <pre>drush default-content-export-module <modulname></pre> schreibt die Dateien nach <code>MODULENAME/content/node/</code>.
* Import: Modul auf der Zielsite aktivieren – die Inhalte werden bei der Installation automatisch importiert (Hook <code>hook_install</code> bzw. <code>default_content_deploy</code>).
* Einsatzzweck: Demo-Inhalte, die zusammen mit einem Feature/Modul ausgeliefert werden sollen.

====Content Sync====
Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.
<pre>
drush content-sync:export
drush content-sync:import
</pre>
Export schreibt Inhalte als YAML in einen Content-Sync-Ordner, Import liest sie auf der Zielsite wieder ein. Eignet sich für Staging→Live-Workflows mit identischer Site-Struktur, bei denen Content wie Konfiguration versioniert/deployed werden soll.

====Migrate API====
Module: <code>migrate_plus</code>, <code>migrate_tools</code>. Der robusteste, aber aufwändigste Weg – funktioniert auch bei unterschiedlichen Strukturen/Content-Types zwischen Quelle und Ziel.
* Migration-Definition als YAML (<code>migrate_plus.migration.*.yml</code>) mit drei Teilen:
** '''source''' – z. B. <code>url</code> (JSON:API der Quellsite), <code>csv</code>, <code>sql</code> (direkter DB-Zugriff)
** '''process''' – Feld-Mapping/Transformation (Quellfeld → Zielfeld, inkl. Transformationen wie Datumsformate)
** '''destination''' – z. B. <code>entity:node</code>
* Ausführen: <pre>
drush migrate:import migration_id
drush migrate:status
drush migrate:rollback migration_id
</pre>
Vorteil: wiederholbar und idempotent, daher gut geeignet für große oder strukturell abweichende Sites.

====Core JSON:API====
Kein Zusatzmodul nötig, nur Core-Modul <code>jsonapi</code> aktivieren.
* Alle Artikel: <pre>GET /jsonapi/node/article</pre> (Pagination über <code>page[offset]</code>/<code>page[limit]</code>)
* Einzelner Node: <pre>GET /jsonapi/node/article/{uuid}</pre>
* Referenzen mitladen: <pre>GET /jsonapi/node/article?include=field_tags,uid</pre>
* Anlegen auf Zielsite: <pre>POST /jsonapi/node/article</pre> mit Bearer-Token oder Basic-Auth-Berechtigung.
* Eignet sich als Quelle für eine Migration (siehe Migrate API, <code>source: plugin: url</code>) oder für eigene Skripte, die Daten abholen und auf der Zielsite wieder anlegen.

====Entscheidungshilfe====
{| class="wikitable"
! Methode !! Für !! Aufwand
|-
| [[Default Content]] || Demo-Inhalte mit Modul ausliefern || gering
|-
| Content Sync || Staging→Live, identische Site-Struktur || gering–mittel
|-
| Migrate API || große/strukturell abweichende Sites, wiederholbare Importe || hoch
|-
| JSON:API || Ad-hoc-Abfragen, eigene Skripte, Migrate-Quelle || gering (aber manuell)
|}

====Benutzerdaten ausschließen====
Bei allen vier Wegen hängt am Node standardmäßig ein Autor-Feld (<code>uid</code>), das sonst die komplette User-Entität (Name, E-Mail, Passwort-Hash, Rollen) mit hochziehen kann.

'''Views Data Export''': unkritisch – nur Felder, die explizit zur View hinzugefügt werden, landen im Export. Das Feld „Authored by“/„uid“ einfach nicht hinzufügen.

'''Default Content''': Der Exporter zieht referenzierte Entitäten (also auch den Autor) standardmäßig mit.
* Vor dem Export den Node-Autor auf einen neutralen, auf beiden Sites vorhandenen Account setzen (z. B. <code>uid: 1</code>), oder
* Nach dem Export das <code>uid</code>-Feld in der generierten YAML-Datei manuell entfernen/überschreiben, oder
* Per <code>hook_default_content_export_alter()</code> das <code>uid</code>-Feld aus dem zu exportierenden Entity-Array streichen, bevor die YAML geschrieben wird.

'''Content Sync''': Im Konfigurationsformular wählst du gezielt aus, welche Entity-Types synchronisiert werden. Lässt du „User“ dort weg, werden keine Benutzer-Entitäten exportiert/importiert – das <code>uid</code>-Feld am Node bleibt dann nur eine ID-Referenz, die auf der Zielsite auf einen dort bereits existierenden User zeigen muss (sonst leer/ungültig).

'''Migrate API''': am saubersten steuerbar – im <code>process</code>-Mapping das Quellfeld <code>uid</code> einfach nicht mappen oder fix auf einen Default-Wert setzen:
<pre>
process:
uid:
plugin: default_value
default_value: 1
</pre>
Damit wird die User-Quelle für diese Migration gar nicht erst abgefragt.

'''JSON:API''':
* Beim Abruf per Sparse Fieldset das <code>uid</code>-Feld weglassen und nicht in <code>include</code> aufführen: <pre>GET /jsonapi/node/article?fields[node--article]=title,body,field_tags</pre>
* Der anonymen/API-Rolle nicht die Berechtigung „View user information“ geben – dann liefert <code>/jsonapi/user/user</code> ohnehin nichts.
* Beim Anlegen (<code>POST /jsonapi/node/article</code>) die <code>uid</code>-Relationship einfach weglassen – Drupal setzt automatisch den authentifizierten API-User als Autor.

'''Empfehlung''': Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.
==Hinweis==
Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Drupal

2026-08-18T16:38:56Z

Thorsten:

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
==Konfiguration exportieren (YAML)==
Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:
<pre>
drush config:export --destination=/pfad/zum/backup/config
</pre>

==Inhalts Backup==
===Inhalte als CSV/XLSX===
Modul Views Data Export (drush en views_data_export). Du legst eine View auf Inhalte an, fügst eine Anzeige „Data Export" hinzu, wählst CSV/JSON/XML und die gewünschten Felder. Ergebnis ist ein Download-Pfad, den du auch per Cron automatisiert schreiben lassen kannst.
===Inhalte auf eine andere Drupal-Site übertragen===
====Default Content====
Modul: <pre>drush en default_content</pre>
Exportiert Nodes samt referenzierter Entitäten (Taxonomiebegriffe, Medien, …) als YAML/JSON-API-Dateien, ideal um Inhalte mit einem Modul/Install-Profil auszuliefern.
* Export: <pre>drush default-content-export node <nid></pre> bzw. <pre>drush default-content-export-module <modulname></pre> schreibt die Dateien nach <code>MODULENAME/content/node/</code>.
* Import: Modul auf der Zielsite aktivieren – die Inhalte werden bei der Installation automatisch importiert (Hook <code>hook_install</code> bzw. <code>default_content_deploy</code>).
* Einsatzzweck: Demo-Inhalte, die zusammen mit einem Feature/Modul ausgeliefert werden sollen.

====Content Sync====
Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.
<pre>
[[drush]] content-sync:export
drush content-sync:import
</pre>
Export schreibt Inhalte als YAML in einen Content-Sync-Ordner, Import liest sie auf der Zielsite wieder ein. Eignet sich für Staging→Live-Workflows mit identischer Site-Struktur, bei denen Content wie Konfiguration versioniert/deployed werden soll.

====Migrate API====
Module: <code>migrate_plus</code>, <code>migrate_tools</code>. Der robusteste, aber aufwändigste Weg – funktioniert auch bei unterschiedlichen Strukturen/Content-Types zwischen Quelle und Ziel.
* Migration-Definition als YAML (<code>migrate_plus.migration.*.yml</code>) mit drei Teilen:
** '''source''' – z. B. <code>url</code> (JSON:API der Quellsite), <code>csv</code>, <code>sql</code> (direkter DB-Zugriff)
** '''process''' – Feld-Mapping/Transformation (Quellfeld → Zielfeld, inkl. Transformationen wie Datumsformate)
** '''destination''' – z. B. <code>entity:node</code>
* Ausführen: <pre>
drush migrate:import migration_id
drush migrate:status
drush migrate:rollback migration_id
</pre>
Vorteil: wiederholbar und idempotent, daher gut geeignet für große oder strukturell abweichende Sites.

====Core JSON:API====
Kein Zusatzmodul nötig, nur Core-Modul <code>jsonapi</code> aktivieren.
* Alle Artikel: <pre>GET /jsonapi/node/article</pre> (Pagination über <code>page[offset]</code>/<code>page[limit]</code>)
* Einzelner Node: <pre>GET /jsonapi/node/article/{uuid}</pre>
* Referenzen mitladen: <pre>GET /jsonapi/node/article?include=field_tags,uid</pre>
* Anlegen auf Zielsite: <pre>POST /jsonapi/node/article</pre> mit Bearer-Token oder Basic-Auth-Berechtigung.
* Eignet sich als Quelle für eine Migration (siehe Migrate API, <code>source: plugin: url</code>) oder für eigene Skripte, die Daten abholen und auf der Zielsite wieder anlegen.

====Entscheidungshilfe====
{| class="wikitable"
! Methode !! Für !! Aufwand
|-
| [[Default Content]] || Demo-Inhalte mit Modul ausliefern || gering
|-
| Content Sync || Staging→Live, identische Site-Struktur || gering–mittel
|-
| Migrate API || große/strukturell abweichende Sites, wiederholbare Importe || hoch
|-
| JSON:API || Ad-hoc-Abfragen, eigene Skripte, Migrate-Quelle || gering (aber manuell)
|}

====Benutzerdaten ausschließen====
Bei allen vier Wegen hängt am Node standardmäßig ein Autor-Feld (<code>uid</code>), das sonst die komplette User-Entität (Name, E-Mail, Passwort-Hash, Rollen) mit hochziehen kann.

'''Views Data Export''': unkritisch – nur Felder, die explizit zur View hinzugefügt werden, landen im Export. Das Feld „Authored by“/„uid“ einfach nicht hinzufügen.

'''Default Content''': Der Exporter zieht referenzierte Entitäten (also auch den Autor) standardmäßig mit.
* Vor dem Export den Node-Autor auf einen neutralen, auf beiden Sites vorhandenen Account setzen (z. B. <code>uid: 1</code>), oder
* Nach dem Export das <code>uid</code>-Feld in der generierten YAML-Datei manuell entfernen/überschreiben, oder
* Per <code>hook_default_content_export_alter()</code> das <code>uid</code>-Feld aus dem zu exportierenden Entity-Array streichen, bevor die YAML geschrieben wird.

'''Content Sync''': Im Konfigurationsformular wählst du gezielt aus, welche Entity-Types synchronisiert werden. Lässt du „User“ dort weg, werden keine Benutzer-Entitäten exportiert/importiert – das <code>uid</code>-Feld am Node bleibt dann nur eine ID-Referenz, die auf der Zielsite auf einen dort bereits existierenden User zeigen muss (sonst leer/ungültig).

'''Migrate API''': am saubersten steuerbar – im <code>process</code>-Mapping das Quellfeld <code>uid</code> einfach nicht mappen oder fix auf einen Default-Wert setzen:
<pre>
process:
uid:
plugin: default_value
default_value: 1
</pre>
Damit wird die User-Quelle für diese Migration gar nicht erst abgefragt.

'''JSON:API''':
* Beim Abruf per Sparse Fieldset das <code>uid</code>-Feld weglassen und nicht in <code>include</code> aufführen: <pre>GET /jsonapi/node/article?fields[node--article]=title,body,field_tags</pre>
* Der anonymen/API-Rolle nicht die Berechtigung „View user information“ geben – dann liefert <code>/jsonapi/user/user</code> ohnehin nichts.
* Beim Anlegen (<code>POST /jsonapi/node/article</code>) die <code>uid</code>-Relationship einfach weglassen – Drupal setzt automatisch den authentifizierten API-User als Autor.

'''Empfehlung''': Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.
==Hinweis==
Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Drush installieren

2026-08-18T16:37:46Z

Thorsten: Die Seite wurde neu angelegt: „mmm“

mmm

Drupal

2026-08-18T15:39:47Z

Thorsten:

Drupal

2026-08-18T15:35:00Z

Thorsten: /* Entscheidungshilfe */

==Konfiguration exportieren (YAML)==
Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:
<pre>
drush config:export --destination=/pfad/zum/backup/config
</pre>

==Inhalts Backup==
===Inhalte als CSV/XLSX===
Modul Views Data Export (drush en views_data_export). Du legst eine View auf Inhalte an, fügst eine Anzeige „Data Export" hinzu, wählst CSV/JSON/XML und die gewünschten Felder. Ergebnis ist ein Download-Pfad, den du auch per Cron automatisiert schreiben lassen kannst.
===Inhalte auf eine andere Drupal-Site übertragen===
====Default Content====
Modul: <pre>drush en default_content</pre>
Exportiert Nodes samt referenzierter Entitäten (Taxonomiebegriffe, Medien, …) als YAML/JSON-API-Dateien, ideal um Inhalte mit einem Modul/Install-Profil auszuliefern.
* Export: <pre>drush default-content-export node <nid></pre> bzw. <pre>drush default-content-export-module <modulname></pre> schreibt die Dateien nach <code>MODULENAME/content/node/</code>.
* Import: Modul auf der Zielsite aktivieren – die Inhalte werden bei der Installation automatisch importiert (Hook <code>hook_install</code> bzw. <code>default_content_deploy</code>).
* Einsatzzweck: Demo-Inhalte, die zusammen mit einem Feature/Modul ausgeliefert werden sollen.

====Content Sync====
Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.
<pre>
drush content-sync:export
drush content-sync:import
</pre>
Export schreibt Inhalte als YAML in einen Content-Sync-Ordner, Import liest sie auf der Zielsite wieder ein. Eignet sich für Staging→Live-Workflows mit identischer Site-Struktur, bei denen Content wie Konfiguration versioniert/deployed werden soll.

====Migrate API====
Module: <code>migrate_plus</code>, <code>migrate_tools</code>. Der robusteste, aber aufwändigste Weg – funktioniert auch bei unterschiedlichen Strukturen/Content-Types zwischen Quelle und Ziel.
* Migration-Definition als YAML (<code>migrate_plus.migration.*.yml</code>) mit drei Teilen:
** '''source''' – z. B. <code>url</code> (JSON:API der Quellsite), <code>csv</code>, <code>sql</code> (direkter DB-Zugriff)
** '''process''' – Feld-Mapping/Transformation (Quellfeld → Zielfeld, inkl. Transformationen wie Datumsformate)
** '''destination''' – z. B. <code>entity:node</code>
* Ausführen: <pre>
drush migrate:import migration_id
drush migrate:status
drush migrate:rollback migration_id
</pre>
Vorteil: wiederholbar und idempotent, daher gut geeignet für große oder strukturell abweichende Sites.

====Core JSON:API====
Kein Zusatzmodul nötig, nur Core-Modul <code>jsonapi</code> aktivieren.
* Alle Artikel: <pre>GET /jsonapi/node/article</pre> (Pagination über <code>page[offset]</code>/<code>page[limit]</code>)
* Einzelner Node: <pre>GET /jsonapi/node/article/{uuid}</pre>
* Referenzen mitladen: <pre>GET /jsonapi/node/article?include=field_tags,uid</pre>
* Anlegen auf Zielsite: <pre>POST /jsonapi/node/article</pre> mit Bearer-Token oder Basic-Auth-Berechtigung.
* Eignet sich als Quelle für eine Migration (siehe Migrate API, <code>source: plugin: url</code>) oder für eigene Skripte, die Daten abholen und auf der Zielsite wieder anlegen.

====Entscheidungshilfe====
{| class="wikitable"
! Methode !! Für !! Aufwand
|-
| [[Default Content]] || Demo-Inhalte mit Modul ausliefern || gering
|-
| Content Sync || Staging→Live, identische Site-Struktur || gering–mittel
|-
| Migrate API || große/strukturell abweichende Sites, wiederholbare Importe || hoch
|-
| JSON:API || Ad-hoc-Abfragen, eigene Skripte, Migrate-Quelle || gering (aber manuell)
|}

====Benutzerdaten ausschließen====
Bei allen vier Wegen hängt am Node standardmäßig ein Autor-Feld (<code>uid</code>), das sonst die komplette User-Entität (Name, E-Mail, Passwort-Hash, Rollen) mit hochziehen kann.

'''Views Data Export''': unkritisch – nur Felder, die explizit zur View hinzugefügt werden, landen im Export. Das Feld „Authored by“/„uid“ einfach nicht hinzufügen.

'''Default Content''': Der Exporter zieht referenzierte Entitäten (also auch den Autor) standardmäßig mit.
* Vor dem Export den Node-Autor auf einen neutralen, auf beiden Sites vorhandenen Account setzen (z. B. <code>uid: 1</code>), oder
* Nach dem Export das <code>uid</code>-Feld in der generierten YAML-Datei manuell entfernen/überschreiben, oder
* Per <code>hook_default_content_export_alter()</code> das <code>uid</code>-Feld aus dem zu exportierenden Entity-Array streichen, bevor die YAML geschrieben wird.

'''Content Sync''': Im Konfigurationsformular wählst du gezielt aus, welche Entity-Types synchronisiert werden. Lässt du „User“ dort weg, werden keine Benutzer-Entitäten exportiert/importiert – das <code>uid</code>-Feld am Node bleibt dann nur eine ID-Referenz, die auf der Zielsite auf einen dort bereits existierenden User zeigen muss (sonst leer/ungültig).

'''Migrate API''': am saubersten steuerbar – im <code>process</code>-Mapping das Quellfeld <code>uid</code> einfach nicht mappen oder fix auf einen Default-Wert setzen:
<pre>
process:
uid:
plugin: default_value
default_value: 1
</pre>
Damit wird die User-Quelle für diese Migration gar nicht erst abgefragt.

'''JSON:API''':
* Beim Abruf per Sparse Fieldset das <code>uid</code>-Feld weglassen und nicht in <code>include</code> aufführen: <pre>GET /jsonapi/node/article?fields[node--article]=title,body,field_tags</pre>
* Der anonymen/API-Rolle nicht die Berechtigung „View user information“ geben – dann liefert <code>/jsonapi/user/user</code> ohnehin nichts.
* Beim Anlegen (<code>POST /jsonapi/node/article</code>) die <code>uid</code>-Relationship einfach weglassen – Drupal setzt automatisch den authentifizierten API-User als Autor.

'''Empfehlung''': Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.

Drupal

2026-08-18T14:58:34Z

Thorsten: Die Seite wurde neu angelegt: „==Konfiguration exportieren (YAML)== Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert: <pre> drush config:export --destination=/pfad/zum/backup/config </pre> ==Inhalts Backup== ===Inhalte als CSV/XLSX=== Modul Views Data Export (drush en views_data_export). Du legst eine View auf Inhalte an, fügst eine Anzeige „Data Export" hinzu, wählst CSV/JSON/…“

==Konfiguration exportieren (YAML)==
Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:
<pre>
drush config:export --destination=/pfad/zum/backup/config
</pre>

==Inhalts Backup==
===Inhalte als CSV/XLSX===
Modul Views Data Export (drush en views_data_export). Du legst eine View auf Inhalte an, fügst eine Anzeige „Data Export" hinzu, wählst CSV/JSON/XML und die gewünschten Felder. Ergebnis ist ein Download-Pfad, den du auch per Cron automatisiert schreiben lassen kannst.
===Inhalte auf eine andere Drupal-Site übertragen===
====Default Content====
Modul: <pre>drush en default_content</pre>
Exportiert Nodes samt referenzierter Entitäten (Taxonomiebegriffe, Medien, …) als YAML/JSON-API-Dateien, ideal um Inhalte mit einem Modul/Install-Profil auszuliefern.
* Export: <pre>drush default-content-export node <nid></pre> bzw. <pre>drush default-content-export-module <modulname></pre> schreibt die Dateien nach <code>MODULENAME/content/node/</code>.
* Import: Modul auf der Zielsite aktivieren – die Inhalte werden bei der Installation automatisch importiert (Hook <code>hook_install</code> bzw. <code>default_content_deploy</code>).
* Einsatzzweck: Demo-Inhalte, die zusammen mit einem Feature/Modul ausgeliefert werden sollen.

====Content Sync====
Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.
<pre>
drush content-sync:export
drush content-sync:import
</pre>
Export schreibt Inhalte als YAML in einen Content-Sync-Ordner, Import liest sie auf der Zielsite wieder ein. Eignet sich für Staging→Live-Workflows mit identischer Site-Struktur, bei denen Content wie Konfiguration versioniert/deployed werden soll.

====Migrate API====
Module: <code>migrate_plus</code>, <code>migrate_tools</code>. Der robusteste, aber aufwändigste Weg – funktioniert auch bei unterschiedlichen Strukturen/Content-Types zwischen Quelle und Ziel.
* Migration-Definition als YAML (<code>migrate_plus.migration.*.yml</code>) mit drei Teilen:
** '''source''' – z. B. <code>url</code> (JSON:API der Quellsite), <code>csv</code>, <code>sql</code> (direkter DB-Zugriff)
** '''process''' – Feld-Mapping/Transformation (Quellfeld → Zielfeld, inkl. Transformationen wie Datumsformate)
** '''destination''' – z. B. <code>entity:node</code>
* Ausführen: <pre>
drush migrate:import migration_id
drush migrate:status
drush migrate:rollback migration_id
</pre>
Vorteil: wiederholbar und idempotent, daher gut geeignet für große oder strukturell abweichende Sites.

====Core JSON:API====
Kein Zusatzmodul nötig, nur Core-Modul <code>jsonapi</code> aktivieren.
* Alle Artikel: <pre>GET /jsonapi/node/article</pre> (Pagination über <code>page[offset]</code>/<code>page[limit]</code>)
* Einzelner Node: <pre>GET /jsonapi/node/article/{uuid}</pre>
* Referenzen mitladen: <pre>GET /jsonapi/node/article?include=field_tags,uid</pre>
* Anlegen auf Zielsite: <pre>POST /jsonapi/node/article</pre> mit Bearer-Token oder Basic-Auth-Berechtigung.
* Eignet sich als Quelle für eine Migration (siehe Migrate API, <code>source: plugin: url</code>) oder für eigene Skripte, die Daten abholen und auf der Zielsite wieder anlegen.

====Entscheidungshilfe====
{| class="wikitable"
! Methode !! Für !! Aufwand
|-
| Default Content || Demo-Inhalte mit Modul ausliefern || gering
|-
| Content Sync || Staging→Live, identische Site-Struktur || gering–mittel
|-
| Migrate API || große/strukturell abweichende Sites, wiederholbare Importe || hoch
|-
| JSON:API || Ad-hoc-Abfragen, eigene Skripte, Migrate-Quelle || gering (aber manuell)
|}

====Benutzerdaten ausschließen====
Bei allen vier Wegen hängt am Node standardmäßig ein Autor-Feld (<code>uid</code>), das sonst die komplette User-Entität (Name, E-Mail, Passwort-Hash, Rollen) mit hochziehen kann.

'''Views Data Export''': unkritisch – nur Felder, die explizit zur View hinzugefügt werden, landen im Export. Das Feld „Authored by“/„uid“ einfach nicht hinzufügen.

'''Default Content''': Der Exporter zieht referenzierte Entitäten (also auch den Autor) standardmäßig mit.
* Vor dem Export den Node-Autor auf einen neutralen, auf beiden Sites vorhandenen Account setzen (z. B. <code>uid: 1</code>), oder
* Nach dem Export das <code>uid</code>-Feld in der generierten YAML-Datei manuell entfernen/überschreiben, oder
* Per <code>hook_default_content_export_alter()</code> das <code>uid</code>-Feld aus dem zu exportierenden Entity-Array streichen, bevor die YAML geschrieben wird.

'''Content Sync''': Im Konfigurationsformular wählst du gezielt aus, welche Entity-Types synchronisiert werden. Lässt du „User“ dort weg, werden keine Benutzer-Entitäten exportiert/importiert – das <code>uid</code>-Feld am Node bleibt dann nur eine ID-Referenz, die auf der Zielsite auf einen dort bereits existierenden User zeigen muss (sonst leer/ungültig).

'''Migrate API''': am saubersten steuerbar – im <code>process</code>-Mapping das Quellfeld <code>uid</code> einfach nicht mappen oder fix auf einen Default-Wert setzen:
<pre>
process:
uid:
plugin: default_value
default_value: 1
</pre>
Damit wird die User-Quelle für diese Migration gar nicht erst abgefragt.

'''JSON:API''':
* Beim Abruf per Sparse Fieldset das <code>uid</code>-Feld weglassen und nicht in <code>include</code> aufführen: <pre>GET /jsonapi/node/article?fields[node--article]=title,body,field_tags</pre>
* Der anonymen/API-Rolle nicht die Berechtigung „View user information“ geben – dann liefert <code>/jsonapi/user/user</code> ohnehin nichts.
* Beim Anlegen (<code>POST /jsonapi/node/article</code>) die <code>uid</code>-Relationship einfach weglassen – Drupal setzt automatisch den authentifizierten API-User als Autor.

'''Empfehlung''': Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.

Hauptseite

2026-08-18T14:57:44Z

Thorsten: /* Siehe auch */

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
== Grundaufbau eines Wissensmanagement-Systems ==
Die folgenden Bausteine beschreiben kein klassisches CMS für Blog-Artikel, sondern ein '''Wissensmanagement-System (Wiki-artig)''': Im Mittelpunkt steht nicht die einzelne Seite, sondern das Netz aus Wissensartikeln, ihren Verknüpfungen und ihrer Auffindbarkeit. Entsprechend rücken Taxonomie, Verlinkung und Suche stärker in den Vordergrund als bei einem reinen Content-Ausgabe-System.

== Hauptbausteine im Detail ==

=== [[Data Engine]] ([[Wissensmodell]] & [[Speicherung]]) ===
Das Herzstück des Systems. Es definiert, wie Wissensartikel und ihre Beziehungen abgelegt werden:
* Entwickler-Entscheidung: Monolithisches Datenmodell (feste Tabellen für articles, categories, tags) oder flexibles Schema (JSONB / EAV-Muster für benutzerdefinierte Wissens-Typen wie Glossareinträge, How-Tos, FAQs).
* Taxonomie als Kernbestandteil: Eigene Tabellen für Kategorien, Tags und Artikel-Artikel-Relationen (Verlinkungen), nicht nur für den Inhalt selbst.
* Mandantenfähigkeit / Multi-Tenancy (optional): Trennung von Daten per tenant_id-Spalte oder separaten Datenbankschemas.
* Datenbank: Relationale Datenbanken wie PostgreSQL bieten mit JSON-Unterstützung volle Flexibilität bei hoher Integrität – wichtig, da Wissensartikel oft variable Zusatzfelder benötigen.

=== Content & Routing Layer (Wissensartikel-Verwaltung & URLs) ===
Verantwortlich für das Laden und Rendern von Wissensartikeln für Nutzer:
* Slug-Mapping: Zuordnung von lesbaren Pfaden (/wiki/rust-cms-guide) zu Datenbank-Einträgen.
* Status & Versionierung: Artikel besitzen Zustände (draft, published, archived) sowie eine Revisions-Historie – bei einem Wissenssystem meist zentraler als bei einem Blog, da Artikel fortlaufend gepflegt statt einmalig veröffentlicht werden.
* Rendering:
** Server-Side Rendering (SSR): HTML wird direkt über eine Template-Engine (z. B. Askama, Tera) gerendert.
** Headless (API): Ausgabe von JSON für entkoppelte Frontends.

=== Wissensverknüpfung & Taxonomie (Knowledge Graph) ===
Das eigentliche Unterscheidungsmerkmal eines Wissenssystems gegenüber einem reinen CMS – Wissen entsteht durch Verknüpfung, nicht nur durch einzelne Artikel:
* Wiki-Links & Backlinks: Erkennung von Verweisen zwischen Artikeln (z. B. <nowiki>[[Artikelname]]</nowiki>-Syntax) sowie automatische Rückverfolgung, welche Artikel auf einen bestimmten Artikel verlinken.
* Kategorien & Tags: Hierarchische und flache Klassifizierung von Wissensartikeln zur Navigation und Filterung.
* Verwandte Artikel: Automatische oder manuelle Vorschläge thematisch ähnlicher Artikel (z. B. über gemeinsame Tags oder Verlinkungsdichte).
* Glossar & Begriffsdefinitionen: Zentrale Verwaltung wiederkehrender Fachbegriffe, die aus Artikeltexten heraus verlinkt werden können.

=== Authentication & Authorization (Sicherheit) ===
Trennt den öffentlichen Bereich vom Verwaltungsbereich:
* Authentifizierung: Identitätsprüfung von Benutzern (z. B. Session-Cookies oder JWT-Tokens).
* Rechteverwaltung (RBAC): Rollenbasierte Zugriffskontrolle (z. B. Admin, Editor, Author), um festzulegen, wer welche Endpunkte oder Inhalte bearbeiten darf.

=== Media Manager (Dateiverwaltung) ===
Verwaltet Bilder, PDFs und sonstige Uploads:
* Upload-Pipeline: Empfang von Dateien, Prüfung von MIME-Types und Dateigrößen.
* Verarbeitung: Automatische Skalierung oder Konvertierung von Bildern (z. B. Erzeugung von WebP-Thumbnails).
* Storage: Speicherung auf dem lokalen Dateisystem oder in einem Object-Storage (S3/MinIO).

=== Admin Backend (Verwaltungsoberfläche) ===
Die Benutzeroberfläche für Redakteure:
* Rich-Text / Markdown Editor: Eingabeoberfläche für Inhalte.
* REST / gRPC / GraphQL API: Kommuniziert mit dem Backend, um Inhalte, Einstellungen, Benutzer und Medien zu verwalten.

=== Caching & Performance Layer ===
Verhindert unnötige Datenbankabfragen bei hoher Last:
* HTTP-Caching: Passende Header (Cache-Control, ETag) für Nginx oder CDNs.
* In-Memory Caching: Zwischenspeichern von zusammengestellten Seiten oder Datenbank-Ergebnissen (z. B. über In-Memory-Stores oder Redis).

=== Search & Discovery (Suche) ===
In einem Wissenssystem oft der wichtigste Einstiegspunkt überhaupt – Nutzer suchen gezielt nach Antworten statt zu stöbern:
* DB-native Suche: Volltextsuche über PostgreSQL tsvector/tsquery, ausreichend für kleinere bis mittlere Datenmengen.
* Externer Suchindex: Bei höheren Anforderungen an Relevanz und Performance Anbindung an Meilisearch, Typesense oder Elasticsearch.
* Facettierung & Filter: Eingrenzung nach Kategorie, Tag, Datum oder Autor.

=== SEO & Metadata ===
Sorgt dafür, dass Inhalte von Suchmaschinen korrekt erfasst werden:
* Meta-Tags & Open Graph: Pro Inhalt konfigurierbare Title-, Description- und Social-Preview-Daten.
* Sitemap & Robots: Automatisch generierte sitemap.xml und robots.txt.
* Kanonische URLs & Redirects: Vermeidung von Duplicate Content, Verwaltung von 301-Weiterleitungen bei Slug-Änderungen.

=== Plugin- & Extension-System ===
Erlaubt es, Funktionalität ohne Eingriff in den Core zu erweitern:
* Hooks & Events: Definierte Erweiterungspunkte (z. B. before_publish, after_upload), an denen Plugins andocken können.
* Middleware-Ketten: Zusätzliche Verarbeitungsschritte in Request/Response-Pipeline einschiebbar.

=== Background Jobs / Task Queue ===
Verlagert zeitintensive Arbeiten aus dem Request-Zyklus:
* Queue-Anbindung: Asynchrone Verarbeitung über Redis-basierte Queues oder tokio-Task-Runner.
* Typische Jobs: Bildkonvertierung, E-Mail-Versand, Sitemap-Neubau, Webhook-Zustellung.
* Retry & Fehlerbehandlung: Wiederholungslogik und Dead-Letter-Handling bei fehlgeschlagenen Jobs.

=== Internationalisierung (i18n / l10n) ===
Unterstützt mehrsprachige Inhalte und Oberflächen:
* Mehrsprachige Inhalte: Übersetzungsstatus pro Sprache und Content-Objekt.
* Locale-Routing: Sprachspezifische Pfade (/de/…, /en/…) oder Subdomains.
* UI-Übersetzung: Lokalisierte Texte im Admin Backend.

=== Notifications & E-Mail ===
Kommuniziert Systemereignisse an Nutzer und Redakteure:
* Transaktionale Mails: Passwort-Reset, Einladungen, Kommentar-Benachrichtigungen.
* Workflow-Benachrichtigungen: Hinweise bei Freigabe-Anfragen oder Statuswechseln von Inhalten.

=== Audit-Log & Monitoring ===
Schafft Nachvollziehbarkeit und Betriebssicherheit:
* Audit-Log: Protokollierung, wer wann welche Änderung vorgenommen hat (Compliance, Nachvollziehbarkeit).
* Monitoring & Tracing: Metriken, Logs und Fehlerreporting für den laufenden Betrieb (z. B. über OpenTelemetry).

=== Konfigurationsmanagement ===
Zentrale Steuerung systemweiter Einstellungen:
* Site-Settings: Globale Konfiguration wie Seitenname, Standardsprache, Zeitzone.
* Feature-Flags: Kontrolliertes Ein-/Ausschalten einzelner Funktionen ohne Redeploy.

=== Deployment & Infrastructure ===
Betrifft Betrieb und Wartbarkeit des Systems:
* Migrations-Tooling: Versionierte Datenbank-Migrationen (z. B. via sqlx oder refinery).
* CI/CD: Automatisierte Tests und Deployments.
* Backup-Strategie: Regelmäßige Sicherung von Datenbank und Medien-Storage.
==Siehe auch==
* [[Grundbegriffe Informatik]]
* [[Weiter]]
* [[Wissenssysteme & Tools im Überblick]]
* [[Drupal]]

==Hinweis==
Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Hauptseite

2026-08-18T10:59:38Z

Thorsten: /* Siehe auch */

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
== Grundaufbau eines Wissensmanagement-Systems ==
Die folgenden Bausteine beschreiben kein klassisches CMS für Blog-Artikel, sondern ein '''Wissensmanagement-System (Wiki-artig)''': Im Mittelpunkt steht nicht die einzelne Seite, sondern das Netz aus Wissensartikeln, ihren Verknüpfungen und ihrer Auffindbarkeit. Entsprechend rücken Taxonomie, Verlinkung und Suche stärker in den Vordergrund als bei einem reinen Content-Ausgabe-System.

== Hauptbausteine im Detail ==

=== [[Data Engine]] ([[Wissensmodell]] & [[Speicherung]]) ===
Das Herzstück des Systems. Es definiert, wie Wissensartikel und ihre Beziehungen abgelegt werden:
* Entwickler-Entscheidung: Monolithisches Datenmodell (feste Tabellen für articles, categories, tags) oder flexibles Schema (JSONB / EAV-Muster für benutzerdefinierte Wissens-Typen wie Glossareinträge, How-Tos, FAQs).
* Taxonomie als Kernbestandteil: Eigene Tabellen für Kategorien, Tags und Artikel-Artikel-Relationen (Verlinkungen), nicht nur für den Inhalt selbst.
* Mandantenfähigkeit / Multi-Tenancy (optional): Trennung von Daten per tenant_id-Spalte oder separaten Datenbankschemas.
* Datenbank: Relationale Datenbanken wie PostgreSQL bieten mit JSON-Unterstützung volle Flexibilität bei hoher Integrität – wichtig, da Wissensartikel oft variable Zusatzfelder benötigen.

=== Content & Routing Layer (Wissensartikel-Verwaltung & URLs) ===
Verantwortlich für das Laden und Rendern von Wissensartikeln für Nutzer:
* Slug-Mapping: Zuordnung von lesbaren Pfaden (/wiki/rust-cms-guide) zu Datenbank-Einträgen.
* Status & Versionierung: Artikel besitzen Zustände (draft, published, archived) sowie eine Revisions-Historie – bei einem Wissenssystem meist zentraler als bei einem Blog, da Artikel fortlaufend gepflegt statt einmalig veröffentlicht werden.
* Rendering:
** Server-Side Rendering (SSR): HTML wird direkt über eine Template-Engine (z. B. Askama, Tera) gerendert.
** Headless (API): Ausgabe von JSON für entkoppelte Frontends.

=== Wissensverknüpfung & Taxonomie (Knowledge Graph) ===
Das eigentliche Unterscheidungsmerkmal eines Wissenssystems gegenüber einem reinen CMS – Wissen entsteht durch Verknüpfung, nicht nur durch einzelne Artikel:
* Wiki-Links & Backlinks: Erkennung von Verweisen zwischen Artikeln (z. B. <nowiki>[[Artikelname]]</nowiki>-Syntax) sowie automatische Rückverfolgung, welche Artikel auf einen bestimmten Artikel verlinken.
* Kategorien & Tags: Hierarchische und flache Klassifizierung von Wissensartikeln zur Navigation und Filterung.
* Verwandte Artikel: Automatische oder manuelle Vorschläge thematisch ähnlicher Artikel (z. B. über gemeinsame Tags oder Verlinkungsdichte).
* Glossar & Begriffsdefinitionen: Zentrale Verwaltung wiederkehrender Fachbegriffe, die aus Artikeltexten heraus verlinkt werden können.

=== Authentication & Authorization (Sicherheit) ===
Trennt den öffentlichen Bereich vom Verwaltungsbereich:
* Authentifizierung: Identitätsprüfung von Benutzern (z. B. Session-Cookies oder JWT-Tokens).
* Rechteverwaltung (RBAC): Rollenbasierte Zugriffskontrolle (z. B. Admin, Editor, Author), um festzulegen, wer welche Endpunkte oder Inhalte bearbeiten darf.

=== Media Manager (Dateiverwaltung) ===
Verwaltet Bilder, PDFs und sonstige Uploads:
* Upload-Pipeline: Empfang von Dateien, Prüfung von MIME-Types und Dateigrößen.
* Verarbeitung: Automatische Skalierung oder Konvertierung von Bildern (z. B. Erzeugung von WebP-Thumbnails).
* Storage: Speicherung auf dem lokalen Dateisystem oder in einem Object-Storage (S3/MinIO).

=== Admin Backend (Verwaltungsoberfläche) ===
Die Benutzeroberfläche für Redakteure:
* Rich-Text / Markdown Editor: Eingabeoberfläche für Inhalte.
* REST / gRPC / GraphQL API: Kommuniziert mit dem Backend, um Inhalte, Einstellungen, Benutzer und Medien zu verwalten.

=== Caching & Performance Layer ===
Verhindert unnötige Datenbankabfragen bei hoher Last:
* HTTP-Caching: Passende Header (Cache-Control, ETag) für Nginx oder CDNs.
* In-Memory Caching: Zwischenspeichern von zusammengestellten Seiten oder Datenbank-Ergebnissen (z. B. über In-Memory-Stores oder Redis).

=== Search & Discovery (Suche) ===
In einem Wissenssystem oft der wichtigste Einstiegspunkt überhaupt – Nutzer suchen gezielt nach Antworten statt zu stöbern:
* DB-native Suche: Volltextsuche über PostgreSQL tsvector/tsquery, ausreichend für kleinere bis mittlere Datenmengen.
* Externer Suchindex: Bei höheren Anforderungen an Relevanz und Performance Anbindung an Meilisearch, Typesense oder Elasticsearch.
* Facettierung & Filter: Eingrenzung nach Kategorie, Tag, Datum oder Autor.

=== SEO & Metadata ===
Sorgt dafür, dass Inhalte von Suchmaschinen korrekt erfasst werden:
* Meta-Tags & Open Graph: Pro Inhalt konfigurierbare Title-, Description- und Social-Preview-Daten.
* Sitemap & Robots: Automatisch generierte sitemap.xml und robots.txt.
* Kanonische URLs & Redirects: Vermeidung von Duplicate Content, Verwaltung von 301-Weiterleitungen bei Slug-Änderungen.

=== Plugin- & Extension-System ===
Erlaubt es, Funktionalität ohne Eingriff in den Core zu erweitern:
* Hooks & Events: Definierte Erweiterungspunkte (z. B. before_publish, after_upload), an denen Plugins andocken können.
* Middleware-Ketten: Zusätzliche Verarbeitungsschritte in Request/Response-Pipeline einschiebbar.

=== Background Jobs / Task Queue ===
Verlagert zeitintensive Arbeiten aus dem Request-Zyklus:
* Queue-Anbindung: Asynchrone Verarbeitung über Redis-basierte Queues oder tokio-Task-Runner.
* Typische Jobs: Bildkonvertierung, E-Mail-Versand, Sitemap-Neubau, Webhook-Zustellung.
* Retry & Fehlerbehandlung: Wiederholungslogik und Dead-Letter-Handling bei fehlgeschlagenen Jobs.

=== Internationalisierung (i18n / l10n) ===
Unterstützt mehrsprachige Inhalte und Oberflächen:
* Mehrsprachige Inhalte: Übersetzungsstatus pro Sprache und Content-Objekt.
* Locale-Routing: Sprachspezifische Pfade (/de/…, /en/…) oder Subdomains.
* UI-Übersetzung: Lokalisierte Texte im Admin Backend.

=== Notifications & E-Mail ===
Kommuniziert Systemereignisse an Nutzer und Redakteure:
* Transaktionale Mails: Passwort-Reset, Einladungen, Kommentar-Benachrichtigungen.
* Workflow-Benachrichtigungen: Hinweise bei Freigabe-Anfragen oder Statuswechseln von Inhalten.

=== Audit-Log & Monitoring ===
Schafft Nachvollziehbarkeit und Betriebssicherheit:
* Audit-Log: Protokollierung, wer wann welche Änderung vorgenommen hat (Compliance, Nachvollziehbarkeit).
* Monitoring & Tracing: Metriken, Logs und Fehlerreporting für den laufenden Betrieb (z. B. über OpenTelemetry).

=== Konfigurationsmanagement ===
Zentrale Steuerung systemweiter Einstellungen:
* Site-Settings: Globale Konfiguration wie Seitenname, Standardsprache, Zeitzone.
* Feature-Flags: Kontrolliertes Ein-/Ausschalten einzelner Funktionen ohne Redeploy.

=== Deployment & Infrastructure ===
Betrifft Betrieb und Wartbarkeit des Systems:
* Migrations-Tooling: Versionierte Datenbank-Migrationen (z. B. via sqlx oder refinery).
* CI/CD: Automatisierte Tests und Deployments.
* Backup-Strategie: Regelmäßige Sicherung von Datenbank und Medien-Storage.
==Siehe auch==
* [[Grundbegriffe Informatik]]
* [[Weiter]]
* [[Wissenssysteme & Tools im Überblick]]

==Hinweis==
Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

2026-08-13T11:55:09Z

Thorsten:

==Grundbegriffe Informatik==
* Daten,Variablen und Datentypen
* Datenstrukturen
* Modelle
* Algorithmen und Programmlogik
===Daten===
====Wissensbasiertes System====
=====Die Ebenen der Datenverarbeitung=====
* Faktendaten (Rohdaten & Information):
* Repräsentiertes Wissen: Strukturierte Daten, die logische Zusammenhänge, Regeln oder Beziehungen beschreiben
* Metadaten: Daten über die Daten
=====Typen von Daten in Wissenssystemen=====
Je nach Architektur und Einsatzzweck des Systems werden unterschiedliche Datenformen genutzt:

'''A. Regelbasiertes Wissen (Explizites Wissen)'''
* Form: „Wenn–Dann“-Regeln (If-Then-Rules).
* Anwendung: Klassische Expertensysteme (z. B. in der Medizin oder bei der Fehlerdiagnose).
* Beispiel: ''Wenn der Fehlercode E-101 auftritt und der Druck > 5 bar ist, dann öffne Ventil B.''

'''B. Strukturierte Wissensgraphen & Ontologien'''
* Form: Entitäten (Knoten) und deren Beziehungen (Kanten).
* Anwendung: Semantic Web, moderne Wiki-Systeme, Enterprise Search.
* Beispiel: ''[Ahrensburg] --(ist eine Stadt in)--> [Schleswig-Holstein]''.

'''C. Dokumentenbasiertes / Unstrukturiertes Wissen'''
* Form: Volltexte, Markdown-Dateien, PDFs, Quellcode, Wiki-Seiten.
* Anwendung: Wissensmanagement-Plattformen, Dokumentations-Engines.
* Besonderheit: Oft kombiniert mit Volltext-Indizes oder Schlagwort-Katalogen zur schnellen Durchsuchbarkeit.

'''D. Vektor-Daten (für KI & RAG)'''
* Form: Einbettungen (Embeddings) – hochdimensionale numerische Vektoren, die die semantische Bedeutung von Texten darstellen.
* Anwendung: Modernes LLM-basiertes Wissensmanagement (Retrieval-Augmented Generation / RAG).
* Vorteil: Ermöglicht die Suche nach Bedeutung und Kontext, nicht nur nach exakten Begriffen.
===Variable===
====Speicherarten in menschlichen kognitiven Systemen====
In der Kognitionswissenschaft unterscheidet man bezüglich des veränderbaren (variablen) Wissens vor allem zwei Speicherformen im Langzeitgedächtnis:

'''Explizites / Deklaratives Wissen ("Wissen, dass")'''
* Episodisches Gedächtnis: Speichert konkrete, zeitlich gebundene Erlebnisse und Ereignisse (z. B. „Gestern habe ich Thema X unterrichtet").
* Semantisches Gedächtnis: Speichert allgemeines, dekontextualisiertes Fakten- und Konzeptwissen (z. B. „Ein Verb beschreibt eine Handlung"). Dieses Netz aus Konzepten passt sich dynamisch an, wenn neue Regeln oder Fakten gelernt werden.

'''Implizites / Prozedurales Wissen ("Wissen, wie")'''
* Speichert Handlungsabläufe und Fertigkeiten (z. B. Grammatikregeln im Sprachgebrauch anwenden). Es verändert sich schrittweise durch Automatisierung und Praxis.

====Speicherungsarten in technischen/digitalen Systemen (KI & Software)====
Bei variablen Wissenssystemen in der Informatik unterscheidet man hauptsächlich zwei Speicherebenen:

'''A) Parameter-Speicher (Parametrisches Wissen)'''
* Wie gespeichert? In den mathematischen Verknüpfungen (Gewichten) neuronaler Netze.
* Variabilität: Ändert sich kontinuierlich während des Trainings oder Fine-Tunings. Einmal trainiert, ist dieses Wissen im laufenden Betrieb jedoch oft starr.

'''B) Externe Vektor- und Graphdatenbanken (Non-parametrisches Wissen)'''
* Wie gespeichert? Informationen werden als Einbettungen (Vectors) oder als semantische Netze (Knowledge Graphs) in Datenbanken abgelegt.
* Variabilität: Sehr hoch. Neue Daten können jederzeit hinzugefügt, aktualisiert oder gelöscht werden, ohne das Grundmodell neu zu trainieren (z. B. bei RAG-Systemen – Retrieval-Augmented Generation).
===Datentypen===
====1. Primitive / Elementare Datentypen====
Diese bilden die kleinsten Bausteine jedes Systems:
* Ganzzahlen (Integer): Diskrete Werte ohne Nachkommastellen (z. B. -42, 0, 1024).
* Gleitkommazahlen (Float, Double): Reelle Zahlen mit Nachkommastellen (z. B. 3.14159).
* Wahrheitswerte (Boolean): Binärwerte (true / false bzw. 1 / 0).
* Zeichen & Zeichenketten (Char, String): Textdaten (z. B. "Wissensgraph").
* Datum & Zeit (Date, Timestamp): Zeitstempel zur zeitlichen Einordnung von Wissen.

====2. Strukturierte & Komplexe Datentypen====
Dienen dazu, mehrere Datenpunkte logisch miteinander zu verknüpfen:

{| class="wikitable"
! Datentyp !! Beschreibung !! Beispiel / Anwendungsfall
|-
| Listen / Arrays || Geordnete Reihenfolge von Elementen || [1, 2, 3, 5, 8]
|-
| Schlüssel-Wert-Paare (Maps / Dictionaries) || Zuordnung von eindeutigen Keys zu Werten || {"Titel": "Artikel", "Autor": "Max"}
|-
| Sätze (Sets) || Ungeordnete Mengen ohne Duplikate || {Rot, Grün, Blau}
|-
| JSON / BSON || Hierarchisch strukturierte Dokumente || Ideal für semi-strukturierte Wissenseinträge
|-
| Blob / Binary || Unstrukturierte Binärdaten || Bilder, Audio-Dateien, Dokumente
|}

====3. Semantische Datentypen (Wissensrepräsentation)====
In modernen Wissenssystemen (z. B. RDF, OWL, Knowledge Graphs) gehen Datentypen über rein technische Formate hinaus und beschreiben Bedeutung und Beziehungen:
* Entitäten / Ressourcen (URIs/IRIs): Eindeutige Identifikatoren für Objekte, Personen oder Konzepte (z. B. http://example.org/person/Thorsten).
* Literale: Konkrete Werte, die an Entitäten hängen (oft kombiniert mit XML-Schema-Datentypen wie xsd:string oder xsd:dateTime).
* Relational- / Kanten-Typen (Predicates): Beschreiben die Art der Beziehung zwischen zwei Entitäten (z. B. istAutorVon, gehörtZuKategorie).
* Vektoren (Embeddings): Dichte numerische Vektoren, die von KI-Modellen und Vektordatenbanken verwendet werden, um semantische Ähnlichkeit zwischen Texten oder Konzepten abzubilden.

===Datenstrukturen===
Wissenssysteme (Knowledge Management Systems, Wissensdatenbanken) nutzen je nach Einsatzzweck, Flexibilität und Abfragesprache ganz unterschiedliche Datenstrukturen. Hier ist eine Übersicht der wichtigsten Strukturen – von einfach und unstrukturiert bis hin zu hochkomplex und semantisch vernetzt:

====1. Unstrukturierte & Hierarchische Strukturen====
'''Flat Files / Plain Text (Markdown, Wikitext)'''
* Funktionsweise: Daten liegen in einfachen Textdateien vor (oft mit Frontmatter für Metadaten).
* Vorteile: Extrem schnell, versionierbar (z. B. via Git), zukunftssicher und ohne Datenbank-Overhead.
* Einsatz: Static Site Generators (Hugo, Jekyll), moderne Notiz-Systeme (Obsidian, Logseq), flache Dokumentationen.

'''Baumstrukturen & Taxonomien'''
* Funktionsweise: Hierarchische Anordnung in Ordnern, Kategorien oder Unterkategorien (Eltern-Kind-Beziehungen).
* Vorteile: Intuitive Navigation für Menschen, klar abgegrenzte Themenbereiche.
* Einsatz: Klassische Dateisysteme, Firmen-Wikis, Inhaltsverzeichnisse.

====2. Strukturierte & Relationale Datenstrukturen====
'''Relationale Datenbanken (SQL)'''
* Funktionsweise: Tabellen mit festem Schema, Primär- und Fremdschlüsseln (z. B. PostgreSQL, MySQL).
* Vorteile: Hohe Datenintegrität (ACID-Konformität), ausgereifte Abfragesprachen, hervorragend für strukturierte Metadaten.
* Einsatz: Klassische Enterprise-CMS (Drupal, TYPO3), Lernplattformen (Moodle), MediaWiki.

'''Dokumentenorientierte Datenbanken (NoSQL)'''
* Funktionsweise: Speicherung in semi-strukturierten Formaten wie JSON, BSON oder XML.
* Vorteile: Flexibles Schema, einfache Skalierbarkeit, schnelle Entwicklung bei sich ändernden Datenmodellen.
* Einsatz: MongoDB, CouchDB, dynamische Wissensplattformen.

====3. Semantische & Vernetzte Strukturen (Graph-basiert)====
'''Eigenschaftsgraphen (Property Graphs)'''
* Funktionsweise: Knoten (Entitäten) und Kanten (Beziehungen) tragen Schlüssel-Wert-Paare (Attributes).
* Vorteile: Abfrage von komplexen, tief verschachtelten Zusammenhängen ohne teure SQL-JOINs.
* Einsatz: Neo4j, Memgraph, Wissensnetze, Empfehlungsdienste.

'''RDF-Tripel / Semantisches Web (Knowledge Graphs)'''
* Funktionsweise: Wissen wird in Form von Aussagen-Tripeln gespeichert: Subjekt → Prädikat → Objekt (z. B. „Ahrensburg → liegtIn → Schleswig-Holstein").
* Vorteile: Standardisiert (W3C, SPARQL, OWL), erlaubt automatische logische Schlussfolgerungen (Inferenz).
* Einsatz: Wikidata, DBpedia, Semantic MediaWiki, ontologiebasierte Expertensysteme.

====4. Moderne & Vektorbasierte Strukturen====
'''Vektordatenbanken (Embeddings)'''
* Funktionsweise: Texte oder Objekte werden durch Machine-Learning-Modelle in hochdimensionale Vektoren (Zahlenreihen) umgewandelt.
* Vorteile: Ermöglicht semantische Suche (Suche nach Bedeutung statt nach exakten Stichwörtern) und Retrieval-Augmented Generation (RAG).
* Einsatz: Pinecone, Qdrant, Chroma, pgvector für KI-Assistenten und LLM-Erweiterungen.
===Modelle===
Während die vorigen Abschnitte einzelne Daten, Datentypen und Datenstrukturen behandeln, beschreibt ein '''Modell''' das übergeordnete Ordnungsprinzip, nach dem ganze Wissensbestände organisiert werden. Die folgenden sieben Modelle sind die in der Praxis dominierenden Ansätze, von einfach bis hochformal.

====1. Hierarchisches / Baum-Modell (Tree / Folder Model)====
* Prinzip: Ordnung über verschachtelte Ordner, Kategorien oder Seitenbäume (Eltern-Kind-Beziehung).
* Typischer Einsatz: Klassische CMS, Dateisysteme, Notiz-Apps (wie Notion, Confluence).
* Vorteil: Intuitive Bedienung, klare Navigation.
* Nachteil: Wissen lässt sich oft nicht eindeutig einem Fachbereich zuordnen (Problem der eierlegenden Wollmilchsau).

====2. Flaches Modell mit Metadaten & Tags (Flat / Key-Value Model)====
* Prinzip: Alle Dokumente liegen auf einer Ebene ("Flat-File") und werden über Schlagwörter (Tags), Taxonomien oder Key-Value-Eigenschaften charakterisiert.
* Typischer Einsatz: Flat-File CMS (z. B. Grav, Kirby), statische Wissensdatenbanken (Markdown-basiert mit Frontmatter).
* Vorteil: Keine starre Ordnerstruktur, hochgradig durchsuchbar, extrem einfach zu sichern/versionieren (z. B. mit Git).
* Nachteil: Ohne disziplinierte Verschlagwortung geht die Übersicht schnell verloren.

====3. Relationales Datenmodell (Relational Model / SQL)====
* Prinzip: Wissen wird in zusammenhängenden Tabellen (Entitäten, Attribute, Fremdschlüssel) strukturiert.
* Typischer Einsatz: Enterprise-Wikis, Moodle/LMS, strukturierte Unternehmensdatenbanken.
* Vorteil: Hohe Datenintegrität, komplexe Abfragen über Fremdschlüssel und Tabellenverknüpfungen möglich.
* Nachteil: Starres Schema; Schemaänderungen bei sich veränderndem Wissen sind aufwendig.

====4. Netzwerk- / Graphen-Modell (Graph Model)====
* Prinzip: Daten bestehen aus Knoten (Entitäten/Dokumenten) und Kanten (Beziehungen).
* Typischer Einsatz: Personal Knowledge Management (z. B. Obsidian, Roam Research), Graph-Datenbanken (Neo4j).
* Vorteil: Spiegelt vernetztes Denken wider. Beziehungen wie ''[Projekt X] --hängt ab von--> [Technologie Y]'' sind native Bestandteile der Datenbank.
* Nachteil: Schwer zu visualisieren/navigieren bei sehr großen Datenmengen ohne gute Filter.

====5. Semantisches / Triples-Modell (RDF / Knowledge Graph)====
* Prinzip: Wissen wird in formallogischen Aussagen aus Subjekt – Prädikat – Objekt (Triples) gespeichert (z. B. ''[MediaWiki] [verwendet] [PostgreSQL]'').
* Typischer Einsatz: Semantic MediaWiki, Wikidata, Ontologie-Systeme (OWL, RDF/SPARQL).
* Vorteil: Maschinenlesbar, erlaubt automatische logische Rückschlüsse (Inferenz) und komplexe semantische Abfragen.
* Nachteil: Hohe Einarbeitungszeit und formale Komplexität beim Erstellen der Ontologien.

====6. Dokumentenorientiertes Modell (NoSQL / JSON)====
* Prinzip: Ein Wissenselement ist ein eigenständiges, strukturiertes Dokument (z. B. JSON/YAML), das eingebettete Attribute und Arrays enthält.
* Typischer Einsatz: CouchDB, MongoDB, elasticsearch-basierte Wissensspeicher.
* Vorteil: Flexibles Schema; jedes Dokument kann individuelle Felder haben, ohne das Gesamtsystem zu blockieren.
* Nachteil: Redundanzen bei Datenbanksicherungen, schwächere Konsistenzprüfungen als bei SQL.

====7. Vektorraum-Modell (Embedding / Latent Space Model)====
* Prinzip: Wissen wird nicht symbolisch, sondern als Position in einem hochdimensionalen Vektorraum repräsentiert; semantische Nähe entspricht geometrischer Nähe (siehe auch [[#Vektor-Daten (für KI & RAG)|Vektor-Daten]] weiter oben).
* Typischer Einsatz: Retrieval-Augmented Generation (RAG), semantische Suche, Empfehlungssysteme (Pinecone, Qdrant, pgvector).
* Vorteil: Findet Zusammenhänge über Bedeutung statt exakter Begriffe, robust gegenüber Synonymen und unscharfen Anfragen.
* Nachteil: Nicht direkt interpretierbar ("Black Box"), keine expliziten Regeln oder Beziehungen wie im Graphen-Modell.

'''Hinweis:''' In der Praxis werden diese Modelle selten pur eingesetzt, sondern kombiniert – dieses Wiki selbst ist ein Beispiel: Es nutzt eine Baumstruktur (Modell 1, über die `==`/`===`-Überschriften), liegt aber als flache, versionierte Textdatei vor (Modell 2).

{| class="wikitable"
! Nr. !! Modell !! Kernprinzip !! Größter Vorteil !! Größter Nachteil
|-
| 1 || Hierarchisch (Baum) || Eltern-Kind-Verschachtelung || Intuitive Navigation || Eindeutige Einordnung oft unmöglich
|-
| 2 || Flach mit Tags || Ebene Dateien + Metadaten || Einfach, git-versionierbar || Erfordert Tagging-Disziplin
|-
| 3 || Relational (SQL) || Tabellen + Fremdschlüssel || Hohe Datenintegrität || Starres Schema
|-
| 4 || Graph (Property Graph) || Knoten + Kanten || Bildet vernetztes Denken ab || Schwer visualisierbar bei großer Skala
|-
| 5 || Semantisch (RDF/Triples) || Subjekt–Prädikat–Objekt || Maschinelle Inferenz möglich || Hoher Formalisierungsaufwand
|-
| 6 || Dokumentenorientiert (NoSQL) || Eigenständige JSON-Dokumente || Flexibles Schema || Schwächere Konsistenzprüfung
|-
| 7 || Vektorraum (Embeddings) || Position im semantischen Raum || Suche nach Bedeutung statt Begriff || Nicht direkt interpretierbar
|}

===Algorithmen und Programmlogik===
Wenn es darum geht, Algorithmen und Programmlogik bildhaft, strukturiert oder regelbasiert darzustellen, unterscheidet man zwischen visuellen Repräsentationsformen (zur Dokumentation und Planung) und formalen Wissenssystemen (zur automatischen Verarbeitung).

====1. Visuelle Wissenssysteme & Graphische Modelle====
Diese Systeme helfen Entwicklern und Lernenden, die Logik eines Programms unabhängig von einer konkreten Programmiersprache zu visualisieren.

{| class="wikitable"
! System / Modell !! Einsatzbereich !! Besonderheit / Logikbausteine
|-
| Nassi-Shneiderman-Diagramm (Struktogramm) || Strukturierte Programmierung, Lehre & Didaktik || Vermeidet Unordnung (kein Pfeilsalat). Basiert auf Sequenz, Auswahl (If-Else) und Wiederholung (Schleifen).
|-
| Programmablaufplan (PAP) / Flowchart || Prozessvisualisierung, technische Abläufe || Klassisches Flussdiagramm (DIN 66001) mit Pfeilen, Rauten für Entscheidungen und Rechtecken für Aktionen.
|-
| UML-Aktivitätsdiagramm || Software-Engineering, objektorientiertes Design || Standard in der Industrie. Zeigt komplexe Kontroll- und Datenflüsse inklusive paralleler Verzweigungen.
|-
| Entscheidungstabellen || Komplexe Geschäftslogik & Regelwerke || Stellt alle möglichen Bedingungen und daraus resultierende Aktionen in Tabellenform gegenüber.
|}

====2. Formale & Regelbasierte Wissenssysteme====
Diese Systeme dienen nicht nur der Visualisierung, sondern führen Programmlogik und Regeln direkt aus:

'''Regelbasierte Systeme & Expertensysteme'''
* Funktionsweise: Wissen wird in Form von Fakten und Logikregeln (WENN Bedingung DANN Aktion) gespeichert. Eine Inferenzmaschine (Inference Engine) wertet diese Logik aus.
* Beispiele:
** Prolog: Deklarative Programmierung basierend auf Prädikatenlogik.
** Drools / Business Rules Engines: Für komplexe Geschäftsregeln im Unternehmensumfeld.

'''Pseudocode & Algorithmen-Markup'''
* Funktionsweise: Eine strukturierte, halbsprachliche Beschreibung von Logik. Er kombiniert natürliche Sprache mit Elementen höherer Programmiersprachen.
* Vorteil: Unabhängig von Syntaxfehlern und konzentriert auf das reine Problemlösungsmuster.

====3. MediaWiki als Referenzimplementierung====
Ein echtes MediaWiki (die Software hinter Wikipedia) setzt praktisch alle in diesem Wiki beschriebenen Modelle gleichzeitig um – nur an unterschiedlichen Stellen der Architektur:

'''Speicherung (Modell 3 Relational + Modell 6 Dokumentenorientiert)'''
* Jede Seite ist ein Dokument (Wikitext-Blob), die Metadaten drumherum sind relational organisiert.

{| class="wikitable"
! Tabelle !! Inhalt
|-
| page || Titel, Namespace, Status je Seite
|-
| revision || Jede Version einer Seite (Autor, Zeitstempel) – die Versionierung
|-
| text / slots || Der eigentliche Wikitext-Blob – unstrukturiert, wie ein Dokument
|-
| page_props || Frei erweiterbare Key-Value-Metadaten pro Seite
|}

'''Struktur der Überschriften (Modell 1 Baum – nur optisch)'''
* `==`, `===`, `====` erzeugen keine echte Baumstruktur in der Datenbank, sondern werden zur Laufzeit nur zu einem Inhaltsverzeichnis (`<h2>`, `<h3>`, …) mit Anchor-Links geparst.

'''Kategorien & Links (Modell 4 Graph + Modell 2 Flach/Tags)'''
* Intern ist MediaWiki ein Graph, kein Baum: die Tabelle `pagelinks` speichert, wer auf wen verlinkt (`[[Ziel]]`), `categorylinks`, welche Seite zu welcher Kategorie gehört, `templatelinks`, welche Seite welche Vorlage einbindet.
* Kategorien funktionieren wie Tags (flach + Metadaten), erlauben durch Verschachtelung aber auch baumartige Navigation – eine Seite kann in mehreren Kategorien gleichzeitig stehen.

'''Semantik (Modell 5 RDF/Triples)'''
* Nicht Core-MediaWiki, sondern die Extension Semantic MediaWiki (SMW): Annotationen wie `[[liegt in::Schleswig-Holstein]]` werden zu echten RDF-Tripeln (Subjekt–Prädikat–Objekt), abgelegt in eigenen SQL-Tabellen und exportierbar als RDF/OWL. `ASK`-Abfragen (SPARQL-ähnlich) werden damit direkt im Wikitext möglich.

'''Algorithmen/Programmlogik im Wiki selbst'''
* ParserFunctions-Extension: `{{#if: Bedingung | Dann | Sonst}}`, `{{#switch: ... }}` – die praktische Umsetzung des „WENN Bedingung DANN Aktion"-Regelsystems, direkt im Wikitext ausführbar.
* Scribunto (Lua-Module): vollwertige Programmlogik innerhalb von Vorlagen – die Inferenzmaschine für Fälle, die ParserFunctions nicht mehr abbilden.
* Templates (`{{Vorlage|Parameter}}`): parametrisierter Pseudocode – wiederverwendbare Logikbausteine, die beim Rendern expandiert werden.

'''Suche (Modell 7 Vektorraum, meist als Erweiterung)'''
* Core-MediaWiki bietet nur einfache Volltextsuche. Für semantische/Vektorsuche braucht es Extensions wie CirrusSearch (Elasticsearch) oder KI-gestützte Erweiterungen mit Embeddings – nativ ist das nicht vorgesehen.

'''Kurz zusammengefasst als Pipeline:'''
* Wikitext (Dokument, Modell 6) → Parser/Präprozessor (Templates/Scribunto = Algorithmen) → HTML-Rendering (Baum-Optik, Modell 1) → gespeichert in relationaler DB (Modell 3) → verknüpft über pagelinks/categorylinks (Graph, Modell 4; Tags, Modell 2) → optional angereichert um SMW-Tripel (Modell 5) und Suchindex/Embeddings (Modell 7).

====4. XWiki als weiteres Beispiel====
XWiki (Java-basiert) verfolgt einen anderen Architekturansatz als MediaWiki und deckt die Modelle an anderen Stellen ab – vor allem, weil Struktur und Daten dort von Anfang an enger verzahnt sind:

'''Speicherung (Modell 3 Relational + Modell 6 Dokumentenorientiert, aber enger verzahnt)'''
* Über Hibernate ORM auf einer relationalen DB (standardmäßig) abgelegt. Jede Seite (`XWikiDocument`) ist zwar ein Dokument, trägt aber – anders als bei MediaWiki – strukturierte Daten direkt eingebettet statt nur als loser Freitext-Blob.

'''Echte Hierarchie (Modell 1 Baum, nicht nur optisch)'''
* XWiki-Seiten leben in verschachtelten Spaces (`Space.SubSpace.Seite`) – eine tatsächliche Baumstruktur in der Datenbank, kein bloß optisches Inhaltsverzeichnis wie bei MediaWikis `==`-Überschriften. Navigation und Rechteverwaltung (Berechtigungen vererben sich space-weise) folgen dieser echten Hierarchie.

'''XClass / XObject – das Kernfeature (Modell 3 Relational, nativ statt per Extension)'''
* Jede Seite kann strukturierte, typisierte Datensätze (XObjects) tragen, deren Schema in einer XClass definiert ist – im Grunde eine pro Seite eingebettete Tabellenzeile mit festem Schema (Felder, Typen, Pflichtfelder).
* Damit sind Wissenseinträge gleichzeitig Dokument (Freitext) und Datensatz (strukturierte Felder) – MediaWiki braucht dafür die Extension Semantic MediaWiki, XWiki hat das nativ im Core.
* Abfragen darüber laufen über XWQL (XWiki Query Language, HQL/JPQL-artig) – SQL-ähnliche Abfragen direkt über die Wissensbasis, ohne SPARQL-Umweg.

'''Algorithmen/Programmlogik im Wiki selbst'''
* Velocity- und Groovy-Skripte direkt in Seiten eingebettet (`#if()`, `#foreach()`, `$doc.getObject(...)`) – vollwertige Programmlogik, näher an einer richtigen Skriptsprache als MediaWikis ParserFunctions.
* Wiki-Makros (ähnlich Templates) kapseln wiederverwendbare Logik, können aber – weil Java-basiert – auch komplexe Berechnungen und Datenbankzugriffe direkt ausführen.

'''Suche'''
* Solr/Lucene-basierte Volltext- und Facettensuche ist im Core enthalten (kein Extension-Zwang wie CirrusSearch bei MediaWiki); neuere Erweiterungen ergänzen KI-gestützte/semantische Suche mit Embeddings.

'''Kurzvergleich MediaWiki vs. XWiki:'''

{| class="wikitable"
! Aspekt !! MediaWiki !! XWiki
|-
| Hierarchie || Optisch über Überschriften, echte Struktur nur via Kategorien (Graph) || Echte verschachtelte Space-Baumstruktur
|-
| Strukturierte Daten (Modell 3/5) || Nur per Extension (Semantic MediaWiki) || Nativ im Core (XClass/XObject)
|-
| Abfragesprache || SMW-ASK (SPARQL-ähnlich, Extension) || XWQL (SQL-ähnlich, Core)
|-
| Programmlogik || ParserFunctions/Scribunto (Lua) || Velocity/Groovy (Java-Ökosystem)
|-
| Typischer Einsatz || Große offene Wissensdatenbanken (Wikipedia) || Unternehmens-Intranets mit strukturierten Formularen/Workflows
|}

====5. Beispiel: KI & RAG-Wissenssystem====
Ein modernes RAG-System (Retrieval-Augmented Generation) verfolgt einen grundlegend anderen Ansatz als MediaWiki und XWiki: Statt Wissen über explizite Struktur (Baum, Kategorien, XClass) zu ordnen, wird es über semantische Nähe im Vektorraum (Modell 7) auffindbar gemacht – die Struktur der vorigen Beispiele fehlt hier größtenteils.

'''Speicherung (Modell 7 Vektorraum + Modell 6 Dokumentenorientiert)'''
* Quelldokumente (Wiki-Seiten, PDFs, Markdown) werden in Chunks zerlegt und über ein Embedding-Modell in hochdimensionale Vektoren umgewandelt.
* Abgelegt in einer Vektordatenbank (Pinecone, Qdrant, Chroma, pgvector) – meist zusammen mit dem Originaltext als Payload/Metadaten, also weiterhin dokumentbasiert im Hintergrund.

'''Struktur (keine echte Hierarchie – Gegenteil von Modell 1)'''
* Es gibt keinen Seitenbaum und keine Kategorien wie bei MediaWiki/XWiki. Auffindbarkeit entsteht rein durch geometrische Nähe im Vektorraum, nicht durch Navigation oder Verlinkung.
* Optional wird das mit einem Graph (Modell 4, „GraphRAG") oder mit Metadaten-Filtern (Modell 2, Tags) kombiniert, um reine Vektorsuche zu verbessern.

'''Algorithmen/Programmlogik – die eigentliche RAG-Pipeline'''
* Anfrage (Query) → Embedding der Anfrage → Ähnlichkeitssuche (z. B. Cosinus-Ähnlichkeit) in der Vektordatenbank → Top-k relevante Chunks abrufen → Re-Ranking (optional) → Chunks als Kontext in den Prompt einfügen → LLM generiert Antwort.
* Das ist funktional das Gegenstück zur „Inferenzmaschine" der regelbasierten Systeme (Abschnitt 2): statt fester WENN-DANN-Regeln wertet hier ein neuronales Netz statistische Ähnlichkeit aus – nicht deterministisch, sondern approximativ.
* Agenten-Frameworks (LangChain, LlamaIndex) übernehmen die Rolle von Templates/Makros: wiederverwendbare, parametrisierte Ablaufbausteine für Retrieval, Re-Ranking und Prompt-Konstruktion.

'''Semantik (implizit statt explizit – Gegenteil von Modell 5)'''
* Anders als RDF-Tripel (Subjekt–Prädikat–Objekt, explizit und maschinenlesbar) ist die „Semantik" eines Embeddings nicht symbolisch, sondern eine gelernte, nicht direkt interpretierbare Position im Vektorraum („Black Box", vgl. Modell 7 im Abschnitt „Modelle").

'''Suche (Modell 7 nativ statt Extension)'''
* Semantische Suche ist hier kein Zusatzfeature (wie CirrusSearch bei MediaWiki), sondern der gesamte Zweck des Systems.

'''Erweiterter Kurzvergleich:'''

{| class="wikitable"
! Aspekt !! MediaWiki !! XWiki !! RAG-System
|-
| Hierarchie || Optisch + Kategorien (Graph) || Echte Space-Baumstruktur || Keine – nur Vektor-Nähe (optional + Graph/Tags)
|-
| Strukturierte Daten || Nur per Extension (SMW) || Nativ (XClass/XObject) || Keine feste Struktur, nur Chunks + Embeddings
|-
| Abfrage || SMW-ASK / Volltext || XWQL / Volltext || Vektor-Ähnlichkeitssuche (semantisch)
|-
| Programmlogik || ParserFunctions/Scribunto || Velocity/Groovy || Retrieval-Pipeline + LLM (LangChain/LlamaIndex)
|-
| Ergebnis-Charakter || Deterministisch, nachvollziehbar || Deterministisch, nachvollziehbar || Approximativ, nicht immer nachvollziehbar
|-
| Typischer Einsatz || Große offene Wissensdatenbanken || Unternehmens-Intranets mit Formularen/Workflows || KI-Assistenten, semantische Suche über große Dokumentenmengen
|}

====6. Obsidian als Beispiel für ein natives Graph-Modell====
Obsidian schließt eine Lücke der bisherigen Beispiele: Es braucht überhaupt keinen Server und keine Datenbank – die Graph-Struktur (Modell 4) entsteht rein client-seitig aus einfachen Textdateien.

'''Speicherung (Modell 2 Flach + Modell 6 Dokumentenorientiert, ohne jede Datenbank)'''
* Jede Notiz ist eine einzelne Markdown-Datei im lokalen Dateisystem (kein MySQL, kein Hibernate, keine Vektordatenbank) – die radikalste Umsetzung von Modell 2 (Flat File) unter allen fünf Beispielen.
* Metadaten liegen als YAML-Frontmatter direkt in der Datei (ähnlich einer sehr leichtgewichtigen XClass, aber ohne erzwungenes Schema).

'''Struktur (Modell 4 Graph, nativ und zentral statt Zusatzfeature)'''
* Verlinkung erfolgt über `[[Wikilinks]]` direkt im Text. Anders als bei MediaWikis `pagelinks`-Tabelle gibt es keine zentrale Datenbank dafür – der Graph wird beim Öffnen des Vaults aus allen Dateien neu aufgebaut (lokaler Index).
* Backlinks (eingehende Verweise) werden automatisch berechnet und in der Graph View visualisiert – der Graph ist hier das Kernprodukt, nicht ein Abfallprodukt der Struktur wie bei MediaWiki/XWiki.
* Es gibt bewusst keine erzwungene Hierarchie (Modell 1): Ordner sind rein organisatorisch, die eigentliche Navigation läuft über Links und Backlinks.

'''Algorithmen/Programmlogik im Wiki selbst'''
* Dataview-Plugin: eine eigene Abfragesprache (DQL, an SQL angelehnt, bzw. JS-basiert), die Frontmatter-Felder über alle Notizen hinweg wie eine Tabelle abfragt – funktional näher an XWQL als an MediaWikis ParserFunctions.
* Templater-Plugin: JavaScript-Templates für dynamische Notiz-Erstellung (Datumslogik, Platzhalter, bedingte Textbausteine) – das WENN-DANN aus Abschnitt 2, aber clientseitig in JS statt serverseitig.

'''Semantik (Modell 5 nur rudimentär, kein echtes RDF)'''
* Frontmatter-Properties (`status: draft`, `tags: [...]`) sind einfache Key-Value-Paare, keine typisierten Tripel wie bei Semantic MediaWiki. Es gibt keine Inferenzmaschine – Schlussfolgerungen (z. B. „alle Notizen mit Tag X, die auf Y verlinken") müssen über Dataview-Abfragen nachgebaut werden.

'''Suche'''
* Lokaler Volltextindex, rein clientseitig. Semantische/Vektorsuche (Modell 7) ist nur über Community-Plugins (z. B. Smart Connections) nachrüstbar, nicht im Core.

'''Vollständiger Kurzvergleich:'''

{| class="wikitable"
! Aspekt !! MediaWiki !! XWiki !! RAG-System !! Obsidian
|-
| Backend || Server + relationale DB || Server + relationale DB (Hibernate) || Server + Vektordatenbank || Kein Server, lokale Dateien
|-
| Hierarchie || Optisch + Kategorien (Graph) || Echte Space-Baumstruktur || Keine – nur Vektor-Nähe || Keine – nur Ordner (kosmetisch) + Graph
|-
| Strukturierte Daten || Nur per Extension (SMW) || Nativ (XClass/XObject) || Keine feste Struktur (Chunks) || YAML-Frontmatter (informell, kein Schema)
|-
| Abfrage || SMW-ASK / Volltext || XWQL / Volltext || Vektor-Ähnlichkeitssuche || Dataview (DQL) / Volltext
|-
| Programmlogik || ParserFunctions/Scribunto || Velocity/Groovy || Retrieval-Pipeline + LLM || Templater (JavaScript)
|-
| Typischer Einsatz || Große offene Wissensdatenbanken || Unternehmens-Intranets mit Formularen/Workflows || KI-Assistenten, semantische Suche || Persönliches Wissensmanagement (PKM)
|}

2026-08-12T01:19:58Z

Thorsten:

* [[Rust-Datenmodell für Drupal-Entities]]
= Rust-Datenmodell für Drupal-Entities =

== Übersicht ==

Dieser Artikel dokumentiert ein Rust-Datenmodell, das die zentralen
Entity-Konzepte von Drupal (Node, User, Taxonomy Term, Media, Paragraph)
als <pre>struct</pre>/<pre>enum</pre>-Typen abbildet. Das Modell enthält bewusst '''keine
Logik''' (keine <pre>impl</pre>-Methoden) – es dient als reine Datenrepräsentation.
Eine (De-)Serialisierung (z. B. mit [https://serde.rs/ serde] für
Drupal-JSON:API-Antworten) ist bewusst noch nicht Teil dieses Modells
und folgt in einem späteren Schritt.

== Motivation ==

Drupal modelliert Inhalte über ein generisches Entity-System:
* '''Entity-Typen''' (<pre>node</pre>, <pre>user</pre>, <pre>taxonomy_term</pre>, <pre>media</pre>, …) definieren die grundlegende Art eines Objekts.
* '''Bundles''' (bei Nodes „Content Types" genannt, z. B. <pre>article</pre>, <pre>page</pre>) spezialisieren einen Entity-Typ.
* '''Felder''' (<pre>field_*</pre>) sind pro Bundle konfigurierbar, typisiert und können einfach- oder mehrwertig (Kardinalität) sein.

Um mit einem Drupal-Backend aus Rust heraus zu arbeiten, braucht man
typisierte Gegenstücke zu diesen Konzepten. Das hier beschriebene
Modell bildet diese Struktur 1:1 in Rust ab.

== Grundtypen ==

<pre>
#[derive(Debug, Clone, PartialEq, Eq)]
pub enum EntityType {
Node,
User,
TaxonomyTerm,
Media,
Paragraph,
File,
Menu,
Block,
Custom(String),
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum PublishStatus {
Published,
Unpublished,
}

pub type LangCode = String;
</pre>

<pre>EntityType</pre> bildet die von Drupal vordefinierten Entity-Typen ab; der
<pre>Custom</pre>-Zweig deckt eigene, per Modul definierte Entity-Typen ab, ohne
das Enum ändern zu müssen.

== Feldwerte: <pre>FieldValue</pre> ==

Drupal-Felder sind stark typisiert (Text, Zahl, Datum, Referenz, Bild, …).
Dies wird über ein Enum mit Payload pro Variante abgebildet:

<pre>
#[derive(Debug, Clone)]
pub enum FieldValue {
Text(String),
TextLong { value: String, format: Option<String> },
Integer(i64),
Decimal(f64),
Boolean(bool),
DateTime(DateTime<Utc>),
Email(String),
Link { uri: String, title: Option<String> },
EntityReference { target_id: u64, target_type: EntityType },
Image {
target_id: u64,
alt: Option<String>,
title: Option<String>,
width: Option<u32>,
height: Option<u32>,
},
List(Vec<FieldValue>),
}

pub type FieldMap = HashMap<String, FieldValue>;
</pre>

* <pre>List(Vec<FieldValue>)</pre> bildet mehrwertige Felder ab (Kardinalität > 1).
* <pre>FieldMap</pre> ist die generische Ablage für alle <pre>field_*</pre>-Werte eines Bundles, adressiert über den Feldmaschinennamen (z. B. <pre>field_tags</pre>).

== Entity-Typen im Detail ==

=== Gemeinsame Basis ===

<pre>
#[derive(Debug, Clone)]
pub struct EntityBase {
pub id: u64,
pub uuid: Uuid,
pub entity_type: EntityType,
pub bundle: String,
pub langcode: LangCode,
pub created: DateTime<Utc>,
pub changed: DateTime<Utc>,
}
</pre>

<pre>EntityBase</pre> fasst Eigenschaften zusammen, die praktisch jede
Content-Entity in Drupal besitzt, und wird per Komposition in konkrete
Entity-Structs eingebettet (siehe <pre>Node</pre>, <pre>Media</pre>). Beim späteren
Ergänzen von serde bietet sich dafür <pre>#[serde(flatten)]</pre> an, damit die
Felder von <pre>EntityBase</pre> beim (De-)Serialisieren auf derselben Ebene
wie die restlichen Felder erscheinen.

=== Node ===

<pre>
#[derive(Debug, Clone)]
pub struct Node {
pub base: EntityBase,
pub title: String,
pub status: PublishStatus,
pub author_id: u64,
pub fields: FieldMap,
}
</pre>

=== User ===

<pre>
#[derive(Debug, Clone)]
pub struct User {
pub id: u64,
pub uuid: Uuid,
pub name: String,
pub mail: String,
pub status: bool,
pub roles: Vec<String>,
pub created: DateTime<Utc>,
pub fields: FieldMap,
}
</pre>

<pre>User</pre> nutzt bewusst kein <pre>EntityBase</pre>, da User-Entities in Drupal kein
<pre>bundle</pre>/<pre>langcode</pre> im klassischen Sinn besitzen und stattdessen
<pre>roles</pre> und einen einfachen <pre>status: bool</pre> (aktiv/blockiert) haben.

=== TaxonomyTerm ===

<pre>
#[derive(Debug, Clone)]
pub struct TaxonomyTerm {
pub id: u64,
pub uuid: Uuid,
pub vocabulary: String,
pub name: String,
pub description: Option<String>,
pub parent_id: Option<u64>,
pub weight: i32,
pub fields: FieldMap,
}
</pre>

Bildet Taxonomiebegriffe inkl. hierarchischer Eltern-Referenz
(<pre>parent_id</pre>) und Sortiergewicht (<pre>weight</pre>) ab.

=== Media & Paragraph ===

<pre>
#[derive(Debug, Clone)]
pub struct Media {
pub base: EntityBase,
pub name: String,
pub fields: FieldMap,
}

#[derive(Debug, Clone)]
pub struct Paragraph {
pub id: u64,
pub uuid: Uuid,
pub bundle: String,
pub fields: FieldMap,
}
</pre>

<pre>Paragraph</pre> ist bewusst schlank gehalten, da Paragraphs in Drupal keine
eigenständigen, direkt aufrufbaren Entities mit URL/Alias sind, sondern
stets über eine Host-Entity referenziert werden.

== Schema-Introspektion (optional) ==

Für Anwendungsfälle, in denen Feld- und Bundle-Definitionen selbst
(nicht nur Werte) abgebildet werden müssen – etwa um ein Drupal-Schema
zu spiegeln oder Formulare dynamisch zu generieren:

<pre>
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum Cardinality {
Single,
Multiple,
Unlimited,
}

#[derive(Debug, Clone)]
pub struct FieldDefinition {
pub field_name: String,
pub field_type: String,
pub cardinality: Cardinality,
pub required: bool,
}

#[derive(Debug, Clone)]
pub struct BundleDefinition {
pub entity_type: EntityType,
pub bundle: String,
pub label: String,
pub fields: Vec<FieldDefinition>,
}
</pre>

== Design-Entscheidungen ==

{| class="wikitable"
|-
! Entscheidung !! Begründung
|-
| <pre>FieldValue</pre> als Enum mit Payload pro Variante || Bildet Drupals starke Feldtypisierung typsicher ab, statt alles als <pre>String</pre> zu behandeln.
|-
| <pre>FieldMap = HashMap<String, FieldValue></pre> || Bundles sind zur Compile-Zeit nicht bekannt; generische Map bleibt flexibel für beliebige <pre>field_*</pre>-Namen.
|-
| <pre>EntityBase</pre> als Kompositionsfeld || Vermeidet Duplikation gemeinsamer Properties zwischen Node/Media, ohne Vererbung (die es in Rust nicht gibt).
|-
| Kein <pre>impl</pre>-Block || Modell bleibt reine Datenschicht; Geschäftslogik (Validierung, API-Calls) gehört in separate Module.
|-
| <pre>EntityType::Custom(String)</pre> || Deckt durch Contrib-/Custom-Module definierte Entity-Typen ab, ohne das Enum erweitern zu müssen.
|}

== Offene Erweiterungspunkte ==

* Weitere <pre>FieldValue</pre>-Varianten je nach genutzten Feldtypen (z. B. <pre>Geolocation</pre>, <pre>Address</pre>, <pre>File</pre> losgelöst von <pre>Image</pre>).
* Übersetzungen (<pre>translations: HashMap<LangCode, FieldMap></pre>), falls Drupal-Mehrsprachigkeit (Content Translation) abgebildet werden soll.
* Konkretes Mapping auf die JSON:API-Hüllstruktur (<pre>data</pre>, <pre>attributes</pre>, <pre>relationships</pre>, <pre>included</pre>), falls direkt gegen die Drupal-JSON:API deserialisiert werden soll, statt ein eigenes flaches Modell zu pflegen.

== Verwendete Crates ==

* [https://crates.io/crates/chrono chrono] – Zeitstempel (<pre>created</pre>, <pre>changed</pre>)
* [https://crates.io/crates/uuid uuid] – Entity-UUIDs

Hinweis: [https://serde.rs/ serde] (für die (De-)Serialisierung) ist
bewusst noch nicht Teil dieses Modells und wird in einem späteren
Schritt ergänzt.

== Siehe auch ==

* Drupal-Dokumentation: [https://www.drupal.org/docs/drupal-apis/entity-api Entity API]
* Drupal-Dokumentation: [https://www.drupal.org/docs/core-modules-and-themes/core-modules/jsonapi-module JSON:API-Modul]

[[Kategorie:Rust]]
[[Kategorie:Drupal]]

Data Engine

2026-08-12T01:17:50Z

Thorsten:

= Rust-Datenmodell für Drupal-Entities =

== Übersicht ==

Dieser Artikel dokumentiert ein Rust-Datenmodell, das die zentralen
Entity-Konzepte von Drupal (Node, User, Taxonomy Term, Media, Paragraph)
als <pre>struct</pre>/<pre>enum</pre>-Typen abbildet. Das Modell enthält bewusst '''keine
Logik''' (keine <pre>impl</pre>-Methoden) – es dient als reine Datenrepräsentation.
Eine (De-)Serialisierung (z. B. mit [https://serde.rs/ serde] für
Drupal-JSON:API-Antworten) ist bewusst noch nicht Teil dieses Modells
und folgt in einem späteren Schritt.

== Motivation ==

Drupal modelliert Inhalte über ein generisches Entity-System:
* '''Entity-Typen''' (<pre>node</pre>, <pre>user</pre>, <pre>taxonomy_term</pre>, <pre>media</pre>, …) definieren die grundlegende Art eines Objekts.
* '''Bundles''' (bei Nodes „Content Types" genannt, z. B. <pre>article</pre>, <pre>page</pre>) spezialisieren einen Entity-Typ.
* '''Felder''' (<pre>field_*</pre>) sind pro Bundle konfigurierbar, typisiert und können einfach- oder mehrwertig (Kardinalität) sein.

Um mit einem Drupal-Backend aus Rust heraus zu arbeiten, braucht man
typisierte Gegenstücke zu diesen Konzepten. Das hier beschriebene
Modell bildet diese Struktur 1:1 in Rust ab.

== Grundtypen ==

<pre>
#[derive(Debug, Clone, PartialEq, Eq)]
pub enum EntityType {
Node,
User,
TaxonomyTerm,
Media,
Paragraph,
File,
Menu,
Block,
Custom(String),
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum PublishStatus {
Published,
Unpublished,
}

pub type LangCode = String;
</pre>

<pre>EntityType</pre> bildet die von Drupal vordefinierten Entity-Typen ab; der
<pre>Custom</pre>-Zweig deckt eigene, per Modul definierte Entity-Typen ab, ohne
das Enum ändern zu müssen.

== Feldwerte: <pre>FieldValue</pre> ==

Drupal-Felder sind stark typisiert (Text, Zahl, Datum, Referenz, Bild, …).
Dies wird über ein Enum mit Payload pro Variante abgebildet:

<pre>
#[derive(Debug, Clone)]
pub enum FieldValue {
Text(String),
TextLong { value: String, format: Option<String> },
Integer(i64),
Decimal(f64),
Boolean(bool),
DateTime(DateTime<Utc>),
Email(String),
Link { uri: String, title: Option<String> },
EntityReference { target_id: u64, target_type: EntityType },
Image {
target_id: u64,
alt: Option<String>,
title: Option<String>,
width: Option<u32>,
height: Option<u32>,
},
List(Vec<FieldValue>),
}

pub type FieldMap = HashMap<String, FieldValue>;
</pre>

* <pre>List(Vec<FieldValue>)</pre> bildet mehrwertige Felder ab (Kardinalität > 1).
* <pre>FieldMap</pre> ist die generische Ablage für alle <pre>field_*</pre>-Werte eines Bundles, adressiert über den Feldmaschinennamen (z. B. <pre>field_tags</pre>).

== Entity-Typen im Detail ==

=== Gemeinsame Basis ===

<pre>
#[derive(Debug, Clone)]
pub struct EntityBase {
pub id: u64,
pub uuid: Uuid,
pub entity_type: EntityType,
pub bundle: String,
pub langcode: LangCode,
pub created: DateTime<Utc>,
pub changed: DateTime<Utc>,
}
</pre>

<pre>EntityBase</pre> fasst Eigenschaften zusammen, die praktisch jede
Content-Entity in Drupal besitzt, und wird per Komposition in konkrete
Entity-Structs eingebettet (siehe <pre>Node</pre>, <pre>Media</pre>). Beim späteren
Ergänzen von serde bietet sich dafür <pre>#[serde(flatten)]</pre> an, damit die
Felder von <pre>EntityBase</pre> beim (De-)Serialisieren auf derselben Ebene
wie die restlichen Felder erscheinen.

=== Node ===

<pre>
#[derive(Debug, Clone)]
pub struct Node {
pub base: EntityBase,
pub title: String,
pub status: PublishStatus,
pub author_id: u64,
pub fields: FieldMap,
}
</pre>

=== User ===

<pre>
#[derive(Debug, Clone)]
pub struct User {
pub id: u64,
pub uuid: Uuid,
pub name: String,
pub mail: String,
pub status: bool,
pub roles: Vec<String>,
pub created: DateTime<Utc>,
pub fields: FieldMap,
}
</pre>

<pre>User</pre> nutzt bewusst kein <pre>EntityBase</pre>, da User-Entities in Drupal kein
<pre>bundle</pre>/<pre>langcode</pre> im klassischen Sinn besitzen und stattdessen
<pre>roles</pre> und einen einfachen <pre>status: bool</pre> (aktiv/blockiert) haben.

=== TaxonomyTerm ===

<pre>
#[derive(Debug, Clone)]
pub struct TaxonomyTerm {
pub id: u64,
pub uuid: Uuid,
pub vocabulary: String,
pub name: String,
pub description: Option<String>,
pub parent_id: Option<u64>,
pub weight: i32,
pub fields: FieldMap,
}
</pre>

Bildet Taxonomiebegriffe inkl. hierarchischer Eltern-Referenz
(<pre>parent_id</pre>) und Sortiergewicht (<pre>weight</pre>) ab.

=== Media & Paragraph ===

<pre>
#[derive(Debug, Clone)]
pub struct Media {
pub base: EntityBase,
pub name: String,
pub fields: FieldMap,
}

#[derive(Debug, Clone)]
pub struct Paragraph {
pub id: u64,
pub uuid: Uuid,
pub bundle: String,
pub fields: FieldMap,
}
</pre>

<pre>Paragraph</pre> ist bewusst schlank gehalten, da Paragraphs in Drupal keine
eigenständigen, direkt aufrufbaren Entities mit URL/Alias sind, sondern
stets über eine Host-Entity referenziert werden.

== Schema-Introspektion (optional) ==

Für Anwendungsfälle, in denen Feld- und Bundle-Definitionen selbst
(nicht nur Werte) abgebildet werden müssen – etwa um ein Drupal-Schema
zu spiegeln oder Formulare dynamisch zu generieren:

<pre>
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum Cardinality {
Single,
Multiple,
Unlimited,
}

#[derive(Debug, Clone)]
pub struct FieldDefinition {
pub field_name: String,
pub field_type: String,
pub cardinality: Cardinality,
pub required: bool,
}

#[derive(Debug, Clone)]
pub struct BundleDefinition {
pub entity_type: EntityType,
pub bundle: String,
pub label: String,
pub fields: Vec<FieldDefinition>,
}
</pre>

== Design-Entscheidungen ==

{| class="wikitable"
|-
! Entscheidung !! Begründung
|-
| <pre>FieldValue</pre> als Enum mit Payload pro Variante || Bildet Drupals starke Feldtypisierung typsicher ab, statt alles als <pre>String</pre> zu behandeln.
|-
| <pre>FieldMap = HashMap<String, FieldValue></pre> || Bundles sind zur Compile-Zeit nicht bekannt; generische Map bleibt flexibel für beliebige <pre>field_*</pre>-Namen.
|-
| <pre>EntityBase</pre> als Kompositionsfeld || Vermeidet Duplikation gemeinsamer Properties zwischen Node/Media, ohne Vererbung (die es in Rust nicht gibt).
|-
| Kein <pre>impl</pre>-Block || Modell bleibt reine Datenschicht; Geschäftslogik (Validierung, API-Calls) gehört in separate Module.
|-
| <pre>EntityType::Custom(String)</pre> || Deckt durch Contrib-/Custom-Module definierte Entity-Typen ab, ohne das Enum erweitern zu müssen.
|}

== Offene Erweiterungspunkte ==

* Weitere <pre>FieldValue</pre>-Varianten je nach genutzten Feldtypen (z. B. <pre>Geolocation</pre>, <pre>Address</pre>, <pre>File</pre> losgelöst von <pre>Image</pre>).
* Übersetzungen (<pre>translations: HashMap<LangCode, FieldMap></pre>), falls Drupal-Mehrsprachigkeit (Content Translation) abgebildet werden soll.
* Konkretes Mapping auf die JSON:API-Hüllstruktur (<pre>data</pre>, <pre>attributes</pre>, <pre>relationships</pre>, <pre>included</pre>), falls direkt gegen die Drupal-JSON:API deserialisiert werden soll, statt ein eigenes flaches Modell zu pflegen.

== Verwendete Crates ==

* [https://crates.io/crates/chrono chrono] – Zeitstempel (<pre>created</pre>, <pre>changed</pre>)
* [https://crates.io/crates/uuid uuid] – Entity-UUIDs

Hinweis: [https://serde.rs/ serde] (für die (De-)Serialisierung) ist
bewusst noch nicht Teil dieses Modells und wird in einem späteren
Schritt ergänzt.

== Siehe auch ==

* Drupal-Dokumentation: [https://www.drupal.org/docs/drupal-apis/entity-api Entity API]
* Drupal-Dokumentation: [https://www.drupal.org/docs/core-modules-and-themes/core-modules/jsonapi-module JSON:API-Modul]

[[Kategorie:Rust]]
[[Kategorie:Drupal]]