Goobi Administration Plugin for managing archive collections
| Name | Wert |
|---|---|
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.
The plugin consists of the following files to be installed
These files must be installed in the correct directories so that they are available in the following paths after installation:
The plugin also requires an additional configuration file, which must be located in the following location:
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:
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:
| Authorisation | Explanation |
|---|---|
Identifier
intranda_administration_archive_management
Repository
Licence
GPL 2.0 or newer
Last change
16.09.2024 13:07:31
Plugin_Administration_Archive_Management_Write
Write access to the data
Plugin_Administration_Archive_Management_Upload
Upload or import (new) EAD files
Plugin_Administration_Archive_Management_New
Creation of new inventories
Plugin_Administration_Archive_Management_Vocabulary
Authorisation to extend selection lists from vocabularies
Plugin_Administration_Archive_Management_Inventory_NAME
Access to individual selected inventories, whereby the suffix NAME must be replaced by the name of the inventory
Plugin_Administration_Archive_Management_All_Inventories
Access to all inventories
Plugin_Administration_Archive_Management_Delete
Delete the selected inventory
Plugin_Administration_Archive_Management_Process
Create processes
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:
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.
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.
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.
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.
Each metadata field consists of at least the following mandatory information:
There are also a number of other optional details:
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.
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
The following functions are available within the plugin for archive management:
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.
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>).
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.
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.
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.
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.
| Value | Description |
|---|---|
| Value | Description |
|---|---|
| Function | Explanation |
|---|---|
Insert new node
This button can be used to add a new node as a sub-node to the end of the existing sub-nodes.
Insert several subnodes at this point
Opens a pop-up in which any number of nodes can be created.
Update references
Checks whether processes exist for the nodes in the inventory. This action updates the references if necessary.
Create missing processes
Generates processes for the selected node and all child nodes if no processes exist for these nodes.
Delete node
This allows you to delete the selected node including all sub-nodes. Attention: This function cannot be used at the level of the main node.
Perform validation
This function can be used to validate the selected node. Violations of the configured validation specifications are listed accordingly.
Move upwards
This button allows you to move the selected node upwards within the same hierarchy level.
Move downwards
This button allows you to move the selected node down within the same hierarchy level.
Move down the hierarchy
This button can be used to move the selected node to a lower hierarchy level.
Moving up the hierarchy
This button can be used to move the selected node to a higher hierarchy level.
Move node to another position
This function opens another editing screen that allows you to move the currently selected node to a completely different position in the hierarchy tree. The entire hierarchy is displayed so that the node within which the selected node is to be inserted as a sub-node can be selected.
Duplicate node
Opens a popup in which a prefix or suffix can be specified for selected metadata (attributes visible and showField). The action duplicates the selected node and all child elements and adds the specified prefixes and suffixes to the new metadata.
name
This value is used to identify the field. It must therefore contain a unique name. If the value has not been configured separately in the messages files, it is also used as the label of the field.
level
This defines the area in which the metadata is inserted. The numbers 1-7 are permitted: 1. identification, 2. context, 3. content and internal organisation, 4. conditions of access and use, 5. related documents, 6. notes, 7. directory control.
xpath
Defines an XPath expression that is used both for reading from existing EAD files and for writing the EAD file. In the case of the main element, the path is relative to the <ead> element; for all other nodes, it is always relative to the <c> element.
@xpathType
This defines whether the XPath expression returns an element (default), an attribute or a text.
@visible
This can be used to control whether the metadata is displayed in the mask or hidden. The field may contain the two values true (default) and false.
@repeatable
Defines whether the field is repeatable. The field may contain the two values true and false (default).
@showField
Defines whether the field is displayed open in the detail display, even if no value is yet available. The field may contain the two values true and false (default).
@rulesetName
A metadata from the rule set can be specified here. When a Goobi process is created for the node, the configured metadata is created.
@importMetadataInChild
This can be used to control whether the metadata should also be created in Goobi processes of child nodes. The field may contain the two values true and false (default).
@fieldType
Controls the behaviour of the field. Possible are input (default) , textarea, dropdown, multiselect, vocabulary, nodelink, gnd, geonames, viaf
value
This sub-element is only used for the two types ‘dropdown’ and ‘multiselect’ and contains the possible values that are to be available for selection.
vocabulary
This sub-element contains the name of the vocabulary to be used. It is only evaluated if vocabulary, dropdown or multiselect is set in the field type and no <value> elements have been configured. The selection list contains the main value of each record.
searchParameter
This repeatable subfield can be used to define search parameters with which the vocabulary is filtered, the syntax is fieldname=value.
@validationType
Here you can set whether the field should be validated. Different rules are possible, which can be combined. unique checks that the content of the field has not been used elsewhere, required ensures that the field contains a value. The type regex can be used to check whether the value filled in corresponds to a regular expression, date checks whether the value corresponds to an EDTF date and list tests whether the value used is contained in the configured list.
Several validation rules can also be combined, for example unique+required, regex+required, regex+unique or date+required. In this case, all specified rules must be fulfilled.
@regularExpression
The regular expression to be used for regex validation is specified here. IMPORTANT: the backslash must be masked by a second backslash. A class is therefore not defined by \w, but by \w.
validationError
This subfield contains a text that is displayed if the field content violates the validation rules.
@searchable
This can be used to control whether the metadata should be offered as a field in the advanced search. The field may contain the two values true and false (default).
