On metadata enrichment - Crossref

Content Registration
, , , ,
1

Metadata is communication; it can tell a story about research and paint a picture for others to respond to and learn from, across the world and throughout the forthcoming generations. Metadata can feel technical with words like ‘infrastructure’ and ‘schema’, and sometimes, like tech in general, it comes with hyperbole. But metadata really is part art (storytelling and pictures) and part science (structured models and standards) with both aspects being equally important, and requiring people as well as systems. That necessary combination of human and machine involvement also makes metadata challenging.

This is a companion discussion topic for the original entry at https://www.crossref.org/blog/on-metadata-enrichment
2 Likes
3

Hello,

I am new to Crossref and I’m not sure if this is the right topic for my suggestion.

I’d like to suggest adding an optional geolocation element to the Crossref schema, usable on scientific publications themselves (journal articles, conference papers, reports…), not only on datasets.

Motivation
Many papers - in Earth Observation, geology, ecology, archaeology, planetary science, etc. - study a specific geographic (or planetary) area: a watershed, a fault system, a reef, a region on a planetary surface, and so on. Today there is no structured way to capture that footprint in Crossref metadata. If it were available, tools could plot papers on a map based on their actual study area, letting readers quickly see, for a given region, which publications have studied it - a genuinely useful discovery feature that text search alone doesn’t provide well (place names are ambiguous, translated, or simply absent from the title/abstract).

This would be optional, additive metadata: it wouldn’t change existing workflows, only enrich them for members who have this information available.

Proposed shape of the element

  • A geolocation block, repeatable (a paper can cover several areas), supporting at minimum:
  • a point (single location studied)
  • a bounding box
  • a polygon (an ordered list of lon/lat vertices), for an actual study-area footprint
  • An explicit, optional coordinate reference system (CRS) identifier, defaulting to WGS 84 if omitted.

On the CRS identifier specifically
Rather than a bare EPSG numeric code, I’d suggest using OGC’s resolvable. These URIs:

  • are cross-referenced with the EPSG dataset itself, so anything registered in EPSG is reachable this way;
  • are already the identifier scheme used by OGC API - Features (Part 2: CRS by Reference) and by GeoJSON-based web services;
  • are already supported out of the box by mainstream geospatial tooling - GDAL, PROJ, QGIS - which makes them very low friction to adopt for anyone who wants to actually plot the geolocation on a map;
  • extend naturally beyond Earth: for planetary/small-body science, the VESPA planetary CRS registry documents how to mint and use identifiers for non-terrestrial bodies, so the same identifier scheme covers both Earth Observation and planetary science use cases without a separate mechanism.

Other existing standards we could reuse for the geometry itself

  • OGC Simple Features / Well-Known Text (WKT, ISO 19125), GeoJSON (RFC 7946) for encoding the point/box/polygon.
  • DataCite already has a <geoLocationPolygon> element (ordered WGS 84 lon/lat points) - reusing a similar structure would make Crossref and DataCite records interoperable, and simplify life for repositories/publishers that deposit with both agencies.
  • For Earth Observation more broadly: the OGC GeoTIFF Standard (OGC 19-008r4) and the OGC API - Features / Coverages family.
  • For astronomy/planetary science: the IAU Working Group on Cartographic Coordinates and Rotational Elements (WGCCRE) reports (e.g. Archinal et al., 2018) define the reference frames for planets and satellites, and OGC’s own Testbed-19 Engineering Reports - “Non-Terrestrial Geospatial” (OGC 23-042) and “Extraterrestrial GeoTIFF” (OGC 23-028) - show OGC actively extending CRS handling beyond Earth.

I’d be glad to discuss this further here, and happy to help test/refine a proposal if there’s community interest.

Thanks for considering it!

1 Like
4

Many journals using OJS already have access to a Coverage metadata field. It would be interesting to explore whether future developments could better align OJS and Crossref, allowing this existing metadata to be reused automatically where appropriate, rather than requiring journals to enter the same information twice.