Temporal Coverage for Awards, Instruments and Projects in DataCite
/Ted Habermann, Metadata Game Changers
Introduction
The DataCite Metadata Working Group stewards the DataCite Metadata Schema and is an important starting point for adding capabilities to the schema and clarifying documentation. With their guidance, the schema has evolved considerably over the years. We have tracked this evolution and tried to help DataCite users understand the benefits of changes as steps towards increasing utilization of DataCite beyond the basic identification and citation use case. One small change in Version 4.6 of the schema was the addition of Coverage to the dateType vocabulary. In terms of the increase in capabilities, this change is small, but mighty.
The Coverage dateType is defined as “The date or date range that the resource content applies to, describes, or covers”. The concept of temporal coverage has existed in many metadata dialects for a long time. The difference between Coverage and the previously existing dateType, Collected, is particularly clear in Earth Science, where rocks, fossils, or ice cores collected today cover very different times in Earth history, and in Archeology, where artifacts created long ago are collected and studied today.
Who is Using It?
Facet values from the DataCite API query https://api.datacite.org/dois?query=dates.dateType:Coverage can be used to identify the top ten early adopters of this new capability which make up 99.9% of the current usage (Table 1). Many of these fall into the Earth Science and Archeology cases described above.
Table 1. Over 160,000 instances of this dateType currently exist in DataCite. The query facets show the top 10 users of dateType = Coverage.
The DataCite schema uses the RKMS-ISO8601 standard for writing date content which works very well for describing dates with many resolutions and for describing time periods. Examples of coverage from the repositories in Table 1 demonstrate this very well.
The Columbia University Information Technology group uses the date string “2025-04-22T18:18:41.535Z/2025-10-20T23:11:23.979Z” to describe the coverage of a LibreChat dataset created several days ago (http://doi.org/ 10.57783/nstp-xm08). The contents of this dataset, hosted by https://redivis.com, are restricted, but the temporal coverage is expressed by two standard high-resolution timestamps separated by a slash.
The Archeological Map of the Czech Republic provides an example at the other end of the resolution spectrum for a report titled “AMCR C-TX-198602247 – brief report”. In this case, there are several dates included in the metadata. Two with the resolution of year and one with a timestamp are listed here:
{
"date": "1651/1800",
"dateType": "Coverage",
"dateInformation": "Modern Period 2"
},
{
"date": "1201/1300",
"dateType": "Coverage",
"dateInformation": "High Middle Ages"
},
{
"date": "2019-01-22T00:25:18+0000",
"dateType": "Created"
},
These dates demonstrate the critical role of the dateInformation metadata element. It allows inclusion of specific information about the date written as free text. In these examples, this is used as “Modern Period 2” and “High Middle Ages”, i.e. names of two time periods in the human history of Europe. This capability is also critical for geologic dates which are often expressed as names of geologic time periods like “Jurassic”.
Instruments, Awards, and Projects
Temporal coverage can play important roles for three relatively new DataCite resourceTypes: instruments, awards, and projects. Instrument became a DataCite resourceType in Version 4.5 during January 2024. Many climate datasets are collected over long time periods and instrumentation changes as instruments age and new observational techniques are developed. One of the best examples of this is the Keeling Curve of CO2 concentrations on Mauna Loa, Hawaii measured over 55+ years. Several different instruments have been used to make those measurements and the time-period over which each was used can be recorded as a coverage in the instrument metadata.
This is a very significant example, but similar changes in instrumentation happen even in small experiments in many environments and labs. Knowing when instruments are used, and more importantly, changed, is critical whenever a time series of data are being analyzed. Of course, temporal coverage is also important for describing the temporal extent of the data themselves in climate datasets in addition to instruments. As shown in Table 1, the World Data Center for Climate currently includes 90 records using coverages for climate datasets.
The landscape of identifiers and metadata for funding awards is changing with the introduction of DOIs for unambiguously identifying awards as a standard identifier type to augment funder specific identifiers currently in use. Award was introduced as a DataCite resourceType in Version 4.6 during December 2024.
The start and end dates for awards are known and shared on, for example, the NSF Award Search, so including these dates in award metadata as a coverage is straight-forward. In this case linked above, the coverage of the INFORMATE project would be written 2023-08-01/2024-12-31.
The advanced NSF award search demonstrates how the temporal coverage in the metadata can be used in the discovery process, supporting searches for awards within a time range, on or before a date, or on or after a date. The dateInformation element mentioned above also allows text strings like “High Middle Ages” or “Jurassic” to be used in discovery interfaces.
Like awards, projects were added as DataCite resource types in Version 4.6 of the schema and, of course, most projects occur over some time-period. Of the repositories listed in Table 1, Metadata Game Changers is the only repository currently exploring using temporal coverage with projects.
As with long-term observations with multiple instruments, long-term projects can be funded in a series of grants, each covering a specific time-period. In addition to funding sources, other characteristics of projects can also change over time. If these changes are judged to be significant by the project organizers, new versions of the project metadata can be created and connected to the original record using related identifiers with the HasVersion and IsVersionOf types.
This approach is analogous to the well-known versioning approach used for hundreds of thousands of Zenodo resources. For example, the FAIR Use Cases for DataCite – Radar Plot Keys presentation has three versions: 10.5281/zenodo.16280459, 10.5281/zenodo.16280683, and 10.5281/zenodo.16643096 and another DOI (10.5281/zenodo.16280458) connects all three versions as relatedIdentifiers:
"relatedIdentifiers": [
{
"relationType": "HasVersion",
"relatedIdentifier": "10.5281/zenodo.16643096",
"relatedIdentifierType": "DOI"
},
{
"relationType": "HasVersion",
"relatedIdentifier": "10.5281/zenodo.16280459",
"relatedIdentifierType": "DOI"
},
{
"relationType": "HasVersion",
"relatedIdentifier": "10.5281/zenodo.16280683",
"relatedIdentifierType": "DOI"
}
]
Project Lifespan
This model allows projects to span multiple versions as they evolve through time, like other research objects, e.g. software or presentations. Figure 1 shows relationships between two versions of a Metadata Game Changers project (purple) that occurred during different years (coverages). The two versions are connected by HasVersion and IsVersionOf relations. They share some members (light green), including the project leader and contact person, while some people are participating on only one version of the project. They also share a funder (dark green) with separate awards (shown as relation labels), and the earlier version of the project already has a result (blue). Note that each version of the project is an independent DOI with independent metadata, giving each version of the project easy access to all DataCite capabilities.
Figure 1. Relations for two versions of a project (purple) that share some team members (light green) and a funder (dark green) with different award numbers. These two versions occurred at different times, so have different temporal coverages, and the earlier project has one published output (blue).
Conclusion
The DataCite schema has evolved in many ways since 2015, some large and some small. Several evolutionary changes have occurred since 2024, and the capabilities they add are described here. These changes include the addition of Coverage to the dateType vocabulary and the addition of Instruments, Awards, and Projects as new resource types. Together, these changes have an incredible impact.
Many datasets from essentially all scientific domains and across scales from microscopic to global are collected using instruments, i.e., devices, that affect the measurements in known and unknown ways. Unambiguously identifying those instruments with an identifier like a DOI is a basic requirement for reuse and reproducibility of the results. Further, the coverage dateType makes it possible to share time periods of operation with users, helping to alleviate incorrect interpretations of instrument changes as environmental changes.
Many funding awards are limited to rather short, i.e. three year, durations. The time periods covered by awards are included on the award cover pages and in the metadata for these awards. The coverage dateType facilitates inclusion of that information in standard metadata for awards identified with DOIs. These dates can be helpful for connecting multiple awards to a single long-term project and identifying contributions made by specific awards during each time frame across the project’s lifetime.
In addition to awards, many other characteristics of projects can also change through time. Well known and heavily used versioning approaches can be combined with coverage dateTypes to provide detailed records and timelines of these changes. Like in the case of software and other research objects, managers of the project can decide when new versions are required.
Evolution of the DataCite schema extends the capabilities of existing identifiers to describe new types of objects more completely, lowering the identifier learning curve while building on existing, well-tested infrastructure. Existing and new users can take advantage of new capabilities immediately. The Archaeological Map of the Czech Republic that created and manages two repositories (arch.igsn and arch.avanjj) provides a great example of how the adoption of new capabilities occurs in practice. These repositories went through a significant refactoring in early 2025. They started by asking “what can DataCite metadata do for me?” rather than “what is the minimum required metadata?” While exploring that question, they came across the new coverage dateType. It was obvious that this new capability was critical to the complete documentation of items in their repository, and now they are using coverage for almost 150,000 of those items, far more than any other repository.
This story is part of our effort to discover and document DataCite Bright Spots. The Archaeological Map of the Czech Republic repository currently has some of the most complete DataCite metadata in the world. As early adopters, they provide great examples for others who are looking for ways to improve their metadata to support a variety of use cases and increase the return on their DataCite investments.