Child pages
  • MODS Guidelines Levels of Adoption

This space has moved to IU's Confluence.
It is located at

Skip to end of metadata
Go to start of metadata

Levels of Adoption

The Digital Library Federation / Aquifer Implementation Guidelines for Shareable MODS Records provide guidance on the use of MODS for metadata intended to be contributed to the DLF Aquifer initiative. The Guidelines, however, are a record-centric view of Aquifer's goals, whereas it is often helpful to set priorities for metadata creation with a user- and use-centric view. This document, the Digital Library Federation Aquifer MODS Guidelines Levels of Adoption, describes five general categories of user functionality that are likely to be supported by following specific recommendations from the Guidelines. It attempts to provide additional guidance to MODS implementers in the planning process by documenting what sorts of functionality is possible when certain elements of the Guidelines are followed.

The Working Group welcomes comments on this documentation. Comments and questions can be sent to any Working Group member.

The Levels of Adoption are listed here from loosest to strictest.

1) Minimum for participation: Allows users to cite the resource

The minimum for participation level defines the information necessary for the most basic indexing of records. It represents a slightly higher minimum than most other aggregations, but this decision reflects the view that Aquifer participants are leaders in the digital library field and therefore will likely be able to commit to higher-quality metadata than other institutions might.

Aquifer will not harvest records that do not contain this information. This determination will be made at the set level.

  • Syntactically valid MODS
  • <name> if applicable (and known)
  • at least one <titleInfo> element with one <title> subelement
  • if known, at least one <originInfo> element with at least one <date> subelement from the recommended list
  • one or more <location> elements with a <url> subelement, one of which should point to the resource in context
  • <accessCondition> if anything other than completely unrestricted

2) Minimum for doing anything useful: Allows users to perform basic searches and filtering

This second level of adoption represents a minimum that will allow an institution's resources to be incorporated meaningfully into an aggregation. While this level is separated out from the minimum for participation level in order for the Aquifer project to obtain as much metadata as possible for the purposes of testing various local implementation scenarios, the project team believes that records that do not meet at least this second level of adoption are likely to be discoverable by end-users or usable in the local implementation scenarios. We expect that over time all Aquifer participants will meet at least this second level of adoption.

  • <subject>
  • at least one <language> element for all resources in which language is primary to understanding the resource
  • One and only one date element must be marked as a key date
  • At least one <typeOfResource> using values from the approved list
  • Use of access attribute on location/url, or include only one URL that points to a view of the resource in context
  • At least one <physicalDescription> element with <internetMediaType> subelement; value to be taken from appropriate list

3) Allows more advanced functionality: Allows users to browse and group search results

The third level of adoption allows the more advanced discovery features expected of an aggregation of records from the high caliber of institution that participates in the Aquifer initiative. Elements in this level represent a level of detail some institutions might not have for legacy collections, but could strive toward in the future.

  • @type on <namePart>, when multiple <namePart> elements appear in a single <name>
  • <role> subelement for <name>
  • at least one <genre> element
  • @encoding attribute on the date with the @keyDate attribute is w3cdtf
  • <form> subelement of <physicalDescription> with @authority attribute
  • More specific <subject> subelements (geographic places, etc.) over <subject>/<topic>
  • @authority attribute on every <classification> element present

4) Adopt all required guidelines (and some recommended): Allows users to perform more precise searches

The fourth level of adoption, like the third, represents more advanced functionality than that found in traditional aggregations. Meeting this fourth level would allow the introduction of very precise searching capabilities across a wide variety of resources.

  • @type on <name>
  • @type attribute for each <languageTerm> present
  • <digitalOrigin> subelement of <physicalDescription>
  • <abstract> if applicable
  • @authority attributes in general
  • @encoding attribute on all date elements under <originInfo>
  • @point attribute on all date elements under <originInfo>, when the date is a date range
  • one <location> element with one and only one <url> subelement contain the @usage attribute value "primary display"
  • one <recordInfo> element with the subelement <languageOfCataloging> to record the language of the text in the MODS record

5) Completely adopt all recommendations: Allows users to effectively evaluate resources

The fifth and highest level of adoption includes information a user would review to make a final evaluation as to whether the resource is relevant to his or her needs. Often this information is only present on the contributing institution's site, but its inclusion in shared records helps enhance the user's experience for the aggregation.

  • @type attribute on <titleInfo>, when applicable
  • <nonSort> subelement of <title>, when applicable
  • @authority attribute on <titleInfo>, when applicable
  • <subTitle>, <partNumber>, and <partName> subelements of <title>, when applicable
  • @collection on <typeOfResource>, when applicable
  • @manuscript on <typeOfResource>, when applicable
  • @qualifier element on appropriate date elements within <originInfo>
  • <targetAudience> element when applicable
  • <place> element within <originInfo>, with all recommendations for subelements and attributes, when applicable
  • <publisher> element within <originInfo>
  • <edition> subelement within <originInfo>, when applicable
  • <extent> subelement within <physicalDescription>, when applicable
  • <note> subelement within <physicalDescription>, when applicable
  • <tableOfContents> element
  • @xlink attribute on <tableOfContents>, when applicable
  • <note> element, containing information that cannot be encoded in a more specific element, when applicable
  • @edition attribute on the <classification> element, when applicable
  • <relatedItem> element, with all recommended attributes, in the cases outlined in the guidelines
  • <identifier> (if applicable)
  • @type attribute on every <identifier> element present
  • @invalid attribute on <identifier>, when applicable
  • @access attribute on <location> subelement <url>
  • @type on <accessCondition> containing the value "useAndReproduction"
  • <part> element, and all recommended subelements and attributes, when applicable
  • <recordContentSource> in <recordInfo>
  • @source attribute for <recordInfo>/<recordIdentifier>, when present
  • <recordOrigin> in <recordInfo>
  • No labels