Q&A: Metadata in Islandora

What HTML tags can I use in my collection descriptions?

<a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>

How can I add attributes like "displayLabel" or "type" to MODS elements in Islandora?

Option 1: Form editing

Contact LYRASIS Support and ask that the "LYRASIS Detailed MODS" form be associated with your Islandora content models.

This is a more complex form that more flexibly supports MODS elements and attributes. It will allow you to add, edit, or delete attributes in the Islandora interface, without directly editing MODS XML.

Option 2: Direct MODS editing

EXISTING OBJECT
- Manage > Datastreams > MODS > Download
- Save file locally
- Use tool of choice to edit and validate MODS
- Manage > Datastreams > MODS > Replace
- Browse/navigate to your edited local MODS file
- Click Upload, then Add Contents
- Manage > Datastreams > MODS > Edit -> submit without making any changes (This is a workaround to keep your DC updated as described below.)

NEW OBJECT
(Assumes you have a MODS file created locally)
- Ingest the object as per the User Manual, clicking Next on the screen about MARC-XML
- Enter a temporary title in the MODS form and nothing else. Submit the form.
- Manage > Datastreams > MODS > Replace
- Browse/navigate to your edited local MODS file
- Click Upload, then Add Contents
- Manage > Datastreams > MODS > Edit -> submit without making any changes (This is a workaround to keep your DC updated as described below. It also forces the update of the main title at the top of the object page to use the title from the replaced MODS record instead of the temporary title you initially entered.)

How do I encode standardized rights statements in my MODS?

LYRASIS currently recommends and supports the alternate MODS recommendation for standardized rights statements from the DPLA Standardized Rights Statements Implementation Guidelines.

This pattern can be used to record rights statements from rightsstatements.org, creativecommons.org, or other standardized rights/license vocabularies.  

Example:

<mods:accessCondition type="use and reproduction"
                      xlink:href="http://rightsstatements.org/vocab/InC-EDU/1.0/">
  In Copyright - Educational Use Permitted
</mods:accessCondition>

(Indenting/whitespace in the above MODS for display purposes only. Best practice would be to have this all as one line.)

To implement standardized rights statements, ideally:

• other, non-standard statements in this field having type="use and reproduction" are changed to use another type value
• the mods:accessCondition element containing the standardized rights statement should occur first

What is the best way to encode dates in MODS for use in Islandora?

This is covered in Deep dive: Best practices for dates in Islandora MODS metadata.

Can this MODS element be displayed differently?

Unfortunately, this is complex.

The part of Islandora that translates the MODS datastream into the object display is the same for all LYRASIS-hosted Islandora clients.

This means:

• The same MODS element cannot be displayed differently per collection, content model, or client.
• Technically, the display can be changed, but we have to be very careful about how it is changed. A lot of data profiling work is required to verify a seemingly simple display change will not be problematic to another client.
• We are happy to hear suggestions for improving display, but ask for your understanding if changes are slow or cannot be made.

(This is a thing we hope will be handled more flexibly in the next version of Islandora.)

What is the relationship between the MODS and DC datastreams?

The DC (Dublin Core) datastream is derived from the MODS via a LYRASIS-customized version of LC's standard MODS->DC XSL transformation. The transformation is the same for all LYRASIS-hosted Islandora clients.

When a MODS record is updated via a form, the DC datastream is automatically updated.

If a MODS record is updated by replacing the datastream file manually (Manage > Datastreams > MODS > Replace) or in a batch process, the DC datastream is not updated.

If you have replaced a MODS datastream manually, force the DC to update by doing Manage > Datastreams > MODS > Edit, and submitting the form without making any changes.

If LYRASIS staff batch replaces MODS for you, it is part of our workflow to run a batch process to re-derive the DC from the new MODS. We can also run this batch process for you upon request.

Can I batch update metadata in my LYRASIS-hosted Islandora instance?

LYRASIS can enable the Islandora Find & Replace module for clients who have experience and expertise batch manipulating data. This tool empowers clients to perform find and replace updates in their metadata datastreams. This tool also has the potential to be very destructive; there is no "undo" button, and an error in configuring a find/replace could result in your MODS becoming invalid. LYRASIS is not responsible for correcting errors introduced by client use of the Find & Replace module. We can assist in batch-reverting datastreams to previous states upon client request in ZenDesk, but if such a cleanup is large or complex, it may need to be handled as a separate project for the client outside of normal support hours.  

Islandora offers no other options for batch manipulating metadata within the user interface, so other batch operations need to be coordinated with LYRASIS.

There are various options for how to go about this type of project, depending on the clients' technical knowledge and preference. Examples include:

• Client harvests MODS from their OAI-PMH endpoint. Client batch edits MODS. Client provides MODS files to LYRASIS to batch replace in the system.
• Client requests MODS files from LYRASIS. All MODS or a specified subset can be provided. Client batch edits MODS and provides the updated files to LYRASIS to batch replace in the system.
• LYRASIS handles the batch editing project on client request.

There are some specific technical requirements to ensure smooth batch metadata replacement, so be sure to discuss with LYRASIS staff before initiating such a project.