Grundbegriffe Informatik

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

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:

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 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).

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.

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.

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 (`

  `, `

  `, …) 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:Vorlage`): 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:

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:

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:

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)