Add temporalCoverage to geoLocation in metadata

DataCite Chat Room
1

I am interested to get your feedback on my proposal to add temporalCoverage to the existing geoLocation in the DataCite metadata schema.

The detailed proposal is available at: https://docs.google.com/document/d/1_R8sqYFalgu6iwsUwoOfD1DdFRFbRQlZdnE4ujnIAag

I am especially interested in your answers to:

  • Is this extension useful for you?
  • Do you currently use of the ‘dates’ field to provide this information?
  • Would you prefer as implementation a temporalCoverage connected to geoLocation or an additional dateType option in the dates section?

Please use DataCite’s Form for your Feedback: Portal Feedback - Metadata Schema Suggestion Survey

1 Like
2

I’m looking at suggestions we’ve received to start planning schema 5.0, and I’d like to revive this discussion!

We’ve received lots of feedback that it should be possible to indicate temporal coverage separately from spatial coverage. Suggestions have pointed to Schema.org, Dublin Core, and other standards as precedent here.

We have also received some other requests to have a date range associated with a specific metadata field, to indicate when that field is applicable. In @Stockhause’s use case, this field is GeoLocation; but we’ve received similar suggestions for Subjects and Creators.

So, I’d like to throw two questions out to the chat room:

  • Do you have a use case for temporal coverage as applied to the entire resource?
  • Do you have a use case for “dates applicable” for a specific metadata field (e.g., GeoLocation, Subject, Creator)?

Thanks in advance for your input!

3

For temporal coverage for the whole resource, I believe this is already done.

Pg 22 of V4.4 in the definition of date says: Use RKMS- ISO860123 standard for depicting date ranges. Example: 2004-03-02/2005- 06-02.

This can be used for any dateType, so, for the temporal extent of the whole dataset, I use dateType=Collected.

4

In the use case I came across spatial and temporal coverages are related. Well, Ted, we can decide to collect start and end dates in different formats but there are some problems with your suggested solution, which I also outlined in the google document:

  1. We loose the relation of spatial and temporal coverage (see second use case in the google doc).
  2. Most date_types describe the data handling not the data content. Mixing these information is not ideal. That has caused non-uniform usage. I have also got the recommendation to use date_type=Valid.
  3. Not all dates are real world calendar dates in our modelling data use case. So we need to define the calendar in addition and indicate that these dates should not be validated by out-of-the-box date validation functions. Coverage is the better term then.

These are the reasons why standards like ISO19115 or W3C DCAT do it in a similar way with related spatial and temporal coverages.

I would be really interesting to get one of the use case, which Kelly mentioned where space and time of the data location are unrelated. I am biased as I studied physics. That’s why I only know use cases located in space and time or have a certain spatial-temporal extend.

5

I think “Collected” and “Coverage” are distinct, though they may overlap in some cases. For example, I could conduct an interview today with someone discussing their experience in the year 2000. The date Collected would be 2023-03-21, but the dates covered by the data (the interview recording) would be 2000-01-01 to 2000-12-31 (or simply “2000”).

6

Sorry for the delay getting back to you @Stockhause, and @tedhabermann! I missed these notifications.

It is definitely the case that standards that are more geospatial-focused, like ISO 19115, tend to link space and time, but this is not true everywhere. In DCAT, the temporal coverage property is not inherently linked to spatial coverage: Data Catalog Vocabulary (DCAT) - Version 2. Relatedly, schema.org has temporalCoverage, again a separate property: temporalCoverage - Schema.org Property.

We do need to consider interoperability with schema.org; indeed, one of the requests for temporal coverage was motivated by our current lack of an equivalent property. So, there definitely needs to be a way to specify temporal coverage without requiring a corresponding location.

As for use cases - I can think of cases where the location is very broad and/or the temporal coverage is more important than the spatial coverage… for example, world population data for a given set of years. There are likely better examples in the humanities; the personal interview/memoir example comes to mind again here. It would be great to get a few more specific use cases.