Systematische Datenaufbereitung

5.3. Systematische Datenaufbereitung#

Story

Die Annotationsdaten wurden erhoben, die Moviebarcodes aus den Filmdateien extrahiert. Projektintern lagen bereits Dokumentationen und Filmlisten vor, allerdings uneinheitlich und ohne konkrete Systematik. Für eine Datenpublikation ist allerdings die Systematisierung unerlässlich: Daten müssen strukturiert, nachvollziehbar und interoperabel sein. Der erste Schritt ist also die systematische Aufbereitung des gesamten Korpus. Dafür wurde ein projektspezifischer Metadatenstandard entwickelt.

Leitfrage

Wie lassen sich unorganisierte Forschungsdaten für eine Nachnutzung systematisieren?

../_images/abb_k05_rohdaten_systematisierung.png — Fig. 5.5 Von den Rohdaten zur Systematisierung (KI-generiert)#

Das Projekt-Metadatenschema: Beschreibungen und DC/EN-Mapping#

Das für das SFB-Projekt entwickelte Metadatenschema orientiert sich an den Basiselementen des DC-Schemas und des EN 15744. Zentrale Identifikationsfelder wie Titel, Identifier, Produktionsland, Jahr, Regie und Laufzeit entsprechen standardnahen Metadatenelementen. Sie dienen einerseits der formalen Einordnung sowie Identifizierbarkeit, andererseits können durch die erfassten Elemente auch weitere Untersuchungen am Korpus ermöglicht werden, wie zum Beispiel Berechnungen von Länderanteilen oder Produktionszeiträumen.

Wie können die Metadaten genutzt werden?

Im Kapitel Diskriminierungssensible Überprüfung führen wir Beispielhaft anhand der Korpusmetadaten punktuell eine Überprüfung mit Fokus auf diskriminierungsensible Aspekte durch.

In der Forschungspraxis lässt sich allerdings häufig kein Schema vollständig auf den wissenschaftlichen Kontext übertragen. Dies liegt insbesondere daran, dass Forschungsprojekte eigene Untersuchungsmethoden, Korpusdefinitionen und Analysekateogorien mitbringen, die in den allgemeinen Standards keine Entsprechung finden.

Für das Teilprojekt C05 bedeutet dies konkret: Das Metadatenschema wurde projektspezifisch entwickelt, in weiten Teilen lassen sich die Element jedoch auf das DC/EN-Schema mappen.

Die folgende Tabelle zeigt alle 13 Felder des Korpusmetadatenschemas mit ihren Entsprechungen in Dublin Core (DC) und EN 15744. Felder ohne Mapping sind projektspezifische Erweiterungen ohne direkte Entsprechung in einem der beiden Standards.

Feld	Beschreibung	Dublin Core	EN 15744	Kommentar
`title`	Originaltitel der audiovisuellen Ressource in Originalsprache	dc:title	Title	Standardfeld mit direkter Entsprechung
`object_id`	Projektspezifischer eindeutiger Identifier (ID) des Objekts (audiovisuelle Ressource)	dc:identifier	Identifier	Projektspezifischer lokaler Identifier
`imdb_id`	Externer IMDb-Identifier	dc:identifier	Identifier	Externe Kennung
`classification`	Korpusspezifisches strukturelles Format des Objekts (audiovisuelle Ressource)	dcterms:type	Genre	Aufteilung folgt nach Werktyp und Filmgattung
`country`	Land der Produktion nach ISO 3166-1 alpha-2	dcterms:spatial	Country of Reference	Geographischer Kontext
`year`	Jahr der Erstveröffentlichung im Produktionsland	dcterms:issued	Year of Reference	Standardfeld
`director`	Vorname Nachname der regieführenden Person(en); bei mehreren Personen getrennt durch Semikolon	dcterms:creator	Credits	Zentrale Referenzperson; anpassen für inklusive Credit-Praktiken
`runtime_min`	Laufzeit in Minuten, menschenlesbar	dcterms:extent	Original Duration	Nicht normiert
`duration_iso8601`	Laufzeit nach ISO 8601 duration format, maschinenlesbar	dcterms:extent	Original Duration	Normiert
`season_episode`	Staffel- und Episodennummer für serielle Formate	dcterms:isPartOf	Series / Serial	Nach etabliertem Standard: S0XE0X
`episode_title`	Originaltitel der Serienepisode in Originalsprache	dc:title	Title	Standardfeld mit direkter Entsprechung
`modes_intervention`	Projektspezifische Analysekategorie	––	––	Aus dem Korpus heraus entwickelt
`annotation_data`	Zugehörige Annotationsdaten	dcterms:relation	Relationship	Abgeleitete oder zugehörige Ressource
`moviebarcode`	Zugehöriger Moviebarcode	dcterms:relation	Relationship	Abgeleitete oder zugehörige Ressource

Hinweis zum Mapping

Nicht jedes Element lässt sich sauber auf die Standards beziehen. Das Feld classification beispielsweise kombiniert Werktyp und Darstellungsmodi (fiktional, dokumentarisch) bzw. Filmgattung und bildet die korpusinternen Aufteilungen ab.

Ein beispielhafter Metadatensatz für eine audiovisuelle Ressource im json-Format sieht so aus:

{
  "title": "Everything Will Change",
  "object_id": "f029e",
  "imdb_id": "tt13086274",
  "classification": "documentary",
  "country": "DE; NL",
  "year": 2021,
  "director": "Marten Persiel",
  "runtime_min": "93 Min.",
  "duration_iso8601": "PT1H33M",
  "season_episode": "",
  "episode_title": "",
  "modes_intervention": "Post-anthropocentric reperspectivations",
  "annotation_data": true,
  "moviebarcode": true
}

Was ist JSON?

JavaScript Object Notation ist ein kompaktes Dateiformat in einfacher Textform, das den Datenaustausch zwischen verschiedenen Anwendungen ermöglicht. Informationen werden dabei in Form von Schlüssel-Wert-Paaren organisiert und können zu Objekten und Listen zusammengefasst werden. Ausführlichere Informationen zum Nachlesen gibt es hier.

Identifier, ISO-Standards und kontrollierte Vokabulare#

Identifier#

Um die audiovisuellen Ressourcen und die Datensätze dauerhaft referenzierbar zu machen, braucht jedes Objekt (sowohl audiovisuelle Ressourcen als auch die Daten selbst) im Korpus einen stabilen, eindeutigen Identifier. Im Projekt wurden zwei Arten von Identifiern verwendet: ein projektspezifischer und ein externer.

Für den projektspezifischen Identifier wird die Bezeichnung object_id verwendet. Die object_id folgt einem dreiteiligen Schema:

Teil	Bedeutung	Beispiel
Präfix	Typ des Objekts: `f` = Film/Dokumentarfilm, `e` = Episode, `v` = Video	`f`
Nummer	Dreistellige fortlaufende Nummer in Aufnahmereihenfolge	`002`
Suffix	Erster Buchstabe oder erste Ziffer des Originaltitels	`a` (→ Anthropocene)

So sieht ein vollständiger Identifier, beispielsweise für den Film Anthropocene: The Human Epoch (R: Jennifer Baichwal, Edward Burtynsky, Nicholas de Pencier, CAN 2018) aus: f002a.

Warum nicht die Variante Titel + Jahr verwenden?

Identifier wie avatar_2009 wirken auf den ersten Blick einfach und sind intuitiv, jedoch nicht sehr robust und fehleranfällig. Denn Filmtitel können Sonderzeichen, Leerzeichen oder Umlaute enthalten, die die Maschinenlesbarkeit verhindern. Ebenso kann es mehrere Titel für einen Film geben, was eine stabile ID beeinträchtigt.

Fazit

Die Objekt-IDs setzen sich aus einem Präfix, einer fortlaufenden numerischen Kennung und einem Suffix zusammen. Die numerischen Bestandteile wurden im Zuge der sukzessiven Erweiterung des Korpus vergeben und folgen keiner inhaltlichen Logik, sondern der projektinernen Erfassungsreihenfolge.

Zusätzlich zu dem projektspezifischen Identifier wurde für jeden Film, wo möglich, ein IMDb-Identifer erfasst (z. B. tt8399690)- Dieser externe Identifier trägt die Bezeichtnung imdb_id. Er dient als stabile und öffentlich abrufbare Referenz und existiert unabhängig vom Projekt. So können Zusatzinformationen über die Filme von anderen Forschenden auch über die imdb_id eingesehen werden.

Warum wurde IMDb als externe Referenz verwendet und nicht beispielsweise die ISAN? ISAN (International Standard Audiovisual Number, ISO 15706) ist der offizielle ISO-Standard zur Identifikation audiovisueller Werke, vergleichbar mit der ISBN für Bücher. In der Praxis sind ISANs allerdings sehr lückenhaft vergeben und ohne institutionellen Zugang nur schwer einsehbar. IMDb-IDs hingegen sind sehr etabliert und frei zugänglich. Die Datenbank enthält zudem eine umfangreiche Menge an katalogisierten Werken, wodurch das Auffinden von audiovisuellen Ressourcen vereinfacht wird. Alternative größere Filmdatenbanken sind unter anderem The Movie Database (TMDb) sowie The Open Movie Database (OMDb). Da IMDb eine kommerziell betriebene Datenbank ist, ist bei der Nachnutzung der Daten Vorsicht geboten. Hierzu mehr im Kapitel Diskriminierungssensible Überprüfung.

Welche Anforderungen allgemein für die Entwicklung guter Identifer zu beachten sind, haben wir hier in übersichtlicher Form zusammengefasst:

Anforderungen an gute Identifier

Eindeutigkeit: Jedes Datenobjekt und jede Ressource bekommt eine ID, die nur einmal vorkommt
Persistenz: Die ID bleibt dauerhaft, auch wenn sich Titel oder Metadaten ändern
Logik und Strukturiertheit: Die ID muss einer konsistenten Logik entsprechen
Maschinenlesbarkeit: Keine Leerzeichen, Umlaute oder Sonderzeichen, im besten Fall durchgehende Nummern/Buchstaben
Referenzierbarkeit: Die ID sollte in allen Metadatenressourcen als Primärschlüssel dienen

Kontrollierte Vokabulare#

Kontrollierte Vokabulare legen fest, welche Werte für ein Feld zulässig sind. Sie werden eingesetzt, um Inkonsistenzen (z. B. durch Tippfehler) oder unterschiedliche Schreibweisen zu verhindern (z. B. “Dokumentarfilm” vs. “Doku”). Dadurch ermöglichen sie eine präzisere Filterung, Suche und maschinelle Auswertung.

In den Korpusmetadaten wurden für zwei Felder kontrollierte Vokabulare festgelegt:

classification
modes_intervention

Wie bereits oben beschrieben, bildet das Element bzw. Feld classification die Aufteilungen des untersuchten Gesamtkorpus (sowie den Teilkorpora von UP 1, UP 2 und UP 3) ab. Diese Aufteilung folgt nach Werktyp (Episode, Video) und Filmgattung (Spielfilm, Dokumentarfilm). Folgende Werte sind für das Feld zugelassen:

feature film
documentary
episode
video

Das Feld modes_intervention (Modi der Intervention) ist eine aus dem Korpus des Projekts heraus entwickelte Analysekategorie, die versucht, die Zirkulation audiovisueller Strategien zu erfassen. Hierfür wurden die audiovisuellen Strategien übergeordneten Mustern und Konfliktlinien zugeordnet, die als Modi der Intervention beschrieben werden.

Es handelt sich um ein kontrolliertes Vokabular mit sieben Werten:

destabilization / restabilization
escalation / de-escalation
disruptive scaling
non-linear temporalities
post-anthropocentric reperspectivations
unintended consequences
collisions

Das Feld ist optional und wird nur für annotierte Objekte befüllt.

Definitionen der Modi

Zum Nachlesen finden sich ausführliche Definitionen der Modi in der Projektdokumentation auf GitHub.

ISO-Standards#

Für zwei Felder werden sogenannte ISO-Standards als kontrollierte Vokabulare eingesetzt.

Was sind ISO-Standards bzw. Normen?

ISO Normen sind weltweit anerkannte, konsensbasierte, schriftlich festgelegte Standards zur Definition für Materialien, Produkte, Dienstleistungen oder Verfahren. Sie werden von der International Organization for Standardization herausgebracht und sind nicht bindend, jedoch aber in vielen Kontexten zur Qualitätssteigerung, Sicherung und Effizienz etabliert.

Durch die Verwendung von ISO-Standards wird sichergestellt, dass die Daten maschinenlesbar, interoperabel und unabhängig von Sprache, Kultur oder Konvention interpretierbar sind.

country: kodiert nach ISO 3166-1 alpha-2, dem internationalen Standard für Ländercodes. Statt “Deutschland”, “Germany”, “GER” oder “DEU” wird einheitlich “DE” verwendet.
duration_iso8601: kodiert nach ISO 8601, dem internationalen Standard für Datums- und Zeitangaben. Laufzeiten werden im Format PT[Stunden]H[Minuten]M angegeben, z. B. PT1H32M für 92 Minuten. Das Feld ergänzt runtime_min (92. Min.), welches für die menschliche Lesbarkeit im Arbeitskontext beibehalten wird. Maschinenlesbar und interoperabel ist jedoch nur die ISO-kodierte Variante.

Beide Beispiele zeigen, wie kontrolliertes Vokabular durch externe Normen eingesetzt werden kann. Die Wertliste wird also folglich nicht selbst definiert, sondern von einem etablierten Standard übernommen.

Wo sind kontrollierte Vokabulare zu finden?

Je nach Disziplin und Anwendungsfall gibt es unterschiedliche Quellen:

ISO 3166-1 für Ländercodes
ISO 639 für Sprachcodes
DCMI Metadata Terms für heterogene Metadatenelemente
Getty Art & Architecture Thesaurus (AAT) für Kunst- und Kulturbegriffe
GND (Gemeinsame Normdatei) der Deutschen Nationalbibliothek für Personen, Orte, Sachbegriffe

Für filmwissenschaftliche Begriffe:

FIAF Glossary of Filmographic Terms für Filmterminologien
PBCore für audiovisuelle Ressourcen und Inhalte

Relationale Verknüpfung des Datensets#

Neben den Korpusmetadaten, die das Kernelement der Referenzierbarkeit und Dokumentation des Datensatzes bilden, gibt es noch zwei weitere Metadaten-Files:

annotation_medadata für die Annotationsdatensätze
moviebarcode_metadata für die Moviebarcodes

Wie in den Informationen zum Datenset ausgeführt, handelt es sich hier um ein relationales Prinzip der Datenverknüpfung. Hauptverknüpfungselement ist dabei der projektinterne Identifier, die object_id. Jedes azp File sowie jede png hat einen einzigen, eindeutigen Identifier, der sich aus der object_id ableitet und somit den einzelnen audiovisuellen Ressourcen zugeordnet werden kann. In den Metadaten finden sich zudem zusätzliche Informationen, wie beispielsweise das Datum der Erstellung oder technische Komponenten.

Alle hier beschriebenen Metadaten-Dateien stehen auf GitHub in den Exportformaten (xlsx, csv, html, json) zur Verfügung. Einzelheiten zu den einzelnen Formaten gibt es im nächsten Kapitel.

Das Metadatenschema als Template#

Das im Rahmen des Projekts entwickelte Metadatenschema steht als downloadbares Template im sogenannten yaml-Format zur Verfügung. Das Template dient als nachnutzbare Vorlage für die strukturierte Beschreibung von filmographischen Metadatensätzen und definiert die relevanten Metadatenelemente in einem maschinenlesbaren Format. Somit kann es als Ausgangspunkt für eigene Metadatenschemata aber auch zur Dokumentation, Validierung oder zur automatisierten Weiterverarbeitung in andere Formate genutzt werden. Selbstverständlich kann die Vorlage an die Bedürfnisse des eigenen Forschungskontexts angepasst werden. Im Abschnitt Metadatenvalidierung wird gezeigt, wie die Metadaten anhand des yaml-Schemas validiert werden.

Was ist eine YAML-Datei und wie kann sie genutzt werden?

yaml (YAML Ain’t Markup Language) ist ein menschenlesbares Datenformat zur strukturierten Speicherung von Informationen. Es ist besonders kompakt und gut lesbar, da es auf Einrückungen statt auf Klammern oder Tags setzt. Im Kontext von Forschungsdaten werden yaml-Dateien häufig für die Dokumentation von Metadatenschemata genutzt, da Felder, Datentypen aber auch Regeln für eine Nachnutzung beschrieben werden können.

Zum Öffnen und Bearbeiten der yaml-Datei kann ein kostenloser Code-Editor genutzt werden. In dieser OER nutzen wir für alle Beispiele Visual Studio Code (VS Code) von Microsoft, da die Software kostenfrei verfügbar und auch für Einsteiger:innen leicht zugänglich ist. Alternativ können ebenso andere, auch nicht kommerziell betriebene Text- oder Code-Editoren verwendet werden.

Die yaml-Datei ist maschinenlesbar und dokumentiert alle Felder mit Typ, Pflichtangaben, DC/EN-Mapping, Validierungsregeln (Pattern/Muster), kontrollierten Vokabularen und Beschreibungen. Die Pattern folgen einer bestimmten Logik und basieren auf sogenannten “regulären Ausdrücken” (Regular Expressions, kurz: Regex). Sie regeln, in welchem Format ein Wert vorliegen soll, beispielsweise für year:

"^[0-9]{4}$"

^ = Anfang des Wertes
$ = Ende des Wertes
[0-9] = Ziffer von 0 bis 9
+ = beliebig oft
{4} = genau viermal

Werden eigene, abweichende Felder verwendet, deren Werte ebenfalls einem bestimmten Muster folgen, kann mit Unterstützung von KI eine passende Regex-Regel erstellt werden. Hierfür genügt es, die gewünschte Pattern-Logik im Prompt zu beschreiben. Die KI kann diese Anforderungen anschließend in einen Regex-Ausdruck übersetzen.

Das YAML-SCHEMA#

schema:
  name: corpus_metadata_schema_climate_film_c05
  version: "1.0.0"
  fields:
    - name: title
      type: string
      required: true
      dc-mapping: "dc:title"
      en15744-mapping: "Title"
      description: "Original title of the audiovisual resource in its original language"
      example: "Anthropocene: The Human Epoch"

    - name: object_id
      type: string
      required: true
      dc-mapping: "dc:identifier"
      en15744-mapping: "Identifier"
      pattern: "^[fev][0-9]{3}[a-z0-9]$"
      description: >
        Project-specific unique identifier (ID) for the object (audiovisual resource);
        Composed of three parts: a classification prefix (f = feature film or documentary,
        e = episode, v = video), a three-digit sequential number, and a suffix
        consisting of the first letter or digit of the original title
      example: "f002a"
      notes: Can be adjusted for project purposes

    - name: imdb_id
      type: string
      required: true
      dc-mapping: "dc:identifier"
      en15744-mapping: "Identifier"
      description: "External IMDb identifier"
      note: Other standards for external identifiers such as ISAN can also be used
      example: "tt8399690"

    - name: classification
      type: string
      required: true
      dc-mapping: "dcterms:type"
      en15744-mapping: "Genre"
      vocabulary:
        - feature film
        - documentary
        - episode
        - video
      description: "Corpus-specific structural format of the object (audiovisual resource)"
      example: "documentary"
      notes: > 
        Can be adjusted for project purposes. No exact correspondence to EN 15744 or DC;
        this field combines work type and genre as a corpus-specific simplification
    
    - name: country
      type: string
      required: true
      dc-mapping: "dcterms:spatial"
      en15744-mapping: "Country of Reference"
      standard: ISO 3166-1 alpha-2
      separator: "; "
      description: "Country/countries of origin"
      example: "CA"
      note: >
        No exact correspondence to DC
    
    - name: year
      type: string
      required: true
      dc-mapping: "dcterms:issued"
      en15744-mapping: "Year of Reference"
      pattern: "^[0-9]{4}$" # Four digits 
      description: "Year of initial release in the country of origin"
      example: "2018"

    - name: director
      type: string
      required: true
      dc-mapping: "dcterms:creator"
      en15744-mapping: "Credits"
      separator: "; "
      description: "First and last name of the director(s); multiple directors are separated with semicolon"
      example: "Jennifer Baichwal; Edward Burtynsky; Nicholas de Pencier"
      notes: Can be adjusted for more inclusive credit practices

    - name: runtime_min
      type: string
      required: false
      dc-mapping: "dcterms:extent"
      en15744-mapping: "Original Duration"
      pattern: "^[0-9]+ Min\\.$"
      description: "Runtime in minutes, human-readable"
      example: "87 Min."
    
    - name: duration_iso8601
      type: string
      required: true
      dc-mapping: "dcterms:extent"
      en15744-mapping: "Original Duration"
      standard: ISO 8601 duration
      pattern: "^PT([0-9]+H)?([0-9]+M)?$"
      description: "Runtime following ISO 8601 duration format, machine-readable"
      example: "PT1H27M"
    
    - name: season_episode
      type: string
      required: false
      dc_mapping: "dcterms:isPartOf"
      en15744_mapping: "Series / Serial"
      pattern: "^S[0-9]{2}E[0-9]{2}$"
      description: >
        Season and episode number for serial formats.
        Only relevant if classification = "episode"
      example: "S01E04"
      notes: >
        Follows the widely used de-facto convention. 
        No official ISO standard exists for this format

    - name: episode_title
      type: string
      required: false
      dc-mapping: "dc:title"
      en15744-mapping: "Title"
      description: "Original title of the series episode in its original language"
      example: "To the Ends of the Earth"
      notes: Only relevant if classification = "episode"
    
    - name: modes_intervention
      type: string
      required: false
      vocabulary:
      - Destabilization / Restabilization
      - Escalation / de-escalation
      - Disruptive scaling
      - Non-linear temporalities
      - Post-anthropocentric reperspectivations
      - Unintended Consequences
      - Collisions
      description: "Project-specific analysis categories"