Identität
Stabile ID, Datensatztyp, Sprache und bevorzugte Bezeichnung.
Für Technikteams
Code, der Skills weltweit anschlussfähig macht.
Offene Schemata, nachvollziehbare Quellen und versionierte APIs geben Entwicklungsteams eine gemeinsame Basis. Lokal integrierbar, global interoperabel und dauerhaft frei von Lock-in.
Gemeinnützig · Weltweites Gemeingut
- Offene Schnittstellen
- Keine Herstellerbindung
- Für globale Vielfalt
Integrationsprinzip
Die Bedeutung reist mit den Daten.
Eine OSC-Integration überträgt nicht nur Labels. Sie hält fest, welcher Skill gemeint ist, woher die Aussage kommt und zu welcher Version sie gehört.
Dadurch bleiben Daten auch dann verständlich, wenn sie ein HR-System, Lernportal oder Analysewerkzeug verlassen.
Kernfelder
Klein anfangen, später erweitern.
Für einen ersten Pilot reicht ein überschaubarer, sauber gepflegter Datensatz. Diese vier Bereiche sollten von Anfang an stimmen.
Bedeutung
Kurze Definition, Synonyme und klar typisierte Beziehungen.
Herkunft
Herausgeber, Quelle, Lizenz und – falls vorhanden – Nachweisbezug.
Lebenszyklus
Version, Änderungsdatum, Status und verständliche Änderungsnotiz.
Datenvertrag
Fachliche Daten und berechnete Signale bleiben getrennt.
Das erleichtert Tests, Audits und spätere Modellwechsel.
- Ontologie-Felder beschreiben Begriffe, Klassen und Regeln.
- Graphdaten verbinden konkrete Skills, Rollen, Quellen und Nachweise.
- Embeddings und Scores tragen Modellversion, Zweck und Erstellungszeitpunkt.
- Nachweise enthalten Aussteller, Methode, Kontext, Gültigkeit und Prüfstatus.
- Ein Matching-Score wird nie als bestätigte Kompetenz ausgegeben.
API-Arbeitsstand
Beispielpfade für Pilotintegrationen.
Die Pfade zeigen die vorgesehene Struktur. Sie sind noch keine Zusage für eine produktive Adresse, Authentifizierung oder Verfügbarkeit.
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/Was wir für einen Pilot brauchen
Ein konkretes Quell- und Zielsystem, einige repräsentative Datensätze und eine klar formulierte Frage. Daraus lässt sich schnell ableiten, welche Felder und Endpunkte wirklich nötig sind.