Report on SPASE 3.0 Effort

Report on SPASE 3.0 Effort Andriy Koval, Rebecca A. Ringuette, Brian A. Thomas, Robert M. Candey, Zach C. Boquet, Tressa L. HelveyKasulke, Lee F. Bargatze, Scott A. Boardsen, Catherine V. Byrd, Katherine Cariglia, Baptiste Cecconi, Shing F. Fung, Alexa J. Halford, Jack Ireland, Melissa R. Kane, Keil Ralf, Arnaud Masson, Ryan M. Mcgranaghan, Masahito Nose, Joana Oliveira, Bill Rideout, Michelangelo Romano, Cogan M. Shimizu, Jon Vandegriff, Robert Weigel, James Weygand, Donald Winston, Seiji Yashiro, Yoshimasa Tanaka Purpose of SPASE 3.0 development •Increase support for FAIR Guiding Principles •Simplify creation and management of SPASE resources •“Distinct from peer initiatives that focus on the human scholar, the FAIR Principles put specific emphasis on enhancing the ability of machines to automatically find and use the data, in addition to supporting its reuse by individuals.”* •“Finally, we wish to draw a distinction between data that is machine-actionable as a result of specific investment in software supporting that data-type, for example, bespoke parsers that understand life science wwPDB files or space science Space Physics Archive Search and Extract (SPASE) files, and data that is machine-actionable exclusively through the utilization of general-purpose, open technologies. To reiterate the earlier point—ultimate machineactionability occurs when a machine can make a useful decision regarding data that it has not encountered before.”* * Wilkinson, M. D. et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci. Data 3:160018 doi: 10.1038/sdata.2016.18 (2016) FAIR Principles and the SPASE data model GO FAIR (https://www.go-fair.org/fair-principles/) provides detailed description of the principles Increasing support for FAIR Principles in SPASE Machine-actionability via general-purpose, open technologies: •Resource Description Framework (RDF) (I1) •Widely used RDF vocabularies and ontologies (I1, I2): Dublin Core, FOAF, SKOS, PROV, DCAT, schema.org, SOSA, I-ADOPT, QUDT, etc. •RDF serialization (e.g., JSON-LD, Turtle, RDF/XML) (I1) Including addressing other FAIR deficiencies in the current version of SPASE: •Universal and flexible support for PIDs (DOI, ORCiD, ROR, RAiD, URI, etc.) (F1, I3) •Universal support for terms from controlled vocabularies, both internal to SPASE and external (I2) •FAIR compliant SPASE internal controlled vocabularies (I2) •Qualified attributions, including to organizations (I3, R1.2) •Qualified references to other resources (I3) https://www.w3.org/TR/rdf11-concepts IRI or blank node IRI IRI, literal or blank node RDF Increasing support for FAIR Principles in SPASE 66 accepted use cases, e.g., accepted use case #2: Users: [Heliophysics Researchers, non-Heliophysics and new to Heliophysics Researchers, Data Scientists, Teacher and curriculum developers, Heliophysics software services] Title: Discover data associated with a given measurement type or phenomenon Description: User wants to discover datasets related to a given measurement type or phenomenon. The user navigates to the Heliophysics-wide search interface (website or API), types the measurement type or phenomenon term into the search bar, and begins exploring the datasets. The user prefers to work with newer/older data and uses the time span feature in the search result page to narrow down the numerous results. Multiple rounds of community proposed/voted space and solar physics use cases: •Focus on Dataset resource type and powering Heliophysics-wide search interface •Expanded support for fundamental functionality of SPASE 2.X SPASE 3.0 development steps Accepted use cases are used to extract SPASE 3.0 functional requirements, e.g.: Req. # Requirement Description Use Case # Comments 1.12 {0 -n} Dataset SPASE metadata shall allow for Measurement Type metadata: 1. {0-1} Measurement type name 2. {1} Measurement type globally unique PID metadata* 2 , 13, 16, 20, 21, 23, 25, 26, 33, 35, 39 Maps SPASE2.X properties: • MeasurementType 1.14 {0 -n} Dataset SPASE metadata shall allow for Phenomenon Type metadata: 1. {0-1} Phenomenon type name 2. {1} Phenomenon type globally unique PID metadata* 2 , 20, 21, 24, 33, 35 Maps SPASE2.X properties: • PhenomenonType 1.18 {0 -1} Dataset SPASE metadata shall allow for data Temporal Coverage metadata: 1. {1} Absolute start time 2. {0-1} Absolute stop time 3. {0-1} Relative stop time Absolute start/stop times shall be in ISO 8601 duration format. Relative stop time (estimated stop time relative to real time, i.e. availability delay) shall be in ISO 8601 duration format. Either absolute or relative stop time, but not both, shall be included. 1, 2, 7, 13, 16, 21, 22, 23, 35, 39 Maps SPASE2.X properties: • TemporalDescription/TimeSpan/StartDate • TemporalDescription/TimeSpan/StopDate • TemporalDescription/TimeSpan/ RelativeStopDate Ref. Reference Description Comments * Globally unique PID metadata shall allow for: 1. {0-1} Identifier scheme name (e.g., DOI) 2. {0-1} Identifier scheme version 3. {0-1} Identifier scheme URI (e.g., https://doi.org/) 4. {0-1} Identifier code in the scheme (e.g., 10.5281… or item/term code) 5. {0-1} Identifier URI (e.g., https://doi.org/10.5281…) Either identifier URI or combination of identifier scheme URI (or scheme name) and identifier code in the scheme is required. Globally unique PID metadata is also used for terms from controlled vocabularies. The term name is supported elsewhere. DRAFT SPASE 3.0 development steps Another example, accepted use case #14: Users: [Curation Staff, Mission data metadata contributors, Research data metadata contributors, Large research data metadata contributors] Title: Add an author or person with another role to a SPASE dataset record and use a taxonomy of terms to indicate their role. Description: The user edits the SPASE record by adding the first and last name of one or more people to the list of contributors to the record. The user has the option to include the ORCiD, the associated institution, and the role from an external taxonomy (e.g. from the CRediT taxonomy https://credit.niso.org/) for each of the people added and for those previously on the record. SPASE 3.0 development steps SPASE 3.0 development steps Req. # Requirement Description Use Case # Comments 1.4 {1 -n} Dataset SPASE metadata shall allow for dataset Creator metadata: 1. {1} Creator type (person or organization) 2. {1} Creator (person or organization) metadata** 3. {0-1} Creator affiliation organization metadata** 4. {0-n} Creator other role metadata: 4.1 {0-1} Role name (including creators that also serve as contacts) 4.2 {1} Role globally unique PID metadata* 5, 7, 11, 14 , 17, 31, 34, 35 Maps SPASE2.X properties: • ResourceHeader/PublicationInfo/Authors • ResourceHeader/Contact/PersonID • ResourceHeader/Contact/Role • spase:Person/PersonName • spase:Person/ORCIdentifier • spase:Person/Email • spase:Person/OrganizationName • spase:Person/RORIdentifier 1.5 {0 -n} Dataset SPASE metadata shall allow for dataset Contributor metadata: 1. {1} Contributor type (person or organization) 2. {1} Contributor (person or organization) metadata** 3. {0-1} Contributor affiliation organization metadata** 4. {1-n} Contributor role metadata: 4.1 {0-1} Role name (including contact roles) 4.1 {1} Role globally unique PID metadata* 14 , 17, 31 Maps SPASE2.X properties: • ResourceHeader/Contact/PersonID • ResourceHeader/Contact/Role • spase:Person/PersonName • spase:Person/ORCIdentifier • spase:Person/Email • spase:Person/OrganizationName • spase:Person/RORIdentifier • ProviderName Ref. Reference Description Comments ** Person metadata shall allow for: 1. {0-1} Given name or initial 2. {0-1} Family name 3. {0-1} Name 4. {0-1} Contact email 5. {0-n} Globally unique PID metadata* (e.g., ORCiD metadata) Both given and family names are required, except for single name persons, where name is required. Given name includes first and middle names or initials. Contact email is required for contact roles. ** Organization metadata shall allow for: 1. {0-1} Name 2. {0-1} Contact email 3. {0-n} Globally unique PID metadata* (e.g., ROR metadata) Contact email is required for organizations (including teams) in contact roles. DRAFT SPASE 3.0 Dataset description prototype •Choice of internal or external controlled vocabularies for roles •Qualified attribution to organizations. Organizations correctly identified as organizations, not as persons. SPASE 3.0 Dataset description prototype •Choice of internal or external vocabularies for measurement and phenomenon types (spase:measurementType, spase:phenomenonType) •Funder with identifier, award with identifier •Acknowledgement (spase: acknowledgement) •Keywords with identifiers SPASE 3.0 Dataset description prototype •Choice of internal or external vocabularies for observed regions •Temporal description (spase:relativeEndDate) SPASE 3.0 Dataset description prototype •Dataset distribution (CDF files at SPDF): access rights, license, format, specification (all with identifiers) •Access services (HTTPS and FTPS) SPASE 3.0 Dataset description prototype •Access services identifier and specifications •Dataset distribution (CDAWeb HAPI server) •Endpoint description URL •Publisher with identifier SPASE 3.0 Dataset description prototype •Qualified references to other resources, including relation type with identifier and related resource type, identifier, version. No need to create separate related resource SPASE descriptions. SOSA Observation, Sensor (https://www.w3.org/TR/vocab-ssn-2023/) •Qualified references to other resources, including software that produced the data. •Instrument references SPASE 3.0 Dataset description prototype I-ADOPT Variable (https://i-adopt.github.io/ontology/) SPASE 3.0 Dataset description prototype •Variable description, including object of interest and property (from internal or external vocabularies) •Preferred unit string and unit string compliant with syntax standard