Die Datenbasis als JSON und YAML

Hinter dieser Website stecken statische HTML-Dateien, die mittels eines Static-Site-Generators (Hakyll) aus einer YAML-Datenbasis generiert werden.

Damit andere diese Datenbasis ebenfalls für ihre Roller-Derby-bezogenen Projekte nutzen können, stelle ich sie nun auch öffentlich zur Verfügung:

• JSON
• YAML

Wie im Dateinamen erkennbar, sind dies die deutschen Versionen, mit deutschsprachigen Ortsnamen. Dieselbe Datenbasis existiert jeweils auch mit englischen und französischen Versionen, dazu bitte die URL entsprechend anpassen.

Aufbau

Die JSON- und die YAML-Version sind exakt gleich aufgebaut. Im folgenden verwende ich der Übersicht halber die YAML-Notation.

Auf oberster Ebene liegen fünf Schlüssel:

• associations enthält die eingepflegten Vereine und ihre Teams
• cities ordnet Städten einen Anzeigenamen und ein Land zu
• countries ordnet Ländern einen Anzeigenamen und eine Zeitzone zu
• encounters enthält die Spieltage und ihre Bouts
• stadiums enthält Spielstätten/Stadien und ihre Adressen

RefOrStruct-Konzept

Mit RefOrStruct bezeichne ich das Muster, Objekte entweder direkt als JSON-Objekte an Ort und Stelle zu beschreiben (Struct), oder in einer zentralen Liste zu beschreiben und überall sonst darauf zu verweisen (Reference).

Folgende Beispiele von Spieltagen machen dies deutlich:

- date: 2026-04-11
  subtext: Tageskasse 6€ (ermäßigt 4€), Essen und Getränke nur draußen
  title: "HARD vs. Leipzig Sun Blockers, HARDischocken vs. Brünster&DerbyDino-Mite"
  place: →HHChristianeum
  bouts:
    - time: '14:30'
      a: →HaRDischocken
      b:
        name: Derby Dino-Mite & Brünster
        alliance:
          - →DinoMite
          - →Bruenster	
- date: 2026-08-01
  place: &Muenchen
    name: 'Unbekanntes Stadion'
    city: →Muenchen
    postcode: 'XXXXX'
    address: 'Unbekannte Str.'
  title: MRR Summertime Madness Tournament
  bouts:
    - a: →RollingRebels
      b: t.b.d.
      time: t.b.d.

Im ersten Fall ist als Spielstätte eine Referenz HHChristianeum angegeben. Dass es sich um eine Referenz handelt, zeigt der kleine Pfeil (→) davor an. Irgendwo in der stadiums-Liste wird nun also der Schlüssel HHChristianeum liegen, und darin stehen dann die Adresse, die Stadt und der Anzeigename.

Im zweiten Fall ist das Stadion noch nicht bekannt, daher kann ich nicht auf eine Spielstädte unter stadiums referenzieren. Ich habe also ein Ad-Hoc-Objekt eingesetzt, mit einer Referenz auf eine Stadt (→Muenchen) und direkten Strings beim Namen, PLZ und Adresse. Zusätzlich ist ein YAML-Anker gesetzt, um an anderen Stellen in der Datenbasis das gleiche Objekt zu kopieren, ohne dabei zu suggerieren, es handle sich um dasselbe Stadion.

Stadien, die unter stadiums aufgeführt sind, und anderswo mit Referenzen verlinkt werden, werden auf der Website als Hyperlinks dargestellt und führen auf eine eigene Übersichtsseite. Ad-Hoc-Stadien erhalten diese nicht.

Anstelle der Referenz auf die Stadt München (→Muenchen) hätte auch hier eine Ad-Hoc-Stadt eingefügt werden können, etwa so:

  place:
    name: 'Unbekanntes Stadion'
    city:
      name: Unbekannte Stadt
      country: DE
    postcode: 'XXXXX'
    address: 'Unbekannte Str.'

In einigen Fällen lassen sich Ad-Hoc-Objekte auch durch einen einzelnen String ausdrücken. Wir sehen dies im oberen München-Beispiel:

  bouts:
    - a: →RollingRebels
      b: t.b.d.
      time: t.b.d.

Das erste Team ist zwar schön referenziert, das zweite Team wurde jedoch noch nicht bekanntgegeben. Hier hätte auch ein strukturiertes Team-Objekt stehen können, allerdings bringt das im unbekannten Fall keinen Mehrwert außer Schreibarbeit - der String “t.b.d.” wird als Teamname interpretiert und ohne weitere Verarbeitung auf die Website übertragen.

Manche Teams sind auch aus anderen zusammengesetzt:

  bouts:
    - time: '14:30'
      a: →HaRDischocken
      b:
        name: Derby Dino-Mite & Brünster
        alliance:
          - →DinoMite
          - →Bruenster

Hier spielen die HaRDischocken gegen eine Spielgemeinschaft aus Brünster und den Derby Dino-Mites, die jeweils als Referenzen aufgeführt werden. Die Spielgemeinschaft selbst ist hier jedoch ad-hoc aufgeführt und nicht zentral deklariert.

Datenmodell bei Teams

Natürlich können Team-Zugehörigkeiten und Organisationsstrukturen stark heterogen sein und strikte Modelle immer wieder sprengen. Mit irgendetwas musste ich aber modellieren, auch wenn das für die Realität vielleicht etwas zu vereinfacht ist:

• Jede Stadt (city) kann mehrere Vereine (associations) beinhalten (1:n).
• Entsprechend ist jeder Verein genau einer Stadt zugeordnet (n:1).
• Jeder Verein kann mehrere Teams (teams) beinhalten (1:n).
• Entsprechend ist jedes Team Teil genau eines Vereins (n:1).
• Ein Team ist ebenfalls genau einer Stadt zugeordnet (n:1).
• Die Stadt eines Teams kann von der Stadt des Vereins abweichen. Ist keine Stadt angegeben, wird die vom Verein übernommen.
• Mehrere Teams können zusammen eine Spielgemeinschaft bilden.
• Spielgemeinschaften (alliances) sind im Datenmodell ebenfalls einem Verein zugeordnet (n:1), dessen Ort wird jedoch ignoriert.
• Spielgemeinschaften haben per se keine Stadt, ersatzweise werden sie als in allen Städten ansässig gesehen, aus denen ihnen Teams angehören.
• Spielgemeinschaften können genau wie Teams referenziert werden.

Beispiele:

- name: Augsburg Rolling Thunder
  city: →Augsburg
  teams:
    RollingThunder:
      name: Rolling Thunder
- name: Roller Derby Erfurt
  city: →Erfurt
  teams:
    Gemstones:
      name: The Gemstones
      comment: FLINTA, 2.BuLi
    MagmaMonsters:
      name: Magma Monsters
      comment: B-Team
    Stonehearts:
      name: Stonehearts
      comment: Kompetitives All-Gender-Team im Aufbau
    SGMRD:
      name: "South German Men's Roller Derby"
      comment: Regionsübergreifendes Herrenteam
- name: Gemeinsame Teams Augsburg/Erfurt
  city: →Augsburg
  teams:
    Augsfurt:
      name: Augsfurt
      alliance:
        - →RollingThunder
        - →Stonehearts