OpenCodeList - Eine Einführung

OpenCodeList ist ein JSON-basiertes Datenformat zur Repräsentation von Schlüsselverzeichnissen. Dieser Blog-Artikel ist eine Einführung in das Format und zeigt anhand eines realen Beispiels, wie OpenCodeList in der Praxis eingesetzt werden kann.

Einführung

OpenCodeList definiert ein generisches Standard-Datenformat zur Repräsentation von Code-Listen bzw. Schlüsselverzeichnissen. Basierend auf dem JSON-Standard kann dieses Format mit nahezu jeder Programmiersprache leicht erzeugt und gelesen werden. Mit Hilfe des OpenCodeList Document Schema können Dokumente im OpenCodeList-Format auf ihre syntaktische Korrektheit hin validiert werden.

OpenCodeList kann zum Austausch von Code-Listen zwischen Diensten oder Anwendungen genutzt werden, als Repräsentationsformat für ofizielle Code-Listen oder als Antwortformat für API-Anfragen (z.B. für RESTful Web-Services).

Was sind Code-Listen?

Code-Listen (auch Schlüsselverzeichnisse genannt) sind strukturierte Sammlungen von Codes bzw. Schlüsseln, die zur Identifikation und Klassifikation von Daten verwendet werden. Diese Verzeichnisse sind essenziell in zahlreichen Bereichen wie Datenbanken, Verwaltungssystemen, wissenschaftlichen Forschungen und industriellen Anwendungen. Sie dienen dazu, Daten konsistent und effizient zu organisieren, zu speichern und abzurufen.

Code-Listen spielen eine zentrale Rolle bei der Standardisierung und Harmonisierung von Daten. Durch die Verwendung standardisierter Codes können unterschiedliche Systeme und Organisationen Daten einheitlich interpretieren und austauschen.

Beispiele für Code-Listen sind:

• Internationale Codes für Staaten, Sprachen und Währungen der International Organization for Standardization (ISO).

• Nationale Gebietsschlüssel (z.B. Gemeindeschlüssel der Bundesrepublik Deutschland)

• Nationale und subnationale Schlüssel im öffentlichen Bereich (z.B. Statistikschlüssel der Statistikbehörden)

Im Prinzip lässt sich jede Datenauswahl auf eine Code-Liste abbilden, selbst ein banaler boolescher Wert kann durch die Codes Nein und Ja repräsentiert werden.

Wie sind Code-Listen aufgebaut?

Es gibt kein Naturgesetz, das die Struktur von Code-Listen vorschreibt. In den meisten Fällen kann man sich aber sehr schnell auf eine tabellarische Darstellung einigen.

Die einfachste Form einer solchen tabellarischen Code-Liste besteht aus zwei Spalten: Schlüssel und Name.

Hier ein Beispiel für ein Länderverzeichnis:

Code-Listen können potentiell beliebig viele Spalten enthalten. Hier ein Beispiel für ein Länderverzeichnis mit drei Spalten:

Code-Listen können aufeinander verweisen. Hier ein Beispiel für ein Länderverzeichnis mit Verweis auf ein separates Kontinente-Verzeichnis:

Das passende Kontinente-Verzeichnis könnte dann so aussehen:

Auch können Code-Listen mehr als einen Schlüssel besitzen. Hier ein Beispiel für ein Länderverzeichnis mit verschiedenen ISO3166-Codes:

Gehen wir noch einen Schritt weiter mit diesem mehrsprachigen Länderverzeichnis. Hier ist es die Kombination aus Schlüssel und Sprache (ebenfalls durch einen Sprachschlüssel repräsentiert), welche Eindeutigkeit ergibt:

Neben Text und Zahlen können Code-Listen auch komplexe Spaltentypen definieren, die beispielsweise mit XML, JSON oder HTML gefüllt sind.

Was macht Code-Listen so kompliziert?

Format und Semantik

Wenn man an Code-Listen denkt, dann erscheint vor dem eigenen geistigen Auge schnell eine Excel-Tabelle mit ein paar Spalten und Zeilen. Aber was bedeuten die Spalten eigentlich? Steht der Code immer in der ersten Spalte? Ist der Inhalt einer Spalte immer als reiner Text zu interpretieren? Und wieso eigentlich Excel? Das ist immerhin ein ziemlich komplexes Datenformat, was nicht gerade gut geeignet ist für eine automatisierte Verarbeitung von Code-Listen. CSV wäre definitiv einfacher zu handhaben, beantwortet die ersten drei Fragen aber leider auch nicht.

Versionierung

Code-Listen können sich im Laufe der Zeit ändern. In diesen Fällen gibt es sowohl eine aktuelle Version einer Code-Liste als auch ältere Versionen einer Code-Liste. Im Zuge dieser Änderungen können sich die Anzahl der Codes wie auch die Bedeutung einzelner Codes ändern.

Abhängigkeiten

Code-Listen können Abhängigkeiten untereinander haben, d.h. Werte aus einer Code-Liste können auf Codes in einer anderen Code-Liste verweisen. Diese Verweise müssen auch eine mögliche Versionierung der jeweils anderen Code-Liste berücksichtigen.

Mehrsprachigkeit

Wenn Code-Listen über Sprachgrenzen hinweg verwendet werden, müssen sie oft für mehrere Sprachen angepasst werden. Ein und derselbe Code hat dann beispielsweise in verschiedenen Sprachen unterschiedliche Bezeichnungen.

Benutzerdefinierte Code-Listen

Wenn wir von Code-Listen sprechen, geht es nicht immer nur um standardisierte Codes, die von einem Gremium, einer Organisation oder Institution festgelegt werden, sondern oft auch um Codes, die eine kleine Benutzergruppe für einen bestimmten Bereich oder sogar eine bestimmte Anwendung verwenden möchte. Diese müssen konfliktfrei mit etablierten Standard-Codes koexistieren können.

Gibt es nicht schon Standards für Code-Listen?

Ja, gibt es: Die Organization for the Advancement of Structured Information Standards (OASIS) hat mit Code List Representation (genericode) einen XML-basierten Standard für Code-Listen definiert.

The OASIS Code List Representation format, “genericode”, is a single model and XML format (with a W3C XML Schema) that can encode a broad range of code list information. The XML format is designed to support interchange or distribution of machine-readable code list information between systems. Note that genericode is not designed as a run-time format for accessing code list information, and is not optimized for such usage. Rather, it is designed as an interchange format that can be transformed into formats suitable for run-time usage, or loaded into systems that perform run-time processing using code list information.

Klingt gut, hat aber einen Haken. Es existiert keine standardisierte JSON-Repräsentation von “genericode”.

Recognizing the custom use of JSON in a tight binding between user-defined processes, the committee sees no purpose served by standardizing a JSON syntax for the genericode vocabulary.

Das bedeutet, es gibt keine offizielle Unterstützung für JSON als Datenformat und somit auch kein offizielles JSON-Schema.

Wer also Code-Listen im XML-Format repräsentieren möchte, dem sei der OASIS-Standard ans Herz gelegt. Wer aber mit JSON arbeiten möchte, der hat mit OpenCodeList eine passende Alternative parat. Natürlich ist OpenCodeList erheblich vom OASIS Code List Representation Format beeinflusst und versucht semantisch weitestgehend kompatibel zu sein.

Warum JSON? XML ist doch gut!

Selbstverständlich ist XML ein tolles, standardisiertes Format, das kaum Wünsche offen lässt. Der Grund für eine JSON-Darstellung von Code-Listen liegt jedoch in dem ausdrücklichen Wunsch, JSON zu verwenden:

• In der Welt cloud-basierter Dienste hat sich JSON als Payload (zu Deutsch: Nutzdaten) für RESTful-APIs weitestgehend durchgesetzt. Natürlich kann eine solche API auch XML als Payload zurückliefern, generiert damit aber eine zusätzliche Abhängigkeit, sowohl auf Serverseite (Generieren von XML) als auch auf Clientseite (Konsumieren von XML). Statt mit einem Format (JSON) muss beim Einsatz von Code-Listen mit einem zusätzlichen Format (XML) hantiert werden. Das erhöht den Aufwand.

• JSON ist kompakter, da der Syntax weniger wortreich daherkommt. Bei umfangreichen Code-Listen wirkt sich das positiv auf die Performanz aus. Im Allgemeinen ist JSON schneller zu parsen als XML, da es weniger syntaktischen Ballast mit sich bringt und die JSON-Parser in den meisten modernen Programmiersprachen inzwischen stark optimiert sind.

• Möchte man Code-Listen in ein übergeordnetes Format einbetten, und dieses übergeordnete Format ist eben JSON-basiert, ist der Bedarf nach einer dedizierten JSON-Repräsentation noch höher.

Beispiel

Soweit zur Theorie. Kommen wir zur Praxis. Wie sieht so eine Code-Liste im OpenCodeList-Format konkret aus?

Dazu nehmen wir uns ein reales Schlüsselverzeichnis als Vorlage, und zwar das Schlüsselverzeichnis K101 - Geschlecht aus der Statistik für Berufsbildende Schulen in Sachsen:

Ich habe hier aus Platzgründen ein wenig geschummelt. Die Angabe (Alle) in der Spalte Schularten ist ein Platzhalter für die Auflistung Berufsschule, Berufsfachschule, Fachschule, Fachoberschule und Berufliches Gymnasium. Die Schlüssel selbst stammen aus einem proprietären XML-Schlüsselkatalog für die berufsbildende Statistik in Sachsen.

Bevor wir anfangen, an unserem OpenCodeList-Dokument zu basteln, schauen wir noch einmal etwas genauer auf das vorliegende Schlüsselverzeichnis. Interessant sind die letzten beiden Spalten. Sie lassen den Schluss zu, dass dieses Schlüsselverzeichnis schon etwas älter ist (erste Version 2005) und insgesamt zweimal ergänzt wurde (2018 und 2020).

Aus meiner Sicht bieten sich daher zwei Strategien an, um dieses Schlüsselverzeichnis in OpenCodeList zu modellieren.

Strategie 1

Ein Schlüsselverzeichnis mit allen Angaben aus obiger Tabelle. Dieses könnte dann wie folgt aussehen:

{
  "$opencodelist": "0.2.0",
  "codeList": {
    "identification": {
      "shortName": "K101",
      "longName": "Geschlecht",
      "version": "v1",
      "publishedAt": "2025-01-28T04:05:32",
      "canonicalUri": "urn:sachsen:codelist:bbs:geschlecht",
      "canonicalVersionUri": "urn:sachsen:codelist:bbs:geschlecht:v1",
      "locationUrls": [
        "https://sachsen.beispiel.de/codelist/bbs/geschlecht-v1.json"
      ],
      "language": "de"
    },
    "columnSet": {
      "columns": [
        {
          "type": "string",
          "id": "id",
          "name": "Schlüssel"
        },
        {
          "type": "string",
          "id": "kurz",
          "name": "Kurzname"
        },
        {
          "type": "string",
          "id": "lang",
          "name": "Langname"
        },
        {
          "type": "enum-set",
          "id": "schularten",
          "name": "Schularten",
          "members": [
            {
              "value": "Berufsschule"
            },
            {
              "value": "Berufsfachschule"
            },
            {
              "value": "Fachschule"
            },
            {
              "value": "Fachoberschule"
            },
            {
              "value": "Berufliches Gymnasium"
            }
          ]
        },
        {
          "type": "integer",
          "id": "sort",
          "name": "Sortierung"
        },
        {
          "type": "date",
          "id": "gueltig_von",
          "name": "Gültig von"
        },
        {
          "type": "date",
          "id": "gueltig_bis",
          "name": "Gültig bis"
        }
      ],
      "keys": [
        {
          "id": "key",
          "name": "Key",
          "columnIds": [
            "id"
          ]
        }
      ],
      "defaultKey": {
        "keyId": "key"
      }
    },
    "dataSet": {
      "rows": [
        {
          "id": "1",
          "kurz": "männl.",
          "lang": "männlich",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 1,
          "gueltig_von": "2005-01-01"
        },
        {
          "id": "2",
          "kurz": "weibl.",
          "lang": "weiblich",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 2,
          "gueltig_von": "2005-01-01"
        },
        {
          "id": "3",
          "kurz": "divers",
          "lang": "divers",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 3,
          "gueltig_von": "2018-12-07"
        },
        {
          "id": "4",
          "shortName": "ohne Angabe",
          "longName": "ohne Angabe",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 4,
          "gueltig_von": "2020-01-22"
        }
      ]
    }
  }
}

Strategie 2

Ein alternative Strategie wäre, die Historie des Schlüsselverzeichnis nachzuvollziehen und insgesamt drei Code-Listen zu erstellen:

• Version 1 mit den Schlüsseln für männlich und weiblich
• Version 2 mit den Schlüsseln aus Version 1 und dem Schlüssel für divers
• Version 3 mit den Schlüsseln aus Version 2 und dem Schlüssel für ohne Angabe.

In diesem Fall begrenzen wir die Gültigkeit des jeweils gesamten Schlüsselverzeichnisses für die erste Version auf 2005 bis 2018, die zweite Version auf 2018 bis 2020 und die aktuelle Version auf 2020 bis unbegrenzt. Die beiden Spalten für “Gültig von” und “Gültig bis” lassen wir weg.

Die drei Code-Listen würden dann wie folgt aussehen:

Version 1:

{
  "$opencodelist": "0.2.0",
  "codeList": {
    "identification": {
      "shortName": "K101",
      "longName": "Geschlecht",
      "version": "v1",
      "publishedAt": "2005-01-01T12:00:00",
      "canonicalUri": "urn:sachsen:codelist:bbs:geschlecht",
      "canonicalVersionUri": "urn:sachsen:codelist:bbs:geschlecht:v1",
      "locationUrls": [
        "https://sachsen.beispiel.de/codelist/bbs/geschlecht-v1.json"
      ],
      "validFrom": "2005-01-01",
      "validTo": "2018-12-06",
      "language": "de"
    },
    "columnSet": {
      "columns": [
        {
          "type": "string",
          "id": "id",
          "name": "Schlüssel"
        },
        {
          "type": "string",
          "id": "kurz",
          "name": "Kurzname"
        },
        {
          "type": "string",
          "id": "lang",
          "name": "Langname"
        },
        {
          "type": "enum-set",
          "id": "schularten",
          "name": "Schularten",
          "members": [
            {
              "value": "Berufsschule"
            },
            {
              "value": "Berufsfachschule"
            },
            {
              "value": "Fachschule"
            },
            {
              "value": "Fachoberschule"
            },
            {
              "value": "Berufliches Gymnasium"
            }
          ]
        },
        {
          "type": "integer",
          "id": "sort",
          "name": "Sortierung"
        }
      ],
      "keys": [
        {
          "id": "key",
          "name": "Key",
          "columnIds": [
            "id"
          ]
        }
      ],
      "defaultKey": {
        "keyId": "key"
      }
    },
    "dataSet": {
      "rows": [
        {
          "id": "1",
          "kurz": "männl.",
          "lang": "männlich",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 1
        },
        {
          "id": "2",
          "kurz": "weibl.",
          "lang": "weiblich",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 2
        }
      ]
    }
  }
}

Version 2:

{
  "$opencodelist": "0.2.0",
  "codeList": {
    "identification": {
      "shortName": "K101",
      "longName": "Geschlecht",
      "version": "v2",
      "publishedAt": "2018-12-01T12:00:00",
      "canonicalUri": "urn:sachsen:codelist:bbs:geschlecht",
      "canonicalVersionUri": "urn:sachsen:codelist:bbs:geschlecht:v2",
      "locationUrls": [
        "https://sachsen.beispiel.de/codelist/bbs/geschlecht-v2.json"
      ],
      "validFrom": "2018-12-07",
      "validTo": "2020-01-21",
      "language": "de"
    },
    "columnSet": {
      "columns": [
        {
          "type": "string",
          "id": "id",
          "name": "Schlüssel"
        },
        {
          "type": "string",
          "id": "kurz",
          "name": "Kurzname"
        },
        {
          "type": "string",
          "id": "lang",
          "name": "Langname"
        },
        {
          "type": "enum-set",
          "id": "schularten",
          "name": "Schularten",
          "members": [
            {
              "value": "Berufsschule"
            },
            {
              "value": "Berufsfachschule"
            },
            {
              "value": "Fachschule"
            },
            {
              "value": "Fachoberschule"
            },
            {
              "value": "Berufliches Gymnasium"
            }
          ]
        },
        {
          "type": "integer",
          "id": "sort",
          "name": "Sortierung"
        }
      ],
      "keys": [
        {
          "id": "key",
          "name": "Key",
          "columnIds": [
            "id"
          ]
        }
      ],
      "defaultKey": {
        "keyId": "key"
      }
    },
    "dataSet": {
      "rows": [
        {
          "id": "1",
          "kurz": "männl.",
          "lang": "männlich",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 1
        },
        {
          "id": "2",
          "kurz": "weibl.",
          "lang": "weiblich",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 2
        },
        {
          "id": "3",
          "kurz": "divers",
          "lang": "divers",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 3
        }
      ]
    }
  }
}

Version 3:

{
  "$opencodelist": "0.2.0",
  "codeList": {
    "identification": {
      "shortName": "K101",
      "longName": "Geschlecht",
      "version": "v3",
      "publishedAt": "2020-01-01T12:00:00",
      "canonicalUri": "urn:sachsen:codelist:bbs:geschlecht",
      "canonicalVersionUri": "urn:sachsen:codelist:bbs:geschlecht:v3",
      "locationUrls": [
        "https://sachsen.beispiel.de/codelist/bbs/geschlecht-v3.json"
      ],
      "validFrom": "2020-01-22",
      "language": "de"
    },
    "columnSet": {
      "columns": [
        {
          "type": "string",
          "id": "id",
          "name": "Schlüssel"
        },
        {
          "type": "string",
          "id": "kurz",
          "name": "Kurzname"
        },
        {
          "type": "string",
          "id": "lang",
          "name": "Langname"
        },
        {
          "type": "enum-set",
          "id": "schularten",
          "name": "Schularten",
          "members": [
            {
              "value": "Berufsschule"
            },
            {
              "value": "Berufsfachschule"
            },
            {
              "value": "Fachschule"
            },
            {
              "value": "Fachoberschule"
            },
            {
              "value": "Berufliches Gymnasium"
            }
          ]
        },
        {
          "type": "integer",
          "id": "sort",
          "name": "Sortierung"
        }
      ],
      "keys": [
        {
          "id": "key",
          "name": "Key",
          "columnIds": [
            "id"
          ]
        }
      ],
      "defaultKey": {
        "keyId": "key"
      }
    },
    "dataSet": {
      "rows": [
        {
          "id": "1",
          "kurz": "männl.",
          "lang": "männlich",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 1
        },
        {
          "id": "2",
          "kurz": "weibl.",
          "lang": "weiblich",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 2
        },
        {
          "id": "3",
          "kurz": "divers",
          "lang": "divers",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 3
        },
        {
          "id": "4",
          "shortName": "ohne Angabe",
          "longName": "ohne Angabe",
          "schularten": [
            "Berufsschule",
            "Berufsfachschule",
            "Fachschule",
            "Fachoberschule",
            "Berufliches Gymnasium"
          ],
          "sort": 4
        }
      ]
    }
  }
}

Die Sache mit den URIs

Sobald ein Schlüsselverzeichnis aktiv genutzt wird, stellt sich die Frage, wie genau denn so ein Schlüssel in einer Anwendung referenziert werden soll.

Auch da gibt es unterschiedliche Strategien.

Ist der Kontext eindeutig, ist also unmittelbar klar, um welche Schlüssel es sich handelt, kann einfach nur der lokale Schlüsselwert referenziert werden. In unserem Beispiel wären dies die Werte:

• Schlüssel = 1
• Schlüssel = 2
• Schlüssel = 3
• Schlüssel = 4

Oft ist die Sache aber nicht selbsterklärend. Zum Beispiel dann, wenn es sich bei den möglichen Schlüsseln um Zahlen ohne weitere semantische Bedeutung handelt. In diesen Fällen bietet es sich an, die Schlüssel zusammen mit der kanonischen URI des Schlüsselverzeichnisses zu speichern, in unserem Beispiel also:

• Schlüssel = urn:sachsen:codelist:bbs:geschlecht:1
• Schlüssel = urn:sachsen:codelist:bbs:geschlecht:2
• Schlüssel = urn:sachsen:codelist:bbs:geschlecht:3
• Schlüssel = urn:sachsen:codelist:bbs:geschlecht:4

Eine Variante wäre auch, kanonische URI und Schlüsselwert getrennt zu speichern:

• URI = urn:sachsen:codelist:bbs:geschlecht und Schlüssel = 1
• URI = urn:sachsen:codelist:bbs:geschlecht und Schlüssel = 2
• URI = urn:sachsen:codelist:bbs:geschlecht und Schlüssel = 3
• URI = urn:sachsen:codelist:bbs:geschlecht und Schlüssel = 4

Der entscheidende Punkt bei den beiden letzten Varianten ist das Hinzuziehen der kanonischen URI. Damit bekommt jeder Schlüssel eine globale Eindeutigkeit und besitzt zugleich einen Hinweis auf die Quelle.

Und wer erklärt mir jetzt, was eine kanonische URI ist?

Dazu müssen wir zunächst die Abkürzung URI aufdröseln: Eine URI (Uniform Resource Identifier) ist eine Zeichenfolge, die eine Ressource eindeutig identifiziert. Sie kann aus einer URL (Uniform Resource Locator), die den Ort (z. B. eine Webadresse) angibt, oder einer URN (Uniform Resource Name), die eine Ressource unabhängig vom Ort identifiziert, bestehen.

Beispiele:

• URL = https://www.beispiel.de/index.html (Adresse einer Webseite)
• URN = urn:isbn:9783522183192 (ISBN einer Buchressource)

Der Begriff kanonisch stammt vom lateinischen Wort “canonicus”, das wiederum aus dem griechischen “kanon” (κανών) abgeleitet ist. Und das bedeutet so viel wie “Regel”, “Norm” oder “Maßstab”.

Bei URLs zum Beispiel bezeichnet “kanonische URL” die einheitliche, standardisierte und bevorzugte Adresse einer Webseite, die als maßgeblich oder “richtige” Version betrachtet wird (sehr wichtig für SEO). SEO? Was ist denn… (ganz anderes Thema, hier nicht wichtig).

Eine kanonische URI ist also eine standardisierte und eindeutige Identifizierung einer Ressource, in unserem Fall eines Schlüsselverzeichnisses. In Kombination mit einem Schlüsselwert bekommen wir einen über Anwendungsgrenzen hinweg eindeutigen Schlüssel.

Eine kanonische URI legt übrigens nicht fest, ob es eine URL oder eine URN sein soll. Eine URN scheint mir aber besser geeignet zu sein, da wir ja nicht adressieren sondern vielmehr (ortsunabhängig) identifizieren wollen. Zum Adressieren gibt es in OpenCodeList die Eigenschaft locationUrls.

Mit diesem Wissen tun sich plötzlich ungeahnte Möglichkeiten auf:

• Schlüssel aus unterschiedlichen, aber semantisch kompatiblen Schlüsselverzeichnissen können konfliktfrei parallel genutzt werden.

• Ältere und neuere Versionen eines Schlüsselverzeichnisses mit abweichenden Bedeutungen können ohne Bauchschmerzen koexistieren.

• Schlüssel können anwendungsübergreifend eindeutig identifiziert werden. Das erleichtert beispielsweise auch die Kommunikation zwischen Schulen und Behörden.

Klingt gut? Finden wir auch. Deshalb hier nocheinmal der Verweis auf die komplette Spezifikation:

• https://openpotato.github.io/opencodelist/de/specification/

Wir freuen uns über Feedback.