Ingest

Das Package "ingest" beinhaltet Schritte für den Ingestprozess.

Ingest: add custom premis event to SIP

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 of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property.
--nodeType=nodeType	defines type of node to which the events are added.
--eventType=eventType	PREMIS event type (can be freely chosen).
--eventDetail=eventDetail	PREMIS event detail (can be freely chosen).
--eventOutcome=eventOutcome	PREMIS event outcome (must either be Success or Failure).
[--eventOutcomeDetail=eventOutcomeDetail ]	PREMIS event outcome detail (optional, can be freely chosen).

Ingest: add DNB URN to the root node of the SIP

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 of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property
--urnNamespace=urnNamespace	namespace for which an URN will be generated.
[--urnIdAccessor=urnIdAccessor]	EAD accessor defining which EAD field of the root node is used to store the URN ID (URN without prefixes). If left empty, no URN ID is written.
[--onlyWriteUrnIdInAccessor=false] ]	{ true|false }, indicating whether only to write the URN-ID (defaults to false).

Ingest: convert BAR-SIP

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 of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.inbox property
[targetFolder]	directory where to move the created SIP to; if omitted, the SIP will be moved to the location defined by the actions.workbench.work property

Ingest: create SIP from eCH-0160 SIP

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	location of the SIP to convert; default lookup folder is actions.workbench.inbox
--levelsFilePath=/path/to/levels.xml	path to the file levels.xml
--[mappingFile=[path/to/]mappingFile]	file from which to read the mapping; defaults to a default mapping file (defined by the mapping module)
--[output-folder=/path/to/folder]	indicate the output folder; defaults to actions.workbench.work

Ingest: check workbench space

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 of the SIP. If no path is given, it will be expected to be in the location defined by the actions.workbench.work property
[numberOfCopies]	optional, number of copies to calculate with; defaults to 3

Ingest: cleanup working copies

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 of the SIP. If no path is given, it will be expected to be in the location defined by the actions.workbench.work property
[prep]	if true, SIPs of the same name in actions.workbench.preparation will be removed as well; defaults to false

Ingest: create EAD file

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 of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property
[targetFilename]	optional, name of the output file; defaults to EAD.xml within the SIP's subfolder in the location defined by the actions.workbench.output property

Ingest: extent calculator

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 of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property

Ingest: migrate files

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 of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property
keepOriginals	{ true|false }, indicating whether to keep the original files after the migration process
[path/to/migration-config.xml]	optional, path to a specific migration configuration file (defaults to ./config/migration-config.xml)
[skipAlreadyMigratedFiles]	optional, { true|false }, indicating whether to migrate files that have already been migrated before; defaults to 'true', i.e. does not migrate files that have undergone a migration before

Ingest: remove SIP from inbox

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	path of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.inbox property
[targetFolder]	directory where to move the SIP to; if omitted, the SIP will be deleted

Ingest: replace file

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	path of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property
[targetFolder]	path to the file to be used as replacement of the current SIP content

Ingest: get MARC from REST and add to SIP

Für jedes Objekt (Dateien als auch Ordner) eines SIPs wird eine MARC-Beschreibung geholt und als beschreibene 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	location of the SIP to convert; default lookup folder is actions.workbench.work

Ingest: add OAIDC from REST by ID from filename

Für das Wurzel-Objekt eines SIPs wird ein webservice für die OAI_DC-Beschreibung abgefragt und als beschreibene Metadaten hinzufgefü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	name of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property

Ingest: convert an EDIDOC/EDIAKT package into a Matterhorn METS SIP

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	location of the package to convert; default lookup folder is actions.workbench.inbox
--levelsFilePath=path/to/levels.xml	path to the level configuration file, to be found to the classpath
[--mappingFile=path/to/mappingFile]	file from which to read the mapping; defaults to ./config/edidoc-mapping.xml, to be found to the classpath
[--outputFolder=/path/to/folder]	indicate the output folder; defaults to actions.workbench.work
[--steuerXml=/path/to/file]	path to the EDIDOC archives extension XML file

Ingest: import or download MARCXML file to or from Alma

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	name of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property.
--marcxml=path/to/marc.xml	MARCXML metadata file path (relative to the SIP's root node).
[--writeMmsId=refCode]	EAD accessor defining the metadata element of the MARCXML file node into which the MMS ID is written after import. If empty, no MMS ID will be written for the file node.
[--writeMmsIdRoot=refCode]	EAD accessor defining the metadata element of the root node into which the MMS ID is written after import. If empty, no MMS ID will be written for the root node.
[--downloadIfMissing=false]	Indicating whether to download a MARCXML file (based on the MMS ID stored in the element defined by the writeMmsIdRoot accessor) from Alma if the MARCXML metadata file path does not point to a file. Default: false.
[--checkMatch=false]	Indicating whether to check for a match. Default: false (record will be saved despite possible match).
[--fromCzMmsId]	The MMS_ID of the Community-Zone record. Leave empty when creating a regular local record.
[--fromNzMmsId]	The MMS_ID of the Network-Zone record. Leave empty when creating a regular local record.
[--importProfile]	The ID of the import profile to use when processing the input record. Note that according to the profile configuration, the API can update an existing record in some cases.
[--normalization]	The ID of the normalization profile to run.
[--overrideWarning=true]	Indicating whether to ignore warnings. Default: true (record will be saved and the warnings will be added to the API output).
[--validate=false]	Indicating whether to validate the MARC XML file. Default: false.

Ingest: rename root node based on EAD metadata

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	name of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property
--accessorName=accessorName	EAD accessor defining which EAD field of the root node is used as the source of the new file or folder name.

Ingest: update xml file in SIP using xslt

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	name of the SIP; if no path is given, it will be expected to be in the location defined by the actions.workbench.work property
--xml=path/to/file.xml	path to xml file within the SIP to be transformed (relative to the SIP's root node). The path accepts a wildcard (*) in place of the root folder.
--xsl=path/to/transformation.xsl	path to the xsl script to be used in the transformation (if relative, assume xsl resides in $ACTIONS_HOME/xslt)

Ingest: Dokumente aus dem RIS (Rechtsinformationssystem) laden und daraus SIP's erstellen

Mit dieser Action können Dokumente aus dem RIS heruntergalden und entsprechend SIP's inklusive zugehörigem mets.xml erstellt werden.
Welche möglichen Werte es für den Request an das RIS gibt, ist unter folgendem Link zu finden: https://data.bka.gv.at/ris/api/v2.6/
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 findet man unter dieser Tabelle	X
--enabledExtensions	Gibt an, welche Dateien aus dem RIS heruntergalden 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 durchnummertiert werden sollen. Mögliche Werte sind "alphabetic" (default) und "numeric".
--enabledContentTypes	Gibt an welche Art von Dateien aus dem RIS heruntergalden 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 Beschriebung 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 um das Metadaten-Feld nur für bestimmte Fassungen zu befülle. (Eine Liste von Nummern muss angegeben werden Beispiel: Fassung A und C sollen das Feld erhalten, dann auf [1,3] setzen.
keyValue	Dient dazu, um Werte nur dann anzugeben, wenn sie auch vorhanden sind. Wenn beispielsweise 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. Beispielsweise könnte die Abkürzung LReg zu Lndesregierung abgeändert werden. Ein Beispiel wie eine solche Liste aussehen könnte, ist weiter unte zu finden.

Welche Werte man für den path setzen kann, muss man der Dokumentation von RIS entnehmen: https://data.bka.gv.at/ris/api/v2.6/

Format Type

Mit dem Type "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 folgendermaßen 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 SIP's 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 SIP's, 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 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	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 Beschriebung der Optionen wenn man den Type "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 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)
keyValue	Dient dazu, um Werte nur dann anzugeben, wenn sie auch vorhanden sind. Wenn beispielsweise 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. Beispielsweise könnte die Abkürzung LReg zu Lndesregierung abgeändert werden. Ein Beispiel wie eine solche Liste aussehen könnte, ist weiter unte zu finden.

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

Format Type

Mit dem Type "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 folgendermaßen 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.