Wie man CSV zur Veröffentlichung, also maschinenlesbar und verständlich, formatiert und erstellt.
Da wir im Vereinsumfeld immer wieder mit offenen Daten zu tun haben, sind wir schon an diversen Stellen auf ziemlich wilde Datensätze gestoßen, im Sinne der Lesbarkeit und Verwendbarkeit. Von größtenteils nicht maschinenlesbaren Formaten (z.B. PDF) abgesehen, sind auch Daten in geeigneteren Formaten wie CSV häufig nicht ohne manuelle Analyse und Bearbeitung maschinell nutzbar.
Für zukünftige Datensätze wollen wir hier ein paar Richtlinien für CSV-Dateien festlegen und anhand von (Positiv- und Negativ-)Beispielen erklären.
Encoding
Das Encoding einer Datei definiert, wie Zeichen (besonders Sonderzeichen wie Umlaute, hochgestellte Zahlen für m², m³ usw.) abgespeichert werden. Beispiele hierfür sind “ISO-8859-1” (Standard bei Excel), “Codepage 850” (Historisch bei MS-DOS verwendet) und “UTF-8” (Aktueller Standard - Kann alle definierten Zeichen darstellen, also z.B. auch kyrillische, chinesische und japanische Schriften).
Es ist nicht notwendig, auf Sonderzeichen zu verzichten - Man muss nur das richtige Encoding wählen.
Standard ist heutzutage fast überall UTF-8, zum Beispiel CKAN und DKAN erwarten beim Import von CSV-Dateien UTF-8.
Der Export als UTF-8-CSV bei Excel ist etwas umständlich, Anleitungen sind im Internet aber leicht zu finden. (Stand Excel 2019: im “Speichern unter”-Menü als Dateityp “CSV (Trennzeichen-getrennt) (*.csv)” auswählen und dann vorm Speichern auf “Tools” -> “Weboptionen…” -> “Codierung” -> “Dokument speichern als:” -> “Unicode (UTF-8)”)
Formatierung
Zur Formatierung gelten ein paar Grundsätze:
- Die erste Zeile (Header) einer CSV-Datei sollte nur die entsprechenden Feldnamen der Tabelle enthalten.
- Einheiten sollten im Header enthalten sein, nicht in den Daten
- Nach der ersten Zeile sollten die Daten direkt anfangen
- Nach den Daten sollten keine weiteren Informationen mehr kommen - Metadaten, Erklärungen zu den Feldern usw. sollten in der Beschreibung zum Datensatz stehen.
- Nach Möglichkeit sollten alle Felder befüllt sein - wenn sich bspw. mehrere Zeilen auf ein Jahr beziehen, sollte das Jahr auch in jeder Zeile stehen.
- Jede Datei sollte nur eine Tabelle enthalten
- Die Tabelle sollte so formatiert sein, dass neue Daten üblicherweise nicht als Spalte, sondern als Zeile angefügt werden (wenn es neue Kategorien gibt, ist es natürlich trotzdem korrekt, neue Spalten hinzuzufügen)
- Es sollten möglichst nicht mehrere Daten in einer Zelle stehen (z.B. bei von-bis-Werten u.Ä.)
Beispiele
Header, Daten
Negativbeispiel - Fußnoten, Referenzen
| Jahr | Anzahl |
|---|---|
| 2019 1) | 123456 |
| 2020 | 123456 |
| 2021 | 123456 |
| 1) Daten unvollständig weil XY | |
| {:.table-bordered} |
Die Fußnoten und die Referenz darauf brechen die Struktur, darum sollten diese eher im Beschreibungstext stehen. Bei regelmäßig auftretenden Hinweisen und Besonderheiten sollte man hier zusätzliche Spalten vorsehen.
Negativbeispiel - Header hat mehrere Zeilen
| Umweltdaten XY | |
|---|---|
| Stadtkreis XY | Alle Werte in m³ |
| Jahr | Wert |
| 2022 | 123456 |
| {:.table-bordered} |
Auch hier sind die zusätzlichen Informationen im Beschreibungstext (bzw. die Einheit in der Spaltenüberschrift) besser aufgehoben.
Negativbeispiel - Felder ausgelassen
| Jahr | Stadtteil | Wert |
|---|---|---|
| 2021 | Böckingen | 123456 |
| Biberach | 123456 | |
| Frankenbach | 123456 | |
| 2022 | Böckingen | 123456 |
| Biberach | 123456 | |
| Frankenbach | 123456 | |
| {:.table-bordered} |
Für manuelle Auswertung ist vermutlich klar, was hier gemeint ist, für maschinelle Auswertung sollte jedes Feld das sinnvoll befüllt werden kann auch befüllt werden:
Positivbeispiel
| Jahr | Stadtteil | Wert |
|---|---|---|
| 2021 | Böckingen | 123456 |
| 2021 | Biberach | 123456 |
| 2021 | Frankenbach | 123456 |
| 2022 | Böckingen | 123456 |
| 2022 | Biberach | 123456 |
| 2022 | Frankenbach | 123456 |
| {:.table-bordered} |
Definition der Spalten/Zeilen, Hinzufügen von Spalten
Negativbeispiel
| Stadtteil | 2018 | 2019 | 2020 |
|---|---|---|---|
| Böckingen | 123456 | 123456 | 123456 |
| Biberach | 123456 | 123456 | 123456 |
| {:.table-bordered} |
Hier sollten die Stadtteile eher die Spalten und die Jahreszahlen die Zeilen sein, da sich die Spalten selten ändern sollten:
Positivbeispiel
| Jahr | Böckingen | Biberach |
|---|---|---|
| 2018 | 123456 | 123456 |
| 2019 | 123456 | 123456 |
| 2020 | 123456 | 123456 |
| {:.table-bordered} |
Positivbeispiel
| Jahr | Männlich | Weiblich | Divers |
|---|---|---|---|
| 2016 | 123456 | 123456 | |
| 2017 | 123456 | 123456 | |
| 2018 | 123456 | 123456 | 123 |
| {:.table-bordered} |
Hier eine neue Spalte hinzuzufügen ist natürlich okay - Es gibt schließlich eine neue Kategorie. Auch die Felder ohne Daten sind hier okay. Eventuell wäre im Beschreibungstext ein Hinweis auf die geänderte Datenstruktur sinnvoll/hilfreich.
Einheiten, mehrere Daten pro Zeile
Negativbeispiel
| Stadtteil | Wasserhärte |
|---|---|
| Böckingen | 14 - 15 ° DH |
| Biberach | 11 ° DH |
| {:.table-bordered} |
Besser wären die Werte hier in seperaten Spalten aufgehoben mit der Einheit in der Spaltenüberschrift:
Positivbeispiel
| Stadtteil | Min. Wasserhärte in ° DH | Max. Wasserhärte in ° DH |
|---|---|---|
| Böckingen | 14 | 15 |
| Biberach | 11 | 11 |
| {:.table-bordered} |