Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Inc drawio
zoom1
simple0
pageId374276107
custContentId618594627
lbox1
diagramDisplayNamepostprocessing-steps.drawio
hiResPreview0
baseUrlhttps://memobase.atlassian.net/wiki
diagramNamepostprocessing-steps.drawio
imgPageId618627505
pCenter0
aspectFxrIFq4vqtaKI8HJX3_7 1
width781
includedDiagram1
aspectHashba6702e1469582dbb70c2cff075c5535736f76fd
linksauto
tbstyletop
height561

Import Process Bridge

[…]

IIIF-Manifest-Generierung

[…]

Medienobjekt-Konversion

[…]

Media Metadata Ingest

Dieser Service fügt IIIF-Manifeste in die Medienserver-Datenbank ein oder ersetzt sie. Er verarbeitet sowohl Manifeste in Version 2 als auch in Version 3 und bietet daher zwei verschiedene Deployment-Manifeste an. Im Moment werden nur Manifeste v2 verwendet.

Die Import Process Bridge überführt die Daten in eine JSON-LD-Struktur, welche von den nachfolgenden Services für die verschiedenen Endpoints aufbereitet wird. Sie ist damit das Bindeglied zwischen dem ersten Teil des Import-Workflows, welcher ursprünglich als einzigen Endpoint das Fedora-Repository hatte, und dem zweiten Teil - dem “Post-Processing”, der als Quelle die in Fedora gespeicherten Daten hatte. Die Import Process Bridge existiert für alle drei Importworkflows - Dokumente, Bestände und Institutionen.

Code Repository

IIIF-Manifest-Generierung

Die IIIF-Manifest-Generierung besteht aus zwei Services - IIIF Manifest Creator und IIIF Manifest Ingester. Der erste ist zuständig für die Erstellung der Manifeste, der zweite für die Indexierung in die MariaDB-Datenbank, wo sie vom Medienserver ausgelesen werden können. Der Creator-Service ist so angelegt, dass er grundsätzlich Manifeste gemäss der IIIF Presentation API v2.1 und auch der aktuellen v3 erstellen kann. Allerdings fehlt bisher noch die Implementation für Letztere, da bislang noch keine produktive Bibliothek zur Erstellung der Manifeste gemäss v3 für die JVM existiert (Stand Herbst 2020).

Medienobjekt-Konversion

Der Media Converter kopiert Mediendateien vom sFTP-Server auf ein in Kubernetes eingehängtes Medienverzeichnis, welches vom Medienserver und vom Bildserver zur Auslieferung der lokalen Medienressourcen genutzt wird. Je nach Medientyp konvertiert er darüberhinaus die Daten in ein geeigneteres Format:

  • Bilddateien (jpg, png): Keine Konversion

  • Videodateien: Keine Konversion

  • Audiodateien: Umverpackung des Inhalts in einen mpeg4-Container, welche für das Streaming geeignetere Eigenschaften besitzt.

Für die Identifikation der Mediendateien auf dem sFTP-Server nutzt der Media Converter einen auf dem sFTP-Host laufenden Service (Media File Distributor), welche eine effiziente Identifikation von Dateien basierend auf der Dokumenten-ID zulässt.

Media Metadata Ingest

Der mediametadatatodb Service indexiert die Medienmetadaten zu Handen des Medienserver in eine MariaDB-Datenbank. Neben dem Link zur Medienressourcen werden verschiedene technische Metadaten (Breite, Höhe, Abspieldauer, Mimetype), Zugang (public / closed), Zugangsart (per redirect oder proxy) sowie dem benötigten Playertyp (lokaler Player vs. verschiedene externe Players) festgehalten (für Details s. Schema Medientabelle).

Code Repository

EDM-Transformation

[…]

Metadaten-Ingest

[…]

Suchindex-Transformation

Dieser Service wird verwendet, um die RiC-RDF-Metadaten in eines von drei Suchindexdokumenten umzuwandeln. Der Dienst verwendet benutzerdefinierte Filter und Transformationslogik, um die RDF-Daten in ein flaches JSON-Dokument umzuwandeln, das einfach für die Suche verwendet werden kann. Der Grund dafür ist, dass die Komplexität des RDF-Modells es komplizierter macht, die Daten direkt für die Suche zu verwenden, und daher eine Reihe von Transformationen dafür notwendig sind. Dies gilt insbesondere auch für die Vorbereitung der Daten für die Facetten.

Metadaten Ingest (in Elasticsearch)

[…]

...

Siehe: Post-Processing Steps (derzeit noch in Erarbeitung)