Skip to Main Content
Course materials support network for Minnesota, South Dakota, North Dakota and beyond

Discovery, Metadata & Accessibility: Metadata: Home

Overview

Metadata
METADATA enables the publishing, distribution, discovery, and management of OER. Repositories commonly use schemas like Dublin Core, LRMI, and IEEE LOM, with templates tailored to describe teaching and learning resources, open licensing, educational alignment, and accessibility. Interoperability is a goal for ensuring OER are shareable across platforms, with crosswalks acting as a start for bridging different metadata standards. Effective implementation may include extending a schema to address local needs and configuring repository software to support these customizations. Various federated searches have been attempted, but still only cover a portion of the available OER. Submission workflows for each repository vary, and sometimes there are technical roadblocks that require creative solutions.

Metadata Topics

Challenges abound when approaching metadata for OER. Being asked to provide one-off metadata presents difficulties as it is an act in isolation that requires significant background research. On the other end of the spectrum, designing a metadata system for your library's repository also requires careful considerations and decisions between schemas and software that require tradeoffs. Effective OER metadata includes elements specific to the education subject domain which will likely present a learning curve in both the interpretation of the content and in making use of controlled vocabularies. 

Considerations

Education-Specific Metadata Elements: Catalogers need to learn new education-specific metadata elements that describe teaching and learning aspects, such as:

  • Learning objectives: What educational goals the resource addresses.
  • Educational level: The intended audience or education level (e.g., primary, secondary, higher education).
  • Learning outcomes: The skills or knowledge students are expected to gain.
  • Pedagogical features: Any teaching strategies or methodologies supported by the resource.
  • Ancillaries: Any extra supporting content included (e.g., quizzes, lecture slides, assignments, worksheets).

Standardization for Multiple Platforms/Interoperability: If the vision includes maximizing the distribution and reach of the OER, work is required to increase the likelihood the applied metadata works across platforms (e.g., OER Commons, Open Textbook Library, institutional repositories) and is compatible with various search and discovery systems. Understanding the pros and cons of different metadata standards (e.g., Dublin Core, LRMI) and which systems are desired targets will help decide how to proceed with implementation.

Managing Open Licensing Information: Open licensing information about a resource, such as Creative Commons licenses, need to be accurately applied to clearly indicate how resources can be used, modified, and redistributed. This involves learning how to tag resources with the correct license information (e.g., CC-BY, CC-BY-SA) and understanding the implications of different licenses.

Adaptations, Derivatives, and Versioning: Metadata librarians must track and tag different versions of the same resource, ensuring users can find the most relevant or up-to-date version. This involves managing derivative works and ensuring the correct metadata reflects the relationships between original and adapted materials (e.g., using the Dublin Core “Relation” element to link original and derivative versions).

Subject Classification for Learning Resources: While subject classification remains important, there’s a shift toward tagging learning resources in a way that enhances discoverability by educators. This involves the use of less traditional and more specialized vocabularies like IEEE LOM (Learning Object Metadata) or educational taxonomies like Bloom’s Taxonomy for learning outcomes. Oftentimes, instructors searching for materials would prefer to pre-apply filters that remove any materials irrelevant to their needs (e.g., lacks ancillaries, incorrect grade level, learning outcomes aligned to irrelevant standards), and this process is reliant on accurate metadata.

Some of the most popular schemas include Dublin Core, LRMI, IEEE LOM (and locally customized customized versions of each). How you apply metadata can depend on what the plan is for hosting and distributing the OER to various referatories. Some example schemas and metadata templates are below.

Schemas

Metadata Templates and Forms

Crosswalks can allow metadata to be mapped between different standards, and serve as a starting point for sharing OER with multiple referatories. Additional metadata is most likely required to ensure that OER works optimally in each repository. Examples focus on Open Textbook Library, MERLOT, and OER Commons.

Complexity of Crosswalks

Metadata Crosswalks: A mapping of metadata elements from one schema to another which allows information cataloged under one scheme to be converted or translated into another, ensuring that the same resource can be discovered across different repositories.

  • Dublin Core and LRMI: Dublin Core is a very flexible and general standard, so it maps relatively easily to other educational metadata schemes, including LRMI. LRMI is built on top of Schema.org, which already has mappings for many Dublin Core elements (e.g., dc:title can map to schema:name, dc:creator to schema:author, and so on).
  • MERLOT’s Customized Dublin Core: MERLOT’s use of extended Dublin Core also maps well with both Dublin Core and LRMI because it follows the same basic principles but adds educational and technical fields. Crosswalking between MERLOT's schema and Dublin Core or LRMI is feasible, although some specific educational fields may require manual mapping or extension.

Challenges with Full Interoperability

  • Basic Interoperability: For most core metadata elements (e.g., title, author, description), crosswalks between Dublin Core, MERLOT’s extended schema, and LRMI should work smoothly. This means that for many OER resources, metadata created for one repository can be translated to work in others.
  • Specialized Educational Metadata: However, because LRMI includes more education-specific metadata fields (such as learning outcomes, instructional method, and standards alignment), if you're using Dublin Core in a repository that emphasizes educational metadata (like OER Commons), you may need to add LRMI-specific elements to ensure full functionality.
  • For example:
    • Dublin Core may not explicitly capture learning objectives or educational alignment, but LRMI does. You may need to add those elements separately for repositories like OER Commons.
    • MERLOT’s extended Dublin Core includes pedagogical context and technical requirements, but these may need to be manually translated into LRMI for repositories that use it.

Applying Metadata Across Repositories: 
To ensure that OER works optimally across all three repositories (Open Textbook Library, MERLOT, and OER Commons):

  • Basic Elements (Title, Creator, Subject, etc.): These are generally interoperable across all repositories due to standard crosswalks.
  • Educational Context and Specific Elements: For repositories like MERLOT and OER Commons, where specialized metadata such as educational use or accessibility may be necessary, it’s often beneficial to apply both Dublin Core and LRMI (or repository-specific metadata).
  • Manual Enrichment: While crosswalks handle most basic metadata, some educational-specific metadata might need to be manually added or enriched for repositories with more detailed educational metadata requirements (like OER Commons).

OER Metadata Rosetta Stone Project 

Important decisions about the metadata schema you will use to ensure that the OER in your repository is discoverable, shareable, and interoperable with other repositories depends on a combination of factors, including the needs of your users, the goals of your repository, and the software platform you choose. 

Steps to Implement Metadata

Choose a metadata schema: There are several metadata schema options to choose from, depending on the level of detail, compatibility, and focus you want for your OER repository. For example:

  • Dublin Core is a widely used, simple, and flexible metadata schema that is compatible with most repositories and platforms. It has 15 core elements (e.g., title, creator, subject, description) that cover basic metadata needs.
  • LRMI is an extension of Schema.org designed specifically for educational resources. It includes education-specific fields, such as learning objectives, educational level, and instructional methods.
  • IEEE LOM is a more detailed metadata standard specifically designed for learning objects, which includes a broader range of technical, educational, and pedagogical metadata fields and is good if your repository hosts complex, multi-component OER (e.g., interactive simulations, multimedia projects).
  • Create a custom schema tailored to the specific needs of your institution, subject area, or user base. Note that this may cause challenges for interoperability.

Check platform compatibility: The software platform you choose for your repository plays a significant role in determining which metadata schema you can use, but you often have flexibility in customizing or extending the metadata (which may require a developer's help).

Determine core metadata fields: Identify which metadata fields are essential for your OER repository. For example, if you're using Dublin Core, you might start with fields like dc:title, dc:creator, dc:subject, and dc:license. If you're using LRMI, include education-specific fields like lrmi:educationalUse, lrmi:audience, and lrmi:learningResourceType.

Configure the metadata in your repository software:

  • Default metadata: If you're using a platform that defaults to Dublin Core (e.g., DSpace, EPrints), you can start by populating the standard metadata fields during the upload process.
  • Custom metadata: For more complex needs, you’ll need to configure your repository software to accept custom metadata fields. This might involve modifying configuration files or using plugins/extensions that allow additional metadata fields.

Define controlled vocabularies: For educational metadata, you might use vocabularies like Bloom’s Taxonomy for learning objectives or LRMI-specific vocabularies for learning resources and audience types.

Ensure interoperability: If you plan to share your metadata across platforms (e.g., via OAI-PMH protocols), it’s essential that the metadata is standardized and uses widely recognized schemas like Dublin Core or LRMI.

Test and validate metadata: Upload sample OER and check how the metadata fields are populated, displayed, indexed, and searchable.

Train users and stakeholders: Provide training or guidelines for users (e.g., faculty, librarians) who will upload OER to the repository. Ensure they understand how to input metadata correctly and consistently.

Associating/Attaching the Metadata to the OER

Uploading metadata via repository interfaces: In most OER repositories, you will enter metadata through an upload form or metadata entry interface when you submit the OER for hosting, and this metadata will exist in the repository's database separate from the OER file. This is the most common method and assures compatibility with the platform's search capabilities. The process involves:

  • Manual Entry into Fields: When you upload the OER (e.g., a textbook, video, or interactive content), you’ll be prompted to fill out a set of metadata fields (such as title, author, description, license) in the repository's submission form. These fields are part of the repository’s metadata scheme, and you do not need to create a separate metadata file.
    • Example: When uploading to MERLOT, you’ll be asked to complete metadata fields like content type, author, language, technical format, and educational context.
    • Example: OER Commons uses an LRMI-based submission form, where you fill out fields for educational alignment, audience, and instructional method.
  • System-Generated Metadata: Some metadata, like file format or size, may be automatically generated by the system when you upload the file. For instance, if you upload a PDF, the repository might auto-fill fields indicating the file type and size.

Embedding metadata within the OER
Another option is to embed metadata directly within the OER file itself. This is more common for specific types of resources, such as digital textbooks, images, or multimedia, where metadata is embedded for long-term portability and discoverability outside of a single repository.

  • For Text-Based OER (e.g., PDFs, eBooks):
    • PDF Metadata: You can embed metadata directly into a PDF file by editing the document’s properties. Tools like Adobe Acrobat or other PDF editors allow you to embed title, author, subject, and other metadata into the file. This is useful if the OER is distributed outside of a repository, as the metadata will stay with the file.
    • ePub or Other eBook Formats: For eBooks (e.g., in ePub format), metadata can be embedded directly within the ePub structure using tools like Calibre or through the ePub editor itself.
  • For Images and Multimedia:
    • EXIF Data for Images: For images, metadata such as author, description, and license can be embedded into the file using EXIF metadata standards. Many image editors, such as Adobe Photoshop or GIMP, allow you to embed metadata directly into image files.
    • ID3 Tags for Audio Files: For audio files, metadata can be embedded using ID3 tags, commonly used for MP3 files. This can include information like the title, artist (author), and even license information.
  • Video Metadata: For videos, metadata can be embedded within the file using formats like XMP (eXtensible Metadata Platform). This allows metadata to travel with the file even when shared outside of a repository.

Uploading a separate metadata record
In some cases, repositories allow or require the submission of a separate metadata record file (in XML or another structured format) alongside the OER. This metadata file contains all the relevant metadata about the OER and is stored alongside the resource itself.

  • XML Metadata Records: If you are using a platform that supports more complex metadata standards (e.g., Dublin Core or LRMI in XML format), you may need to upload a separate metadata file. This file contains the structured metadata in a machine-readable format.
    • Example: In repositories that use Dublin Core, you might create a metadata XML file that contains elements such as <dc:title>, <dc:creator>, and <dc:license>. This XML file is uploaded alongside the OER itself.
  • Metadata Templates: Some repositories provide metadata templates or forms that generate a metadata file (e.g., an XML or JSON-LD file) that can be downloaded and re-uploaded with the OER. This file will then be used to populate metadata fields in the repository.

Harvesting metadata from other repositories
Some repositories use protocols like OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) to share and harvest metadata records from other platforms. In this case, metadata doesn’t need to be manually added each time; instead, it’s harvested from an existing system.

  • Metadata Harvesting: If the OER is already in a repository that supports OAI-PMH, another repository can harvest the metadata automatically. This is common in federated repositories where metadata is shared between platforms.

Further Reading

  • Sharing OER via University of British Columbia's Program for Open Scholarship and Education - This page describes OER sharing from a practical perspective including some example workflows and questions you need to answer before proceeding.

Active Federated Search Options

Challenges in Developing a Union Catalog for OER

  • Metadata Inconsistencies: OER repositories often use different metadata standards (e.g., Dublin Core, LRMI, custom schemes). While crosswalks exist, full metadata harmonization is challenging.
  • Global vs. Local Repositories: Some OER repositories are localized (focused on specific regions, institutions, or subjects), making it difficult to aggregate metadata globally.
  • Decentralization: OER resources are hosted in a decentralized manner, which complicates creating a centralized catalog that indexes all available resources.
  • Sustainability: Developing and maintaining a global union catalog requires significant financial and institutional support, which has historically been difficult to sustain over time.

Reading

Viewing

  • LRMI Metadata in use - overview of LRMI, and ""presentations from projects that have used LRMI in a national context to describe OER, to make curriculum content more reusable, and to match learning resources to learning objectives.