Page tree
Skip to end of metadata
Go to start of metadata

WG Participant List

WG Scope

Naming authorities =
- testing, validation and quality control.

WG Proposed Outcome

  • make sure quality allows automated processing, content review
  • testing suites in repositories
  • opening/access to metadata

WG Pages

Naming Authority Discussion

  • No labels


  1. Dear SPASE Registry WG,

    During our last couple of SMWT meetings, we've been developing slowly a "recipe" for assigning NamingAuthroities (NAs) for SPASE descriptors of heliophysics data resources. I'm providing that recipe here as a starting point for the WG to consider:

    Possible scheme for assigning NAs for observational data resources:

    For space-based resources, use…

    • Use major oversight/funding agency (NASA, ESA, CNES, JAXA,…) for resources from missions that fall well within agency management;
    • Use instrument PI institution or it’s logical oversight agency for resources from joint space mission projects, e.g., SOHO, Cluster, etc.;


    For ground-based resources, use…

    • Use major oversight/funding agency (e.g., NSF) for resources from observatories or instruments (e.g., DKIST) that fall well within agency management;
    • Use project name as NA for major community-based data resources, such as ASWS, ISWI, IUGONET, Madrigal, SuperDARN, SuperMAG, GONG,…etc.
    • Use project name for multiagency-funded projects (e.g., Nançay)
    • Use instrument PI institution if none of the above applies.

    Application starts from the top bullet to the bottom bullet in succession, stopping at the most logical level at which resource provenance can be assigned. The NA does not have to be the responsible entity that maintains the SPASE documents for the resources in question because that function could be assigned to a third party (e.g., the SMWT). 

    Please know also that while provenance applies only to inanimate objects like data resources, observatories, and instruments. It does not apply to people, who may only have affiliations, ORCIDs, etc.  The SMWT thus recommends that SMWG be retained as the NA for Person descriptions.

    In order to ensure progress can be made on the NA issue at a reasonable rate, so other work that depends on it can move forward, please try to provide your input by 12/31/2020.



  2. Hi Shing, 

    The proposed scheme (and the one currently in use) is embedding metadata into the Resource ID. This is fine in a controlled and limited environment (e.g., NASA context only, as it was at the beginning).

    When several several entities start implementing a SPASE registry tree for their own resource and creating SPASE Resource records, then the problems pop up. We discussed briefly this issue at the last telecon: how to discover resources registered in the CNES/CDPP tree ? how to keep the NSSDC archive tree up-to-date ? What about ground based observatories ?

    There are 2 questions: 

    • the search (how to find a resource?)
    • the maintenance (how to update a resource?)

    We are dealing with the 2nd bullet here: the maintenance of the resource descriptors (this includes the initial release, i.e., is the "naming" step). The various SPASE resources are not all equivalent, and are managed by different entities. There are "generic" resources (e.g., Person), there are resources managed by agencies (e.g., Observatory, Instrument...), and other by data centres (Repository, NumericalData, DisplayData...).

    This step of mapping of the maintenance responsibilities to the resources is required, however, the mapping will not be enough to decide, since some agencies will not register nor maintain there resource, although those observational resources can be referred to in NumericalData or DisplayData...

    Moreover, for resources derived from several data products (from various instruments or observatories), there can be several funding agencies, and thus the "funding-agency based" naming authority might be an issue. 

    An obvious option is then to set the root element of the SPASE resource ID to the entity who released and maintains the resource. This implies that naming authorities should then mainly be data centres (or managed by data centres). In other words, a data centre can not create resources names outside their naming scope (i.e., their tree).  

    I would advocate for adoption this solution, which would not change too much the current setup, and would imply to rely on metadata management authorities, rather than on "oversight, funding or PI" agencies. The SPASE trees would still be managed though the HPDE Github repository, so that they are accessible and findable. 

    If this scheme seems promising enough, we could try to draft a registry reorganisation path. 

    PS: Lastly, I come back to the first question listed at the beginning: there is a need for a search engine, since data of interest will appear in several SPASE trees.