Ingest

Das Package ingest beinhaltet Schritte für den Ingestprozess.

Ingest: benutzerdefiniertes Premis-Ereignis zu SIP hinzufügen

Diese Action fügt ein oder mehrere PREMIS Events zum SIP hinzu. Mit dem Parameter nodeType kann angegeben werden, zu welchen Nodes im SIP die Events hinzugefügt werden. Folgende Werte stehen zur Auswahl: all (alle Nodes im SIP), root (Root Folder oder Root File), file (Alle File-Nodes im SIP, inkl. Root-File), folder (alle Folder-Nodes im SIP, inkl. Root-Folder). Mit den übrigen Parameter können die Details des Events definiert werden.

java ch.docuteam.actions.ingest.AddCustomPremisEvent \
     --sip=[/path/to/]SIP \
     --nodeType=nodeType \
     --eventType=eventType \
     --eventDetail=eventDetail \
     --eventOutcome=eventOutcome \
     [--eventOutcomeDetail=eventOutcomeDetail] \

Parameter	Beschreibung
--sip=[path/to/]SIP	Name des SIPs; wenn kein Pfad angegeben wird, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
--nodeType=nodeType	Definiert den Typ von Node zu welchem die Ereignisse hinzugefügt werden.
--eventType=eventType	PREMIS-Event Typ (frei wählbar).
--eventDetail=eventDetail	PREMIS-Event Detail (frei wählbar).
--eventOutcome=eventOutcome	PREMIS-Event Ergebnis (entweder Success oder Failure).
[--eventOutcomeDetail=eventOutcomeDetail]	PREMIS-Event Ergebnis Detail (optional, frei wählbar).

Ingest: DNB URN zum Root-Node des SIPs hinzufügen

Diese Action nutzt den URN-Vorschlagsdienst der Deutschen Nationalbibliothek (DNB), um eine URN im ausgewählten Namespace zu erzeugen und als Metadatenelement (Accessor URN) des Root-Nodes zu speichern. Wenn bereits eine URN in den Metadaten vorhanden ist, wird keine neue URN generiert. Optional kann die URN-ID (ein Teilstring der URN ohne Präfixe) in einem zusätzlichen Element gespeichert werden, indem der Parameter urnIdAccessor ausgefüllt wird. Wenn dieses Feld bereits einen Wert enthält, wird keine URN-ID geschrieben. Mit dem optionalen Parameter onlyWriteUrnIdInAccessor kann auf das Speichern der URN verzichtet werden, damit nur die URN-ID geschrieben wird.

java ch.docuteam.actions.ingest.AddDnbUrnToRootNode \
     --sip=[/path/to/]SIP \
     --urnNamespace=urnNamespace \
     [--urnIdAccessor=urnIdAccessor] \
     [--onlyWriteUrnIdInAccessor=false] \

Parameter	Beschreibung
--sip=[path/to/]SIP	Name des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
--urnNamespace=urnNamespace	Namespace für den eine URN generiert wird.
[--urnIdAccessor=urnIdAccessor]	EAD-Accessor, der definiert, welches EAD-Feld des Root-Nodes zum Speichern der URN-ID (URN ohne Präfixe) verwendet wird. Wenn dieses Feld leer bleibt, wird keine URN-ID geschrieben.
[--onlyWriteUrnIdInAccessor=false] ]	true / false, Angabe, ob nur die URN-ID geschrieben werden soll (Default false).

Ingest: BAR-SIP konvertieren

Konvertiert ein SIP in ein SIP, welches dem Matterhorn Profil entspricht.

java ch.docuteam.actions.ingest.BARSIPConverter \
     [path/to/]SIP [targetFolder]

Parameter	Beschreibung
[path/to/]SIP	Name des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
[targetFolder]	Verzeichnis, in das das erstellte SIP verschoben werden soll; wird dieses Feld leer gelassen, wird das SIP in den von actions.workbench.work definierten Speicherort verschoben

Ingest: SIP aus eCH-0160 SIP erstellen

Erstellt ein auf dem Matterhorn Profil basierendes SIP aus einem eCH-0160 SIP.

java ch.docuteam.actions.ingest.CreateSIPFromECH0160SIP \
     --sip=[path/to/]SIP \
     --levelsFilePath=/path/to/levels.xml \
     --[mappingFile=[path/to/]mappingFile] \
     --[output-folder=/path/to/folder]

Parameter	Beschreibung
--sip=[path/to/]SIP	Speicherort der zu konvertierenden SIP-Datei; der Standardordner ist actions.workbench.inbox
--levelsFilePath=/path/to/levels.xml	Pfad zur Datei levels.xml
--[mappingFile=[path/to/]mappingFile]	Datei, aus der das Mapping gelesen werden soll. Default: es wird eine Standard-Mappingdatei verwendet (definiert durch das Mapping Modul)
--[output-folder=/path/to/folder]	Gibt den Ausgabeordner an; Default: actions.workbench.work

Ingest: Workbench Space überprüfen

Prüft, ob genügend Platz für die Verarbeitung des SIPs (d.h. für Arbeitskopien) vorhanden ist.

java ch.docuteam.actions.ingest.CheckWorkbenchSpace \
     [path/to/]SIP [numberOfCopies]

Parameter	Beschreibung
[path/to/]SIP	Name des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
[numberOfCopies]	optional, Anzahl der SIP-Kopien, die für die Berechnung verwendet werden; Default: 3

Ingest: Arbeitskopien bereinigen

Löscht vorhandene SIPs in actions.workbench.work. Optional können auch gleichnamige SIPs in actions.workbench.preparation gelöscht werden.

java ch.docuteam.actions.ingest.Cleanup \
     [path/to/]SIP [prep]

Parameter	Beschreibung
[path/to/]SIP	Name des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
[prep]	falls true, SIPs desselben Namens in actions.workbench.preparation werden auch entfernt; Default: false

Ingest: EAD Datei erstellen

Erstellt aus einzelnen Knotenpunkten von einem gegebenen SIP EAD-Datenblöcke.

java ch.docuteam.actions.ingest.CreateEADFile \
     [path/to/]SIP [targetFilename]

Parameter	Beschreibung
[path/to/]SIP	Name des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
[targetFilename]	optional, Name der Output Datei. Default: EAD.xml im Unterordner des SIPs im von actions.workbench.output definierten Speicherort.

Ingest: extent-Rechner

Setzt die Anzahl Dateien in das Metadatenfeld Umfang und die Einheit auf den Default-Wert Datei(en).

java ch.docuteam.actions.ingest.ExtentCalculator \
     [path/to/]SIP

Parameter	Beschreibung
[path/to/]SIP	Name des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet

Ingest: Dateien migrieren

Vergleicht die Dateien eines SIP mit den Angaben in der Konfigurationsdatei migration-config.xml und konvertiert die Dateien gemäss den dort angegebenen Konvertierungsrichtlinien.

java ch.docuteam.actions.ingest.SIPFileMigrator \
     [path/to/]SIP keepOriginals [path/to/migration-config.xml]

Parameter	Beschreibung
[path/to/]SIP	Name des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
keepOriginals	true/false, gibt an, ob die Originaldateien nach der Migration erhalten bleiben sollen.
[path/to/migration-config.xml]	optional, Pfad zu einer spezifischen Migrationskonfigurationdatei (Default: ./config/migration-config.xml)
[skipAlreadyMigratedFiles]	optional, true/false, gibt an, ob bereits zuvor migrierte Dateien erneut migriert werden sollen; Default: true, d. h. Dateien, die bereits zuvor migriert wurden, werden nicht erneut migriert

Ingest: SIP aus der Inbox entfernen

Verschiebt ein vorhandenes SIP aus actions.workbench.inbox in einen vorgegebenen Ordner oder löscht es, sofern kein Zielordner angegeben ist.

java ch.docuteam.actions.ingest.SIPRemoveFromInbox \
     [path/to/]SIP [targetFolder]

Parameter	Beschreibung
[path/to/]SIP	Pfad des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
[targetFolder]	Verzeichnis, in das das SIP verschoben werden soll; wird dieses Feld leer gelassen, wird das SIP gelöscht.

Ingest: Datei ersetzen

Ersetzt eine Datei in einem SIP. Dabei werden die Metadaten beibehalten oder ergänzt. Zurzeit können mit diesem Schritt nur SIPs verarbeitet werden, die eine einzelne Datei enthalten.

java ch.docuteam.actions.ingest.ReplaceFile \
     [path/to/]SIP [targetFolder]

Parameter	Beschreibung
[path/to/]SIP	Pfad des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
[targetFolder]	Pfad zu der Datei, die als Ersatz für den aktuellen SIP-Inhalt verwendet werden soll

Ingest: MARC aus REST abrufen und zu SIP hinzufügen

Für jedes Objekt (Dateien als auch Ordner) eines SIPs wird eine MARC-Beschreibung geholt und als beschreibende Metadaten hinzufgefügt.

Die URL des webservices ist in den actions.properties als aleph.webservice.url zu konfigurieren. Die URL sollte einen Platzhalter \{ documentNumber\} enthalten, der durch die effektive Dokument-Nummer ersetzt wird. Letztere wird für jedes Objekt anhand des Dateinamens ermittelt:

• Für einen Dateinamen BAU_5_000000444.wav wird die Dokument-Nummer 000000444 extrahiert
• Für einen Ordnernamen DIRECTORY_X_000000555 wird die Dokument-Nummer 000000555 extrahiert

Wenn der HTTP-Request fehlschlägt oder ein Dateiname ungültig ist bricht die Aktion ab und das SIP wird nicht geändert. Bestehende MARC-Metadaten werden mit dieser Aktion überschrieben.

java ch.docuteam.actions.oai_dc.AddOAIDCFromRESTByIDFromFilename \
     --sip=[path/to/]SIP

Parameter	Beschreibung
--sip=[path/to/]SIP	Pfad des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet

Ingest: OAIDC aus REST anhand der ID aus dem Dateinamen hinzufügen

Für das Wurzel-Objekt eines SIPs wird ein webservice für die OAI_DC-Beschreibung abgefragt und als beschriebene Metadaten hinzugefügt.

Die URL des webservices ist in den actions.properties als oai.webservice.url zu konfigurieren. Die URL sollte einen Platzhalter \{ identifier\} enthalten, der anhand des Knotennamens gemäss folgendem Muster ersetzt wird:

• “Kürzel-SignaturTIFF” z.B. “bbb-0027TIFF” wird zum \{ identifier\} "bbb/0027".

Wenn der Name ungültig ist oder der HTTP-Request fehlschlägt bricht die Aktion ab und das SIP wird nicht geändert. Bestehende OAI_DC-Metadaten werden mit dieser Aktion nicht überschrieben sondern führen ebenfalls zum Abbruch der Aktion.

Die OAI_DC-Informationen werde zusätzlich nach -Elemente geprüft, die auf XML-Dateien verweisen. Werden solche gefunden, speichert die Aktion diese Dateien (bei mehreren Varianten die deutschsprachige) im aktuellen Paket in einen Unterordner mit der Bezeichnung "TEI-Handschriftenbeschreibungen".

java ch.docuteam.actions.oai_dc.AddOAIDCFromRESTByIDFromFilename \
     --sip=[path/to/]SIP

Parameter	Beschreibung
--sip=[path/to/]SIP	Pfad des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet

Ingest: EDIDOC/EDIAKT-Paket in Matterhorn METS SIP konvertieren

Erstellt ein auf dem Matterhorn METS Profil basierendes SIP aus einem EDIDOC-/EDIAKT-Paket.

java ch.docuteam.actions.ingest.CreateSIPFromEdidocSIP \
     --sip=[path/to/]SIP \
     --levelsFilePath=path/to/levels.xml \
     [--mappingFile=path/to/mappingFile] \
     [--outputFolder=/path/to/folder] \
     [--steuerXml=/path/to/file]

Parameter	Beschreibung
--sip=[path/to/]SIP	Pfad des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
--levelsFilePath=path/to/levels.xml	Pfad zur Konfigurationsdatei der Verzeichnisstufen. Findet sich im classpath
[--mappingFile=path/to/mappingFile]	Datei, aus der das Mapping gelesen werden soll; Default: ./config/edidoc-mapping.xml, zu finden im classpath
[--outputFolder=/path/to/folder]	gibt den Outputordner an; Defaults: actions.workbench.work
[--steuerXml=/path/to/file]	Pfad zur EDIDOC-Archiv-Erweiterungs-XML-Datei

Ingest: MARCXML-Datei in Alma importieren oder aus Alma herunterladen

Importiert eine MARCXML-Datei nach Alma über dessen REST API. Die MARCXML-Datei muss Teil des SIPs sein. Nach erfolgreichem Import wird die MARCXML-Datei mit der Antwort von Alma aktualisiert. Wenn die Datei im SIP nicht vorhanden ist, schlägt die Aktion entweder fehl oder (wenn das optionale downloadIfMissing-Flag gesetzt ist) wird die MARCXML-Datei über die Alma-API heruntergeladen (vorausgesetzt, ihre MMS-ID ist im Root-Knotenelement gespeichert, das durch den Parameter writeMmsIdRoot definiert ist). Optional kann die MMS-ID der importierten/heruntergeladenen MARCXML-Datei auch in die EAD-Metadaten des Root-Ordners (writeMmsIdRoot) und/oder des MARCXML-Dateiknotens (writeMmsId) geschrieben werden.

Die Verbindungsinformationen für die Alma REST API sind im actions.properties zu hinterlegen.

java ch.docuteam.actions.ingest.alma.ImportOrDownloadMarcXmlIntoAlma \
     --sip=[/path/to/]SIP \
     --marcxml=path/to/marc.xml \
     [--writeMmsId] \
     [--writeMmsIdRoot] \
     [--downloadIfMissing=false] \
     [--checkMatch=false] \
     [--fromCzMmsId] \
     [--fromNzMmsId] \
     [--importProfile] \
     [--normalization] \
     [--overrideWarning=true] \
     [--validate=false]

Parameter	Beschreibung
--sip=[path/to/]SIP	Pfad des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
--marcxml=path/to/marc.xml	MARCXML-Metadaten Dateipfad (relative zum Root-Node des SIPs)
[--writeMmsId=refCode]	EAD-Accessor, der das Metadatenelement des MARCXML-Dateiknotens definiert, in das die MMS-ID nach dem Import geschrieben wird. Wenn leer, wird keine MMS-ID für den Dateiknoten geschrieben.
[--writeMmsIdRoot=refCode]	EAD-Accessor, das das Metadatenelement des Root-Nodes definiert, in das die MMS-ID nach dem Import geschrieben wird. Wenn dieses Feld leer ist, wird keine MMS-ID für den Root-Node geschrieben.
[--downloadIfMissing=false]	Gibt an, ob eine MARCXML-Datei (basierend auf der MMS-ID, die im Element gespeichert ist, das durch den writeMmsIdRoot-Accessor definiert ist) von Alma heruntergeladen werden soll, wenn der Pfad der MARCXML-Metadatendatei nicht auf eine Datei verweist. Default: false.
[--checkMatch=false]	Gibt an, ob nach einem Match gesucht werden soll. Default: false (Datensatz wird trotz möglichem Match gespeichert)
[--fromCzMmsId]	Die MMS-ID des Community-Zone-Records. Bei der Erstellung eines regulären lokalen Records leer lassen.
[--importProfile]	Die ID des Importprofils, das bei der Verarbeitung des Input-Records verwendet werden soll. Beachten Sie, dass die API je nach Profilkonfiguration in einigen Fällen einen vorhandenen Record aktualisieren kann.
[--normalization]	Die ID des zu verwendenden Normalisierungsprofils
[--overrideWarning=true]	Gibt an, ob Warnungen ignoriert werden sollen. Default: true (Datensatz wird gespeichert und die Warnungen werden zur API-Ausgabe hinzugefügt)
[--validate=false]	Angabe, ob die MARC-XML-Datei validiert werden soll. Default: false.

Ingest: Umbenennen des Root-Nodes basierend auf EAD-Metadaten

Benennt den Datei- oder Ordnernamen des Root-Nodes im SIP um, basierend auf EAD-Metadaten des Root-Nodes. Sonderzeichen werden normalisiert. Existiert das angegebene Metadatenelement mehr als einmal, wird die erste Instanz verwendet.

java ch.docuteam.actions.ingest.RenameRootNodeFromEad \
     --sip=[/path/to/]SIP \
     --accessorName=accessorName \

Parameter	Beschreibung
--sip=[path/to/]SIP	Pfad des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
--accessorName=accessorName	EAD-Accessor, der definiert, welches EAD-Feld des Root-Nodes als Quelle für den neuen Datei- oder Ordnernamen verwendet wird

Ingest: XML-Datei in SIP mit xslt aktualisieren

Mit dieser Funktion kann eine XML-Datei, die sich im SIP befindet, mit einer anzugebenden XSL-Transformation aktualisiert werden. Die Funktion definiert einen xsl:parameter mit dem Namen pathToMets, der den Pfad zur mets.xml-Datei enthält, damit diese in der xsl-Transformation ausgelesen werden kann.

java ch.docuteam.actions.ingest.ModifyFileWithXSL \
     --sip=[/path/to/]SIP \
     --xml=path/to/file.xml \
     --xsl=path/to/transformation.xsl

Parameter	Beschreibung
--sip=[path/to/]SIP	Pfad des SIPs; wenn kein Pfad angegeben ist, wird erwartet, dass es sich am von actions.workbench.work definierten Speicherort befindet
--xml=path/to/file.xml	Pfad zur XML-Datei innerhalb des zu transformierenden SIPs (relativ zum Stammknoten des SIP). Der Pfad akzeptiert einen Platzhalter (*) anstelle des Root-Ordners.
--xsl=path/to/transformation.xsl	Pfad zum XSL-Skript, das für die Transformation verwendet werden soll (bei relativen Pfaden wird davon ausgegangen, dass sich XSL in $ACTIONS_HOME/xslt befindet)

Ingest: Dokumente aus dem RIS (Rechtsinformationssystem) laden und daraus SIPs erstellen

Mit dieser Action können Dokumente aus dem RIS heruntergeladen und entsprechend SIPs inklusive zugehörigem mets.xml erstellt werden. Welche möglichen Werte es für den Request an das RIS gibt, ist hier zu finden. Pro Eintrag im RIS wird ein separates SIP erstellt und ebenfalls ein Feeder Event getriggert, auf das weiter reagiert werden kann.

java ch.docuteam.actions.ingest.ris.RISExporter \
     --endpoint=[Landesrecht/Bezirke/Gemeinden/Bundesrecht] \
     --requestPath=[path/to/request/file].json \
     --exportPath=[path/where/the/sips/get/exported/to] \
     --levelsPath=[path/to/the/levels/file] \
     --mappingPath=[path/to/the/mapping/file/of/the/metadata].json \
     [--enabledExtensions=[enabled extensions of files to download]] \
     [--copiesCount=[number of physical copies of the currently requested RIS entries]] \
     [--copiesEnumeration=[sets the numeration for each copy including the main entry. Default is alphabetically (possible values: alphabetic, numeric)]] \
     [--enabledContentTypes=[enabled content types which are allowed for the SIP (separated by commas)]] \
     [--saTemplate=[string that is used to reference a submission agreement (template sa)]] \
     [--dssId=[string that is used to reference a data submission session within the submission agreement]]

Parameter	Beschreibung	Erforderlich (nicht optional)
--endpoint	Implementierte Endpoints. Mögliche Werte sind derzeit: - Landesrecht - Bezirke - Gemeinden - Bundesrecht	X
--requestPath	Pfad zur benötigten Request-Datei. Welche Werte pro Endpoint nötig sind, sind der RIS API Dokumentation (v2.6) zu entnehmen. Die Datei muss als JSON-Datei abgespeichert werden.	X
--exportPath	Pfad an dem die exportierten SIP's erstellt werden sollen. Pro Eintrag im RIS wird ein separates SIP erstellt.	X
--levelsPath	Pfad zur Levels-Datei, die für den Export verwendet werden soll.	X
--mappingPath	Pfad zur Mapping-Datei, die für das Mapping der Response auf das mets.xml verwendet werden soll. Eine genauere Beschreibung zu dieser Datei befindet sich unter dieser Tabelle.	X
--enabledExtensions	Gibt an, welche Dateien aus dem RIS heruntergeladen werden sollen (getrennt durch Kommata). Hierbei wird rein auf die Dateiendung geachtet. Der Default sind: - pdfsig - xml - pdf Derzeit mögliche Werte sind folgende: - pdfsig - xml - pdf - html - png - jpg - rtf
--copiesCount	Gibt die Anzahl an physischen Dateien pro exportiertem RIS-Dokument an. Hier wird lediglich eine Nummer angegeben und dann die komplette Ordner-Struktur X-fach zusätzlich in jedem SIP hinzugefügt. Gibt man hier beispielsweise 2 an, werden auf der Ebene des Ordners für die digitale Archivalie zwei weitere Ordnerstrukturen angelegt.
--copiesEnumeration	Gibt an mit welchem Wert die Fassungen durchnummeriert werden sollen. Mögliche Werte sind alphabetic (default) und numeric.
--enabledContentTypes	Gibt an welche Art von Dateien aus dem RIS heruntergeladen werden sollen. Der Default sind: - MainDocument - Attachment Derzeit mögliche Werte sind folgende: - MainDocument - Attachment - EmbeddedAttachment - Letter - Material
--saTemplate	Text für Submission Agreement. Default ist derzeit: - sa_all-formats-01
--dssId	Text für die Referenz zum Submission Agreement. Default ist derzeit: - dss-01

Mapping von RIS Metadaten

Um die Metadaten der Response von RIS in das mets.xml zu mappen, wird eine entsprechende Mapping-Datei benötigt, die man mit dem Paramter --mappingPath angeben kann.
Das JSON setzt sich aus folgenden Blöcken zusammen:

{
  "levels": {
    "konvolut": "Konvolut",
    "fassung": "Fassung",
    "einzelstueck": "Einzelstück",
    "datei": "Datei",
    "dokumentationsdateien": "Dokumentationsdateien"
  },
  "fields": [
    {
      "matterhorn": "refCode",
      "type": "Applikation",
      "path": "Lgblnummer"
    },
    ...
  ]
}

Das Objekt levels muss diesen Aufbau haben und beschreibt die levels (die mit den Levels aus dem levels.xml übereinstimmen müssen). Darunter findet man die Liste fields, welche jeweils ein Feld der Metadaten ins mets.xml hinzufügt.

Folgende Werte sind als Parameter derzeit möglich:

Parameter	Beschreibung
matterhorn	Das benötigte Matterhorn-Metadaten Feld, das befüllt werden soll
type	Die Response ist derzeit in drei Objekte aufgeteilt: Metadaten Beinhaltet alle allgemeinen Metadaten, die nicht Endpoint oder Applikations-spezifisch sind. Beispielsweise technische ID's. Endpoint Beinhaltet Metadaten die global für den Endpoint (beispielsweise "Landesrecht") spezifisch sind. Applikation Beinhaltet alle Metadaten die spezifisch für die Applikation sind (beispielsweise LgblAuth-spezifische Daten) Format Dies sind "spezielle" selbst definierte Daten, die zwar die Metadaten beinhalten können, aber nicht müssen. Eine genauere Beschreibung der Optionen wenn man den Type "Format" verwendet, ist weiter unten zu finden
path	Der Pfad innerhalb des Type-Objekts innerhalb der Response
multiple	Falls der gewünschte Wert eine Liste ist, kann mit diesem Parameter auch eine Liste von Strings abgefragt bzw. entsprechend Metadaten dazu erstellt werden
values	Wenn mehrere Werte innerhalb eines Feldes gewünscht sind oder sich das Metadaten-Feld aus mehreren Teilen zusammenstellt, kann das Feld values benutzt werden. Dieses ist ebenfalls eine Liste aus den hier genannten Feldern.
valueSeparator	(Nur wenn values verwendet wird) Sollten die Werte mit einem bestimmten Text getrennt werden, kann dieser Wert hier angegeben werden.
format	(Nur bei type = "Format") Kann verwendet werden, um funktionale Parameter oder einen fixen Text in ein Metadaten-Feld zu schreiben. Eine Liste der funktionalen Parameter ist weiter unten zu finden.
multipleValues	(Kann ohne einen type verwendet werden) Kann dafür verwendet werden, um mehrere Einträge eines Metadaten-Feldes mit unterschiedlichen Werten zu generieren. (Mögliche Werte sind true oder false)
fassungen	Dient dazu, das Metadaten-Feld nur für bestimmte Fassungen zu befüllen. (Eine Liste von Nummern muss angegeben werden Beispiel: Fassung A und C sollen das Feld erhalten, dann auf [1,3] setzen.)
keyValue	Dient dazu, Werte nur dann anzugeben, wenn sie auch vorhanden sind. Wenn beispielsweise ein fixer Text nur dann vor ein Metadaten-Feld geschrieben werden soll, wenn es ausgefüllt ist, kann man hier den Text angeben, der davor stehen soll.
regexReplacements	Wird als Liste angegeben und kann dazu verwendet werden, Text innerhalb eines Metadaten-Feldes zu verändern. Beispielsweise könnte die Abkürzung LReg zu Landesregierung abgeändert werden. Ein Beispiel wie eine solche Liste aussehen könnte, ist weiter unten zu finden.

Welche Werte man für den path setzen kann, muss man der Dokumentation von RIS entnehmen.

Format Type

Mit dem Type Format kann man spezifische und selbst definierte Werte in Metadaten-Felder schreiben. Hierfür kann man sowohl einfache Texte in das format-Property des Feldes in der Mapping-Datei schreiben als auch funktionale Parameter. Eine Kombination ist hierbei auch möglich. Mögliche Felder könnten beispielsweise so aussehen:

[
  {
    "matterhorn": "reproductions",
    "type": "Format",
    "format": "Auslieferungsinformationspaket als Zugangsrepräsentation"
  },
  {
    "matterhorn": "processInfoDate",
    "type": "Format",
    "format": "$DATE"
  },
  {
    "matterhorn": "extent",
    "type": "Format",
    "format": "$COUNT_DOCUMENTS Dokumente (Dateien)"
  }
]

Funktionale Parameter

Parameter	Beschreibung
$DATE_TIME	Wird ersetzt durch heutiges Datum und jetzige Uhrzeit
$DATE	Wird ersetzt durch heutiges Datum
$TIME	Wird ersetzt durch jetzige Uhrzeit
$COUNT_DOCUMENTS	Wird ersetzt durch die Anzahl vorhandener Dokumente in diesem SIP
$FASSUNG	Wird ersetzt durch die derzeitige Fassung, für die gerade Metadaten befüllt werden
$EINZELSTUECK_TYPE_SHORT	Wird ersetzt mit H (für Hauptdokument) oder mit AX (für Anlage X)
$EINZELSTUECK_TYPE	Wird ersetzt mit Hauptdokument oder mit Anlage X
$NUMERATE	Setzt die nächste Nummer und erhöht den Counter um 1.

Beispiel für RegexReplacement Parameter

Ein mögliches Feld mit Regex-Anpassungen könnte folgendermassen aussehen:

{
  "matterhorn": "origination",
  "type": "Metadaten",
  "path": "Technisch.Organ",
  "regexReplacements": [
    {
      "regex": "LReg",
      "value": "Landesregierung"
    },
    {
      "regex": "LTag",
      "value": "Landtag"
    }
  ]
}

In diesem Fall werden LReg zu Landesregierung und LTag zu Landtag umgewandelt.

Ingest: Signaturen von PDF-Dateien mit RTR-Schnittstelle validieren

Mit dieser Action können PDF-Dateien innerhalb eines SIPs nach Signatur geprüft werden. Es werden allerdings nur PDF-Dokumente überprüft, bei denen auch eine Signatur vorhanden ist. Derzeit sind nur Validierungen mit SIPs, die in der RIS-Action erstellt wurden, möglich.

java ch.docuteam.actions.ingest.rtr.RTRVerification \
     --sipFolderPath=[path/to/the/sip/file] \
     --levelsPath=[path/to/the/levels/file] \
     --mappingPath=[path/to/the/mapping/file/of/the/metadata].json \
     [--scanAll=[true/false]] \
     [--scanFolder=[path/to/the/folder/that/includes/PDFs]] \
     [--saveReports=[true/false]] \
     [--saveReportsInStructure=[true/false]] \
     [--quitOnFailure=[true/false]] \

Parameter	Beschreibung	Erforderlich (nicht optional)
--sipFolderPath	Pfad zu dem gezippten SIP-Paket
--levelsPath	Pfad zur Levels-Datei
--mappingPath	Pfad zur Mapping-Datei, die für das Mapping der Response auf das mets.xml verwendet werden soll. Eine genauere Beschreibung zu dieser Datei findet man unter dieser Tabelle
--scanAll	Gibt an, ob nur Dokumente auf erster Ebene oder Dokumente in der gesamten Struktur validiert werden sollen
--scanFolder	Pfad eines bestimmten Ordners in einem Paket, auf den geprüft werden soll. Prüft alle PDF-Dokumente mit Signatur innerhalb dieses Ordners
--saveReports	Gibt an, ob der Prüfbericht als PDF auf oberster Ebene innerhalb des SIP-Pakets gespeichert werden soll
--saveReportsInStructure	Gibt an, ob die Prüfberichte innerhalb der Struktur (jeweils bei dem zu prüfenden Dokument) gespeichert werden sollen
--quitOnFailure	Gibt an, ob die Action einen Fehler werfen soll, wenn die Signatur als abgelaufen oder fehlerhaft geprüft wird

Mapping von RTR Metadaten

Um die Metadaten der Response von RTR in das mets.xml zu mappen, wird eine entsprechende Mapping-Datei benötigt, die man mit dem Parameter --mappingPath angeben kann.
Das JSON setzt sich aus folgenden Blöcken zusammen:

{
  "levels": {
    "konvolut": "Konvolut",
    "fassung": "Fassung",
    "einzelstueck": "Einzelstück",
    "datei": "Datei",
    "dokumentationsdateien": "Dokumentationsdateien"
  },
  "fields": [
    {
      "matterhorn": "refCode",
      "type": "Applikation",
      "path": "Lgblnummer"
    },
    ...
  ]
}

Das Objekt levels muss diesen Aufbau haben und beschreibt die Verzeichnisstufen bzw. Levels, (die mit den Levels aus dem levels.xml übereinstimmen müssen). Darunter findet man die Liste fields, welche jeweils ein Feld der Metadaten ins mets.xml hinzufügt.

Folgende Werte sind als Parameter derzeit möglich:

Parameter	Beschreibung
matterhorn	Das benötigte Matterhorn-Metadaten Feld, das befüllt werden soll
type	Muss bei Response-Objekten nicht explizit angegeben werden, sondern nur, wenn man den Typ "Format" verwendet Format Dies sind "spezielle" selbst definierte Daten, die zwar die Metadaten beinhalten können, aber nicht müssen. Eine genauere Beschreibung der Optionen wenn man den Typ "Format" verwendet, ist weiter unten zu finden
path	Der Pfad innerhalb des Metadaten-Objekts innerhalb der Response
multiple	Falls der gewünschte Wert eine Liste ist, kann mit diesem Parameter auch eine Liste von Strings abgefragt bzw. entsprechend Metadaten dazu erstellt werden
values	Wenn mehrere Werte innerhalb eines Feldes gewünscht sind oder sich das Metadaten-Feld aus mehreren Teilen zusammenstellt, kann dieses Feld benutzt werden. Dieses ist ebenfalls eine Liste aus den hier genannten Feldern.
valueSeparator	(Nur wenn values verwendet wird) Sollten die Werte mit einem bestimmten Text getrennt werden, kann dieser Wert hier angegeben werden.
format	(Nur bei type = Format) Kann verwendet werden, um funktionale Parameter oder einen fixen Text in ein Metadaten-Feld zu schreiben. Eine Liste der funktionalen Parameter ist weiter unten zu finden.
multipleValues	(Kann ohne einen type verwendet werden) Kann dafür verwendet werden, um mehrere Einträge eines Metadaten-Feldes mit unterschiedlichen Werten zu generieren. (Mögliche Werte sind true oder false)
keyValue	Dient dazu, um Werte nur dann anzugeben, wenn sie auch vorhanden sind. Wenn bspw. ein fixer Text nur dann vor ein Metadaten-Feld geschrieben werden soll, dann kann man hier den Text angeben, der zuvor stehen soll.
regexReplacements	Wird als Liste angegeben und kann dazu verwendet werden, um Text innerhalb eines Metadaten-Feldes zu verändern. Bspw. könnte die Abkürzung LReg zu Landesregierung abgeändert werden. Ein Beispiel wie eine solche Liste aussehen könnte, ist weiter unten zu finden.

Welche Werte man für den path setzen kann, muss man der Dokumentation von RTR entnommen werden.

Format Type

Mit dem Typ "Format" kann man spezifische und selbst definierte Werte in Metadaten-Felder schreiben. Hierfür kann man einfache Texte in das "format"-Property des Feldes in der Mapping-Datei schreiben, als auch funktionale Parameter. Eine Kombination ist hierbei auch möglich. Mögliche Felder könnten beispielsweise so aussehen:

[
  {
    "matterhorn": "reproductions",
    "type": "Format",
    "format": "Auslieferungsinformationspaket als Zugangsrepräsentation"
  },
  {
    "matterhorn": "processInfoDate",
    "type": "Format",
    "format": "$DATE"
  },
  {
    "matterhorn": "extent",
    "type": "Format",
    "format": "$COUNT_DOCUMENTS Dokumente (Dateien)"
  }
]

Funktionale Parameter

Parameter	Beschreibung
$DATE_TIME	Wird ersetzt durch heutiges Datum und jetzige Uhrzeit
$DATE	Wird ersetzt durch heutiges Datum
$TIME	Wird ersetzt durch jetzige Uhrzeit
$COUNT_DOCUMENTS	Wird ersetzt durch die Anzahl vorhandener Dokumente in diesem SIP
$FASSUNG	Wird ersetzt durch die derzeitige Fassung, für die gerade Metadaten befüllt werden
$EINZELSTUECK_TYPE_SHORT	Wird ersetzt mit H (für "Hauptdokument") oder mit AX (für "Anlage X")
$EINZELSTUECK_TYPE	Wird ersetzt mit Hauptdokument oder mit Anlage X
$NUMERATE	Setzt die nächste Nummer und erhöht den Counter um 1.

Beispiel für RegexReplacement Parameter

Ein mögliches Feld mit Regex-Anpassungen könnte folgendermassen aussehen:

{
  "matterhorn": "origination",
  "type": "Metadaten",
  "path": "Technisch.Organ",
  "regexReplacements": [
    {
      "regex": "LReg",
      "value": "Landesregierung"
    },
    {
      "regex": "LTag",
      "value": "Landtag"
    }
  ]
}

In diesem Fall werden LReg zu Landesregierung und LTag zu Landtag umgewandelt.