Structural metadata is one of the types of metadata, and it is most closely associated with the management of resources. It is commonly used to explain the internal organization of the resource and/or its relationship to other data. Structural metadata informs the display and navigation of digital resources. It may overlap with descriptive metadata (titles that indicate part numbers and names). It also often overlaps with technical and administrative metadata because managing resources over time requires understanding the internal structures of those resources and displaying multi-part works requires knowing what file interpretation is required for those parts.
Examples of structural metadata are page numbers, collection name and location, parent item names and location, and related item names and locations. Details regarding the creation of structural metadata for inclusion in descriptive metadata files can be found under Technical and Administrative Metadata. The information below describes the structural metadata necessary for uploading items into CONTENTdm and Islandora 7.x, and briefly explains how that data is stored and used by the system. Additional information may be available in the documentation of the schema or platform being used for a particular metadata project.
Best practices for describing structural metadata are often platform-dependent.
In CONTENTdm items can be uploaded individually and manually reorganized into the preferred hierarchical structure. There are also detailed instructions and encoding requirements that allow uploading a single compound object or a batch of compound objects using text files. In Islandora most modules expect items to be contained in folders and for structural information to be conveyed by the alphanumeric order of the filenames in those folders. In both cases, the software creates the majority of the structural information it uses in an alternate schema and separate metadata workflow.
There are metadata schema that were created with the intention of describing hierarchical structural information (PREMIS, EAD), but those are not currently used at Tulane, and as such are not described in this guide. Instead, this guide describes required, recommended, and optional structural metadata necessary in nearly any schema. It is platform-agnostic and aims to provide content providers with standards any data refiner or programmer could use to recreate the structure of the objects. The expectation is that programmers and metadata librarians will be able to refine or restructure this data according to the specific requirements of any current or future system architecture, but examples will be provided for software currently in use.
It is recommended that the metadata for all objects, whether compound or simple, be included in a single spreadsheet. Accompanying this spreadsheet should be one folder that contains all of the digital objects to be uploaded. If the collection will contain compound objects, each compound object's individual files should be grouped in a subfolder. Each row of the spreadsheet should represent one record. The first three columns of this spreadsheet should include the following structural metadata.
1. In the first column, titled "Item", enter a sequential item number per record, beginning at 1 (such that each line is numbered in order, 1, 2, 3, 4…). This column is always required.
2. If a spreadsheet describes multiple objects and some of them are compound, the second column should be titled "Child". Enter into this column a secondary sequential item number, beginning at 01, per child item (such that each compound object has numbered children, 01, 02, 03…). Leave the cell blank if that row describes a simple object. If the entire collection contains only simple objects, this column may be omitted. This column is required if the collection includes compound objects.
3. In the third column titled "Directory," enter the name of the folder the contains the file to be uploaded. For compound objects, this will be a subfolder. If the collection contains only simple objects, this column will usually contain only one folder name, but not always. This column is required, but may be populated for you. Contact Digital Publishing Initiatives or the Metadata Librarian to see if they can provide you the information for this column.
4. If a spreadsheet includes compound objects, each Child object is required to have the primary title of the parent object in a column titled "Parent Item Title".
In Islandora virtually all structural metadata is created automatically during ingest. Islandora will also create an edit the necessary files to describe structural metadata if compound objects are created manually in Islandora, however this process is not recommended.
Structural metadata in Islandora is contained in separate datastreams and uses XML encoding and the Resource Description Framework (RDF). The two datastreams available are RELS-EXT and RELS-INT. RELS-INT describes datastreams that belong to an object and RELS-EXT describes the relationship between fedora objects (for example: collections, parent objects, child objects, and related objects). These two datastreams are also automatically created or updated for resources in Islandora as updates, deletions, and other modifications to the structure are made...removing the need for a cataloger of metadata librarian to create or edit these files except in a very small number of special cases.
If a special circumstance requires it, RELS-EXT and RELS-INT Datastreams can be provided as part of a Fedora ingest file or added through a Fedora management service interface.
How to Batch Ingest Files in Islandora below includes detailed information for some existing modules, and other methods are in development for batch uploading, including programmatic and automated methods. However, the process can be summarized in this way:
Regardless of which batch upload used,
