| Status | ||||
|---|---|---|---|---|
|
| Inc drawio | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Import Process Bridge
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.
...
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 /wiki/spaces/MD/pages/366444673-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 /wiki/spaces/MD/pages/366411975 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 Java Virtual Machine existiert (Stand Herbst 2020).
Media Metadata Ingest
Der mediametadatatodb Service indexiert die Medienmetadaten zu Handen des Medienserver in eine MariaDB-Datenbank. Neben dem Link zur Medienressource werden verschiedene technische Metadaten (Breite, Höhe, Abspieldauer, MIME-Type), Zugang (public / closed), Zugangsart (per redirect oder proxy) sowie der benötigte Playertyp (lokaler Player vs. verschiedene externe Players) festgehalten.
Medienobjekt-Konversion
Der Media Converter kopiert Mediendateien vom sFTP-Server auf ein in Kubernetes /wiki/spaces/MD/pages/366444646 eingehängtes Medienverzeichnis, welches vom Medienserver und vom Bildserver zur Auslieferung der lokalen Medienressourcen genutzt wird. Je nach Medientyp konvertiert er darüberhinaus darüber hinaus die Daten in ein geeigneteres FormatDateiformat:
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 welcher eine effiziente Identifikation von Dateien basierend auf der Dokumenten-ID zulässt.
Media Metadata Ingest
...
EDM-Transformation
Wie bei der Transformation der Daten für den Suchindex sind die RiC- Memobase RDF Metadaten die Grundage Grundlage für die Datenpipeline. Target Format Zielformat ist das von Europeana definierte EDM Format. Obwohl sowohl Ausgangs- als auch Zielmodell Zielformat in RDF abgebildet werden, unterscheiden sie sich stark voneinadervoneinander. Kommt hinzu, dass wir Ric-Memobase RDF in Json-ld serialisieren, das JSON-LD serialisiert wird, EDM RDF Format jedoch zwingend in RDF-XML serialisiert werden muss.
Die durch die pipeline Datenpipeline erstellten EDM RDF-XML Dokumente werden in unserem im Elasticsearch-Index indexiert (dafür wird der Microservice “Metadaten Ingest” genutztsiehe unten Metadaten Ingest). Der ES Elasticsearch-Index (Indexname oai-v*) ist dann die Grundlage für die OAI Schnittstelle. die /wiki/spaces/MD/pages/366313714 (siehe die Beispielabfrage mit verb ListRecords und einem setSet, welches für Europeana erstellt wurde).
Das Mapping der Daten zwischen RiC-Memobase RDF und EDM ist recht aufwendig . Ausserdem und benötigt man neben den rico RiCO-Daten noch weitere Informationen aus den institution und record-set Suchindices. Gewichtige Gründe dafür, dieses mapping Suchindizes für Institutionen und Bestände. Aus diesen Gründen wurde das Mapping nicht als ad-hoc-Transformation in die oai Schittstelle zu verlegen. OAI-Schittstelle verlegt (wie das dies früher zum Teil in http://sru.swissbib.ch gemacht worden ist. Bei anderen Formaten mag das wieder anders sein oder Transformationen können komplett obsolet werden, wenn wir über oai zum Beispiel direkt RicRDF ausliefern wollen. Allerdings wäre wohl, um dem OAI Standard gerecht zu werden, eine RDF XML Serialisierung notwendig.
Abschlussbemerkung: Die Basis des service ist ein Scala “functional Extractor” Mechanismus, wie er von Sebastian Schüpbach für den IIIF Manifest Creator zuerst implementiert wurde. Dieser eignet sich sehr gut auch für Metadatenspezialist*innen, sei es im Umfeld memoriav oder Bibliothek. Diese dann auch interaktiven Möglichkeiten, mit denen Datenpipelines- oder Datenanalyseservices auch von einem breiteren Personenkreis erstellt werden können, werden wir in Zukunft ausbauen. Dabei wird der breitere Personenkreis wohl eher Python als Scala verwenden. (es sein denn Scala 3 wird plötzlich doch zu Python für jedermann - man wird sehen….) bspw. in swissbib SRU gemacht wurde). In anderen, nicht-EDM-bezogenen Fällen kann diese Methode angepasst werden - bspw. indem direkt Memobase RDF in einer XML-Serialisierung ausgeliefert wird.
Suchindex-Transformation
Dieser Service wird verwendet, um die RiC-Memobase RDF - Metadaten in eines einen von drei Suchindexdokumenten Suchindizes 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)Dieser Service akzeptiert Metadaten im JSON format und indexiert diese in Elasticsearch. Der Service ist optimiert, damit möglichst viele Dokumente gleichzeitig indexiert werden können.