Overview

Introduction

This documentation describes the installation, configuration and use of the Administration Plugin for automated pagination resetting within a large number of processes within Goobi workflow.

Installation

The plugin consists of the following files to be installed:

plugin-intranda-administration-reset-pagination-base.jar
plugin-intranda-administration-reset-pagination-gui.jar
plugin_intranda_administration_reset_pagination.xml

These files must be installed in the correct directories so that they are available in the following paths after installation:

/opt/digiverso/goobi/plugins/administration/plugin-intranda-administration-reset-pagination-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin-intranda-administration-reset-pagination-gui.jar
/opt/digiverso/goobi/config/plugin_intranda_administration_reset_pagination.xml

Overview and functionality

If the plugin has been installed and configured correctly, it can be found within the menu item Administration. After entering, the parameters described above can once again be individually adjusted in the interface.

After clicking on the button Execute plugin the update of the METS files starts. A progress bar informs about the progress. Within the table, the processes already processed are listed and the respective status about the success of the execution is displayed.

Configuration

The plugin is configured via the configuration file plugin_intranda_administration_reset_pagination.xml and can be adapted during operation. The following is an example configuration file:

<config_plugin>
	
	<!-- default filter to use -->
	<filter>stepdone:export</filter>
	
</config_plugin>

To use this plugin, the user must have the correct role authorisation. Therefore, please assign the role Plugin_administration_reset_pagination to the user group.

After installing the plugin and the associated database, the plugin must also be configured. This takes place within the configuration file plugin_intranda_administration_archive_management.xml and is structured as follows as an example:

<config_plugin>
    <export>
        <!-- configure export for a specific inventory -->
        <file name="sample.xml">
            <folder>/opt/digiverso/viewer/hotfolder/</folder>
        </file>
        
        <!-- default export for all inventories without a specific  -->
        <file name="*">
            <folder>/opt/digiverso/viewer/hotfolder/</folder>
        </file>
    </export>

    <backup>
        <!-- backup folder -->
        <folder>CHANGEME</folder>
        <!-- number of backups for each inventory -->
        <numberOfFiles>10</numberOfFiles>
        <!-- tool to create the backup files -->
        <tool>/usr/bin/mysqldump</tool>
        <!-- database password. The user name, database name, tables etc. can be recognized automatically, but the password must be entered.-->
        <!-- Leave it empty if access is possible without authentication (e.g. configured in ~/.my.cnf)  -->
        <password></password>
    </backup>


    <config>
        <!-- define the name(s) of all archives for the plugin -->
        <archive>*</archive>
        <!-- default title for a new node -->
        <nodeDefaultTitle>Document</nodeDefaultTitle>

        <!-- configurations for generating process titles -->

        <!-- maximum length of the body token that will be used to generate a new process title -->
        <!-- the specifically set HEAD token and TAIL token will not be affected by this limit -->
        <!-- if the limit is positively configured, then CAMEL_CASE_LENGTH_LIMITED will be applied upon every body token, otherwise CAMEL_CASE will be applied -->
        <lengthLimit>0</lengthLimit>
        <!-- separator string that will be used to combine the tokens -->
        <separator>_</separator>

        <!-- use id from parent node instead of id from node -->
        <useIdFromParent>false</useIdFromParent>

        <!-- Optional title generation, if nothing is configured, process titles are built based on the node ID -->
        <!-- attribute value: contains a static text. If it is empty, it is assumed that a metadata value is being searched for -->
        <!-- attribute name: contains the metadata name to use -->
        <!-- attribute type: can be NORMAL (use text as it is), CAMEL_CASE (each word begins with an upper case letter), 
             AFTER_LAST_SEPARATOR (insert at the end), BEFORE_FIRST_SEPARATOR (insert in front) -->

        <!-- 
        <title name="shelfmarksource" type="NORMAL"    />
        <title name="static" type="CAMEL_CASE" value="STATIC TEXT"  />
        <title name="CatalogIDDigital" type="AFTER_LAST_SEPARATOR"    />
        -->

        <!-- // configurations for generating process titles // -->

        <!-- configuration for node/process mapping -->
        <!-- it will be used during ead import or when the button to update references is used -->
        
        <!--
            nodeIdentifierField contains the identifying value of the node 
            processIdentifierField contains the name of the metadata where the node value is stored
            If both fields contain the same value, a link between node and process is created
        --> 
        <!-- 
        <nodeIdentifierField>id</nodeIdentifierField>
        <processIdentifierField>NodeId</processIdentifierField>
        -->
        <!-- define metadata fields. All fields are displayed on the UI based on the level and the order within this file.
                - @name: contains the internal name of the field. The value can be used to translate the field in the messages files. The field must start with a letter and can not contain any white spaces.
                - @level: metadata level, allowed values are 1-7:
                    * 1: metadata for Identity Statement Area 
                    * 2: Context Area 
                    * 3: Content and Structure Area
                    * 4: Condition of Access and Use Area
                    * 5: Allied Materials Area
                    * 6: Note Area
                    * 7: Description Control Area
                - @xpath: contains a relative path to the ead value. The root of the xpath is either the <ead> element or the <c> element
                - @xpathType: type of the xpath return value, can be text, attribute, element (default)
                - @repeatable: defines if the field can exist once or multiple times, values can be true/false, default is false
                - @visible: defines if the field is displayed on the UI, values can be true/false, default is true
                - @showField: defines if the field is displayed as input field (true) or badge (false, default), affects only visible metadata
                - @fieldType: defines the type of the input field. Posible values are input (default), textarea, dropdown, multiselect, vocabulary, nodelink, gnd, geonames, viaf
                - @rulesetName: internal name of the metadata in ruleset. If missing or empty, field is not imported into process metadata
                - @importMetadataInChild: defines if the field is imported or skipped in processes for child elements 
                - @validationType: defines a validation rule, allowed values are unique, required, regex, date, list or any combined values (e.g. date+required)
                - @regularExpression defines a regular expression that gets used for validation type regex
                - validationError: message to display in case of validation errors
                - value: list of possible values for dropdown and multiselect lists
                - vocabulary: name of the vocabulary
                - searchParameter: distinct the vocabulary list by the given condition. Syntax is fieldname=value, field is repeatable
         -->

        <!-- internal fields, not visible on the UI -->

        <metadata xpath="./ead:control/ead:maintenancestatus/@value" xpathType="attribute" name="maintenancestatus" level="1" repeatable="false" visible="false" />
        
        <metadata xpath="./ead:control/ead:maintenanceagency/ead:agencyname" xpathType="element" name="agencycode" level="1" repeatable="false" fieldType="input" />

        <!-- repository data group -->
        <metadata xpath="./ead:archdesc/ead:did/ead:repository" group="true" name="repository" level="1" repeatable="true" visible="false" fieldType="group" rulesetName="Repository">
            <metadata xpath="@label" xpathType="attribute" name="repositoryLabel" level="1" repeatable="false" visible="true" rulesetName="RepositoryLabel" />
            <metadata xpath="ead:address/ead:addressline" xpathType="element" name="repositoryaddressline" level="1" repeatable="true" visible="true" rulesetName="RepositoryAddress" />
            <metadata xpath="ead:extref/@href" xpathType="attribute" name="extrefhref" level="1" repeatable="true" visible="true" rulesetName="RepositoryLink" />
            <metadata xpath="ead:extref" xpathType="element" name="extref" level="1" repeatable="true" visible="true" rulesetName="RepositoryLinkName" />
        </metadata>


        <!--  Identity Statement Area -->
        <metadata xpath="./ead:control/ead:recordid" xpathType="element" name="recordid" level="1" repeatable="false" fieldType="input" rulesetName="RecordID" />
        
        <metadata xpath="./ead:control/ead:filedesc/ead:titlestmt/ead:titleproper" xpathType="element" name="titleproper" level="1" repeatable="false" visible="true" />

        <metadata xpath="./ead:control/ead:eadid" xpathType="element" name="eadid" level="1" repeatable="false" showField="false" fieldType="input" rulesetName="EADID" />

        <metadata xpath="(./ead:archdesc/ead:did/ead:unitid[not(@type)] | ./ead:did/ead:unitid[not(@type)])[1]" xpathType="element" name="unitid" level="1" repeatable="false" showField="false" fieldType="input" rulesetName="UnitID" />

        <metadata xpath="./ead:did/ead:unitid[@type='shelfmark']" xpathType="element" name="Shelfmark" level="1" repeatable="true" rulesetName="shelfmarksource" validationType="unique">
            <validationError>The value has already been used.</validationError>
        </metadata>
        
        <metadata xpath="(./ead:archdesc/ead:did/ead:unittitle | ./ead:did/ead:unittitle)[1]" xpathType="element" name="unittitle" level="1" repeatable="false" fieldType="textarea" rulesetName="TitleDocMain" importMetadataInChild="false" searchable="true" showField="true" />
        
        <metadata xpath="(./ead:archdesc/ead:did/ead:unitdate | ./ead:did/ead:unitdate)" xpathType="element" name="unitdate" level="1" repeatable="false" rulesetName="PublicationYear" importMetadataInChild="false" validationType="date" searchable="true" showField="true">
            <validationError>The value must be entered either as a year in the format YYYY or as a date in the format YYYY-MM-DD.</validationError>
        </metadata>
        
        <metadata xpath="(./ead:archdesc/ead:did/ead:unitdatestructured | ./ead:did/ead:unitdatestructured)[1]" xpathType="element" name="unitdatestructured" level="1" repeatable="false" validationType="date" rulesetName="DateOfOrigin" showField="true">
            <validationError>The value must be entered either as a year in the format YYYY or as a date in the format YYYY-MM-DD.</validationError>
        </metadata>

        <metadata xpath="(./ead:archdesc/@level | ./@level)[1]" xpathType="attribute" name="descriptionLevel" level="1" repeatable="false" fieldType="dropdown" validationType="list">
            <value>collection</value>
            <value>fonds</value>
            <value>class</value>
            <value>recordgrp</value>
            <value>series</value>
            <value>subfonds</value>
            <value>subgrp</value>
            <value>subseries</value>
            <value>file</value>
            <value>item</value>
            <value>otherlevel</value>
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:did/ead:physdescstructured|./ead:did/ead:physdescstructured)" xpathType="element" name="physdescstructured" level="1" repeatable="true"
            rulesetName="physdesc" group="true" fieldType="group" visible="true">
            <metadata xpath="ead:quantity" xpathType="element" name="physdescquantity" level="1" repeatable="false" rulesetName="Quantity" visible="true" />
            <metadata xpath="ead:unittype" xpathType="element" name="physdescunittype" level="1" repeatable="false" rulesetName="Unittype" visible="true" />
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:did/ead:physdesc/ead:extent|./ead:did/ead:physdesc/ead:extent)" xpathType="element" name="physdesc" level="1" repeatable="false"
            rulesetName="physicalDescriptionExtent" />

        <!-- Context Area -->
        <metadata xpath="(./ead:archdesc/ead:did/ead:origination[@label='Creator']/ead:persname|./ead:did/ead:origination[@label='Creator']/ead:persname)[1]" xpathType="element" name="origination" level="2" repeatable="true" rulesetName="Provenience" />
        
        <metadata xpath="(./ead:archdesc/ead:did/ead:origination[@label='Creator']/ead:corpname|./ead:did/ead:origination[@label='Creator']/ead:corpname)[1]" xpathType="element" name="originationcorpname" level="2" repeatable="true" rulesetName="Provenience" />

        <metadata xpath="(./ead:archdesc/ead:odd|./ead:odd)" xpathType="element" name="oddnote" level="2" repeatable="true" visible="true" group="true" fieldType="group">
            <metadata xpath="ead:head" xpathType="element" name="role" level="2" repeatable="false" visible="true" fieldType="input" />
            <metadata xpath="ead:p" xpathType="element" name="person" level="2" visible="true" repeatable="false" fieldType="input" />
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:bioghist/ead:p | ./ead:bioghist/ead:p)[1]" xpathType="element" name="bioghist" level="2" repeatable="true" fieldType="textarea" rulesetName="BiographicalInformation" />

        <metadata xpath="(./ead:archdesc/ead:custodhist/ead:p|./ead:custodhist/ead:p)" group="true" name="custodhist" level="2" repeatable="true" visible="true" fieldType="group" rulesetName="InventoryHistoryGroup">
            <metadata xpath="ead:head" xpathType="element" name="AcquisitionMethod" level="2" repeatable="false" visible="false" fieldType="input" rulesetName="AcquisitionMethod" />
            <metadata xpath="ead:list/ead:item" xpathType="element" name="AcquisitionAgent" level="2" repeatable="false" visible="false" fieldType="input" rulesetName="AcquisitionAgent" />
            <metadata xpath="ead:p" xpathType="element" name="AcquisitionNotes" level="2" repeatable="false" visible="false" fieldType="textarea" rulesetName="AcquisitionNotes" />
        </metadata>

        <!-- Content and Structure Area -->
        <metadata xpath="(./ead:archdesc/ead:scopecontent/ead:p | ./ead:scopecontent/ead:p)[1]" xpathType="element" name="scopecontent" level="3" repeatable="false" fieldType="textarea" rulesetName="ContentDescription" />
        
        <metadata xpath="(./ead:archdesc/ead:appraisal/ead:p | ./ead:appraisal/ead:p)[1]" xpathType="element" name="appraisal" level="3" repeatable="false" fieldType="textarea" rulesetName="AppraisalInformation" />
        
        <metadata xpath="(./ead:archdesc/ead:arrangement/ead:p | ./ead:arrangement/ead:p)[1]" xpathType="element" name="arrangement" level="3" repeatable="false" fieldType="textarea" rulesetName="Arrangement" />

        <!-- accruals group-->
        <metadata xpath="(./ead:archdesc/ead:accruals|./ead:accruals)" group="true" name="accruals" level="3" repeatable="true" visible="true" fieldType="group" rulesetName="AccrualsGroup">
            <metadata xpath="ead:head" xpathType="element" name="accruals_head" level="3" repeatable="false" visible="true" rulesetName="Title" />
            <metadata xpath="ead:p" xpathType="element" name="accruals_p" level="3" repeatable="false" visible="true" rulesetName="Description" />
            <metadata xpath="ead:chronlist/ead:chronitem/ead:datesingle" xpathType="element" name="accruals_date" level="3" repeatable="false" visible="true" rulesetName="Date" validationType="date" />
        </metadata>

        <!-- Condition of Access and Use Area -->
        <metadata xpath="(./ead:archdesc/ead:accessrestrict|./ead:accessrestrict)" group="true" name="accessrestrict" level="4" repeatable="true" visible="true" fieldType="group" rulesetName="AccessRestrictGroup">
            <metadata xpath="(ead:p|ead:p)" xpathType="element" name="accessrestrict_value" level="4" repeatable="false" fieldType="dropdown" rulesetName="RestrictionOnAccessLicense" importMetadataInChild="true">
                <value>open access</value>
                <value>restricted</value>
            </metadata>
            <metadata xpath="ead:chronlist/ead:chronitem/ead:datesingle" xpathType="element" name="accessrestrict_date" level="3" repeatable="false" visible="true" rulesetName="Date" validationType="date" />
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:userestrict/ead:p | ./ead:userestrict/ead:p)[1]" xpathType="element" name="userestrict" level="4" repeatable="false" fieldType="dropdown" importMetadataInChild="true" rulesetName="UseRestriction">
            <value>CC0 1.0</value>
            <value>CC BY 4.0</value>
            <value>CC BY-SA 4.0</value>
            <value>CC BY-ND 4.0</value>
            <value>CC BY-NC 4.0</value>
            <value>CC BY-NC-SA 4.0</value>
            <value>CC BY-NC-ND 4.0</value>
        </metadata>

        <metadata xpath="./ead:did/ead:langmaterial/ead:language" xpathType="element" name="langmaterial" level="4" repeatable="true" fieldType="textarea" rulesetName="DocLanguage" importMetadataInChild="false">
            <value>ger</value>
            <value>eng</value>
            <value>fre</value>
            <value>ita</value>
            <value>lat</value>
            <value>spa</value>
            <value>ara</value>
            <value>heb</value>
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:did/ead:langmaterial[@label='font'] | ./ead:did/ead:langmaterial[@label='font'])[1]" xpathType="element" name="font" level="4" repeatable="false" fieldType="multiselect" rulesetName="FontType" importMetadataInChild="false">
            <value>antiqua</value>
            <value>fracture</value>
            <value>handwritten</value>
            <value>mixed</value>
            <value>no text</value>
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:phystech/ead:p | ./ead:phystech/ead:p)" xpathType="element" name="phystech" level="4" repeatable="false" fieldType="textarea" rulesetName="PhysTech" />
        
        <metadata xpath="(./ead:archdesc/ead:otherfindaid|./ead:otherfindaid)" group="true" name="otherfindaid" level="4" repeatable="true" visible="true" fieldType="group" rulesetName="OtherFindAidGroup">
            <metadata xpath="(ead:head|ead:head)" xpathType="element" name="otherfindaid_type" level="4" repeatable="false" fieldType="input" rulesetName="Type" />
            <metadata xpath="ead:p/ead:ref" xpathType="element" name="otherfindaid_link" level="4" repeatable="false" fieldType="input" rulesetName="OtherFindAid" />
            <metadata xpath="ead:p/ead:ptr" xpathType="element" name="otherfindaid_node" level="4" repeatable="false" fieldType="nodelink" rulesetName="OtherFindAid" />
        </metadata>

        <!-- Allied Materials Area -->

        <!-- Location of Originals group-->
        <metadata xpath="(./ead:archdesc/ead:originalsloc|./ead:originalsloc)" group="true" name="originalsloc" level="5" repeatable="true" visible="true" fieldType="group" rulesetName="OriginalsLocationGroup">
            <metadata xpath="ead:p/ead:name" xpathType="element" name="originalsloc_person" level="5" repeatable="false" visible="true" rulesetName="Person" fieldType="input" />
            <metadata xpath="ead:p/ead:subject" xpathType="element" name="originalsloc_shelfmark" level="5" repeatable="false" visible="true" rulesetName="shelfmarksource" />
            <metadata xpath="ead:p/ead:ref" xpathType="element" name="originalsloc_link" level="4" repeatable="false" fieldType="input" rulesetName="RepositoryLink" />
        </metadata>

        <!-- Alternative Form Available group-->
        <metadata xpath="(./ead:archdesc/ead:relatedmaterial|./ead:relatedmaterial)" group="true" name="altformavail" level="5" repeatable="true" visible="true" fieldType="group" rulesetName="CopyLocationGroup">
            <metadata xpath="ead:p/ead:name" xpathType="element" name="altformavail_person" level="5" repeatable="false" visible="true" rulesetName="Person" fieldType="input" />
            <metadata xpath="ead:p/ead:subject" xpathType="element" name="altformavail_shelfmark" level="5" repeatable="false" visible="true" rulesetName="shelfmarksource" />
            <metadata xpath="ead:p/ead:ref" xpathType="element" name="altformavail_link" level="4" repeatable="false" fieldType="input" rulesetName="RepositoryLink" />
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:separatedmaterial/ead:p|./ead:separatedmaterial/ead:p)[1]" xpathType="element" name="separatedmaterial" level="5" repeatable="true" rulesetName="SeparatedMaterial" fieldType="nodelink" />
        
        <metadata xpath="(./ead:archdesc/ead:bibliography|./ead:bibliography)[1]" xpathType="element" name="bibliography" level="5" repeatable="false" rulesetName="BibliographicCitation" />

        <!-- Note Area -->
        <metadata xpath="(./ead:archdesc/ead:note/ead:p|./ead:note/ead:p)[1]" xpathType="element" name="didnote" level="6" repeatable="true" fieldType="textarea" rulesetName="DidNote" />
       
        <metadata xpath="./ead:control/ead:localtypedeclaration" xpathType="element" name="Conventions" level="6" repeatable="false" fieldType="textarea" rulesetName="ConventionDeclaration" />
        
        <metadata xpath="./ead:processinfo/ead:chronlist/ead:chronitem/ead:datesingle" xpathType="element" name="DescriptionDates" level="6" repeatable="false" fieldType="textarea" rulesetName="DescriptionDates" />


        <!-- Description Control Area -->
        <metadata xpath="./ead:archdesc/ead:processinfo/ead:list/ead:item" xpathType="element" name="editorName" level="7" repeatable="true" fieldType="textarea" visible="false" />

        <metadata xpath="./ead:processinfo/ead:p" xpathType="element" name="ArchivistNote" level="7" repeatable="false" fieldType="textarea" rulesetName="ArchivistNote" />

        <metadata xpath="./ead:control/ead:conventiondeclaration/ead:abbr" xpathType="element" name="conventiondeclaration" level="7" repeatable="false" fieldType="multiselect">
            <value>ISAD(G)</value>
            <value>NCARules</value>
            <value>ISO 8601</value>
            <value>DACS</value>
        </metadata>

        <metadata xpath="./ead:control/ead:maintenancehistory/ead:maintenanceevent" group="true" name="maintenancehistory" level="7" repeatable="true" visible="false" fieldType="group">
            <metadata xpath="ead:eventtype" xpathType="element" name="eventtype" level="1" repeatable="false" visible="false" />
            <metadata xpath="ead:agent" xpathType="element" name="agent" level="1" repeatable="false" visible="false" />
            <metadata xpath="ead:eventdescription" xpathType="element" name="eventdescription" level="1" repeatable="false" visible="false" />
            <metadata xpath="ead:eventdatetime" xpathType="element" name="eventdatetime" level="1" repeatable="false" visible="false" />
        </metadata>

        <!-- viaf sample
        <metadata xpath="./ead:archdesc/ead:index/ead:indexentry/ead:corpname/ead:part" xpathType="element" name="Corporate" level="7" repeatable="true" searchable="true" showField="true" fieldType="viaf"
        searchFields="210__a; 111__a; 100__a; 110__a; 150__a; 151__a;" displayFields="001=NORM_IDENTIFIER; 0247_a=URI; 1001_a=NORM_NAME; 1001_d=NORM_LIFEPERIOD; 1001_q=NORM_SEX; 375__a=NORM_SEX;" />
        -->

        <!-- geonames sample
        <metadata xpath="./ead:archdesc/ead:index/ead:indexentry/ead:geogname/ead:part[@localtype='place']" xpathType="element" name="Place" level="7" repeatable="true" fieldType="geonames" visible="true" />
        -->
        <!-- gnd sample
        <metadata xpath="./ead:archdesc/ead:index/ead:indexentry/ead:persname/ead:part" xpathType="element" name="Person" level="7" repeatable="true" fieldType="gnd" visible="true" />
        -->

        <!-- extend configured areas -->
        <showGroup level="1" />

        <!--
        <showGroup level="2" />
        <showGroup level="3" />
        <showGroup level="4" />
        <showGroup level="5" />
        <showGroup level="6" />
        <showGroup level="7" />

        -->

        <treeView>
            <!-- tree view: display/hide node id-->
            <showNodeId>false</showNodeId>
        </treeView>

        <!-- enables template and project name selection in process creation area -->
        <showProjectSelection>false</showProjectSelection>
        <!-- 
        possible namespaces: 
            ead2: urn:isbn:1-931666-22-9
            ead3: http://ead3.archivists.org/schema/
            ead4: https://archivists.org/ns/ead/v4 
        -->
        <eadNamespaceRead>http://ead3.archivists.org/schema/</eadNamespaceRead>
        <eadNamespaceWrite>http://ead3.archivists.org/schema/</eadNamespaceWrite>

        <node name="file" ruleset="File" icon="fa fa-file-text-o" processTemplateId="456" />
        <node name="folder" ruleset="Folder" icon="fa fa-folder-open-o" processTemplateId="456" />
        <node name="image" ruleset="Picture" icon="fa fa-file-image-o" processTemplateId="456" />
        <node name="audio" ruleset="Audio" icon="fa fa-file-audio-o" processTemplateId="456" />
        <node name="video" ruleset="Video" icon="fa fa-file-video-o" processTemplateId="456" />
        <node name="other" ruleset="Other" icon="fa fa-file-o" processTemplateId="456" />
    </config>
    
    
    <config>
        <archive>ead2 sample</archive>
        <processTemplateId>2</processTemplateId>
        <nodeDefaultTitle>Document</nodeDefaultTitle>
        
        <lengthLimit>25</lengthLimit>
        
        <separator>_</separator>
        
        <useIdFromParent>false</useIdFromParent>
        
        <useShelfmarkAsId>false</useShelfmarkAsId>

        <metadata xpath="./ead:eadheader[@countryencoding='iso3166-1'][@dateencoding='iso8601'][@langencoding='iso639-2b'][@repositoryencoding='iso15511'][@scriptencoding='iso15924']/ead:eadid/@mainagencycode" xpathType="attribute" name="mainagencycode" level="1" repeatable="false" visible="false"/>
        <metadata xpath="./ead:eadheader/ead:profiledesc/ead:creation/@normal" xpathType="attribute" name="normalcreationdate" level="1" repeatable="false" visible="false"/>
        <metadata xpath="./ead:eadheader/ead:profiledesc/ead:creation" xpathType="element" name="creationdate" level="1" repeatable="false" visible="false"/>
        <metadata xpath="./ead:eadheader/ead:filedesc/ead:titlestmt/ead:titleproper" xpathType="element" name="titlestmt" level="1" repeatable="false" visible="false"/>

        <!--  Identity Statement Area -->
        <metadata xpath="./ead:control/ead:maintenanceagency/ead:agencycode" xpathType="element" name="agencycode" level="1" repeatable="false" fieldType="input"/>
        <metadata xpath="./ead:eadheader/ead:eadid" xpathType="element" name="eadid" level="1" repeatable="false" showField="false" fieldType="input" rulesetName="EADID"/>
        <metadata xpath="./ead:control/ead:recordid" xpathType="element" name="recordid" level="1" repeatable="false" fieldType="input" rulesetName="RecordID"/>
        <metadata xpath="(./ead:archdesc/ead:did/ead:unitid[not(@type)] | ./ead:did/ead:unitid[not(@type)])[1]" xpathType="element" name="unitid" level="1" repeatable="false" showField="false" fieldType="input" rulesetName="UnitID"/>

        <metadata xpath="./ead:did/ead:unitid[@type='Vorl. Nr.']" xpathType="element" name="Number" level="1" repeatable="true" />
        <metadata xpath="./ead:did/ead:unitid[@type='Altsignatur']" xpathType="element" name="Shelfmark" level="1" repeatable="true" rulesetName="shelfmarksource" validationType="unique">
            <validationError>Der Wert wurde an anderer Stelle bereits verwendet</validationError>
        </metadata>
        <metadata xpath="(./ead:archdesc/ead:did/ead:unittitle | ./ead:did/ead:unittitle)[1]" xpathType="element" name="unittitle" level="1" repeatable="false" fieldType="textarea" rulesetName="TitleDocMain" importMetadataInChild="false" />
        <metadata xpath="(./ead:archdesc/ead:did/ead:unitdate | ./ead:did/ead:unitdate)[1]" xpathType="element" name="unitdate" level="1" repeatable="false" rulesetName="PublicationYear" importMetadataInChild="false" regularExpression="\\d{4}" validationType="regex">
            <validationError>Der Wert ist keine vierstellige Jahreszahl</validationError>
        </metadata>
        <metadata xpath="(./ead:archdesc/ead:did/ead:unitdatestructured | ./ead:did/ead:unitdatestructured)[1]" xpathType="element" name="unitdatestructured" level="1" repeatable="false"  rulesetName="DateOfOrigin"/>
        <metadata xpath="(./ead:archdesc/@level | ./@level)[1]" xpathType="attribute" name="descriptionLevel" level="1" repeatable="false" fieldType="dropdown">
            <value>collection</value>
            <value>fonds</value>
            <value>class</value>
            <value>recordgrp</value>
            <value>series</value>
            <value>subfonds</value>
            <value>subgrp</value>
            <value>subseries</value>
            <value>file</value>
            <value>item</value>
            <value>otherlevel</value>
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:did/ead:physdesc | ./ead:did/ead:physdesc)[1]" xpathType="element" name="physdesc" level="1" repeatable="false" rulesetName="Format" />
        <metadata xpath="(./ead:archdesc/ead:did/ead:physdescstructured | ./ead:did/ead:physdescstructured)[1]" xpathType="element" name="physdescstructured" level="1" repeatable="false" rulesetName="physicalDescriptionExtent" />

        <!-- Context Area -->
        <metadata xpath="(./ead:archdesc/ead:did/ead:origination | ./ead:did/ead:origination)[1]" xpathType="element" name="origination" level="2" repeatable="true" rulesetName="Provenience"/>
        <metadata xpath="(./ead:archdesc/ead:odd/ead:head | ./ead:odd/ead:head)[1]" xpathType="element" name="role" level="2" repeatable="false" fieldType="vocabulary">
            <vocabulary>Rollen</vocabulary>
            <!--<searchParameter>type=visible</searchParameter>-->
        </metadata>
        <metadata xpath="(./ead:archdesc/ead:odd/ead:p | ./ead:odd/ead:p)[1]" xpathType="element" name="person" level="2" repeatable="false"/>

        <metadata xpath="(./ead:archdesc/ead:dsc/ead:bioghist | ./ead:dsc/ead:bioghist)[1]" xpathType="element" name="bioghist" level="2" repeatable="true" fieldType="textarea" rulesetName="BiographicalInformation" />
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:custodhist | ./ead:dsc/ead:custodhist)[1]" xpathType="element" name="custodhist" level="2" repeatable="false" fieldType="textarea" rulesetName="InventoryHistory"/>
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:acqinfo | ./ead:dsc/ead:acqinfo)[1]" xpathType="element" name="acqinfo" level="2" repeatable="false" fieldType="dropdown" rulesetName="AquisitionInformation" >
            <value>value 1</value>
            <value>value 2</value>
            <value>...</value>
        </metadata>

        <!-- Content and Structure Area -->
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:scopecontent | ./ead:dsc/ead:scopecontent)[1]" xpathType="element" name="scopecontent" level="3" repeatable="false" fieldType="textarea" rulesetName="ContentDescription"/>
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:appraisal | ./ead:dsc/ead:appraisal)[1]" xpathType="element" name="appraisal" level="3" repeatable="false" fieldType="textarea" rulesetName="AppraisalInformation"/>
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:accruals | ./ead:dsc/ead:accruals)[1]" xpathType="element" name="accruals" level="3" repeatable="true" fieldType="textarea" rulesetName="Additions"/>
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:arrangement | ./ead:dsc/ead:arrangement)[1]" xpathType="element" name="arrangement" level="3" repeatable="false" fieldType="textarea" rulesetName="Arrangement"/>

        <!-- Condition of Access and Use Area -->
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:accessrestrict | ./ead:dsc/ead:accessrestrict)[1]" xpathType="element" name="accessrestrict" level="4" repeatable="false" fieldType="dropdown" rulesetName="RestrictionOnAccessLicense" importMetadataInChild="true">
            <value>open access</value>
            <value>restricted</value>
            <value>required registration</value>
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:dsc/ead:userestrict | ./ead:dsc/ead:userestrict)[1]" xpathType="element" name="userestrict" level="4" repeatable="false" fieldType="dropdown" importMetadataInChild="true" rulesetName="UseRestriction">
            <value>damaged</value>
            <value>good condition</value>
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:did/ead:langmaterial[@label='Language']/ead:language | ./ead:did/ead:langmaterial[@label='Language']/ead:language)[1]" xpathType="element" name="langmaterial" level="4" repeatable="false" fieldType="multiselect" rulesetName="DocLanguage" importMetadataInChild="false">
            <value>eng</value>
            <value>ger</value>
            <value>dut</value>
            <value>fre</value>
            <value>esp</value>
            <value>ita</value>
            <value>lat</value>
            <value>pol</value>
            <value>rus</value>
            <value>swe</value>
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:did/ead:langmaterial[@label='font'] | ./ead:did/ead:langmaterial[@label='font'])[1]" xpathType="element" name="font" level="4" repeatable="false" fieldType="multiselect" rulesetName="FontType" importMetadataInChild="false">
            <value>antiqua</value>
            <value>fracture</value>
            <value>handwritten</value>
            <value>mixed</value>
            <value>no text</value>
        </metadata>

        <metadata xpath="(./ead:archdesc/ead:dsc/ead:phystech | ./ead:dsc/ead:phystech)[1]" xpathType="element" name="phystech" level="4" repeatable="false" fieldType="textarea" rulesetName="PhysTech" />
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:otherfindaid | ./ead:dsc/ead:otherfindaid)[1]" xpathType="element" name="otherfindaid" level="4" repeatable="false" fieldType="textarea" rulesetName="OtherFindAid"/>

        <!-- Allied Materials Area -->
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:originalsloc | ./ead:dsc/ead:originalsloc)[1]" xpathType="element" name="originalsloc" level="5" repeatable="false" fieldType="dropdown" rulesetName="OriginalsLocation">
            <value>value 1</value>
            <value>value 2</value>
        </metadata>
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:altformavail | ./ead:dsc/ead:altformavail)[1]" xpathType="element" name="altformavail" level="5" repeatable="false" fieldType="dropdown" rulesetName="AlternativeFormAvailable">
            <value>value 1</value>
            <value>value 2</value>
        </metadata>
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:relatedmaterial/ead:separatedmaterial | ./ead:dsc/ead:relatedmaterial/ead:separatedmaterial)[1]" xpathType="element" name="separatedmaterial" level="5" repeatable="false" rulesetName="SeparatedMaterial"/>
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:bibliography | ./ead:dsc/ead:bibliography)[1]" xpathType="element" name="bibliography" level="5" repeatable="false" rulesetName="BibliographicCitation"/>


        <!-- Note Area -->
        <metadata xpath="(./ead:archdesc/ead:did/ead:didnote | ./ead:did/ead:didnote)[1]" xpathType="element" name="didnote" level="6" repeatable="false" fieldType="textarea" rulesetName="DidNote"/>
        <metadata xpath="(./ead:archdesc/ead:dsc/ead:odd | ./ead:dsc/ead:odd)[1]" xpathType="element" name="oddnote" level="6" repeatable="false" fieldType="textarea" rulesetName="Odd" />

        <!-- Description Control Area -->
        <metadata xpath="./ead:control/ead:conventiondeclaration" xpathType="element" name="conventiondeclaration" level="7" repeatable="false" fieldType="multiselect" rulesetName="ConventionDeclaration">
            <value>val 1</value>
            <value>val 2</value>
            <value>val 3</value>
            <value>val 4</value>
        </metadata>

        <eadNamespaceRead>urn:isbn:1-931666-22-9</eadNamespaceRead>
        <eadNamespaceWrite>urn:isbn:1-931666-22-9</eadNamespaceWrite>

        <node name="file" ruleset="File" icon="fa fa-file-text-o" processTemplateId="309544" />
        <node name="folder" ruleset="Folder" icon="fa fa-folder-open-o" processTemplateId="309544"/>
        <node name="image" ruleset="Picture" icon="fa fa-file-image-o" processTemplateId="309544" />
        <node name="audio" ruleset="Audio" icon="fa fa-file-audio-o" processTemplateId="309544"/>
        <node name="video" ruleset="Video" icon="fa fa-file-video-o" processTemplateId="309544"/>
        <node name="other" ruleset="Other" icon="fa fa-file-o" processTemplateId="309544" />
    </config>
    
    
</config_plugin>

General configuration

The connection to the Goobi viewer is configured in the <export> area. The location to which an export as EAD-XML is to be made and which inventories are to be exported are defined here. The export takes place automatically at regular intervals or can be started manually from the user interface.

In the second area <backup> an automatic backup of the individual inventories can be configured. A separate file is created for each inventory. You can define how many backups should be kept and which tool should be used to create the backups. If a password is required for database access, this can also be configured here.

This is followed by a repeatable <config> block. The repeatable <archive> element can be used to specify which files the <config> block should apply to. If there is to be a default block that applies to all documents, * can be used.

The <processTemplateId> is used to specify the production template on the basis of which the Goobi processes are to be created.

Configuration of the generation of task titles

The parameters <lengthLimit> <separator> <useIdFromParent> and <title> are used to configure the naming of the task to be generated:

• The value <lengthLimit> sets a length limit for all tokens except the manually set prefix and suffix. The default setting is 0, i.e. it does not limit the length.

• The parameter <separator> defines the separator to be used to combine all separate tokens. The default setting is _.

• The parameter <useIdFromParent> configures whose ID should be used to create the task title. If it is set to true, the ID of the parent node is used. Otherwise, the ID of the current node is used.

• The <title> parameter configures which metadata should be used for the title generation. The value attribute can contain a static text or the name attribute can contain the name of a metadata field. The type is used to control what should happen with the value NORMAL inserts the field unchanged, CAMEL_CASE replaces spaces and starts each word with a capital letter, AFTER_LAST_SEPARATOR always inserts the field at the end, BEFORE_FIRST_SEPARATOR always inserts it at the beginning. If no title has been configured, the process title is formed on the basis of the node ID.

Configuration of the reference between node and process

The two parameters <nodeIdentifierField> and <processIdentifierField> are used to link the node and the process. The <nodeIdentifierField> field contains the name of the field that contains the identifier of the node. Any configured field can be used. Unless otherwise specified, id is used. The <processIdentifierField> contains the metadata in which the identifier of the node is to be saved. This is usually NodeId.

If a new EAD file is imported or the ‘ Update references to processes ’ button is used, the configured metadata is searched for in all processes. The system then compares whether the metadata contains the value that is entered in the field in a node. If this is the case, a link is created between the node and the process. For all nodes for which no match was found, any existing links are removed.

Configuration of the metadata fields

This is followed by a list of <metadata> elements. This controls which fields are displayed, can be imported, how they should behave and whether there are validation rules.

Mandatory information

Each metadata field consists of at least the following mandatory information:

Optional information

There are also a number of other optional details:

Examples of different field configurations

Simple input field

<metadata xpath="./ead:control/ead:maintenanceagency/ead:agencycode" xpathType="element" name="agencycode" level="1" repeatable="false" fieldType="input"/>

Textfeld

<metadata xpath="(./ead:archdesc/ead:did/ead:unittitle | ./ead:did/ead:unittitle)[1]" xpathType="element" name="unittitle" level="1" repeatable="false" fieldType="textarea" rulesetName="TitleDocMain" importMetadataInChild="false" />

Selection list

<metadata xpath="(./ead:archdesc/@level | ./@level)[1]" xpathType="attribute" name="descriptionLevel" level="1" repeatable="false" fieldType="dropdown">
    <value>collection</value>
    <value>fonds</value>
    <value>class</value>
    <value>recordgrp</value>
    <value>series</value>
    <value>subfonds</value>
    <value>subgrp</value>
    <value>subseries</value>
    <value>file</value>
    <value>item</value>
    <value>otherlevel</value>
</metadata>

Multiple selection

        <metadata xpath="(./ead:archdesc/ead:did/ead:langmaterial[@label='font'] | ./ead:did/ead:langmaterial[@label='font'])[1]" xpathType="element" name="font" level="4" repeatable="false"
            fieldType="multiselect" rulesetName="FontType" importMetadataInChild="false">
            <value>antiqua</value>
            <value>fracture</value>
            <value>handwritten</value>
            <value>mixed</value>
            <value>no text</value>
        </metadata>

Validierung von Datumsangaben im ISO 8601 Format

<metadata xpath="(./ead:archdesc/ead:did/ead:unitdate | ./ead:did/ead:unitdate)[1]" xpathType="element" name="unitdate" level="1" repeatable="false" rulesetName="PublicationYear" importMetadataInChild="false" regularExpression="^([0-9]{4}\\-[0-9]{2}\\-[0-9]{2}|[0-9]{4})(\\s?\\-\s?([0-9]{4}\\-[0-9]{2}\\-[0-9]{2}|[0-9]{4}))?$" validationType="regex">
  <validationError>Der Wert ist keine Datumsangabe. Erlaubte Werte sind entweder Jahreszahlen (YYYY), exakte Datumsangaben (YYYY-MM-DD) oder Zeiträume (YYYY - YYYY, YYYY-MM-DD-YYYY-MM-DD)</validationError>
</metadata>

Validation of dates in EDTF format

<metadata xpath="(./ead:archdesc/ead:did/ead:unitdate | ./ead:did/ead:unitdate)[1]" xpathType="element" name="unitdate" level="1" repeatable="false" rulesetName="PublicationYear" importMetadataInChild="false" validationType="date">
  <validationError>Der Wert ist keine Datumsangabe</validationError>
</metadata>

Connection of a controlled vocabulary

<metadata xpath="(./ead:archdesc/ead:dsc/ead:acqinfo | ./ead:dsc/ead:acqinfo)[1]" xpathType="element" name="acqinfo" level="2" repeatable="false" fieldType="vocabulary" rulesetName="AquisitionInformation" >
  <vocabulary>Aquisition</vocabulary>
  <searchParameter>type=visible</searchParameter>
  <searchParameter>active=true</searchParameter>
</metadata>

Linking to another node within the inventory

        <metadata xpath="(./ead:archdesc/ead:relatedmaterial/ead:ref | ./ead:relatedmaterial/ead:ref)" xpathType="element" name="nodelink" fieldType="nodelink" level="5" repeatable="false" />

Search in the GND

            <metadata xpath="./ead:archdesc/ead:index/ead:indexentry/ead:persname/ead:part" xpathType="element" name="Person" level="7" repeatable="true" fieldType="gnd" visible="true" />

Search in Geonames

            <metadata xpath="./ead:archdesc/ead:index/ead:indexentry/ead:geogname/ead:part[@localtype='place']" xpathType="element" name="Place" level="7" repeatable="true" fieldType="geonames" visible="true" />

Search in VIAF

            <metadata xpath="./ead:archdesc/ead:index/ead:indexentry/ead:corpname/ead:part" xpathType="element" name="Corporate" level="7" repeatable="true"
                searchable="true" showField="true" fieldType="viaf" searchFields="210__a; 111__a; 100__a; 110__a; 150__a; 151__a;"
                displayFields="001=NORM_IDENTIFIER; 0247_a=URI; 1001_a=NORM_NAME; 1001_d=NORM_LIFEPERIOD; 1001_q=NORM_SEX; 375__a=NORM_SEX;" />

Configuration of the display of the areas

In the default setting, the individual sections 1 Identification, 2 Context, 3 Content and internal organisation, 4 Access and usage conditions, 5 Related documents, 6 Notes and 7 Directory control are collapsed for reasons of space and are not displayed. The element <showGroup level=‘1’ /> can be used so that they are already expanded and displayed when a node is selected. The ordinal number in the level attribute is used to control which area is expanded. The attribute <showField=‘true’ can be used within the <metadata> definition to display unfilled metadata immediately without adding it using a badge.

Configuration of the XML namespace

The two elements <eadNamespaceRead> and <eadNamespaceWrite> define which XML namespaces are to be used for reading and writing EAD documents. Usually both contain the same value. However, EAD2 documents can also be read and exported as EAD3 documents. In this case, the corresponding namespaces must be defined and care must be taken in the xpath expressions of the individual metadata to ensure that both variants are specified. It is therefore easier to use the enclosed converter and convert from EAD2 to EAD3 before importing the documents.

• Namespace for ead2 (deprecated): urn:isbn:1-931666-22-9

• Namespace for ead3 (current): http://ead3.archivists.org/schema/

• Namespace for ead4 (in draft status): https://archivists.org/ns/ead/v4

Overview

Introduction

This documentation describes the installation, configuration and use of the Administration Plugin for managing archive collections from within Goobi workflow. This allows the data from several archives to be managed and enables even small archives to record data in a standardised way without having to install third-party software that is subject to a charge. Export as standardised EAD files is possible at any time and can also be carried out automatically at regular intervals.

Installation

Installation of the plugin

The plugin consists of the following files to be installed

plugin-administration-archive-management-base.jar
plugin-administration-archive-management-gui.jar
plugin-administration-archive-management-job.jar
plugin-administration-archive-management-lib.jar
plugin_intranda_administration_archive_management.xml

These files must be installed in the correct directories so that they are available in the following paths after installation:

/opt/digiverso/goobi/plugins/administration/plugin-administration-archive-management-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-archive-management-gui.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-archive-management-job.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-archive-management-lib.jar

The plugin also requires an additional configuration file, which must be located in the following location:

/opt/digiverso/goobi/config/plugin_intranda_administration_archive_management.xml

Overview and functionality

The plugin for editing archives can be found under the menu item ‘Administration’.

To use the plugin, the user must first have the Plugin_Administration_Archive_Management right. If this right has not yet been assigned, the user will receive the following message:

The corresponding rights must therefore first be assigned to the respective user groups.

Once the required rights have been assigned and, if necessary, a new login has been created, the plugin can be used.

The user initially only has read access. In order to be able to change data, the following additional rights are available, which can be assigned if necessary:

A detailed explanation of how to use the plugin and its functions can be found on this page:

Using the plugin

Configuration

After installation, the plugin and the associated interface are configured in the configuration file plugin_intranda_administration_archive_management.xml. This is described in detail on the following page:

Configuration of the plugin

To start up the Goobi-to-Goobi mechanism, various plugins must be installed and configured on both the source and target systems. These are described in detail here.

1. Source system

First of all, the source system must be prepared for export. This includes first of all the installation of the correct plugin. Afterwards, only a permission for the appropriate users has to be configured to allow the export.

1.1 Installation

On the source system, the plugin plugin_intranda_administration_goobi2goobi_export must first be installed to create the export directories. To do this, the following two files must be copied to the appropriate paths:

Please note that these files must be readable by the user tomcat.

1.2 Configuration

To enable the user to export data, the user must have the following roles:

These roles can be configured within the Goobi workflow user groups. To do this, simply select the roles on the right-hand side or enter them in the input field and then click on the plus icon.

With this configuration the preparation on the side of the initial system is already completed.

2. Target system

The target system must also be prepared for the import. After the installation of the corresponding plugin and the corresponding configuration files, some configurations have to be checked or made.

2.1 Installation

On the target system, the plugin plugin_intranda_administration_goobi2goobi_import must first be installed to import the export directories. To do this, the following two files must be copied to the appropriate paths:

After the installation of the actual plugin, the corresponding configuration files must also be installed. These can be found under the following paths:

Again, please note that the installed files must all be readable for the user tomcat.

2.2 General configuration

To enable a user to perform the import, the user must have the following role:

This role can be configured within the Goobi workflow user groups by entering it in the input field on the right-hand side and clicking on the plus icon.

2.3 Configuration for importing the infrastructure

To influence the data to be imported during the import of the infrastructure, the configuration file plugin_intranda_administration_goobi2goobi_import_infrastructure.xml can be adapted. This configuration can look like the following example:

In this configuration file all fields are optional. If a field is missing, its value is not overwritten during configuration. If the field is empty, it will be imported empty, otherwise it will be overwritten with the value from this configuration file. The fields for adding or removing are basically repeatable.

2.4 Configuration for the import of data

To import the data to the target system, you can specify in the configuration file plugin_intranda_administration_goobi2goobi_import_infrastructure.xml where the data is located and how it should be processed during the import. This configuration can look like the following example:

In the upper part of the file, some general settings are made that apply to all imports. These general settings are followed by the individual configured rules.

General settings: globalConfig

The individual rules for the import operations will be defined within the <config> element. The name of the rule is defined in <rulename>. If no rule is explicitly selected during the import, it will be determined by the project name of the processes. The field is repeatable, so that several identical rules can be created, for example if the same workflow is used in different projects.

Workflow steps within the workflows: step

By means of <step> individual steps of the process can be manipulated. All fields are optional. If they are not specified, the original value is used. Otherwise the field is overwritten with the configured field content. If the field is of type String, it can also be specified empty to empty it.

Docket: docket

In this element, the assigned docket can be replaced. The xsl file to be used must exist on the server. If a docket has already been defined with the new specifications, it will be used, otherwise a new docket will be defined and stored in the database.

Project: project

This rule can be used to change the assigned project. The project must already exist. Changes to the projects themselves can be made using Import infrastructure.

| Element | Example | Meaning | | :--- | :--- | :— | | @name | | Project A | Old Project | | | newProjectName | Project B | New Project |

Properties: property

This rule is used to manipulate process properties.

| Element | Example | Meaning | | :--- | :--- | :— | | @name | CollectionName | Name of the property to be adjusted. | | oldPropertyValue | Digitised | Value of the property to be adjusted. If a value is specified, the property must contain this value. | | newPropertyName | Collection | New name of the property. Optional. | | newPropertyValue | default collection | New value of the property. Optional. |

Ruleset: ruleset

This rule can be used to change the assigned rule set. If the ruleset does not yet exist, it is created and saved in the database. The file must exist on the server.

| Element | Example | Meaning | | :--- | :--- | :— | | @name | Default | Name of the ruleset used so far. | | newRulesetName | default ruleset | New name for the ruleset. | | newFileName | ruleset.xml | New file name for the ruleset. This must exist on the target system. |

Metadata: metadata

With this rule the metadata can be changed. Values of existing metadata can be changed, new metadata added or existing metadata deleted.

Further configurations

Further general settings can be defined within a rule.

The import of data on the target system takes place using two different plugins. These must first be installed and configured accordingly. More information about their installation and configuration can be found here:

After the successful installation, you can continue with the actual import. A distinction must be made here between the pure import of processes and the import of an exported infrastructure. Depending on the project, the import of the infrastructure may be necessary as the first step.

1. Import of the infrastructure

In the area for importing the infrastructure, the previously exported infrastructure of the source system can be imported. To do this, first open the plugin Goobi-to-Goobi Import - Infrastructure in the Administration menu.

At this point you can now upload a zip file that was previously created on the source system. After the successful upload, the file is unpacked on the server and analyzed. The user then receives a summary of the data to be imported.

If users, projects, groups, etc. already exist in the target system with the same name as the data to be imported, they do not count as new data to be imported and cannot be overwritten. After selecting the importing data, the import can be started by clicking on Execute import of infrastructure.

If desired, the data can be manipulated during the import. This is possible by adapting the configuration file plugin_intranda_administration_goobi2goobi_import_infrastructure.xml. More details can be found in the section Configuration for importing the infrastructure here:

2. Import of processes

To import the processes from the source system, they must first be successfully exported and transferred to the target system. How the transfer of the sometimes very large amounts of data can take place is described here:

Once the data has been completely transferred to the target system, you can start the import of the data. To do this, open the plugin Goobi-to-Goobi Import - Data in the Administration menu. There the configured rules for the import are displayed in the upper part of the user interface. If these rules are edited on the target system, they can be reloaded at any time by clicking on the Reload rules button.

The actual import takes place in the lower area of the user interface. There the user can first search for the data to be imported by clicking on Reload files. If this search takes longer than 10 seconds due to the large amount of data, the further search takes place in the background and the user gets the feedback that he should please update the page again after some time.

If files are successfully listed after the search of the data to be imported, they can now be selected. To do this, you can either select them individually or let Goobi select them all by clicking on Select all. To do this, you need to select the rule that you want to apply to the import. This can either be selected directly or determined using Autodetect rule. In this case, the system checks whether there is a rule that corresponds to the name of the project to which the process was assigned.

A click on the button Perform import of data then starts the actual import. During this import, an internal Goobi ticket is created for each selected process and sent to the internal queue (Message Queue). The individual tickets are processed in the background and the processes are thus imported successively.

You can configure the import and the underlying rules in detail in the configuration file plugin_intranda_administration_goobi2goobi_import_data.xml. Further information about this configuration can be found in the section Configuration for import of data:

Overview

Introduction

This documentation describes the installation, configuration and use of the Administration Plugin for automated repeated retrieval of data (e.g. from a catalog) to update records in Goobi workflow.

Installation

The plugin consists in total of the following files to be installed

These files must be installed in the correct directories so that they are in the following paths after installation:

In addition, there is a configuration file that must be located at the following location:

Overview and functionality

The Data Poller plugin is automatically activated by Goobi. Its runtime starts at the configured start time and repeats according to the configured number of hours, e.g. every 24 hours, i.e. once a day.

If a user wants to have access to the plugin's user interface in addition to this automatic feature, he must belong to a user group that has been granted the following plugin-specific permission for this purpose:

To assign this right, the desired user group must first have the permission entered in the right pane.

If the permission for the user group should be newly entered, the user must first log in to Goobi again to be able to use this permission level. Afterwards he can click on the plugin Data Poller in the menu Administration and there he can also manually re-trigger an update of the data records by means of a query at any time.

Automatic backups

If the plugin finds updated metadata for an operation and therefore updates the METS file, it will first automatically create a backup of the current METS file meta.xml and if relevant also of meta_anchor.xml. The backup is stored next to the updated METS file.

Logging within the journal

The updates of the metadata by the plugin usually take place fully automatically in the background. In order to be able to understand nevertheless at any time for a data record, what happened with this in the meantime, the events are logged. For each process for which there were changes from this plugin, detailed entries are therefore automatically inserted within the ‚journal'. In addition to the timestamp, these contain, among other things, an exact listing of the changed metadata fields together with their contents. Thus, it is possible at any time to trace the previous or the new value as well.

Configuration

The configuration of the plugin is done via the configuration file plugin_intranda_administration_data_poller.xml and can be adjusted during operation. The following is an example configuration file:

Attributes of the rule element

Subelements of the rule element

Additional elements/parameters - rule type filter

Additional elements/parameters - rule type hotfolder

Overview

Introduction

This documentation describes the installation, configuration and use of the Administration Plugin for the automated transfer of a central anchor file of a volume (e.g. from journals or multi-volume works) to other volumes within Goobi workflow.

Installation

To be able to use the plugin, the following files must be installed:

There is currently no configuration file for this plugin.

Overview and functionality

If the plugin has been installed and configured correctly, it can be found under the menu item Administration.

Definition of a master anchor

Once the plugin has been fully set up, it can be used. To do this, first add the newly defined metadata InternalNote within the tape that is to be marked as the master anchor and enter AnchorMaster as the value. This is illustrated in the following screenshot:

The adapted journal volume was defined as the master with this change. From now on, the metadata of the parent work (e.g. the journal) used there will serve as the default for all other associated volumes. Changes that are to be made for all volumes within the anchor files will therefore be made within this data record from now on.

Transfer of metadata for all associated volumes

As soon as a volume has been defined as the master within a Goobi process, the plugin can be used to transfer all metadata from the master to all associated volumes. To do this, proceed as follows:

First open the plugin using the Administration menu and then the Copy master anchor data menu item.

Enter the catalogue identifier of the parent work in the input field of the plugin (e.g. the ID of the journal) and then click on the Start copying process button. This starts the copying process, which automatically copies the metadata of the master anchor data record to all associated volumes (e.g. all volumes of the journal).

Configuration

The plugin does not have its own configuration file. Nevertheless, customisation of the rule set used is a mandatory requirement for the operation of the plugin. This is shown by way of example using a rule set that can be found under the following path:

The metadata InternalNote must be defined within the rule set:

This metadata must now be allowed within the definition of the volumes. This is done using a journal volume as an example:

With this adjustment to the rule set, the preparations for using the plugin are already complete.

The following functions are available within the plugin for archive management:

Selection of existing inventories

Once the plugin has been opened, a list of available archive holdings is displayed. Here the user can select an archive inventory and start editing it.

Alternatively, a new archive inventory can also be created. In this case, a name must first be assigned to the file. The name must be unique as it is used for identification. In addition, no special characters such as :/\ should be used, as the name is also the basis for the file name of the EAD export.

The third option is to import an existing file. An EAD file can be selected and uploaded here. If no inventory with the name of the file exists yet, the file is imported as a new inventory and opened directly. If the name is already in use, the existing inventory can be overwritten with the content of the EAD-XML file after a query.

If the user has authorisation to create new inventories, a copy of an inventory can also be created using the corresponding button. This creates a new fonds and copies all nodes with all their metadata. The only exception here is the ID of the nodes. These are automatically created and assigned to the nodes.

After selecting the archive to be edited, the user is forwarded to the editing screen. The structure tree can now be edited in the left-hand area. The details of the selected node can be edited in the right-hand area.

By clicking on the buttons Cancel (read rights) or Save and exit archive (write rights), you will be redirected to the page for selecting an archive.

Edit structure tree

The structure of the archive file can be edited in the left-hand area of the editing screen. All nodes including their hierarchy can be viewed here at a glance. There is an icon in front of each element that can be used to display or hide the sub-elements of the node. To select a node, click on it. It is then highlighted in colour and the details of the selected node are displayed on the right-hand side. If a node has been selected in the left-hand area of the editing screen, the buttons on the right-hand edge of the left-hand box can also be used to change the node. The following options are available:

To generate several sub-nodes at once, the number of nodes to be created and their type must be defined. Various metadata can then be defined and entered in all new nodes. Either the same text can be used in all fields, an identifier can be generated or a text with a subsequent counter can be generated. The counter format and the start value can be defined here.

In the upper area of the hierarchy display, you can also search within the metadata of the nodes. The nodes found, including the hierarchy, are displayed and highlighted in colour. To reset the search, it is sufficient to empty the content of the search term again and perform an empty search accordingly. Alternatively, the button on the left-hand side of the search field can be used.

The advanced search can be used to the right of the field. Individual fields can be searched for here. Which fields are available can be controlled via the configuration file (attribute searchable=‘true’ within <metadata>).

Editing a selected node

If a node has been selected in the left-hand area, the details of the selected node are displayed in the right-hand area.

The right-hand area is divided into several categories. The corresponding Goobi process is displayed at the top of the right-hand section, along with an option to create the docket. If no Goobi process has yet been created for the node, a new process can be created on the basis of the configured production template. The selected node type is used as the document type in accordance with the configuration. Depending on the configuration and the rule set used, the following options are available, for example:

• Folder

• File

• Image / Picture

• Audio

• Video

• Other / Miscellaneous

The individual metadata of the node is listed below the document type. They are divided into the following areas in accordance with the ISAD(G) standard:

• Identification

• Context

• Content and internal organisation

• Conditions of access and use

• Related documents

• Annotations

• Cataloguing control

Each of these areas can be opened and closed individually. Even if an area is collapsed, it is very easy to recognise which metadata per area is possible and which is already filled in. The individual metadata are displayed as differently highlighted badges. A dark background indicates that a value has already been entered for this metadata. A light background indicates that this field is still empty. If a field can be created repeatedly, the badge contains a plus icon.

If the details of an area are expanded, the individual metadata is displayed. By default, only those fields that already have a value are displayed. Additional fields can be added by clicking on one of the badges. Fields can be removed again using the minus icon.

Validation of the metadata

Both the Download as EAD file button and the Execute validation button ensure that the metadata is valid. The configured rules are applied and it is checked whether individual values violate them. If this is the case, the affected nodes are highlighted in colour in the left-hand area. If such an invalid node is selected, the affected badges are displayed in red and the configured error text is displayed in the metadata alongside the border.

A failed validation does not prevent the archive from being saved or Goobi processes from being created.

Saving the data

Unless editing is only carried out in read-only mode, data is always saved automatically when you insert or delete nodes, switch to another node, export the data, create a copy of it or create links or end editing using Save and exit.

Export and download

The two buttons for Download as EAD file and the Viewer export generate a new EAD based on the current status of the nodes. With the exception of the top node, each node is displayed as an independent <c> element. The data of the top node is written within the <archdesc> below the <ead> element.

With viewer export, the generated file is written to the Goobi viewer hotfolder, whereas with download it can be saved locally.

The generated file contains all metadata in the form in which it was specified in the configuration file. The content of the xpath attribute of the metadata is used. If there is no entry for a field, it is an intensive metadata that is not exported as an EAD.

After the export directories have been created, the task folders can be copied from the source system to the target system. Depending on the amount of data involved, different methods can be used for the transfer.

Transfer using an external hard disk

If an external hard disk is to be used for the transfer, the cp command can be used to copy from the source system to the hard disk and later back from the hard disk to the target system.

Example call for the copy operation from the source system to the external hard disk:

cp -r /opt/digiverso/goobi/metadata/* /external_harddisk/export/

Example call for the copy operation from the external hard disk to the target system:

cp -r /external_harddisk/export/* /opt/digiverso/TEMP/

Transfer via the Internet

If a network connection can be established between the source system and the target system, data transfer is possible using the commands scp or rsync. The advantage of transferring data using rsync is that any interruption of the connection can be resumed without having to start the entire transfer again from the beginning.

An example of such a call is as follows:

rsync -avhP --stats /opt/digiverso/goobi/metadata/ ZIELSYSTEM:/opt/digiverso/TEMP/

If the call should only transfer certain directories, use a maximum bandwidth and also exclude other data, such a call could also become a bit more extensive:

rsync -avhP --stats --bwlimit=10000 --exclude 'taskmanager' --exclude '*.xml.*' /opt/digiverso/goobi/metadata/{1,2,3,4,5,6,7,8,9,10} ZIELSYSTEM:/opt/digiverso/TEMP/

Transfer to an S3 Bucket of an AWS system

To export to an S3 Bucket to AWS you can use the script s3sync.py.

Overview

Introduction

This plugin is used to directly edit the various configuration files of Goobi workflow directly from the user interface within the web browser.

Installation

The plugin consists in total of the following files to be installed:

plugin_intranda_administration_config_file_editor_base-base.jar
plugin_intranda_administration_config_file_editor-gui.jar
plugin_intranda_administration_config_file_editor.xml

These files must be installed in the correct directories so that they are available under the following paths after installation:

/opt/digiverso/goobi/plugins/administration/plugin_intranda_administration_config_file_editor-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin_intranda_administration_config_file_editor-gui.jar
/opt/digiverso/goobi/config/plugin_intranda_administration_config_file_editor.xml

This plugin has its own permission level for use. For this reason, users must have the necessary rights.

Therefore, please assign the following right to the user group of the corresponding users:

Plugin_administration_config_file_editor

Overview and functionality

After installation, the plugin can be found in its own entry in the Administration menu, from where it can be opened.

After opening, all Goobi configuration files are listed on the left-hand side. These can be opened by clicking on the respective icon in order to edit them.

Please note that the configuration file of this plugin does not appear in the list by default for security reasons and is editable only by super administrators.

Also, no hidden files and no files from hidden folders are displayed.

If you open a file, a text editor appears on the right-hand side in which the file can be edited. If you edit and save a file, a backup is automatically created in the defined backup directory.

According to the value set in the configuration file, a certain number of older backups are retained here before they are replaced by newer ones.

If a file has been changed and an attempt is made to change to another file without saving it, the operator is asked how to proceed with the changes.

Within Goobi, help texts can be defined for configuration files, which can be helpful for editing in this editor. The stored help texts are displayed in the left-hand area depending on the file currently open and also have the option of working with formatting here.

Configuration

The plugin is configured via the configuration file plugin_intranda_administration_config_file_editor.xml and can be adapted during operation. The following is an example configuration file:

<?xml version="1.0" encoding="UTF-8" ?>
<config_plugin>
    <!--
    The configFileDirectories element contains a list of directories
    that are used to collect all displayed files in the browser interface.

    Each directory should be an absolute path that contains xml or properties files.
    Other file types are not supported until now.
    The directory name may end with a slash (/), otherwise it will be added automatically.

    Backups are automatically created in a subfolder called "backup/".
    You can override this with the optional attribute backupFolder="myOwnBackupPath/".
    IMPORTANT: The directory must be an absolute path while the backupFolder parameter must be a relative path.
    The backup directory name may end with a slash (/), otherwise it will be added automatically.
    To save backup files in the selected configuration directory, overwrite the backup folder with backupFolder="".

    By default 8 backup files are kept, older files will be deleted.
    You can override this with the optional attribute backupFiles="".

    You can filter the displayed configuration files in a directory with the fileRegex="" parameter.
    If the parameter is not used or is empty, it will be ignored.
    -->

    <configFileDirectories>
        <directory backupFiles="16">/opt/digiverso/goobi/config/</directory>
        <directory backupFolder="wizzardBackup/" backupFiles="4">/opt/digiverso/layoutwizzard/</directory>
        <directory backupFolder="itmPluginsBackup/" backupFiles="4" fileRegex=".*\.xml">/opt/digiverso/itm/plugins/config/</directory>
        <directory backupFolder="itmBackup/" fileRegex=".*\.xml">/opt/digiverso/itm/config/</directory>
        <!--
        Example:
        <directory backupFolder="exampleBackup/" backupFiles="12" fileRegex="*\.xml">/opt/digiverso/example/config/</directory>
        -->
    </configFileDirectories>

</config_plugin>

The parameters within this configuration file have the following meanings:

If help texts for individual configuration files are to be displayed, these must be stored within the messages files. For this purpose, an adjustment is made in these files, for example:

/opt/digiverso/goobi/config/messages_de.properties
/opt/digiverso/goobi/config/messages_en.properties

For each configuration file, a value like the following can be entered there in the respective file.

German version within the file messages_de.properties:

plugin_administration_config_file_editor_help_goobi_projects.xml = Dies ist ein Hilfetext für die Konfiguration der Anlegemaske. <br/>Hier kann eine <i>Beschreibung</i>, die <b>formatiert</b> ist.<br/><br/><pre>Und auch Quellcode kann hier stehen</pre>

English version within the file messages_en.properties:

plugin_administration_config_file_editor_help_goobi_projects.xml = This is a help text for the creation mask. <br/>You can add a <i>Description</i> here, which is <b>formatted</b>.<br/><br/><pre>And you can put source code here as well</pre>

Note that the prefix plugin_administration_config_file_editor_help_ is added before the name of the configuration file.

Overview

Introduction

The two plugins described here can be used to transfer data from one Goobi workflow system to another Goobi workflow system (Goobi-to-Goobi). This documentation explains how to install, configure and use the associated plugins.

Installation and configuration

Before the export and import mechanism can be used, various installation and configuration steps must be completed. These are described in detail here:

Installation

Mode of operation

The mechanism for transferring data from one Goobi workflow system to another Goobi workflow system (Goobi-to-Goobi) is divided into three major steps.

These three steps are as follows:

a) Creation of the export directories

The first step involves enriching the data within the file system on the source system with the information that Goobi has stored internally in the database for each process. When this step is performed, an additional xml file containing the database information on the workflow and some other necessary data is written to the folder for each Goobi process.

Erzeugung der Export-Verzeichnisse

b) Transfer of the export directories

After the complete creation and enrichment of the export directories on the source system, they can be transferred to the server of the target system. This can be done in different ways. Due to the amount of data involved, a transfer using rsync has proven to be the most suitable.

Transfer der Export-Verzeichnisse

c) Importing the export directories

After the export directories have been successfully transferred to the target system, the data can be imported there. To do this, the data must be stored in the correct place in the system and some further precautions regarding the infrastructure must also be prepared.

Einspielen der Export-Verzeichnisse

On the following pages you will find documentation for various plug-ins and extensions for Goobi workflow. Please select the desired plugin from the table of contents on the left to access the documentation.

Please note that within Goobi workflow there are different types of plugins for the respective application scenarios.

Export Plugins

Export plugins are used to export data from Goobi workflow to another system. They are executed either automatically as part of the workflow or manually by clicking on the corresponding icon in the process list. They are usually installed within this path:

/opt/digiverso/goobi/plugins/export/

Export plug-ins within Goobi are set up in such a way that they are selected from the list of step plug-ins within a workflow for a step and the Export checkbox is also activated. Usually, the checkbox Automatic task is also selected in order to have the exports executed automatically in the course of the workflow.

Some export plugins have their own configuration file. This file is generally named like the plugin itself and is usually located at the following path:

/opt/digiverso/goobi/config/

Step Plugins

Step plugins are used to extend tasks within the Goobi workflow. Such plugins can be used, for example, to integrate individual functionality into the workflow that Goobi does not provide out-of-the-box. Examples of such plug-ins include special conversion plug-ins, entry masks, image manipulations, etc.

Such step plugins are installed in the folder:

/opt/digiverso/goobi/plugins/step/

If a plugin also has a user interface in addition to the actual functionality, the part of the user interface must also be installed in this folder:

/opt/digiverso/goobi/plugins/GUI/

Step plugins in Goobi are set up in such a way that they are selected as plugins within a task.

Please note that there are currently three different types within Step Plugins:

Some Step Plugins have their own configuration file. This file is generally named like the plugin itself and is usually located at the following path:

/opt/digiverso/goobi/config/

Opac Plugins

Opac plugins are used for communication with external data sources. Typical examples are plugins for the connection of library catalogues or databases. Depending on the data source, different implementations exist for this in order to correctly address the respective interface to be used.

Opac plugins are usually installed in this path:

/opt/digiverso/goobi/plugins/opac/

After installing such a plugin, it is available in the Search in Opac field within the Create Processes in Goobi screen.

Import Plugins

Import plugins are used for the execution of larger mass imports. Unlike Opac plugins, they do not query from a single data source, process by process. Instead, import plugins usually import hundreds or thousands of data at the same time, often in different formats. Common examples here include import plugins for importing SQL dumps, Excel tables or other proprietary data sources.

The import plugins are installed in the folder:

/opt/digiverso/goobi/plugins/import/

These plugins are used in a separate mask for mass imports in which you select the different import mechanism and the desired plugin before selecting the data.

Some import plugins have their own configuration file. This is generally named like the plugin itself and is usually located at the following path:

/opt/digiverso/goobi/config/

Administration Plugins

Administration plugins are available for some special use cases. The special feature is that these plugins are not functionally restricted. They are not explicitly integrated at a given point within the workflow nor are they executed at a defined moment. Instead, they usually have their own user interface and offer independent functionality as an extension of Goobi. Examples of this include administrative intervention in process data or the administration of controlled vocabularies.

The installation of the administration plugins takes place in the folder:

/opt/digiverso/goobi/plugins/administration/

‌Since most administration plugins have a user interface in addition to the actual functionality, this must also be installed into the following folder:

/opt/digiverso/goobi/plugins/GUI/

Some administration plugins have their own configuration file. This file is generally named like the plugin itself and is usually located at the following path:

/opt/digiverso/goobi/config/

Workflow Plugins

The workflow plugins are technically very similar to the administration plugins. They can also offer an independent user interface for the provision of additional functionality. In contrast to the administration plug-ins, however, access to these plug-ins is also possible without administrative rights within Goobi, so that a larger group of users usually has access to these functions.

The workflow plug-ins are installed in the folder:

/opt/digiverso/goobi/plugins/workflow/

Since most workflow plugins have a user interface in addition to the actual functionality, it must also be installed in the following folders:

/opt/digiverso/goobi/plugins/GUI/

Some administration plugins have their own configuration file. This file is generally named like the plugin itself and is usually located at the following path:

/opt/digiverso/goobi/config/

Dashboard Plugins

With the Dashboard Plugins it is possible to provide a special Dashboard with additional functionality instead of the standard start page. This could, for example, already display some statistical information that shows integration with other systems and also give an insight into the current monitoring.

The Dashboard Plugins are installed in the folder:

/opt/digiverso/goobi/plugins/dashboard/

The user interface of the dashboards must also be installed in the following folders:

/opt/digiverso/goobi/plugins/GUI/

Some Dashboard plugins have their own configuration file. This is generally named like the plugin itself and is usually located at the following path:

/opt/digiverso/goobi/config/

Please also note that individual dashboards must always be activated within the main configuration file goobi_config.properties. This can be done as follows:

dashboardPlugin=intranda_dashboard_extended

Statistics Plugins

The statistics plugins are available for the provision of individual statistics. Depending on which of these plugins are installed, a wide variety of statistical evaluations can be carried out, either as diagrams, tables or downloads in various formats.

The installation of the statistic plugins takes place in the folder:

/opt/digiverso/goobi/plugins/statistics/

The user interface of the statistic plugins must also be installed in the following folders:

/opt/digiverso/goobi/plugins/GUI/

Validation Plugins

In Goobi, the validation plug-ins are used to ensure that data is available as required before completing a step. If the validation is not successful, the user cannot complete the task and therefore cannot remove it from his task list.

The validation plugins are installed in the folder:

/opt/digiverso/goobi/plugins/validation/

The validation plug-in must then be selected accordingly in the Validation plug-in field within the task for the required workflow step.

Some validation plugins have their own configuration file. This is generally named like the plugin itself and is usually located at the following path:

/opt/digiverso/goobi/config/

REST Plugins

With the REST plugins, Goobi has another way for external systems to communicate with Goobi. In contrast to the Web API, however, communication here is via REST and takes place largely via JSON.

REST plugins are installed in the following folder:

/opt/digiverso/goobi/lib/

Like the Web-API plugins, the REST plugins do not have their own user interface. Also the access permission is controlled by the same configuration file and controls the access from selected IP addresses and authentication. For the REST Plugins the configuration is done in the following file:

/opt/digiverso/goobi/config/goobi_rest.xml

The export from the source system consists of up to three sub-steps. However, before the export can take place, it must first be specified within the role system of Goobi workflow that the user must have export permissions. Information on the configurations to be made can be found here:

Installation

After configuring the required user rights, the actual export can begin. In most cases, only the first of the following three steps will be necessary.

1st sub-step: Creating the export files for processes

For most purposes, only this sub-step is required to generate the export files for all desired processes. For all selected processes within the file system, an xml file with all relevant information about the process is generated from the database in the folder of each selected process.

Export using GoobiScript

To perform such an export for several processes together, you can start it using GoobiScript. The following GoobiScript command is required for this:

action:exportDatabaseInformation

When you run this GoobiScript, you will find the relevant export xml file (e.g. 5_db_export.xml) in each process folder.

Manual export for individual processes

To perform such an export for a single process, it is possible to start it within the details of a process. To do this, simply click on the corresponding icon for the export.

Unlike exporting via GoobiScript, this starts a download of the xml file that contains the database information.

2nd sub-step: Exporting the process templates

Notice: This substep is optional and is only required in rare cases.

If you want to transfer more than just processes from one Goobi workflow to another, you can also generate export data for process templates. However, as GoobiScript is not available within the process template area, this export can be done from the provided Goobi-to-Goobi Export plugin within the Administration menu.

Now click on the button Generate database files for process templates. This will also save an xml file with the database information for each process template in the file system and can be used for the transfer to the target system.

3rd sub-step: Export of the infrastructure

Notice: This substep is optional and is only required in rare cases.

If, in addition to the actual Goobi processes, you also want to transfer more detailed information about the infrastructure from one Goobi workflow to another, you can also have this exported within the export plugin. To do this, select the checkboxes provided within the Goobi-to-Goobi Export plugin to influence the export in a targeted manner. The following parameters are available for this:

Once you have selected the desired information and clicked on the Download infrastructure as a zip file button, Goobi generates a zip file and offers it for download under the name goobi-to-goobi-export.zip. This zip file now contains all the information selected from the Goobi database for transfer to the target system.

Overview

Introduction

This documentation describes the installation, configuration and use of the Administration Plugin for automated checking of a large number of processes within Goobi workflow with the assigned rule set. Any incompatibilities with the respective rule sets are identified and a corresponding message about the specific incompatibility is displayed.

Installation

The plugin consists of the following files to be installed:

plugin-intranda-administration-ruleset-compatibility-base.jar
plugin-intranda-administration-ruleset-compatibility-gui.jar
plugin_intranda_administration_ruleset_compatibility.xml

These files must be installed in the correct directories so that they are available in the following paths after installation:

/opt/digiverso/goobi/plugins/administration/plugin-intranda-administration-ruleset-compatibility-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin-intranda-administration-ruleset-compatibility-gui.jar
/opt/digiverso/goobi/config/plugin_intranda_administration_ruleset_compatibility.xml

To use this plugin, the user must have the correct role authorisation. Therefore, please assign the role Plugin_administration_ruleset_compatibility to the user group.

Overview and functionality

If the plugin has been installed and configured correctly, it can be found under the menu item Administration. After accessing it, the parameters described above can be customised again in the interface.

After clicking on the button Execute plugin the check of the METS files starts. A progress bar informs about the progress. The processes already processed are listed within the table. Any incompatibilities are immediately displayed. In addition, it is possible to directly enter the metadata editor of individual processes.

Configuration

The plugin is configured via the configuration file plugin_intranda_administration_ruleset_compatibility.xml and can be adapted during operation. The following is an example configuration file:

<config_plugin>
	
	<!-- default filter to use -->
	<filter>stepdone:export</filter>
	
</config_plugin>

Overview

Introduction

This plugin is used to directly edit the ruleset files of Goobi workflow directly from the user interface within the web browser.

Installation

The plugin consists in total of the following files to be installed:

plugin_intranda_administration_ruleset_editor-base.jar
plugin_intranda_administration_ruleset_editor-gui.jar
plugin_intranda_administration_ruleset_editor.xml

These files must be installed in the correct directories so that they are available under the following paths after installation:

/opt/digiverso/goobi/plugins/administration/plugin_intranda_administration_ruleset_editor-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin_intranda_administration_ruleset_editor-gui.jar
/opt/digiverso/goobi/config/plugin_intranda_administration_ruleset_editor.xml

This plugin has its own permission level for use. For this reason, users must have the necessary rights.

Therefore, please assign the following right to the user group of the corresponding users:

Plugin_administration_ruleset_editor

Overview and functionality

After installation, the plugin can be found in its own entry in the Administration menu, from where it can be opened.

After opening, all Goobi ruleset files are listed on the left-hand side. These can be opened by clicking on the respective icon in order to edit them.

If you open a file, a text editor appears on the right-hand side in which the file can be edited. If you edit and save a file, a backup is automatically created in the defined backup directory.

According to the value set in the configuration file, a certain number of older backups are retained here before they are replaced by newer ones.

If a file has been changed and an attempt is made to change to another file without saving it, the operator is asked how to proceed with the changes.

Configuration

The plugin is configured via the configuration file plugin_intranda_administration_ruleset_editor.xml and can be adapted during operation. The following is an example configuration file:

<config_plugin>
	
	<!-- By editing a ruleset file in the browser GUI, a backup file will be stored in the backup directory -->
	<rulesetBackupDirectory>/opt/digiverso/goobi/rulesets/backup/</rulesetBackupDirectory>

	<!-- backup files will be stored as ruleset.xml.1, ruleset.xml.2, ..., ruleset.xml.n -->
	<numberOfBackupFiles>10</numberOfBackupFiles>
	
</config_plugin>

The parameters within this configuration file have the following meanings:

Overview

Introduction

This plugin for Goobi workflow restores image folders that were previously archived with the plugin goobi-plugin-step-archiveimagefolder.

Installation

The plugin consists of the following files to be installed:

goobi-plugin-administration-restorearchivedimagefolders-base.jar
goobi-plugin-administration-restorearchivedimagefolders-gui.jar
plugin_intranda_administration_restorearchivedimagefolders.xml

These files must be installed in the correct directories so that they are available in the following paths after installation:

/opt/digiverso/goobi/plugins/administration/plugin-intranda-administration-restorearchivedimagefolders-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin-intranda-administration-restorearchivedimagefolders-gui.jar
/opt/digiverso/goobi/config/plugin_intranda_administration_restorearchivedimagefolders.xml

To use this plugin, the user must have the correct role authorisation. Therefore, please assign the role Plugin_administration_restorearchivedimagefolders to the user group.

Overview and functionality

The plugin offers a graphical user interface that can be opened via the menu Administration. There, a search filter can be used, as it is used in other parts of Goobi workflow (e.g. for the task list). Clicking on 'Run Plugin' will then restore the images for the tasks found via the filter entered. The user interface updates automatically.

Configuration

The configuration file is empty at the moment, but must still be present.

<config_plugin>
  <!-- currently no configuration is needed -->
</config_plugin>

The information from where the data is to be fetched is stored in the respective process folder in an XML file by the archiving plug-in.

For authentication on ssh servers, public keys are searched for in the usual places ($USER_HOME/.ssh). Other authentication methods such as username/password are not provided.

Overview

Introduction

This dashboard plugin was developed to facilitate the use of a barcode scanner in the Goobi Workflow. On the right side is a form for various actions, such as accepting and completing tasks or tracking the location of objects.

Installation

In order to use the plugin, the following files must be installed:

/opt/digiverso/goobi/plugins/dashboard/plugin_intranda_dashboard_barcode.jar
/opt/digiverso/goobi/plugins/GUI/plugin_intranda_dashboard_barcode-GUI.jar

To configure how the plugin should behave, various values in the configuration file can be adjusted. The configuration file is usually located here:

/opt/digiverso/goobi/config/plugin_intranda_dashboard_barcode.xml

To use this plugin, the user must select the intranda_dashboard_barcode value within the dashboard settings.

Overview and functionality

To use this dashboard plugin, you first need to activate it via Settings -> General -> Dashboard and then log in again. If the plugin is correctly installed and configured, it should already be activated under the Dashboard menu item.

On the right side, there is a form with various actions. You can select one by clicking on it. If the action Change Location Only is chosen, an additional input field will appear, expecting the name of the new location.

For all actions, there is a mandatory input field where the title of the Goobi process is expected. This field is automatically focused after loading to facilitate the use of a barcode scanner. By clicking the Execute button, the selected action will be performed, and messages regarding success will be displayed. The performed action and the input location are saved to facilitate further applications. They remain unchanged until a manual change is made.

Im Fall, dass Ortwechsel erfasst werden, sind diese auch zu einem späteren Zeitpunkt jederzeit innerhalb des Journals noch nachvollziehbar.

Der jeweils aktuelle Aufenthaltsort des Objektes wird darüber hinaus in einer eigenen Eigenschaft gespeichert.

Configuration

The plugin is configured in the file plugin_intranda_dashboard_barcode.xml as shown here:

<?xml version="1.0" encoding="UTF-8"?>

<config_plugin>
	
	<!-- number of previous tasks that shall be shown -->
	<tasks-latestChanges-size>37</tasks-latestChanges-size>
	
	<!-- display the option to accept tasks -->
	<show-accept-option>true</show-accept-option>
	​
	<!-- display the option to finish tasks -->
	<show-finish-option>true</show-finish-option>
	​
	<!-- display the option to accept and finish tasks as one action -->
	<show-accept-and-finish-option>true</show-accept-and-finish-option>
	​
	<!-- display the option to change the location -->
	<show-change-location-option>true</show-change-location-option>
	
	<!-- define which filter shall be used to find the processes. Use {BARCODE} 
	as placeholder for the input field content (e.g. "meta:*:{BARCODE}" ) -->
	<filter>meta:*:{BARCODE}</filter>
	
</config_plugin>

The following table contains a summary of the parameters and their descriptions:

Overview

Introduction

This plugin is used for a special export of multiple METS files per process. From a single METS file within Goobi workflow, a separate METS file with the associated image files is created during the export for each structural element contained.

This plugin was developed for the Federal Office for the Protection of Monuments in Austria and is functionally geared to their needs and therefore may not be directly applicable to other use cases.

Installation

The plugin consists of the following files to be installed:

This file must be installed in the following directory:

Overview and functionality

To put the plugin into operation, it must be activated for one or more desired tasks in the workflow. This is done as shown in the following screenshot by selecting the plugin intranda_export_singleImage from the list of installed plugins.

Since this plugin should usually be executed automatically, the workflow step should be configured as automatic. In addition, the task must be marked as an export step.

Once the plugin has been fully installed and set up, it is usually run automatically within the workflow, so there is no manual interaction with the user. Instead, calling the plugin through the workflow in the background does the following:

For each structural element within the METS file, an independent METS file is created during the export, to which the respective image files are exported along with it. The entire METS file is not exported. The number of METS files created in this way differs accordingly from the number of Goobi processes and corresponds to the number of existing structural elements.

Configuration

This plugin does not have its own configuration file.

Overview

Introduction

This dashboard plugin provides an improved overview through detailed display options. For example, the most recently edited tasks or relevant statistics can be shown.

Installation

In order to use the plugin, the following files must be installed:

To use this plugin, the user must select the value intranda_dashboard_extended within the dashboard settings.

Overview and functionality

If the plugin is installed correctly and users have set it as their dashboard, it will be visible after logging into Goobi workflow instead of the start page.

Configuration

The plugin is configured in the file plugin_intranda_dashboard_extended.xml as shown here:

The following table contains a summary of the parameters and their descriptions:

Overview

Introduction

This documentation describes the installation, configuration and use of the Heris export plugin in Goobi.

This plugin for Goobi workflow can be used to export the images and associated metadata selected in a previous step to a JSON file. The export is then carried out via SFTP to an external server.

Installation

The following files must be installed in order to use Heris Export:

An automatic step must be inserted in the workflow in which the intranda_export_heris plugin has been selected. This step must be carried out after the step with the "Image Selection" plugin, in which the images to be exported are selected.

Overview and functionality

When the plugin is executed, it first checks whether at least one image has been selected in the step with the Image Selection plugin. If this is the case, the following tasks are carried out:

• Copying the selected images to a temporary folder

• Check whether there is already an older export for the current HERIS ID

  • If yes, create a backup of the old JSON file, download the old JSON file

  • Check whether the selected files correspond to the image names in the old JSON file

    • For each image that remains the same, the old image identifier is determined so that it can be reused in the new JSON.

    • every image that has already been exported and is no longer present in the new export is deleted remotely

    • each new image that did not exist in the old export is treated as a completely new export

• Determination of the metadata for the selected images

• Creation of the JSON file from the determined metadata, retaining the old image IDs if necessary

• Copy the generated data to the destination

• Deleting the temporary data

Configuration

The configuration takes place in the file plugin_intranda_export_heris.xml as shown here:

The <config> area can be repeated, allowing different exports for different projects or steps.

The <propertyName> field defines the property in which the selected images are saved. This value must match the configuration of the image selection plugin.

The JSON file is then described. The <herisId> field contains the metadata in which the HERIS ID is saved and the <jsonRootElement> is used to configure the name of the JSON object in which the individual images are described.

The individual fields of the image objects are described in the <field> list. Each field has three entries.

• The name attribute defines the name of the element within the JSON file.

• The value is described in the element itself.

• The type is used to specify what type it is. The value is interpreted differently depending on the type.

The following specifications are possible:

• static: The value is written unchanged as text in the JSON.

• filename: The image name is saved here.

• representative: Can contain the values true/false. The first image in the list is used as the representative.

• identifier: Contains the identifier of the image from the HERIS database. The previous identifier is reused during a re-export. The field remains empty for new exports.

• metadata: The value is interpreted as a metadata and determined from the metadata. The metadata is first searched for in the sub-element "photo" that was assigned to the image. If this does not exist, the metadata is expected in the main element 'Document'.

The SFTP connection is configured in the last block. Options are available here for authentication using user name and password, user name and key or user name and password-protected key.

Overview

Introduction

This documentation describes how to install, configure and use an export plugin in Goobi.

Using this export plugin for Goobi, Goobi operations can be exported to multiple locations simultaneously within one operation.

Installation

This plugin is integrated into the workflow in such a way that it is executed automatically. Manual interaction with the plugin is not necessary. For use within a work step of the workflow, it should be configured as shown in the screenshot below.

The plugin must first be copied into the following directory:

In addition, there is a configuration file that must be located in the following place:

Configuration

The plugin is configured via the configuration file plugin_intranda_export_configurable-base.jar and via the project settings. The configuration can be adjusted during operation. The following is an example configuration file:

The config block

The block <config> is repeatable and can thus define different metadata in different projects. The block with <project>*</project> is applied if no block with the project name of the project exists.

The includeFolders block

The includeFolders block is located inside each config element. It controls which directories are to be taken into account for the export.

If the attribute enabled is set to false, then no export of the corresponding folder will take place.

The configuration of the destination folder can be done within the project settings in the Goobi workflow user interface. If the checkbox for Create task folder is set there, the task will be stored in a subfolder with its title as name in the target folder.

Overview

Introduction

This documentation explains the plugin for exporting PDF files with special folder and file naming for the National Library of Israel. The plugin creates any required subfolders in a defined directory and saves an existing PDF file from the master folder with the desired name within the created folder structure.

Installation

In order to use the plugin, the following files must be installed:

Once the plugin has been installed, it can be selected within the workflow for the respective workflow steps and thus executed automatically. A workflow could look like the following example:

To use the plugin, it must be selected in a workflow step:

Overview and functionality

The plugin is executed automatically during the workflow and reads the parameters from the configuration file. On this basis, the plugin then determines metadata from the respective process. The information thus determined is then used to generate a directory path for the export and to create the directory if it does not already exist. The plugin then generates a file name that ends with a counter. The file name generated in this way is checked to see whether it is already in use, so that the counter is adjusted if necessary to obtain a file name that is not yet in use. The first PDF document is then determined from the master directory of the Goobi process and saved under the previously generated file name within the directory path.

Configuration

The plugin is configured in the file plugin_intranda_export_nli_pdf_to_folder_structure.xml as shown here:

The parameters used are described here:

Overview

Introduction

The plugin is used to create the METS structure for the import into the newspaper portal of the German Digital Library. A METS anchor file is created for the complete record of a newspaper, for each exported volume another METS anchor file is created and linked within the complete record. The year contains further structures for month and day.

Each output is created as individual METS files and linked in the METS anchor file of the vintage. The issue may contain further structural data such as article descriptions or supplements. The digitised images are also referenced here.

Installation

The plugin consists of the following file:

This file must be installed in the correct directory so that it is available at the following path after installation:

In addition, there is a configuration file that must be located in the following place:

Overview and functionality

Once the plugin has been fully installed and set up, it is usually run automatically within the workflow, so there is no manual interaction with the user. Instead, the workflow invokes the plugin in the background and performs the following tasks:

A separate METS file is created for each output, linking the images and OCR data associated with the output. The output can have further sub-elements such as articles or inserts.

The individual issues are then combined into one METS file for the year. The METS files of the issues are linked within a structure for month and day.

The last step is to check whether a record with the metadata of the entire issue exists in the target directory. If not, a METS file is created, otherwise the year is entered into the structure data of the overall recording.

To put the plugin into operation, it must be activated for a task in the workflow. This is done as shown in the following screenshot by selecting the plugin intranda_export_newspaper from the list of installed plugins.

Since this plugin is usually to be executed automatically, the task should be configured as automatic in the workflow. Furthermore, the task must be marked as an export step.

In addition, there must be another regular export step so that the linked images and ALTO files can be delivered via the Goobi viewer interfaces.

Configuration

The configuration of the plugin is done via the configuration file plugin_intranda_export_newspaper.xml and can be adjusted during operation. The following is an example configuration file:

In the first section <export> some global parameters are set. Here it is determined whether images are to be exported in addition to the METS files (<images> true/false), whether these are to be exported per issue or per year and linked in the data sets (<subfolderPerIssue> true/false), to which directory the export should be made (<exportFolder>) and which resolvers should be written for the METS file (<metsUrl>) and the link to the published record (<resolverUrl>).

In the second section <metadata> a set of metadata is defined. These fields must exist in the rule set and are partly copied from the overall record to the individual outputs during the export.

The third section <docstruct> defines some structural elements to be generated. These must also be configured in the rule set.

Overview

Introduction

This documentation describes the installation, configuration and use of the Fedora Export Plugin in Goobi workflow.

Installation

The plugin must be installed in the following folder:

There is also a configuration file, which must be located at the following location:

Overview and functionality

An export step must be configured:

• Export DMS

• Automatic task

• Plugin for step: FedoraExport

When the step is executed, the Goobi process is exported (in the same way as it is exported to the file system) to the configured Fedora Repository, taking into account the configuration (see above).

The process data can then be retrieved from the repository using the following URL pattern:

Examples of URLs after successful ingest to Fedora

URL of the data record

URL for the METS file

URL for the master images

URL for the derivatives of the images

Configuration

The configuration is done via the configuration file intranda_export_fedora.xml and can be adapted during operation.

Overview

Introduction

This documentation describes the installation, configuration and use of the export plugin for the creation of special export packages for the Imagen Media Archive Management software. Within the plugin, 5 special publication types are currently taken into account and processed individually.

Installation

To be able to use the plugin, the following files must be installed:

Once the plugin has been installed, it can be selected within the workflow for the respective work steps and thus executed automatically. A workflow could look like the following example:

To use the plugin, it must be selected in one step:

Overview and functionality

This plugin is automatically executed as an export plugin within the workflow and generates the required data within a configured directory. Depending on the publication type, these are

• Image files

• Plain text files with OCR results

• ALTO files with OCR results

• METS files

• METS anchor files

• XML export files

The structure of the XML export files in particular varies greatly depending on the publication type. Here is an example of a Generic Print publication type:

Configuration

The plugin is configured in the file plugin_intranda_export_adm_bsme.xml as shown here:

The parameters used are detailed here:

Für eine einfachere Inbetriebnahme befindet sich in install-Ordner des Plugins einn Verzeichnis mit den zwei passende Regelsätze als Referenz, die zu der hier aufgeführte Konfigurationsdatei passen.

Overview

Introduction

This documentation describes the installation, configuration and use of the Fedora Export Plugin in Goobi workflow.

Overview and functionality

An export step must be configured:

• Export DMS

• Automatic task

• Plugin for step: FedoraExport

When the step is executed, the Goobi process is exported (in the same way as it is exported to the file system) to the configured Fedora Repository, taking into account the configuration (see above).

The following process properties are used to create container URLs or additional container attributes (and are mandatory):

• barcode (containing either a 10-character barcode or a 36-character PID)

• unit_Item_code (only mandatory when using a 10-digit barcode)

• full_partial

The process data can then be retrieved from the repository using the following URL pattern:

Examples of URLs after successful ingest to Fedora

Example using a barcode (barcode=“barcode123”):

Main container for the pictures

Container for the master images

Containers for JP2 derivatives

Example using a PID (barcode=“DB0027DB-F83B-11E9-AE98-A392051B17E6”):

Main container for the pictures

Container for the master images

Containers for JP2 derivatives

Configuration

The configuration is done via the configuration file intranda_export_fedora.xml and can be adapted during operation.

The block config is repeatable and can define different metadata in different projects. The workflow sub-element is used to check whether the current block is to be used for the current step. The system checks whether there is an entry that contains both the workflow name and the current step. If this is not the case, the block is used with <workflow>*</workflow>.

Overview

Introduction

The present documentation describes the installation, configuration, and use of the Stanford Export Plugin in Goobi workflow.

Installation

To be able to use the plugin, the following files must be installed:

In addition, there is a configuration file that must be located at the following location:

To use the plugin, it must be selected in a workflow step:

Overview and functionality

An export step must be configured:

• Export DMS

• Automatic task

• Plugin for workflow step: intranda_export_stanford

During the execution of the step, an export of the Goobi process (similar to exporting to the file system) is performed into the configured directory.

Within this directory, subfolders are created based on the identifier. For example, the identifier qx797sg1405 would generate the following structure: /path/to/folder/qx/797/sg/1405. Within this folder, two additional folders are created: metadata and content.

In the content folder, all generated images, and if available, the ALTO files and single-page PDFs are stored. Additionally, a complete PDF file is generated from the single pages. The metadata folder contains an XML file with information about the files within the content folder.

Finally, the configured URL to the REST API is called to initiate the ingest into the system.

Configuration

The plugin is configured in the file plugin_intranda_export_stanford.xml as shown here:

The following table contains a summary of the parameters and their descriptions:

Overview

Introduction

This documentation describes the installation, configuration and use of the VLM export plugin in Goobi.

Using this plugin for Goobi, Goobi operations can be exported to the configured location for VLM within one step.

Installation

This plugin is integrated into the workflow in such a way that it is executed automatically. For use within a workflow step, it should be configured as shown in the screenshot below.

The plugin must first be copied to the following directory:

In addition, there is a configuration file that must be located in the following place:

Configuration

The plugin is configured via the configuration file plugin_intranda_export_vlm.xml. The configuration can be adjusted during operation. The following is an example configuration file:

Condition format

Currently, there is support for only one type of condition, the variablematcher condition. This type of condition checks any kind of variable, that is defined as field, and performs a regular expression matching against the regular expression that is defined in matches.

A sample condition could look like:

This condition has the type variablematcher. It checks the field {meta.singleDigCollection}, which corresponds to the singleDigCollection value of the metadata file. The condition tries to match this field against the regular expression \d{20}, i. e. checks if the field consists of 20 digits.

Overview

Introduction

This documentation describes the installation, configuration and use of an export plug-in in Goobi, as required for the Klassik Stiftung Weimar within the digitization project. With the help of this Goobi export plug-in, Goobi processes can be simultaneously exported to several locations within a single workflow step. The special features of the Klassik Stiftung Weimar, such as the use of EPNs as identifiers and the merging of covers and sheet cuts into a common structural element, remain unchanged.

Installation

The plugin must first be installed in the following directory:

In the Goobi configuration directory, the additional plug-in configuration file must be made available under the following path during installation:

Configuration

The content of the configuration file is structured as follows:

The exportFolder list can be used to define various locations to which the export is to be made. Any number of folders can be defined. However, at least one folder must be defined at this point.

In order to be able to use the export plug-in within the workflow after successful installation, a work step must be defined in which the Export DMS function was activated. In addition, the value HaabExport must be entered as the step plug-in.