Improving FAIR for Heliophysics Digital Resource Library (HDRL)'s Metadata: Mapping from SPASE to Schema.org and DataCite and Quality Improvements

Methodology •Formed an informal working group to iterate on the existing external standards and the RDA mapping •Received input from internal groups and the community surrounding the existing standards •Implemented the finalized mapping in Python software following best practices •Incorporated our implemented mapping into existing open-source software (Schema.org) or new open-source software (DataCite) Why DataCite and Schema.org? •Both DataCite DOI and Schema.org metadata are used for assessing FAIR •Enriching our mapping to Schema.org metadata increases our interoperability with other sciences •Schema.org metadata is used by internet search engines •DataCite is considered by publishers to be the “record of truth” •NASA SMD best practice is to use DataCite to create DOIs Improving FAIR for Heliophysics Digital Resource Library (HDRL)’s Metadata: Mapping from SPASE to Schema.org and DataCite and Quality Improvements Zach Boquet1,2, Rebecca Ringuette1,2, Baptiste Cecconi3, Andriy Koval4,5, Colin Smith6,7, Tressa Kasulke1,8, Catherine Byrd4,5, Brian A. Thomas5, Robert M. Candey5. 1Heliophysics Data and Modeling Consortium; 2ADNET Systems, Inc.; 3Observatoire de Paris, Université de Recherche Paris Sciences et Lettres; 4University of Maryland Baltimore County; 5NASA GSFC; 6Environmental Data Initiative; 7University of Wisconsin-Madison; 8ASRC Federal System Solutions 0009-0005-1686-262X Figure 9: Statistics for critical metadata fields in the NASA SPASE record repository. Orange indicates fields needed for citations, slash lines show fields needed for DCAT3-US compliance, with blue used for the remaining fields. Green is used to project the number of records to be updated with the respective metadata field very soon. SPASE Metadata Improvements •Full support for data licenses coming soon •1863 publisher names have been corrected (RORs also added for 1804 of these) and new publishers will soon be added to 638 records •ObservedRegions added to ~600 SPASE records Why Not Use the Existing Mapping Between Schema.org and DataCite? •Several fields from the Schema.org metadata record do not carry over to the associated DataCite metadata record such as RORs, funding, rights, etc. when using the DataCite REST API, leading us to resort to creating our own mapping Schema.org input Figure 3: Providing the same Schema.org JSON-LD (left) as input for the DataCite REST API outputs the DataCite metadata as a DataCite JSON (middle) and a Schema.org JSON-LD (right). Notice that in the DataCite Schema.org output, contributors are mapped as editors instead which causes an unknown field name error. Schema.org Metadata Issues •Citation (publication) •Merged authors (creator:name) •Genre instead of keywords •No SPASE landing page URL (identifier and subjectOf) •Adds metadata not found in the SPASE record, such as the incorrect license Figure 1: The current embedded Schema.org JSON-LD in SPASE landing page, with problematic metadata highlighted in red. (https://doi.org/10.48322/6cfb-rq65). DataCite Metadata Issues •Missing useful metadata found in the SPASE record •Metadata is not identical with the Schema.org JSON-LD despite being the same SPASE record •Adds metadata not found in the SPASE record, such as ROR IDs and an incorrect license Figure 2: The current DataCite JSON-LD metadata record for the same SPASE record used in Figure 1, with problematic metadata highlighted in red. Figure 8: Sample FAIR assessment of Schema.org (left) and DataCite (middle) metadata created from a gold standard SPASE record shown on a radial plot, with averaged scores shown in the table (right). A larger covered area implies a greater FAIR score. Before: Schema.org JSON-LD currently embedded in SPASE landing page, DataCite xml from their API. After: New Schema.org generated with soso. New DataCite generated from the new Python implementation. Projected: Once the data license metadata is added to the SPASE record. DataCite JSON output DataCite Schema.org output Figure 7: New Schema.org JSON-LD (left) and new DataCite JSON (right) created by the improved mappings using the same SPASE record used for Figures 1-2, with some notable improvements highlighted in green. Creators now match and are no longer one merged string for Schema.org. RORs and ORCiDs are now only included in these metadata records if found within the associated SPASE record. Results and Next Steps •We will use these new, more usable tools to synchronize external metadata: •Embed correct and rich Schema.org metadata in HDRL’s dataset landing pages •Mapping into the ODIS and possibly the Science Explorer •Drafting, updating and minting DOIs from NASA SPASE records •Implementing these tools is expected to significantly increase our FAIR scores Implementation Figure 4: Diagram showing how HDRL will implement the new mapping scripts within our existing metadata pipelines. The mapping from SPASE to Schema.org (incorporated in the soso python package: 10.5281/zenodo.17042051) will be used to update the existing embedded Schema.org JSONs within the SPASE records. The mapping from SPASE to DataCite will be used to update/mint DOIs which can then be included within the SPASE record metadata and serve as persistent identifiers for them. Both implementations will be an improvement for our FAIR score. Figure 6: Structure chart from the DataCite mapping documentation detailing how a DOI is minted/updated when converting from SPASE to DataCite. The script uses similar extraction functions to those found in soso, formats this SPASE metadata according to the DataCite schema, and then follows this process for minting/updating the DOI. Using the Mapping Scripts Figure 5: Screenshot from soso documentation to convert from SPASE to Schema.org. Full documentation is found at https://soso.readt hedocs.io/en/lates t/user/examples/s paseHowToConvert.ht ml, including instructions for cloning necessary repositories from the SPASE Github. ? X