Struktur & Kulissen

D-Book als lernbares Informatiksystem

Das D-Book ist nicht nur Medium. Es kann selbst Gegenstand informatischer Analyse sein: als Zusammenspiel von Datenmodell, API, Laufzeitverarbeitung und View-Regeln.

Leitdifferenz: Konzeption = Begründungsebene, Kulissen = Umsetzungs- und Modellierungsebene.

Vom Konzept zur Umsetzung: der rote Faden

Die Konzeption beschreibt das D-Book als Lern- und Wissensarchitektur. Diese Kulissen-Seite zeigt die technische Operationalisierung: wie derselbe fachliche Kern in Datenmodell, API, Runtime und Darstellung wirksam wird.

Der Übergang folgt einer didaktischen Bewegungslogik: Inhaltsseite -> Concept -> Relation -> Context/View -> sichtbarer Teilgraph -> Lernhandlung. Damit wird keine beliebige Technikreihenfolge dokumentiert, sondern ein fachlich begründeter Umsetzungsweg.

Concepts stabilisieren Bedeutung, Relations machen Zusammenhänge explizit, Context und ContextDefinition ordnen curricular ein, und die View Policy reduziert sichtbar, ohne den Modellkern zu verändern. Views sind Zugriffsebenen, nicht neue Wahrheiten.

Konzeptionsbegriffe in der Umsetzung

Semantischer Kern

Concept ist die Primäreinheit des Wissenskerns. Relation und RelationType modellieren typisierte, gerichtete Bedeutungsbezüge statt bloßer Clusternähe. Resource verankert Begriffe in Seiten, Glossar, Werkzeugen und Materialien.

Kontextualisierung

Context beschreibt den curricularen Verwendungszusammenhang. ContextDefinition erlaubt kontextspezifische Erklärung desselben Concepts. View und View Policy steuern Fokus, Distanz, Reduktion und Sichtbarkeit, ohne den semantischen Kern zu duplizieren.

Epistemische Zugriffsebenen

Inhaltsseite, Glossar/Inline-Erklärung, Wissensnetz sowie Werkzeug- und Aufgabenebene erfüllen unterschiedliche Erkenntnisfunktionen: erklären, definieren, relational einordnen, anwenden und reflektieren.

Aufgabe und Lernmodus schließen an denselben Concept-Kern an. Übergänge zwischen den Ebenen sind daher nicht nur Navigationstechnik, sondern didaktische Struktur.

D-Book als System

Das D-Book ist Quelle des Lernens (Inhalte, Begriffe, Relationen, Werkzeuge) und zugleich Gegenstand des Lernens (Modellierungs- und Architekturentscheidungen im realen System).

Prozessmodell: Progressive Begriffserschließung im D-Book

Die Bewegung ist nicht beliebige Navigation, sondern epistemische Arbeit am Begriffszusammenhang: Jede Station leistet eine andere Form des Verstehens auf demselben Concept-Kern.

Komponenten, Rollen und D-Book-Anknüpfung

Sequenzdiagramm des Aufbauprozesses

Warum die Trennung wichtig ist

• stabile Concept-Identität über mehrere Seiten- und Nutzungskontexte
• typisierte Relationsbedeutung statt unstrukturierter Linkmenge
• kontextspezifische Erklärung ohne Duplikation des Concept-Kerns
• rekonstruierbarer Graph aus relationalen Tabellen über Fremdschlüssel

Layoutdaten sind Darstellungshilfen. Sie ersetzen keine kuratierte Relation.

Vier Ebenen, vier Aufgaben

Reduktion in API oder View ist kein Verlust der Fachwahrheit, sondern kontrollierte Perspektivierung.

7.1 API-Payload-Mapping: persistente Struktur → API-Daten

Der Ausschnitt zeigt, wie aus gelesenen Tabellenstrukturen ein konsolidiertes Payload-Objekt aufgebaut wird. Sichtbar ist die Trennung von Concept-, Relation-, Resource- und Kontextdaten.

didaktisch gekürzter Ausschnitt

$concepts = array_map(static function (array $row) use ($halfyearByConcept, $primaryContextByConcept, $structuralGroupsByConcept, $additionalContextsByConcept): array {
    $label = trim((string) ($row['label'] ?? ''));
    $conceptId = (string) ($row['id'] ?? '');
    return [
        'id' => $conceptId,
        'slug' => trim((string) ($row['slug'] ?? '')) !== '' ? (string) $row['slug'] : slugify($label !== '' ? $label : $conceptId),
        'label' => $label,
        'description' => trim((string) ($row['description'] ?? '')) !== '' ? (string) ($row['description'] ?? '') : (string) ($row['definition'] ?? ''),
        'importance' => isset($row['importance']) ? (float) $row['importance'] : (isset($row['node_weight']) ? (float) $row['node_weight'] : 0.0),
        'node_weight' => isset($row['node_weight']) ? (float) $row['node_weight'] : (isset($row['importance']) ? (float) $row['importance'] : 0.0),
        'halfyear' => $halfyearByConcept[$conceptId] ?? null,
        'primary_context' => array_key_exists($conceptId, $primaryContextByConcept) ? $primaryContextByConcept[$conceptId] : null,
    ];
}, $conceptsRaw);

$payload = [
    'concepts' => $concepts,
    'concept_relations' => $conceptRelations,
    'resources' => $resources,
    'concept_resource_links' => $conceptResourceLinks,
    'cluster_assignments' => $clusterAssignments,
    'contextDefinitions' => $contextDefinitions,
];

Der Ausschnitt zeigt die strukturierte Zusammenführung. Er zeigt nicht den vollständigen SQL-Teil oder alle Fehlerfälle des Endpoints.

7.2 Konsistenzprüfung: Strukturqualität vor Ausgabe

Der nächste Ausschnitt zeigt, dass die Payload vor der Auslieferung gegen Strukturregeln geprüft wird (IDs, Referenzen, Relationstypen, Duplikate).

didaktisch gekürzter Ausschnitt

foreach ($payload['concept_relations'] as $index => $relation) {
    $sourceId = (string) ($relation['source_concept_id'] ?? '');
    $targetId = (string) ($relation['target_concept_id'] ?? '');
    $type = trim((string) ($relation['relation_type'] ?? ''));

    if ($sourceId === '' || !isset($conceptIds[$sourceId])) {
        $details[] = [
            'code' => 'INVALID_RELATION_SOURCE',
            'path' => "concept_relations[$index].source_concept_id",
        ];
    }
    if ($targetId === '' || !isset($conceptIds[$targetId])) {
        $details[] = [
            'code' => 'INVALID_RELATION_TARGET',
            'path' => "concept_relations[$index].target_concept_id",
        ];
    }
    if ($type === '') {
        $details[] = [
            'code' => 'MISSING_RELATION_TYPE',
            'path' => "concept_relations[$index].relation_type",
        ];
    }
}

Der Ausschnitt zeigt die Qualitätskontrolle im Datenfluss. Er zeigt nicht die gesamte Validierungslogik für alle Tabellenbereiche.

7.3 Laufzeitdaten laden: API-/Snapshot-/Fallback-Pfad

Die Runtime entscheidet, aus welcher Quelle sie den Graphen lädt. Der Ausschnitt zeigt den Einstiegspunkt und den API-Aufrufpfad.

sinngemäß gekürzter Auszug

async function loadKnowledgeGraphFromApi(mode = KNOWLEDGE_GRAPH_SOURCE_MODES.api) {
  const url = withNoStore(appendTimestamp(KNOWLEDGE_GRAPH_API_URL));
  const response = await fetch(url, { cache: 'no-store' });
  if (!response.ok) throw new Error('Wissensnetz-API konnte nicht geladen werden.');
  const payload = await response.json();
  if (!payload || payload.ok !== true || !payload.data) {
    throw new Error('Wissensnetz-API hat kein gültiges Datenset geliefert.');
  }
  return mapApiSnapshotToKnowledgeGraph(payload.data, { source: mode });
}

async function loadKnowledgeGraphData() {
  const sourceMode = resolveKnowledgeGraphSourceMode();
  if (sourceMode === KNOWLEDGE_GRAPH_SOURCE_MODES.legacy) return loadLegacyKnowledgeGraphData();
  try {
    return await loadKnowledgeGraphFromApi(sourceMode);
  } catch (apiError) {
    if (sourceMode === KNOWLEDGE_GRAPH_SOURCE_MODES.api) throw apiError;
    return loadLegacyKnowledgeGraphData();
  }
}

Der Ausschnitt zeigt die Auswahl der Datenquelle. Er zeigt nicht alle Diagnose- und Debugzweige des vollständigen Ladeablaufs.

7.4 API-/Snapshot-Daten auf Runtime-Modell mappen

Hier wird sichtbar, wie API-Objekte zu Laufzeit-Nodes und -Edges normalisiert werden. Das ist die Brücke zwischen Persistenz/API und Darstellung.

sinngemäß gekürzter Auszug

function mapApiSnapshotToKnowledgeGraph(payload, options = {}) {
  const conceptRows = Array.isArray(payload.concepts) ? payload.concepts : [];
  const relationRows = Array.isArray(payload.concept_relations) ? payload.concept_relations : [];

  const nodes = conceptRows.map((entry) => ({
    id: String(entry.id || ''),
    label: String(entry.label || ''),
    node_weight: Number(entry.node_weight || entry.importance || 0),
    importance: Number(entry.importance || entry.node_weight || 0),
  })).filter((node) => node.id && node.label);

  const edges = relationRows.map((entry, index) => ({
    id: String(entry.id || `api-edge-${index}`),
    source: String(entry.source_concept_id || ''),
    target: String(entry.target_concept_id || ''),
    type: normalizeRelationSlug(entry.relation_type_slug || entry.relation_type || 'thematisch_verwandt'),
    directed: normalizeRelationDirection(entry.directed),
    weight: Number(entry.weight || 0),
  })).filter((edge) => edge.source && edge.target);

  return { nodes, edges, clusters: payload.cluster_assignments || [] };
}

Der Ausschnitt zeigt die Normalisierung in ein konsumierbares Runtime-Graphmodell. Er zeigt nicht alle zusätzlichen Metadaten und Deduplizierungsregeln.

7.5 Page-/Scope-Filter: sichtbaren Teilgraphen reduzieren

Die Runtime kann denselben Modellkern je nach Einbettung auf ein Kapitel- oder Kontextteilnetz begrenzen.

sinngemäß gekürzter Auszug

function filterGraphByEmbedSettings(graph, settings = {}) {
  const pageFilter = String(settings.pageFilterKey || '').trim().toUpperCase();
  if (!pageFilter) return graph;
  const allowedNodeIds = new Set();
  graph.nodes.forEach((node) => {
    const contexts = Array.isArray(node.structural_groups) ? node.structural_groups : [];
    const hasMatch = contexts.some((ctx) => String(ctx.slug || '').toUpperCase().includes(pageFilter));
    if (hasMatch) allowedNodeIds.add(node.id);
  });
  const nodes = graph.nodes.filter((node) => allowedNodeIds.has(node.id));
  const edges = graph.edges.filter((edge) => allowedNodeIds.has(edge.source) && allowedNodeIds.has(edge.target));
  return { ...graph, nodes, edges };
}

Der Ausschnitt zeigt die didaktische Reduktion für eingebettete Views. Er zeigt nicht die gesamte Konfigurationsmatrix aller Embed-Varianten.

7.6 Traversierung: Nachbarschaft und Ordnung 1/2/3

Fokusordnungen entstehen nicht aus Layoutabstand, sondern über Graphtraversierung (Adjacency + Distanzberechnung).

sinngemäß gekürzter Auszug

function buildTraversalAdjacency(nodes, edges, options = {}) {
  const adjacency = new Map();
  nodes.forEach((node) => adjacency.set(node.id, new Set()));
  edges.forEach((edge) => {
    if (!adjacency.has(edge.source) || !adjacency.has(edge.target)) return;
    adjacency.get(edge.source).add(edge.target);
    if (!edge.directed || options.bidirectional === true) adjacency.get(edge.target).add(edge.source);
  });
  return adjacency;
}

function computeDistancesFromFocus(adjacency, focusId, maxDistance) {
  const distances = new Map();
  if (!focusId || !adjacency.has(focusId)) return distances;
  const queue = [[focusId, 0]];
  distances.set(focusId, 0);
  while (queue.length) {
    const [nodeId, distance] = queue.shift();
    if (distance >= maxDistance) continue;
    for (const nextId of adjacency.get(nodeId) || []) {
      if (distances.has(nextId)) continue;
      distances.set(nextId, distance + 1);
      queue.push([nextId, distance + 1]);
    }
  }
  return distances;
}

Der Ausschnitt zeigt Ordnung als Navigationsdistanz. Er zeigt nicht die gesamte View-Policy, die danach Sichtbarkeit und Hervorhebung steuert.

7.7 Sichtbarkeit und Opacity: Modellkante ≠ sichtbare Kante

Zwischen vorhandener Relation und sichtbarer Kante liegt eine Policy-Schicht. Sie bestimmt, was in welcher Situation dargestellt oder gedimmt wird.

sinngemäß gekürzter Auszug

function buildGraphViewState() {
  const hasFocus = Boolean(state.focusedId);
  const adjacency = buildTraversalAdjacency(state.graph.nodes, state.graph.edges, { includeClusterEdges: state.showClusterRelations });
  const distances = computeDistancesFromFocus(adjacency, state.focusedId, state.maxDistance);

  const visibleEdges = state.graph.edges.filter((edge) => {
    if (!state.showClusterRelations && isClusterStructureEdge(edge)) return false;
    if (!hasFocus) return overviewPolicyAllows(edge);
    return focusPolicyAllows(edge, distances);
  });

  const edgeOpacity = new Map();
  visibleEdges.forEach((edge) => {
    const sourceDistance = distances.get(edge.source);
    const targetDistance = distances.get(edge.target);
    edgeOpacity.set(edge.id, sourceDistance === 0 || targetDistance === 0 ? 1 : 0.24);
  });
  return { nodes: state.graph.nodes, edges: visibleEdges, distances, edgeOpacity };
}

Der Ausschnitt zeigt die Sichtbarkeitsschicht zwischen Graphmodell und Darstellung. Er zeigt nicht die vollständige Renderausgabe in 3D/Labeling.

7.8 Embedded Views: Einbettung per data-knowledge-net-*

Kapitelnetze werden per Konfiguration eingebettet. Dadurch entstehen keine separaten Wissensnetze, sondern kontextspezifische Views desselben Modellkerns.

didaktisch gekürzter Ausschnitt

function renderKnowledgeNetModule(codeRaw, options = {}) {
  const code = normalizeFilterKey(codeRaw);
  if (!code) return '';
  const safeCode = escapeHtml(code);
  const safeCodesCsv = escapeHtml(normalizeFilterKeyList(codeRaw).join(','));
  return `
    <div class="chapter-knowledge-net__viewer"
      data-knowledge-net
      data-knowledge-net-variant="embedded"
      data-knowledge-net-page-filter="${safeCode}"
      data-knowledge-net-page-filters="${safeCodesCsv}"
      data-knowledge-net-layout-mode="sphere"
      data-knowledge-net-cluster-mode="thema"
      data-knowledge-net-mode="3d">
    </div>
  `;
}

Der Ausschnitt zeigt die Einbettungskonfiguration. Er zeigt nicht die gesamte Initialisierung der Runtime nach dem Mounting.

Warum Kapitelnetze anders aussehen als das Gesamtnetz

Kapitelnetze reduzieren den sichtbaren Ausschnitt auf die didaktisch relevante Teilstruktur einer Seite oder Einheit. Embedded Views reduzieren stärker als die große Gesamtansicht, damit Lesbarkeit und Lernfokus erhalten bleiben.

Die Konzeption-Seite beschreibt Views als epistemische Zugriffsebenen. Technisch umgesetzt wird das hier über Filter- und Policy-Logik.

Rollen von PageFilter, FocusConcept und MaxDepth

• PageFilter: begrenzt den thematischen/kapitelbezogenen Scope
• FocusConcept: setzt den lokalen Analysemittelpunkt
• MaxDepth: begrenzt die Traversierungsdistanz

Diese Parameter haben unterschiedliche Aufgaben und wirken kombiniert. Dadurch wird nicht die Fachwahrheit geändert, sondern die Darstellungssicht.

View-Typen und didaktische Funktion

View ist immer didaktische Entscheidung: Sichtbarkeit ist nicht nur technischer Filter, sondern gesteuerte Erschließung.

Didaktischer Anker und relationale Zugriffsebene

Die Inhaltsseite bleibt didaktischer Anker (Erklärung, Progression, Aufgabenkontext). Das eingebettete Wissensnetz ergänzt als relationale Zugriffsebene.

Reduzierter Sichtausschnitt in Embeds bedeutet nicht reduzierten Modellkern.

Didaktischer Übergang

• lesen und verstehen
• vergleichen und einordnen
• modellieren und simulieren
• ausführen und prüfen
• reflektieren und sichern

Damit folgt die technische Umsetzung der Konzeption: vom Dokumentraum zur handlungsorientierten Lernarchitektur.

D-Book als lernbares Informatiksystem im Unterricht

Die Kulissen-Seite kann als Analysefläche für mehrere informatische Ebenen genutzt werden: ER-Modellierung (Concept, Relation, Resource), Relationenmodell und Join-Pfade, API-Payloads und Mapping, Graphtraversierung (Adjacency, Distanz, Ego-Netz), View-Logik (Filter, Fokus, Reduktion), Embedded-Komponenten sowie Darstellungs- und Layoutschichten.

Der Abschnitt Technische Komponenten als Lerngegenstände im D-Book macht diese Ebenen als integrierte Systemperspektive mit Kapitelanschlüssen und Leitfragen sichtbar.

Damit wird die D-Book-Konzeption konkret operationalisiert: Das D-Book bleibt Quelle des Lernens (Inhalte, Begriffe, Werkzeuge) und wird zugleich Gegenstand des Lernens (Modellierungs- und Architekturentscheidungen an einem realen System).

Kuratiert, evolutiv, überprüfbar

Das Wissensnetz ist ein kuratiertes, evolutives Modell. Es ist keine vollständige Abbildung der Informatik.

Relationstypen, Concept-Grenzen, Context-Zuordnungen und View-Policies bleiben überprüfbar und revidierbar.

Automatisierung und Kuration

Automatisierung kann Kuration unterstützen, aber nicht ersetzen. Runtime-Heuristiken dürfen fachliche Setzungen nicht stillschweigend überschreiben.

Darstellung erzeugt keine neue fachliche Wahrheit.