Metadata

From FIG

Jump to: navigation, search
Navigation
NewFig1201.png
FL-Islandora Guides (FIG)
FL-Islandora Overview
User Interface
Permissions and users
Collection Creation and Management
Content models
Creating Content Objects
Metadata
Suppressing Objects From View
PALMM guidelines
Fl-Islandora and Mango
Site Administration
Workflow: From Spreadsheet to Islandora
Using Google Analytics with FL-Islandora
Collection Information Menu
A-I. FL-Islandora Glossary
A-II. Field Inventory

Contents

Metadata Basics

Metadata Object Description Schema (MODS)

For all content in Islandora, the way each item is described is using MODS. When MODS was developed, the goal was to be able to carry all the same information as MARC. Think about how a MARC record can potentially have many fields to store information in. MODS is similar, and has many fields. Any one item in Islandora won't use all the fields, but there are many, many potential fields for storing metadata about that item. In the wider world of library metadata, Dublin Core is one of the simplest schemas, and MODS is one of the most complex schemas.

FLVC is using MODS because the complexity can better meet specialized needs of a given collection, and can better hold metadata mapped from MARC records which is helpful for digitized versions of older books where a catalog record was available.

At this time, MODS 3.4, 3.5, and 3.6 are in use in Florida Islandora sites.

FLVC's MODS Requirement for Everyone: Identifier (IID)

(A detailed MODS profile is published below, but here is the MODS requirement for everyone.)

New Islandora users should read the this section before preparing metadata for FL-Islandora!

In the FL-Islandora implementation, one and only one identifier with type “IID” (Item Identifier) is required for every item loaded to Islandora. The value of the IID identifier must be unique in the system.

The IID is intended to be an identifier meaningful to the institution. You should assign IIDs in a way that helps you to organize your files and digital objects. It could be an accession number, processing control number, or other-system number with some link to library records.

To ensure that IIDs are unique, it is recommended that they begin with a short character string used only by one institution, e.g. “FS” for Florida State University. For more information on creating IIDs see the CAGER Guidelines on Identifier. Libraries should be careful not to use a prefix already claimed by another institution using FL-Islandora. It is the responsibility of the owning institution to keep track of the IIDs that they assign and ensure their uniqueness.

There are two ways to export a list of existing IIDs in a site. From the homepage, or any collection, you can click to "View All Items in this Collection", then click the icon for Excel in the top right corner, and that makes a .csv report for you to download. You can also go to "Advanced Search", and in the box for "Metadata Browse" enter mods.identifier.iid.

If the metadata is being entered online and the IID is not present or not unique, or if there are more than one IID in the metadata form, the metadata cannot be saved until corrected. If a faulty MODS file is included in a zip file submitted via batch import (zip file importer) a warning may be issued and a stub metadata record will be created containing only a title. If a faulty MODS record is included in a package for offline ingest, the package will not be ingested.

The value of the IID is used to create a PURL automatically for new content in the system.

FLVC's MODS forms

The same MODS forms are installed on all FLVC hosted Islandora sites. FLVC is not able to customize on a site-by-site basis, because of the administrative overhead in testing each form and in troubleshooting numerous forms. The Islandora SubGroup (ISG) of the Digital Initiatives Standing Committee (DISC) of the Members Council on Library Services makes decisions about form fields.

There are three forms in use on all Islandora sites:

1) MODS Simple Entry

  • The MODS Simple Entry form has a small subset of MODS fields. This form should be used for most work in Islandora, and especially for adding new items to Islandora.

2) Full MODS form

  • The Full MODS form is intended to be able to touch up any metadata in use on any site in the entire Florida Islandora system. Across all the sites, many collections have migrated onto Islandora from other platforms, many items have metadata mapped from MARC, and there is a wide variety of metadata. The Full MODS form is not intended for general use in adding new items to Islandora, because it has so many fields that someone will have to scroll down through several screens to find a few fields.

3) Full MODS: Newspaper

  • For Newspaper Issues (as opposed to the parent newspaper object), you don't have a choice of which form to use. You have to use the Full MODS form, with one small modification - dateIssued is required in this form, because the dateIssued information powers the accordion style display that lets someone browse to a specific issue by date.

There are two ways to request a change to a form. First, if the form has a bug, you can directly report that to help@flvc.org . The kinds of odd behavior you might notice are things like you type a change and press "Save" but your change doesn't show up, something saves wrong either to an unintended field or with a wrong attribute, labels on form fields are confusing and could be worded better, or the Full MODS form can't get to metadata that you have on your site. Second, for any other changes, for example, if you would like a field added to a form, then attend an ISG meeting and request the change there. Each ISG meeting has an open call for announcements, and you can suggest a change then, or you can email ahead of time and have your request added to the agenda. It's fine to email help@flvc.org with all requests, and FLVC will write back and tell you to bring it to ISG if the change should be reviewed by ISG.

FLVC does offer limited services in custom forms. FLVC is able to make a custom form that is a shortened version of MODS Simple Entry. For example, if you are cleaning up author names, it is in the realm of possibility that FLVC will make a form that opens only author names, so that when you edit metadata you see only that field and don't have to scroll up and down to find the field. Custom forms are intended to be used for a limited time only and to be used for targeted metadata clean up projects. FLVC will not provide a custom form for purposes of creating metadata as you upload objects.

Prefilling Metadata in the MODS Forms

Starting with a MARC record

Anytime you go to upload a single item, Islandora will ask you whether you have a MARCXML record. If you do, then you can upload it, and Islandora will convert that MARC record to MODS and prefill the Islandora form.

This is useful if you have digitized print materials from your collection. In that case, you can get the MARC record for the print item from your catalog, and use that to prefill metadata when you upload to Islandora.

This is also useful if you have a collection with many repeated fields. You can make a template MODS file with the repetitive fields, use MARCEdit to convert that to MARCXML, and use that template to prefill metadata. Be careful with this, and make sure that you are prefilling exactly the fields you want and not prefilling additional fields.

Metadata templates

If you have a collection or project with many repeated fields, FLVC can install a version of the MODS Simple Entry or Full MODS form that prefills with that repeated information. For example, if you had a newspaper, The Observer, where every issue had an identical uniform title, and identical publisher, and identical copyright statement, etc., the you can request a form "Full MODS: The Observer" that will prefill with those required fields. That "Full MODS: The Observer" form will show up as an option on your site whereever forms show up, and when adding an issue to the newspaper, you can choose that form. To make the request, make a sample record with all the repeated information, and contact help@flvc.org with "Islandora" in the subject line and a request to set up a template.

This request for prefilled information in a MODS form is straightforward for FLVC to set up, and FLVC encourages you to ask for this service if it is useful in completing a project.

Other metadata in use in Islandora

FLVC's Local MODS Profile

Who should use this section?

The FLVC MODS profile is technical information for librarians working directly with MODS. It is likely not of general interest and is a bit egghead.

For regular librarians just wanting to upload a variety of content, the time you might use this page is if you want to do a metadata clean up project. If so, then skim this page, and see whether there's an FLVC-specific way of handling the metadata you want to add. For example, FLVC has a specific way it wants you to enter in Digital Object Identifiers (DOIs), so you want to be aware of that before you start clean up to add hundreds of DOIs to your material or before you begin a collection where the items have DOIs.

Core Requirements (FLVC's local MODS profile):

  • <identifier type="IID">
    • Required
    • non-repeatable
    • Each IID must be unique from all other IIDs used across institutions.
    • Requirements: The only characters allowed are A to Z, a to z, 0 to 9, underscore, dash, period, left- and right-parenthesis. (This requirement is because the IIDs are used to make PURLs.)
    • Requirements: No spaces allowed in an IID. (This requirement is because the IIDs are used to make PURLs.)
  • <titleInfo><title>
    • Required (This is a required field in all forms.)
  • <originInfo><dateIssued>
    • The dateIssued is required for Newspaper Issues in order to show up in the tree browse from the top level newspaper element.
    • A dateIssued is also required by the Excel to MODS Transformer service. The Excel to MODS Transformer will not process MODS unless a dateIssued is included.
  • Local fields: These are <extension><flvc:flvc><flvc:owningInstitution></flvc:owningInstitution><flvc:submittingInstitution></flvc:submittingInstitution><flvc:otherLogo></flvc:otherLogo><flvc:objectHistory></flvc:objectHistory></flvc:flvc></extension>
    • <flvc:owningInstitution>
      • Required
      • non-repeatable
      • "The home FL-Islandora repository." (text FLVC displays in the MODS forms)
      • Pulls from a controlled vocabulary (see https://fig.wiki.flvc.org/wiki/index.php/Institution_code for controlled vocabulary) (because it is used for creating a PURL based on FLVC's code for the owning institution and IID). This is implemented with a drop down menu in forms.
    • <flvc:submittingInstitution>
      • optional field
      • non-repeatable
      • "The institution submitting the digital object for ingest." (text FLVC displays in the MODS forms)
      • Pulls from the same controlled vocabulary as <flvc:owningInstitution>. (See https://fig.wiki.flvc.org/wiki/index.php/Institution_code for the controlled vocabulary.)
    • <flvc:otherLogo>
      • optional field
      • repeatable (according to http://wiki.fcla.edu/wiki/index.php/DL:Offline_Ingest_Specs )
      • "The name of a logo to display with the object in addition to the logo of the owning institution." (text FLVC displays in the MODS forms)
      • Maximum of 25 characters (alphanumeric plus underscores). Case insensitive.
    • <flvc:objectHistory source="digitool">
      • optional field
      • Used to store provenance information about Digitool.
    • Required that one and only one FLVC <extension> exists.
    • The FLVC extension is for internal use only within FLVC, and should not be used for meeting requirements of any harvesting projects. As of summer 2018, FLVC uses the FLVC extension for internal quality control and reports, and to display one or more institutional logos in the bottom right corner of each object's web display.

How to Store Digital Object Identifiers in the MODS

Digital Object Identifiers (DOIs) should be stored in MODS in the identifier element with a type="doi".

Example:

<identifier type="doi">10.1007/BF02126356</identifier>

and you enter it in the MODS form like this:

Screenshot of a DOI entered into the MODS form.  Under the header "Identifiers", for "Type" enter "doi" (all lowercase), and for "Identifier" enter the DOI only and not any URL made from the DOI.  For example, enter "10.1007/BF02126356" as the "Identifier".

The DOI encoding is used to pull any altmetrics information available for the publication in the altmetric.com service. For this to work, the DOI has to be stored exactly as described above.

How to Store RightsStatements.org values in the MODS

RightsStatements.org values should be entered into the MODS in the accessCondition element with a type="use and reproduction" and with a displayLabel="RightsStatements.org". The URI should be entered with no other information in the same field (ie. do not mix in human readable information along with the URI - the URI should be by itself).

Significantly, RightsStatements.org URIs use "http" and NOT "https".

Example:

<accessCondition type="use and reproduction" displayLabel="RightsStatements.org">http://rightsstatements.org/vocab/InC/1.0/</accessCondition>

and you enter it in the MODS form like this:

Screenshot of the RightsStatements.org field in the MODS form.  Under the header "ACCESS CONDITION: RIGHTSSTATEMENTS" then under the header "RightsStatements.orgValue", use the drop down menu to select a statement.  You will see a human readable value in the form, and the form will save that as a URI.


RightsStatements.org and the Excel to MODS Transformer

As of summer 2018, the Excel to MODS Transformer cannot create RightsStatements.org values encoded to FLVC's requirements. There are no plans to add this functionality. If you wish to use the Excel to MODS Transformer to create metadata, then enter the RightsStatements.org URIs in the column labeled "access condition" (just a single URI for each file with no other info in that "access condition" column). Then contact help@flvc.org with "Islandora" in the subject line, send the Excel file, and request FLVC to send you back a .zip file of the MODS records with the RightsStatements.org encoding.


Special note on encoding RightsStatements.org as an xlink:

FLVC is aware that FSU will encode the RightsStatements.org values as an xlink.


Special note about the Digital Public Library of America's (DPLA's) MODS requirements:

The DPLA has examples of how to encode RightsStatements.org in this guidance document Standardized Rights Statements Implementation Guidelines. DPLA requires that a RightsStatement.org or Creative Commons value be included with every item going into DPLA. And, DPLA requires that this RightsStatement.org or Creative Commons value be the only value stored in <accessCondition type="use and reproduction"> and that local rights statements using uncontrolled language be stored using another type, type="local rights statement". However, this is incompatible with the MODS schema. The examples in the User Guidelines clearly show uncontrolled rights statements in type="use and reproduction". Because the Library of Congress maintains the MODS standard, FLVC will follow the published standard. DPLA is one of many projects using the MODS standard and is not authoritative.

Islandora shares out records via OAI-PMH. One of the settings on the OAI-PMH configuration in Islandora is an option to transform records as they go out. It is possible to install a transformation on the Islandora site's OAI-PMH feed which would remove uncontrolled <accessCondition type="use and reproduction"> statements and send out only the RightsStatements.org and Creative Commons values by taking <accessCondition type="use and reproduction" displayLabel="RightsStatements.org"> and converting it to <accessCondition type="use and reproduction">.

How to Store Creative Commons values in the MODS

Creative Commons values should be entered into the MODS in the accessCondition element with a type="use and reproduction" and with a displayLabel="Creative Commons". The URI should be entered with no other information in the same field (ie. do not mix in human readable information along with the URI - the URI should be by itself).

Encoding is identical to that used for RightsStatements.org values, except that for Creative Commons values, the displayLabel attribute is different. diplayLabel="Creative Commons" should be used.

Significantly, Creative Commons URIs use "http" and NOT "https".

How RightsStatements.org and Creative Commons values are used in Islandora

ReuseRightsFacetsScreenshot.png

The RightsStatements.org and Creative Commons values are matched to one of 3 categories:

  • Free Re-use
  • Limited Re-use
  • No Re-use

Here's what's in each

How to Store ORCIDs in the MODS

ORCIDs should be stored in <name><nameIdentifier type="ORCID">.

The ORCID is always the URI version, and should always be expressed with "https" and NOT "http". ORCID's guidance document of the ORCID Identifier states, "The ORCID iD is expressed as an https URI, i.e. the 16-digit identifier is preceded by "https://orcid.org/". A hyphen is inserted every 4 digits of the identifier to aid readability."


For example:


<name>

<namePart type="given">Wilhelmina</namePart>

<namePart type="family">Randtke</namePart>

<nameIdentifier type="orcid">https://orcid.org/0000-0002-7439-8205</nameIdentifier>

</name>


As of summer 2018, Islandora is not interacting with the ORCID API, and adding interaction with the ORCID API is not planned or scheduled.

Metadata rules in Fl-Islandora

Input

Standard Version Schema Info
MODS 3.4 http://www.loc.gov/standards/mods/v3/mods-3-4.xsd http://www.loc.gov/standards/mods/
MARCXML http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd http://www.loc.gov/standards/marcxml

Also found in FL-Islandora

DC http://www.openarchives.org/OAI/2.0/oai_dc.xsd http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=elements
MARC21 http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd http://www.loc.gov/standards/marcxml https://www.loc.gov/marc/
METS http://www.loc.gov/standards/mets/mets.xsd http://www.loc.gov/standards/mets/METSOverview.v2.html
  • Each object has one master metadata stream. In FL-Islandora, the master metadata record is MODS format and stored in objects as the MODS datastream. MODS is a standard maintained by the Library of Congress (see http://www.loc.gov/standards/mods/). MODS records submitted to Islandora should validate using the MODS schema provided by the Library of Congress.
  • A MARCXML record uploaded to online ingest or submitted to batch ingest will be converted to MODS. MARCXML can be regenerated from the MODS for viewing or download. MARCXML is not indexed by FL-Islandora but can be generated for loading to Mango or OAI-PMH harvesters.
  • Fedora requires that all objects have a Dublin Core datastream. Dublin Core derivative records are made from master MODS records and stored with the object. The derived DC terms are indexed but are only found hit by expanding a search to all metadata (catch_all_fields). The Dublin Core records can also be used in OAI (Open Archives Initiative) metadata harvesting.

There are a few local extension elements and special rules for using MODS in FL-Islandora (see below).

FLVC extension

There are three elements local to FL-Islandora:

Owning institution: The institution code of the institution that owns the digital object. This is a required field.

Submitting institution: The code of the institution that submitted the object for ingest. If not provided, this is assumed to be the same as the owning institution.

Other logo: The name/code of an image to display in the logo area beneath an object, in addition to the institution’s logo, for secondary branding purposes. The name/code must be predefined in the system through the manual addition of an image and/or link. See Site Administration: Object Branding for details.

In the MODS record, these elements are stored in an FLVC extension:

<extension>
    <flvc:flvc>
        <flvc:owningInstitution>FSU</flvc:owningInstitution>
        <flvc:submittingInstitution>FSU</flvc:submittingInstitution>
        <flvc:otherLogo>Banfield</flvc:otherLogo>
    </flvc:flvc>
</extension>



Using preexisting metadata

Objects created using batch import (the zip file importer), book batch, or offline ingest must have metadata submitted as part of the batch. All of these methods will accept valid MODS or MARCXML. Please see Creating Content Objects: Batch Import for details.

MODS records should validate against the MODS schema and begin with this declaration:

<?xml version="1.0" encoding="UTF-8"?>
<mods xmlns="http://www.loc.gov/mods/v3"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     version="3.4"
     xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-4.xsd">

MARCXML records should validate against the MARCXML schema and begin with:

<record xmlns="http://www.loc.gov/MARC21/slim" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd">
Please Validate All Metadata Files Before Zip Loading or replacing MODS files!

Validation resources:

Personal tools