Lesbare Referenzseite
Die Seite benennt Kompetenzkennung, Bezeichnung, Beschreibung, Herausgeber, Version, Quelle und Status. Sie bleibt für fachliche Prüfung, Suche und Barrierefreiheit nutzbar.
Entwickler
Kompetenzdaten sauber modellieren und pilotierbar austauschen.
Diese Seite beschreibt den vorgesehenen Arbeitsstand für OSC-kompatible Datenmodelle, Exportprofile und Schnittstellenverträge in Piloten. Beispielpfade sind keine freigegebenen produktiven API-Adressen.
Integrationspfad
Vom lesbaren Katalog zum prüfbaren Datenaustausch.
Eine OSC-Implementierung beginnt mit fachlich geprüften Inhalten. Dieselben Pflichtfelder sollen in Exporten und Schnittstellen wiederverwendet werden: eindeutige Kennungen, Bezeichnungen, Versionen, Quellen, Status und Nachweisbezüge.
Stabile Kennungen
Jede Kompetenz erhält eine dauerhafte Kennung. Bezeichnungen, Synonyme und Relationen können sich ändern; die Kennung bleibt der technische Bezug.
Exportprofile
Geplante JSON- und CSV-Profile beschreiben Feldnamen, Datentypen, Pflichtfelder, zulässige Werte und Fehlerfälle für Pilotimporte und Qualitätssicherung.
Freigabe und Versionierung
Änderungen brauchen Status, Freigabe, Änderungsnotiz und Versionsbezug. Integrationen können Entwurf, Pilotstand und geprüfte Empfehlung gezielt unterscheiden.
Grundsätze
Lesbar, versioniert, fachlich prüfbar.
Die technische Integration darf fachliche Prüfung nicht ersetzen. Ontologie, Wissensgraph, Embeddings und Evidenzobjekte bleiben getrennte Datenarten; Modell-Ausgaben und Ähnlichkeitswerte liefern Hinweise, aber keine Kompetenznachweise.
Kernfelder vor Modellwerten
Identifier, Bezeichnung, Beschreibung, Quelle, Version und Evidenzstatus bleiben Pflichtinformationen.
Quellen und Versionen
Jede Änderung an Skill-Daten, Relationen oder Nachweisen soll reproduzierbar und datiert sein.
HTML, Export und API konsistent
Lesbare Seiten, geplante JSON/CSV-Exporte und API-Antworten verwenden dieselben Kernfelder.
Entwickler-USP
Ein Vertrag für Graphdaten, Vektoren und Evidenzstatus.
OSC trennt Felder, die in KI-Projekten oft vermischt werden. Der API-Vertrag kann Graphrelationen, Embedding-Metadaten, LLM-generierte Entwurfssignale und Evidenzverweise als unterschiedliche Datenarten ausweisen. Das macht Integrationen testbarer und Reviews belastbarer.
Graph-Payload
Skill-IDs, Relationstypen, Quellen, Sprache, Version und Status werden sichtbar, damit Systeme die Bedeutung eines Knotens prüfen können.
Vektor-Metadaten
Modellversion, Eingabeumfang, Aktualisierungsdatum und Verwendungszweck gehören zu Embeddings. Ein Vektor ohne Metadaten ist keine prüfbare Kompetenzaussage.
Evidenzverweis
Assessments, Credentials, Projekte und Quelldokumente bleiben in expliziten Evidenzfeldern, getrennt von Matching-Werten oder Verhaltensindikatoren.
Datenmodell
Pflichtfelder für Kompetenzdatensätze im Pilot.
Die Felder bilden ein Referenzmuster für Piloten. Sie sind kein final veröffentlichtes Schema und müssen je nach Integrationskontext, Datenquelle und Freigabestatus geprüft werden.
- stabile Kompetenzkennung und Datensatztyp
- Hauptbezeichnung, Sprache und optionale Synonyme
- kurze, fachlich prüfbare Beschreibung
- Ontologiebezug: Klasse, Relation, Regel oder Mapping
- Herausgeber, Quelle, Lizenz und Nutzungsbedingungen
- Version, Änderungsdatum, Status und Freigabestand
- Beziehungen zu Clustern, Rollen, Lernangeboten oder Evidenzobjekten
- Prüfstatus und Zweckbindung, wenn ein Nachweis referenziert wird
Trennung
Ontologie, Wissensgraph, Embeddings und Evidenz getrennt halten.
Eine Schnittstelle sollte klar ausweisen, welche Daten fachliche Semantik beschreiben, welche Relationen im Graphen stehen, welche Werte technisch abgeleitet wurden und welche Nachweise geprüft sind.
- Ontologie: Begriffe, Klassen, Relationen, Regeln und Semantik.
- Wissensgraph: Skill-Instanzen, Rollen, Quellen, Relationen und Evidenzverweise.
- Embeddings und Modellwerte: Ähnlichkeiten, Cluster, Empfehlungen und Normalisierungsvorschläge als Hilfssignale.
- Evidenzobjekte: Assessments, Credentials, Projektartefakte und dokumentierte Quellen mit Prüfstatus.
- Bewertungslogik, Quelle, Zeitpunkt, Gültigkeit und Zweckbindung gehören in eigene Felder.
Service-Compliance-Test
Praktischer Abgleich für Felder, Kennungen und Verträge.
Der Service-Compliance-Test ist als pilotierbare Prüfung gedacht. Er vergleicht Beispieldaten, Exportprofile und Schnittstellenverträge mit den vereinbarten Pflichtangaben, ohne produktive API-Adressen oder Freigaben vorwegzunehmen.
Compliance bedeutet hier eine dokumentierte Prüfung gegen den OSC-Arbeitsstand. Sie umfasst Datenfelder, Kompetenznachweise, Schnittstellen und Governance. Sie ist keine Zertifizierung und keine produktive Freigabe.
Pflichtfelder
Geprüft wird, ob Kennung, Datensatztyp, Bezeichnung, Sprache, Beschreibung, Status und Version in den Beispieldaten eindeutig und vollständig vorhanden sind.
Verträge und Exporte
JSON-, CSV- oder API-Verträge werden gegen Feldnamen, Datentypen, Pflichtlogik, zulässige Werte und dokumentierte Fehlerfälle abgeglichen.
Nachweise und Herkunft
Evidenz-, Quellen-, Lizenz- und Versionsmetadaten bleiben nachvollziehbar getrennt. Ein Prüfstatus beschreibt den Arbeitsstand, nicht automatisch eine Anerkennung.
Exporte und API
Beispielpfade für geplante Pilot-APIs und Exporte.
Die folgenden Pfade sind Arbeitsbeispiele für Pilotintegrationen. Produktive Adressen, Authentifizierung, Ratenbegrenzung, Fehlercodes und Versionierung werden erst in der jeweiligen Spezifikation verbindlich.
GET /osc/api/v1/skills/?language=de-DE
GET /osc/api/v1/skills/{skill_id}/
GET /osc/api/v1/evidence/{evidence_id}/
GET /osc/api/v1/graphs/relations/?skill_id={skill_id}
GET /osc/api/v1/embeddings/similar-skills/?skill_id={skill_id}
POST /osc/api/v1/pilots/evidence-check/API-Hinweis zum Arbeitsstand
HTML-Seiten liefern kanonische Inhalte. JSON- und CSV-Exporte sollen dieselben Pflichtfelder enthalten: Kennung, Bezeichnung, Beschreibung, Version, Quelle, Sprache, Status, Lizenz und dokumentierte Fehlerfälle.
Endpunkte zur Evidenzprüfung sind als Pilot-Arbeitsstand zu verstehen: Sie referenzieren Nachweise und geben einen Prüfstatus zurück, ersetzen aber keine fachliche Anerkennung oder Governance-Freigabe.