Conceptually, it is useful for identifiers to be assigned at a more granular level than just the software project (often synonymous with the “software concept” or “software project”). For instance a software product may consist of different modules, which in turn may be implemented by different files. This metric tests that these different components are not all assigned the same identifier, and that the relationship between components is embodied in the identifier metadata.
Domain-agnostic comments
The granularity levels for software have been defined by the RDA Software Source Code Identifiers WG in Gruenpeter et al. (2021). Identifiers for each software component should be globally unique and persistent (as tested by FRSM-01). This metric should not be confused with FRSM-10 and FRSM-12 (related to I2) which checks that other related non-software objects are properly described and FRSM-13 (related to R2) which checks that software dependencies which are not considered a part of the
software concept of product are described.
CESSDA comments
CESSDA requirements for modularity are defined in CMA4: Modularity.
CESSDA’s products are designed and built using a microservices approach. It is expected that a separate Git repository is used for the source code of each component (aka microservice).
Context
F1: Software is assigned a globally unique and persistent identifier.
F1.1: Components of the software representing levels of granularity are assigned distinct identifiers.
Possible Implementation
domain-agnostic
requirements
software identifiers
method
Check if each software identifier resolves to the appropriate software component and examine identifier metadata.
essential
Where the “software” consists of multiple distinct components, each component has a distinct identifier.
important
The relationship between components is embodied in the identifier metadata
useful
Every component to granularity level GL3 (module) has its own unique identifier.
CESSDA
requirements
Software source code repository
method
Check that each software product is split into component microservices, each with its own DOI
essential
A separate Git repository is used for the source code of each component (aka microservices). The product deployment scripts assemble the constituent components.
important
Each component is deposited in Zenodo with its own DOI.
useful
The Zenodo record for each component is tagged with the product(s) that it contributes to.
karacolada
commented
1 month ago
D5.2 p13, p24
Detailed Description
Conceptually, it is useful for identifiers to be assigned at a more granular level than just the software project (often synonymous with the “software concept” or “software project”). For instance a software product may consist of different modules, which in turn may be implemented by different files. This metric tests that these different components are not all assigned the same identifier, and that the relationship between components is embodied in the identifier metadata.
Domain-agnostic comments
The granularity levels for software have been defined by the RDA Software Source Code Identifiers WG in Gruenpeter et al. (2021). Identifiers for each software component should be globally unique and persistent (as tested by FRSM-01). This metric should not be confused with FRSM-10 and FRSM-12 (related to I2) which checks that other related non-software objects are properly described and FRSM-13 (related to R2) which checks that software dependencies which are not considered a part of the software concept of product are described.
CESSDA comments
CESSDA requirements for modularity are defined in CMA4: Modularity.
CESSDA’s products are designed and built using a microservices approach. It is expected that a separate Git repository is used for the source code of each component (aka microservice).
Context
F1: Software is assigned a globally unique and persistent identifier. F1.1: Components of the software representing levels of granularity are assigned distinct identifiers.
Possible Implementation
domain-agnostic
CESSDA