Announcement: The operation of NSDL has been transferred to ISKME's OER Commons (effective December, 2014) - Read the news release.
This documentation describes the policies, procedures, and services that existed while NSDL was operated by UCAR.
Digital libraries revolve around the sharing of metadata. This means contributors to the library need to share their metadata with the library. And then libraries need to share this metadata back out with users and downstream consumers. This section describes both of these processes. Also, sharing you metadata with a digital library is a great way to ensure more exposure of your collections than otherwise might be possible.
Please note that all collections submitted to the NSDL must be approved by NSDL management. To find more information about that process please visit the Contributing a Collection section.
All metadata record in the NSDL are xml documents that are valid and well-formed. To create such xml documents, you can
Since xml is a text-based markup language, you could probably create xml metadata records by hand for a very small collection of resources. This certainly isn't recommended, though, since a) it's extremely tedious and b) oftentimes the person most familiar with the educational resource (who will be cataloging the resource metadata) is not familiar with xml.
And if you don't have metadata for your resources yet, it is probably easiest to create metadata records with a cataloging system that creates a convenient and straightforward user interface in which to enter information. The cataloging system then translates the information entered by the cataloger into xml records in the appropriate format behind the scenes.
The NSDL supports the use of the NSDL Collection System (NCS). The NCS can be downloaded and run from your own servers or you can have NSDL host an instance of the NCS web application. Having the NSDL host an instance has some costs.
If you have existing metadata in spreadsheets, databases or generate metadata from websites or other catalog system, you may programmatically make xml records and load them into an OAI provider for harvest by the NSDL. NSDL can help with crosswalking your metadata.
Xml records are shared with the NSDL using OAI-PMH (Open Archives Initiative-Protocol for Metadata Harvesting). OAI-PMH specifications can be found [here|]. This process involves setting up an OAI provider that points to your repository of xml records. This OAI provider has a base url which is used by NSDL to make http requests to get your metadata.
In order for the NSDL to make successful requests for your metadata, your metadata records need to be xml valid and xml well-formed and in one of the following accepted NSDL metadata formats:
Then you load your metadata records into your OAI provider with each collection and metadata format combination being a separate OAI set. Then provide NSDL the OAI base url, setName and setSpec.
There are many different software packages which will help you to set up your own OAI provider. We recommend the NSDL web application call jOAI. Information about jOAI and how to install it can be found on the Services and Tools wiki. For more information on the implementation of an OAI provider, please see the OAI Server Checklist.
After a collection builder's metadata records have been checked for validity and well-formedness, the OAI provider has been tested, and the collection has been officially accepted into the NSDL, we can officially accession the collection into the NSDL by harvesting the records into our repository. Our harvesting program is set to harvest from the collection builder's OAI provider once every 30 days. New harvests completely refresh all of the records in the NSDL's repository with the records posted in the collection builder's repository. This ensures that we get all new records and updates on a monthly basis.
The date of harvest is automatic by default, but can be set for a certain date by collection builder request. If connection to the OAI provider's base url is lost during harvest, or if more than 10 percent of the records in the collection builder's repository are not valid and well-formed, then the harvest will fail. In this case, the NSDL will need to work with the collection builder to correct the problem before any metadata records can be updated.
For all collection builders who have collections accessioned into the NSDL, we provide reports about the resources and how they are being used at nsdl.org. The first measure reported on is resource vitality. Our vitality application checks each resource url four times per month to ensure that a connection can be made. If the resource url is a broken link or is unresponsive all four times it is checked, it will be marked as having 'low' vitality (as opposed to medium or high vitality). A report is then generated listing all of the resources which the collection builder needs to fix. Sometimes, collection builders do not have the means to fix these low vitality resources. In these cases, the NSDL may mark certain resources to not be shown at nsdl.org (known as 'weeding'), in which case the collection builder will receive notification via weeding reporting. Lastly, the NSDL provides collection builders with information about how many times their resources were viewed or favorited at nsdl.org. All of these reports are sent out in a combined email every other month to the collection building staff on our email list.
For more information about programmatically accessing the metadata from our repository, please see the documentation about the NSDL OAI Data Provider.