DOKUMENTATION DER SOFTWARE IAIS-CORTEX (AUSZUG) Stand: Version 0.12 ( )

Transkript

1 F RAUNHOF ER -INSTITUT FÜR INTELL I GENTE ANAL YSE- UND INF ORMATIONSSYSTEME IAIS DOKUMENTATION DER SOFTWARE IAIS-CORTEX (AUSZUG) Stand: Version 0.12 ( )

2 1. IAIS Cortex Überblick Die Software Cortex wurde entworfen, um eine große Zahl von Objekten des kulturellen Erbes aus den kulturellen und wissenschaftlichen Einrichtungen Deutschlands über das Internet zur Verfügung zu stellen. Die Objekte werden als Metadaten und ggf. binäre Derivate in heterogener Form geliefert und sollen in zeitgemäßer Form online recherchiert werden können. Der Implementierung liegt ein einfaches Konzept zugrunde: Die heterogenen Eingangsmetadaten werden in ein einheitliches Datenrepräsentationsmodell übersetzt, das eine Abbildung der Semantik der Originaldaten in möglichst verlustfreier Form erlaubt, aber von einzelnen Datenformaten und Metadatensprachen abstrahiert. Die vereinheitlichten Metadaten und Derivate werden im Archiv der Cortex-Plattform gespeichert Beschreibung des Datenmodells Die Datenmodelle der spartenspezifischen Daten, die von den Providern geliefert werden, müssen innerhalb von Cortex vereinheitlicht werden, allerdings nicht so, dass eine vollständige Replikation der schon in den Originaldaten abgebildeten Semantik in einem weiteren Modell erfolgt, sondern zweckorientiert. Das Modell kann für verschiedene Zwecke genutzt werden: zur Erzeugung exportierbarer Formate (etwa das Europeana Daten Modell) zur Deduplikation von Objekten zur Vernetzung von Objekten (z. B. in Form von Hierarchien) Die Originalmetadaten bleiben innerhalb von Cortex stets unverändert erhalten und können ebenso abgefragt werden wie andere Repräsentationen der Objekte innerhalb von Cortex. Ein verbreiteter Ansatz zur datentechnischen Abbildung von heterogenen Metadaten beruht auf der Annahme, dass es möglich sei, einen gemeinsamen Nenner an Zielfeldern zu definieren, auf die dann die Felder der Eingangsmodelle gemappt werden. Dieser Ansatz bringt in der Praxis je nach Art der Umsetzung Probleme mit sich. Er führt entweder zu semantischer Unschärfe oder zu einer hohen Anzahl von meist ungenutzten Zielfeldern. Innerhalb von Cortex werden für jedes Objekt im Zuge eines Transformationsprozesses verschiedene statische Repräsentationen (z. B. (X)HTML) erzeugt, die von Endgeräten leicht angezeigt werden können. Beispielsweise existieren verschiedene Views (Sichten) zur Darstellung von Objekten in Trefferlisten und Detailansichten beim Zugriff auf die Suchmaschine. Um die originalen Metadaten auf das interne Datenmodell und die zugehörigen Views abbilden zu können (Mapping Prozess), wurde eine Mapping-Library implementiert. Diese ist so aufgebaut, dass die beinhalteten Transformationsregeln nicht nur spezifisch für ein Metadatenformat, sondern vielmehr auch spezifisch für einen Provider oder eine Sammlung ausgelegt und versioniert werden können. Auf diese Weise können Views Fraunhofer IAIS Dokumentation der Software IAIS Cortex 8

3 auf spezielle Möglichkeiten und Bedürfnisse detailliert angepasst werden. Programmiertechnisch aufwändiger sind die Transformatoren, die aus den Originalmetadaten Repräsentationen im Cortex-eigenen Format erzeugen, auf welchen im Nachhinein das Retrieval (Suche, Filtern) der Objekte und die Visualisierung der Semantik beruht und aus denen ggf. exportierbare Dritt-Formate erzeugt werden können. Als Sprachraum des genannten Zwischenformats, auf das bei der Transformation während des Dateningests alle Originalmetadaten normalisiert werden, wurde ein ISO- Standard gewählt: das CIDOC CRM, welches seit vielen Jahren in zahlreichen Projekten und unterschiedlichen Wissensdomänen erfolgreich eingesetzt wird. Das CRM beruht auf zwei sehr übersichtlichen Hierarchien von Entitäten und Properties. Dessen ungeachtet erlaubt das CRM ein hohes Maß an semantischer Präzision. Es eignet sich daher als Zwischenformat, dessen Verwendung die Anzahl der notwendigen Mappings dramatisch reduziert, wenn verschiedene Eingangsformate und mehrere Zielsprachen benötigt werden. Das CRM verwirklicht einen eleganten gedanklichen Ansatz, da es im Kern nicht Begriffszusammenhänge darstellt, sondern Zustandsänderungen beschreibbar macht. Es ist, verglichen mit anderen Modellen, äußerst kompakt, weil es auf den Versuch verzichtet, jeder Entität einen mehr oder weniger vollständigen Satz von möglichen Attributen zuzuordnen, die dann ihrerseits zu allen möglichen Entitäten in Beziehung stehen können. Statt dessen fokussiert das CRM auf Aussagen, die Retrieval-relevante Zusammenhänge konstruieren. Abbildung 1 zeigt, welche fundamentalen Zusammenhänge auf Grundlage eines Mappings auf CRM konstruiert und in der Folge abfragbar gemacht werden können. Abbildung 1: Beziehungen der CRM Kategorien 9 Dokumentation der Software IAIS Cortex Fraunhofer IAIS

4 Welche Aussagen tatsächlich im Modell abgebildet werden, hängt einerseits von den Daten ab, die providerseitig zur Verfügung stehen, andererseits von erfolgreich durchgeführten Mappings Facetten CRM lässt sich leicht in Form von RDF-Tripeln serialisieren. Um einen benutzerfreundlichen Zugang zu den Daten zu gewährleisten, wurde ein Ansatz gewählt, der die in CRM abgebildeten Transitionen im modellierten Graph auf einen künstlichen Namensraum projiziert, welcher aus einer Menge von Kategoriebegriffen wie Ort oder Zeit besteht. Dem Benutzer werden so intuitiv verständliche Such-Facetten zur Einschränkung der Treffermenge beim Retrieval angeboten. Die Entkoppelung von Originalmetadaten, CRM-Modellierung und Facettenerzeugung erlaubt es, die Facetten äußerst flexibel zu gestalten. So können beispielsweise unterschiedliche konkrete Pfade unter ein und demselben Namen zusammengefasst werden. Es ist konfigurierbar, ob rollenspezifische Personenfacetten (creator, publisher, contributor,...) ausgebildet oder alle involvierten Personen unter einer allgemeinen Personenfacette zusammengefasst werden sollen CRM anhand eines Beispiels Das Grundprinzip des CRM und das macht das CRM als Zwischensprache besonders interessant besteht darin, die einzelnen in den Originalmetadaten vorgefundenen verschiedenen Entitäten, die ein Objekt ausmachen (z. B. bei einem Buch: der Autor, der Publisher), über entsprechende Events zu vermitteln. Konkret bedeutet das, dass zwischen Autor und Buch ein CreationEvent steht. Die Events ergeben interessante Kandidaten für eine Deduplikation: zwei identische CreationEvents verweisen offensichtlich auf zwei identische Bücher. Auch wenn diese Bücher von verschiedenen Einrichtungen eingebracht werden und uneinheitlich erfasst wurden, besteht eine Chance, die Identität anhand der Events zu erkennen. Eine Konsequenz der Verwendung von Modellen wie dem CRM ist, dass die semantische Beschreibung der Objekte, die sich bei den Originalmetadaten mehr oder weniger stark an der Metapher des Bilbiothekskatalogs bzw. des Karteikastens orientiert, in eine graphbasierte Darstellung übertragen wird Mapping von Quell-Metadaten Cortex erlaubt das Mapping von beliebigen Ausgangsmetadatenformaten. Für einige der relevanten Metadatenformate liegen generische Beispiele vor, die von den Entwicklern des CRM veröffentlicht wurden. Die entworfenen Mappings für DC, EAD, LIDO und andere Metadatenformate orientieren sich an diesen Empfehlungen. Für die Übertragung der flachen Formate in den CRM-Graphen werden Sets von Feldern auf Cluster gemappt, wobei die Gesamtmenge der Cluster ein komplettes Mapping ergibt. Für diese Art der Übertragung gibt es die bereits erwähnten konzeptionellen Fraunhofer IAIS Dokumentation der Software IAIS Cortex 10

5 Vorlagen. Da das vollständige Mapping z. B. eines DC-Records auf CRM eine Anzahl Cluster dieser Art verlangt, müssen die verschiedenen in den einzelnen Clustern abgebildeten Entities von anderen Clustern des gleichen Objekts referenziert werden können. Dieses Binding-Problem wird aktuell mit in den XSL-Transformatoren automatisch generierten lokalen Identifiern gelöst. Lokale Identifier werden beim Ingest gegen persistente Identifier ausgetauscht. Die Mapping Library deckt u.a. Transformatoren für folgende Formate ab: DC EAD MARC21 LIDO METS/MODS Cortex-Objekte Ein nach Cortex ingestierbares Objekt muss, um später zugreifbar zu sein, lediglich einen Identifier besitzen. Ein solches Objekt muss dafür eine Herkunftskennung (Halter, Lieferant) und eine beliebige, providerseitig eindeutige Objekt-Kennung (z. B. Inventarnummer oder Signatur) haben. Um später über die Suchmaschine findbar zu sein, muss ein Objekt zudem über mindestens ein beliebiges belegtes deskriptives Metadatenfeld oder einen deskriptiven Text verfügen. Zusätzlich zu den genannten minimalen deskriptiven Informationen über ein Objekt kann Cortex weitere Informationen auswerten und nutzen. Hierzu zählen in erster Linie weitere (tiefere, reichere) deskriptive Metadaten, des Weiteren die oft als administrativ bezeichneten Metadaten (beispielsweise zu Rechten und Lizenzen), sowie strukturelle Informationen zu möglicherweise enthaltenen Binärdaten und binäre Daten selbst, also z. B. digitalisierte Surrogate von physischen Objekten wie Büchern, Skulpturen, Bildern usw., die entweder ebenfalls in die Plattform ingestiert werden können oder über Links zu entfernten Quellen im Web angebunden sind Die Cortex-Architektur Konzeptionelle Architektur Abbildung 2 zeigt einen Überblick der funktionalen Komponenten inklusive deren Schnittstellen und Kommunikationsverhalten. Kultureinrichtungen verwenden den ASC zur Aufbereitung der Eingangsdaten und zur Erzeugung der ingestierbaren Pakete (SIPs). Eine oder mehrere Instanzen des ASC schicken die fertigen SIPs parallel an den Ingest Multiplexer. Dieser sorgt für die weitgehend synchrone Auslieferung der SIPs an verschiedene Produktionslinien 11 Dokumentation der Software IAIS Cortex Fraunhofer IAIS

6 Systemadministrator (FIZ) Lokales System Lokales Objekt ASC User Frontend-Cluster SIP... Instance Frontend... Local Storage Multiplexer LoadBalancer ProductionLineN ProductionLine1 ProductionLineN ProductionLine1 LoadBalancer LoadBalancer Instance Instance Instance... Ingest... Server Instance Instance Instance... Acess Server... Ingest Sub-Service Service Access Sub-Service Legende Datenspeicher Template Object Storage Solr Modul Systemgrenze Daten User Aufruf-Beziehung Datenfluss Fraunhofer IAIS Dokumentation der Software IAIS Cortex 12 Abbildung 2: Konzeptionelle Architektur Cortex

7 des Core Service (Ingest-Cluster). Nachdem die lokalen Identifier durch persistente Identifier ersetzt worden sind, bezeichnen wir das SIP als AIP. Im Anschluss an die Prozessierung und Speicherung der AIPs (eindeutige referenzierbare SIPs mit Zusatzinformationen) kann über die Access-Cluster auf die ingestierten Daten zugegriffen werden Systemarchitektur Stark vereinfacht kann man sich ein produktives Cortex-System als Zusammenspiel von Subsystem-Typen vorstellen: dem ASC zur Aufbereitung der Metadaten der verschiedenen Provider. Der ASC setzt sich mit den Metadatenformaten auseinander und vereinheitlicht sie. Die Ergebnisse werden zusammen mit evtl. zugehörigen binären Derivaten in ein SIP geschrieben. Benutzer des Cortex-Systems haben keinen Zugriff auf den ASC, lediglich Systemadministratoren des Betreibers arbeiten damit. Der ASC ist im Wesentlichen ein Thread in einer JVM. Es werden nur wenige Annahmen über die Maschinen gemacht, auf denen er läuft und wo er läuft. Ausreichend Heapspace (in etwa 4 GB) ist die Hauptanforderung, die der ASC stellt. dem Produktionssystem (PS) zum Ingest der SIP und zur Lieferung der Daten an die Benutzer. Ein Produktionssystem besteht aus mehreren Servern, auf denen WEB-Container deployt sind (i. d. R. jetty), die ausschließlich über REST- Aufrufe angesprochen werden. Die Server können HTTP-Verbindungen zu den anderen Servern aufbauen. Jeder dieser Server läuft in einer eigenen JVM. Für das Verständnis des IM ist von allen Servern nur der Ingest Server wichtig. Er nimmt die letztlich vom ASC erzeugten SIPs entgegen, bearbeitet sie und leitet anschließend die Indexierung in SOLR und die Archivierung ein. I. d. R. ist der IngestServer in einem Produktionssystem repliziert und nicht direkt, sondern nur über einen Lastverteiler erreichbar. dem Frontend. Es bereitet die vom Produktionssystem gelieferten Daten im Browser des Benutzers auf. Das Frontend ist für das Verständnis des IM ohne Bedeutung. Von den zwei für den IM interessanten Subsystem-Typen (ASC und Produktionssystem) können in einer konkreten Konfiguration viele Exemplare vorhanden sein: Die Zahl der Exemplare des ASC kann stark variieren. Sie können jederzeit gestartet werden, Abbrüche haben keine Auswirkungen auf die Produktionssysteme. Ein Exemplar des ASC kann man sich als einen Thread vorstellen, der zu jedem Zeitpunkt genau einen Pre-)Ingest für genau einen Provider aufbereitet. Ist die Aufbereitung der Dateien eines Providers beendet, wird entweder der nächste aus einer Liste von Providern verwendet (die Liste wird als Startparameter mitgegeben) oder der ASC beendet sich. Die beiden (möglichen) Grenzfälle sind: 13 Dokumentation der Software IAIS Cortex Fraunhofer IAIS

8 ein ASC erhält die Liste aller zu bearbeitenden Provider und arbeitet einen nach dem anderen ab. für jeden Provider wird genau ein ASC gestartet, der nur die Metadaten- Dateien dieses Providers bearbeitet und sich dann beendet. Der ASC nimmt also die (Original-)Metadaten eines Providers und produziert daraus SIPs. Dies wird gelegentlich auch Ingest genannt, ein genauerer Name ist aber Pre-Ingest. Die Zahl der Instanzen der Produktionssysteme ist fest konfiguriert. Ein Produktionssystem stellt hohe Anforderungen an die Server-Maschinen, enthält sehr große Dateisysteme mit Index- und Archiv-Dateien erfordert eine hochperformante Anbindung an das Internet. Mehrere Exemplare werden nur deshalb vorgehalten, um Ausfallsicherheit zu erreichen und die Last der Benutzeranfragen gut zu verteilen. Zwei oder drei Produktionssysteme sind typisch. Jedes Produktionssystem erhält die vom ASC produzierten Daten, um sie aufzubereiten und abzulegen. Dieser Vorgang wird als (der eigentliche) Ingest bezeichnet. Der IngestMultiplexer (IM) ist ein weiterer (und der letzte) Subsystem-Typ. Er ist ein Vermittler zwischen den beiden Subsystem-Typen ASC und Produktionssystem. Er hat zwei Hauptaufgaben: Er nimmt die von den (vielen) ASCs generierten SIPs entgegen und archiviert sie (Er archiviert SIPs! Die Produktionssysteme archivieren die aus den SIP gewonnenen AIP unabhängig vom IM ein weiteres Mal). Dieses SIP-Archiv gibt Auskunft über die gesamte Ingest-Geschichte des Systems. Von diesem SIP- Archiv aus kann der gesamte Datenbestand der Produktionssysteme vollständig rekonstruiert werden. Der IM kann in sein Archiv nur neue SIPs aufnehmen. Er wird niemals SIPs löschen, d.h. sein Archiv wächst ständig an. Es ist prinzipiell möglich, Teile dieses Archiv auf backup-medien auszulagern. er verteilt die erhaltenen SIP an die Produktionssysteme weiter. Er hält den Stand der Versorgung für jedes Produktionssystem nach. Da i.d.r. viele SIP aus vielen Pre-Ingests zugleich zur Verteilung vorliegen, lässt sich die Zahl der parallel an die Produktionssysteme gelieferten SIPs im IM konfigurieren. Strategien, welche SIPs gesendet werden, lassen sich im Prinzip über Scheduling-Strategien festlegen (z.b. round robin: von jedem Pre-Ingest ein SIP, dann vom nächsten Pre-Ingest; smalltolarge: erst die kleinen Datenmengen, dann die großen). Zur Zeit ist nur die Strategie first-come,first-served realisiert. Ein Administrator kann auf die Auswahl der SIP und die Versorgung der Produktionssysteme mit SIPs Einfluss nehmen. Es gibt - im Gegensatz zu ASC und Produktionssystem - nur einen IM. Für den Ingest wird folgender Workflow angenommen: Es gibt eine größere Zahl von Providern. Fraunhofer IAIS Dokumentation der Software IAIS Cortex 14

9 Jeder Provider hat einen oder mehrere Datensätze, die er in Cortex einbringen will (das können z.b. verschiedene Sammlungen, verschiedene Epochen oder verschiedene Themenbereiche sein). Dies sind die Ingests des Providers. Die Festlegung, wie viele Ingests mit welchen Metadaten durchgeführt werden sollen, ist die Entscheidung des Providers. Ein Ingest besteht also aus einer Menge von Metadatensätzen. Diese Daten werden sich über die Zeit ändern, teils weil sie korrigiert oder erweitert werden, evtl. kommen auch neue Metadatensätze zum Ingest hinzu (Ankauf neuer Objekte etc.). Ein Provider kann sich daher entscheiden, einen Ingest erneut durchzuführen. Das haben wir eine neue Revision genannt. Die alten Daten werden im Produktionssystem durch die neuen ersetzt (die genaue Definition von Ersetzen ist für den IM unwesentlich). Im Gegensatz dazu sind im Archiv des IM sowohl die alten Daten (die alte Revision) als auch die neuen Daten (die neue Revision) zu finden. Um Konfusion zu vermeiden, kann eine neue Revision nur dann begonnen werden, wenn die vorherige Revision (des gleichen Ingests) für alle Produktionssysteme komplett abgeschlossen ist Schichtenmodell Abbildung 3 zeigt einen Überblick der Schichtenarchitektur, welche Cortex zugrunde liegt. Es handelt sich um eine klassische 3-Schichten-Architektur bestehend aus Präsentationsschicht, (Geschäfts-)Logik-Schicht und Persistenzschicht, wobei Cortex keine Implementation der Präsentationsschicht realisiert. Während die konzeptionelle Architektur einen Querschnitt des Systems über alle funktionalen Komponenten beschreibt und Systemgrenzen aufzeigt, illustriert dieser Abschnitt den logischen Aufbau des Digital Library Cores. In Richtung Präsentationsschicht bietet Cortex eine REST- API an, welche neben der Suche (nach Volltexten und Facetten) auch den Access auf verschiedene Repräsentationen von Objekten realisiert. Mögliche Repräsentationen sind (X)HTML (Preview), JSON (Suchergebnisse), XML (Views) oder Streams (Binärdaten, z. B. Videos oder MP3s). Die Logikschicht implementiert drei Geschäftsprozesse: Access, Search und Ingest. Während Access und Search überwiegend Anfragen der Präsentationsschicht geeignet transformiert an die Persistenzschicht (Index, Archiv) weiterleiten, bietet der Geschäftsprozess Ingest die Möglichkeit, verschiedenste heterogene Datensätze in die Plattform einzuspielen. Sowohl Access, Search als auch Ingest kommunizieren via REST-Services mit der Persistenzschicht. Über die Services ist der Zugriff auf den Index (Solr) und das Archiv (Filesystem) gekapselt. Die lose Kopplung über das REST-API erlaubt eine leichte Einbindung von Speicheralternativen (Cloud), Datenbanken oder weiteren Index-Lösungen. Index und Archiv werden in den folgenden Abschnitten genauer beschrieben. 15 Dokumentation der Software IAIS Cortex Fraunhofer IAIS

10 Abbildung 3: Schichtenmodell Cortex Index Als Index wird Solr verwendet. Im Zuge des Ingests werden Facettenwerte und Volltextfelder für jedes Objekt im Index gespeichert und somit durchsuchbar gemacht. Die Schnittstelle und Verwendung von Solr ist im IndexServer implementiert. Relevante Projekte sind RP_IndexServer, RP_IndexImpl und RP_IndexInterface (siehe A.6). Archiv Die Dokumentenablage ist eine Aufgabe des Archival Storage. Dokument ist hier im allgemeinsten Sinn das im SIP enthaltene XML inklusive aller Contentund Context-Information. Aus Gründen der besseren Performanz ist es sinnvoll, die AIPs redundant so zu speichern, dass die gespeicherten Einheiten den Abfragen entsprechen. Momentan wird ein AIP als Verzeichnis abgelegt, das über den Identifier des Informationsobjekts anzusprechen ist und die Metadaten, RDF Daten, Views und Binaries als Dateien enthält. Die REST-Pfade werden auf diese Ressourcen gemappt. Die Implementierung des Archivs ist im ArchiveServer umgesetzt. Relevante Projekte sind RP_ArchiveServer, RP_ArchiveImpl und RP_ArchiveInterface sowie RP_DirectArchiveImpl (siehe A.5). Fraunhofer IAIS Dokumentation der Software IAIS Cortex 16