Design Principles for Enhancements to MODS and MADS
(September 2009)
These statements are intended as guiding principles to be used in formulating future enhancements to the Metadata Object Description Schema (MODS) and the Metadata Authority Description Schema (MADS). The MODS Editorial Committee developed these as principles to apply to any requested changes or additions. Approved changes for future versions are available on the MODS website.
General statements about MODS and MADS and their relationship
General description of MODS
MODS is an XML schema and guidelines for encoding a resource description. It supports discovery and management of resources, and access to them, as well as exchange and management of encoded descriptions.
General description of MADS
MADS is an XML schema and guidelines for encoding an authority description. It supports control, normalization, and management of some types of data used in a resource description, as well as exchange and management of encoded descriptions.
Relationship of MODS and MADS
MODS and MADS can be used independently. To support those who implement them in an integrated manner, the definitions of elements and attributes in MODS and MADS are coordinated whenever appropriate, and there is an ability to reference a MADS record from a MODS record.
Goals to guide the enhancement of MODS and MADS
Table 1. Goals that apply to both MODS and MADS
| Goal (applies to both MODS and MADS) | How to achieve that goal |
| 1. Support localization and customization needs | 1) Define an "extension" element that can contain elements that are not part of the MODS and MADS schemas 2) Provide unrestricted value options for attributes (such as "displayLabel") and elements that are likely to have local or customization needs 3) Provide an option to include elements from other schemas where appropriate (such as for the "accessCondition" element, which may include elements from other schemas that focus on access) |
| 2. Accommodate widely adopted descriptive practices | 1) Define elements and attributes for the various kinds of information that are treated by widely adopted standards (such as AACR2) and practices for describing a resource 2) Define options for coded or natural language information 3) Define options that allow for more or less granularity in a description (to support descriptive practices such as minimal and full levels) |
| 3. Maintain a relatively small number of elements and attributes to reduce training, application, and implementation costs | [97 elements defined in MODS 3.3; 33 elements defined in MADS 1.0] 1) Rely on attributes such as "authority", "source" and "type" to express meta-information below the element level 2) Define a new element or attribute only when a need (retrieval, presentation, linking, communication ...) is expressed by a significant number of MODS and MADS users 3) Reuse an element or attribute when it is needed
in more than one context, but has the same semantics (such as the
reuse of "name" and "title" elements as children of the "subject" element) |
| 4. Support the communication of resource and authority descriptions | 1) Adopt widely used and supported data encoding formats (currently XML) 2) Maintain good documentation of MODS and MADS to promote consistency in their application |
| 5. Support validation of the encoding | 1) Adopt widely used and supported validation tools (such as XML Schema) 2) Provide a means to explicitly state which version of the XML Schema was used for encoding (namely, the "version" attribute) |
| 6. Allow use of MODS/MADS elements by other standards and in application profiles | Externalize elements and definitions in the XML schema |
| 7. Maintain continuity of structure and content | Prefer backward compatible options when considering changes |
| 8. Maintain a single way to encode a piece of information | Do not define more than one element or attribute for a particular piece of information |
| 9. Accommodate indexing of data in the description | 1) Define specific elements and attributes for particular kinds of information that are commonly used for retrieval (such as subjects, titles, names) 2) Prefer schema constructs that facilitate indexing |
| 10. Accommodate presentation of data in the description | 1) Define specific elements and attributes for particular kinds of information that are commonly used for presentation (such as subjects, titles, names, notes) 2) Define specific elements (such as "name/displayForm") and attributes (such as "displayLabel") to control presentation of a description 3) Define elements and attributes that control presentation of alternate language or script versions of metadata |
| 11. Make element and attribute names as intelligible as possible to a general audience | Avoid use of jargon from a specific domain |
| 12. Allow for extensibility to include data from richer element sets | Provide a means for including more granular data from a richer element set (namely, the "extension" element) |
| 13. Accommodate information about the metadata and record itself | Provide a means for encoding information about the source of the metadata, language of cataloging, cataloging rules used (namely, "recordInfo" and its subelements) |
| 14. Accommodate conversion to and from other commonly used resource and authority description encodings (such as Dublin Core, MARC, VRA Core) | 1) Define sufficient elements and attributes to maintain a mapping to other description encodings 2) Document and publicize mappings to other description encodings |
| 15. Accommodate controlled vocabularies that are commonly used in resource and authority description | Define the "authority" attribute to record which controlled vocabularly is in use |
Table 2. Goals that apply only to MODS
| Goal (specific to MODS) | How to achieve that goal |
| 1. Allow full description of whole-to-part and similar types of relationships | Repeat <relatedItem type=”constituent”> as needed to describe the parts of a complex resource |
| 2. Support encoding a description for any type of resource | 1) Make no restrictions on type of resource described 2) Define new elements and attributes needed for unsupported types of resources 3) Provide a means for encoding descriptive elements that are not otherwise accommodated in MODS (namely, the "extension" element) |
| 3. Support encoding the relationship of an agent to a resource | Define an element whose value expresses that relationship (namely, the "role/roleTerm" element) |
Table 3. Goals that apply only to MADS
| Goal (specific to MADS) | How to achieve that goal |
| 1. Support encoding an authority description for a name, title, name/title, topic, temporal entity, genre, geographic entity, hierarchical geographic entity, occupation | Define elements for those entities |
Questions and comments:
Contact Us (
February 2, 2022
)
Legal | External Link Disclaimer