BatCAT deliverable 4.2: Report on data stewardship and good practice

101137725/BatCAT/WP4/D4.2 D4.2: Report on data stewardship and good practice Grant agreement number: 101137725 Project acronym: BatCAT Project title: Battery Cell Assembly Twin Project website: http://batcat.info/ Project start date: 01.01.2024 Project duration: 42 months Call topic: HORIZON-CL5-2023-D2-01-03 Deliverable type1: Report (R) Related work package: WP4 Due date: 30.09.2025 Actual submission date: 30.09.2025 Responsible beneficiary: NMBU Dissemination level2: Public (PU) Version: v1.0.0 Abstract: This report outlines the governance framework for data stewardship in BatCAT (Task 4.6). It sets practical rules for handling project data and metadata, complementing schema development (in T4.2), data landscape mapping (in T4.3), and ontology development (in T4.4). The proposed framework defines minimal metadata kernels per record type, a metadata-change workflow, PID management based on Handles system. Integrity and consistency checks are addressed through validation against the BatCAT PID profile. The deliverable emphasises alignment with community recommendations (FAIR, EMMC, RDA). 1 Deliverable type: R = Report, P = Prototype, D = Demonstrator, O = Other. 2 Dissemination level: PU = Public, SEN = Sensitive. Ref. Ares(2025)8236504 - 30/09/2025 Version v1 Page 2 of 18 Author list Beneficiary Name Contact e-mail IS Timm Fitschen [email protected] GCL Gerhard Goldbeck [email protected] STFC UKRI Silvia Chiacchiera [email protected] NMBU Martin Thomas Horsch [email protected] STFC UKRI Noel Vizcaino noel.vizcain[email protected] NMBU Maria Bashir [email protected] Document history Version Date Reason/comment Revised by 1.0 30.09.2025 Deliverable due date See author list for all who contributed Disclaimer Funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Climate, Infrastructure and Environment Executive Agency (CINEA). Neither the EU nor the CINEA can be held responsible for them. Abbreviations and acronyms W3C Word Wide Web Consortium. EMMC European Materials Modelling Council FAIR Findable, Accessible, Interoperable, Reusable FDO FAIR Digital Object IRI Internationalized Resource identifier. Internationalised URI. (RFC 3987) PID Persistent Identifier RDA Research Data Alliance RDF Resource Description Framework SDO Scientific Data Officer KI Kernel Information JSON-LD W3C JSON for Linked Data. DCAT W3C Data Catalog Vocabulary MD5 Hash algorithm. (RFC 1321). PRO-V W3C Provenance Vocabulary. SHA Family of hash algorithms (RFC 4634). SPDX Software Package Data Exchange. SPDX 2.2.1 equals ISO/IEC 5962:2021. ISO 8601 Datetime standard (RFC 3339). ORCID Open Researcher and Contributor ID DOI (Crossref) Digital Object Identifier. UTF-8 Superset of ASCII including additional bytes to encode Unicode characters. Version v1 Page 3 of 18 BatCAT has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement no. 101137725. Contents 1. Contents ...................................................................................................................................................... 3 2. Executive summary...................................................................................................................................... 4 3. Roles for the governance workflow ............................................................................................................ 4 Scientific Data Officer (SDO) – NMBU ............................................................................................................. 4 Data Contacts – Each Partner .......................................................................................................................... 5 Platform Contacts – Technical Partners .......................................................................................................... 5 Ontology Contacts ........................................................................................................................................... 5 4. Persistent identifiers and metadata profiles ............................................................................................... 5 The BatCAT Handle Record Profile (v0.1) ........................................................................................................ 6 Authoritative metadata, landing pages, and record-type templates .............................................................. 6 Creation, validation, and use ........................................................................................................................... 7 Versioning ........................................................................................................................................................ 7 Tombstoning .................................................................................................................................................... 7 5. Metadata schema change workflow ........................................................................................................... 8 Metadata schema change workflow: .............................................................................................................. 9 6. Sovereignty, data sharing, and data access ................................................................................................. 9 7. Consistency ................................................................................................................................................ 10 8. Integrity ..................................................................................................................................................... 11 9. Retention & deletion ................................................................................................................................. 12 10. Analysis of community recommendations ............................................................................................ 13 11. Managing and publishing governance specifications ............................................................................ 16 12. References ............................................................................................................................................. 17 13. Annex ..................................................................................................................................................... 18 Version v1 Page 4 of 18 1. Executive summary This document provides the first version of the BatCAT data stewardship framework, generated under Task 4.6 - ‘Data Stewardship’. The aim is to ensure that data produced and exchanged in the project is managed in a consistent, transparent, and FAIR-compliant way, while keeping the approach practical for all the partners. The document introduces the roles and workflow for metadata governance (cf. Sec. 2 and Sec. 4) and PID architecture together with a minimal set of metadata fields agreed through a consortium survey and proposes initial practices for persistent identifiers (Handles/DOIs) and versioning (cf. Sec. 3) and consistency checks will be supported through validating PIDs against the BatCAT Handle Record Profile (cf. Sec. 3) to ensure that all records comply with a common rule set. Overall, this deliverable should be seen as a living governance baseline rather than a fixed rulebook. This is the description of how data stewardship is envisioned at present. It will evolve over the course of the project as partners provide feedback, and it complements related work in WP4 on schemas, metadata landscape, and ontologies. Accordingly, this document is accompanied by a public GitHub repository (https://github.com/HEBatCAT/BatCAT-DataStewardship) where the agreed (meta)data policies are stored, in markdown format. All text, from all sources, must be encoded as UTF-8 for processing 3 . 2. Roles for the governance workflow To ensure that data stewardship in BatCAT is implemented in a structured and transparent manner, a governance framework has been established. The identified roles (SDO, Data, Platform and Ontology contacts) are described below. Scientific Data Officer (SDO) – NMBU NMBU serves as the Scientific Data Officer (SDO) for Task 4.6. This role provides oversight and coordination of BatCAT’s data stewardship governance. The SDO is the point of contact for changes that could affect how data and metadata are structured, described, or managed across the consortium. In practice, this means the SDO is responsible for receiving and reviewing change requests related to the metadata schema, the use of persistent identifiers (PIDs), and the rules for data retention. Every formal change request is reviewed within five working days. If the change is relevant only to a local workflow or documentation, it may be directed to the appropriate partner or platform contact. 3 https://www.gov.uk/government/publications/open-standards-for-government/cross-platform-character-encodingprofile Version v1 Page 5 of 18 However, if the change has consequences for the project as a whole, the SDO ensures that it follows the full governance workflow. The SDO is notified only when a change is considered major, for example, modifications to the agreed kernel attributes (the minimum set of metadata fields required), changes to PID profiles or adjustments that affect the alignment with ontologies developed in Task 4.4. These kinds of changes influence interoperability and long-term data governance and therefore require central review. When such a request is made, the SDO is responsible for triaging it, consulting with ontology and platform contacts where necessary, and ensuring that the final decision is recorded. All approved major changes are entered into the central decision log, which serves as the authoritative record of BatCAT’s data stewardship governance. This process guarantees accountability and provides transparency for both consortium partners and external reviewers. Data Contacts – Each Partner Every consortium partner designates a Data Contact for the data they generate, curate, or manage. The role of the Data Contact is to ensure that the agreed minimum metadata kernel is completed for each dataset or digital object contributed to BatCAT. The Data Contact also confirms that retention rules are followed locally, according to the shared Retention Playbook. Platform Contacts – Technical Partners Technical partners serving as Platform Contacts are responsible for the implementation of approved changes in the systems used by BatCAT, including eLabFTW, LinkAhead, and the central node. Once a metadata or PID policy change is agreed, Platform Contacts ensure that it is reflected in the operational systems in a timely manner, typically within two weeks of approval. Ontology Contacts When a proposed change alters the meaning of a metadata field or raises questions of semantic alignment, the Ontology Contacts are consulted. Their role is to verify that BatCAT’s metadata remains consistent with the ontologies being developed in Task 4.4 and with external standards such as EMMO. This ensures long-term interoperability and alignment with the broader materials modelling community. 3. Persistent identifiers and metadata profiles To make digital object identifiers both human-resolvable and machine-actionable, BatCAT follows architecture that distinguishes (i) globally unique persistent identifiers (PIDs); (ii) a minimal, machine-actionable record stored with the PID itself (iii) domain-rich master metadata in BatCAT’s platforms and presented on the PID’s landing page. Version v1 Page 6 of 18 This is consistent with is community guidelines. Research Data Alliance (RDA) recommends keeping only a small, stable set of attributes in the PID record sufficient for automated decisions at resolution time while richer descriptions remain in external systems and on the landing page (Weigel, et al., 2019). PID kernel Information is a set of mandatory and optional attributes that is stored within a PID record. In parallel, the FAIR Digital Object (FDO) approach frames PID records as profile-governed collections of attributes whose keys and value constraints are registered, so that software can validate and interpret PID records. Concept of PID Kernel Information is implemented through a Handle record profile (FDO Forum, 2024). The BatCAT Handle Record Profile is our PID KI profile. The BatCAT Handle Record Profile (v0.1) In BatCAT we implement PID-KI as the BatCAT Handle Record Profile (v0.1), a short public specification registered with its own PID, that lists mandatory attributes for every BatCAT Handle record inspired by RDA PID-KI ( see Annex Table 1) . Each BatCAT PID includes a profile pointer to this Profile, and new records are validated against for consistency checks . In other words, the rule set for PID KI are enforced through the BatCAT Handle Record Profile. Every BatCAT Handle record include at least: • 21.T11966/FdoProfile: PID of the BatCAT Handle Record Profile (v0.1). • 0.TYPE/URL or 10320/loc : Landing-page URL. • 21.11172/dateCreated: ISO 8601 creation timestamp. • 21.11172/versionId: Opaque 160bit version identifier (or longer) • 21.11172/digitalObjectPolicy: link/PID to the policy covering lifecycle rules (embargo, retention, access, tombstoning). Recommended attributes are • 21.11172/license: Link/PID to license (in case of publicly available data) • 21.11172/dateModified: ISO 8601 timestamp of last modification • 21.11172/authors: List of attributable authors of the data (not publishers or curators) • 21.11172/citation: Recommended citation of this dataset. • 21.11172/keywords: List of keywords. • 21.11172/provenance: Link/PID to a provenance information • 21.11172/versionTag: SemVer 2.0.0 compliant version tag Tombstoning is handled via the policy and landing page: PIDs never disappear. If an object is withdrawn, the PID resolves to a tombstone page stating what was removed, when and why, and, where available, the replacement PID (Weigel et al., 2018). Authoritative metadata, landing pages, and record-type templates Version v1 Page 7 of 18 The Handle record is intentionally thin. The landing page summarises the object for humans and links to its authoritative metadata and files, for example in LinkAhead. Inside LinkAhead, BatCAT applies a small project-wide baseline, minimal kernel includes: Owner/creator, title/name, creation date, version, license, provenance/source, related PIDs, with optional fields such as format and description. It could be said that changing e.g. kernel attributes is de facto an architectural change (affecting all platform). Rarely should happen. Creation, validation, and use Handle PIDs and Records should never be created manually. The DKMS based on LinkAhead will mint PIDs during the creation of LinkAhead Entities and create PID Records when an Entity is being published in the BatCAT Dataspace. As detailed in the sections Consistency and Integrity, the consistency and integrity of the PID Records are partly guaranteed by design. However, the conformance with the BatCAT Profile is the responsibility of any agent creating or updating the Handle Record. LinkAhead’s creation procedures are tested with detailed integration tests to ensure conformance with any configured FDO Profile. LinkAhead also provides an automated way to validate PID Records, even those which have not been created by LinkAhead, by just following the FDO Specifications (FDO Forum, 2024)and the Profile Definition. Governance note. Profile changes are rare by design. Any update is treated as a major change under the metadata-change workflow (triage, review with ontology consultation where needed) Versioning Versioning in BatCAT ensures that changes to digital objects remain traceable and consistent across systems. Each object carries an opaque bit-valued version identifier and, if applicable, the link to a previous version. The version is recorded both in the PID record and on the landing page. Additionally, versions may be tagged as revisions using a strictly ordered versioning scheme, following SemVer 2.0.0. While SemVer is originally intended to be used for software versioning (source code and/or compiled code), we apply it to datasets by defining the API of a dataset as the formatting and structure of the data – correcting errors in a data set would increase the patch version, adding data (e.g., appending rows to a table) or changing the structure in a backwards-compatible way (e.g., by appending a column to a table) would increase the minor version. Breaking changes (e.g., removing a column from a table and splitting it up into two new columns) would require a major version bump. Tombstoning Persistent identifiers remain resolvable even after withdrawal. If a digital object (or a version) is withdrawn, the PID resolves to a tombstone landing page that states: • the object identifier/title • its status = withdrawn • the withdrawal date/time • a brief reason/context where appropriate • a replacement or successor PID, if available. • The descriptive metadata remains accessible so that citations and provenance are preserved. Version v1 Page 8 of 18 This is governed by the project’s PID policy is documented in public repository 4 4. Metadata schema change workflow The PID Profile in Sec. 3 stays minimal and stable but metadata schema and template changes must therefore be controlled, reviewed and documented. In this document “metadata schema” refers to the project-wide minimum templates used for ingest into LinkAhead and/or eLabFTW. This section (cf. Sec. 4) covers baseline project-wide metadata fields (i) (title/name, creator/owner, creation date, version, licence, provenance/source, related PIDs, optional description/format) and (ii) ontology mappings tied to those templates and any proposal to add, rename or reclassify any of these baseline fields are governed here. The following workflow governs changes to the minimum templates for ingest into LinkAhead/eLabFTW. Figure 1: Metadata schema change workflow. 4 https://github.com/HE-BatCAT/BatCAT-Dataewardship Version v1 Page 9 of 18 Metadata schema change workflow: 1. Submit request: A partner submits a short change request (either via the repository form (preferred) or by email). 2. Triage (≤ 5 working days, SDO): Within 5 working days, the SDO reviews the request, classifies it as minor or major, and tags the relevant Data Owner. 3. Review/Decision: The request is then assessed: it can be approved, sent back for clarification, or rejected with rationale. 4. Implementation: Once approved, implementation is ensured by the designated platform contact. 5. Review check: The SDO performs a final check; if the change alters the meaning of a field, the Ontology contact is also consulted. 6. Release/Publish: The update is released and made available to partners. 7. Log and Notify: A brief entry is added to the decision log, and all partners are notified of the outcome. Timescale: Review and decision (triage, assessment, and final check) are targeted to be achieved within five working days each while technical implementation of approved changes by Platform Contacts should be completed within two weeks of approval. These timelines are indicative targets rather than rigid deadlines, inspired and aligned with earlier Horizon projects such as (VIMMP Consortium, 2021) BatCAT ontologies: A set of ontologies developed within BatCAT, they contain all relevant concepts needed in the project, in particular to describe its use cases. By construction they are richer than the schema, in terms of the number of domain-specific entities (concepts, relations) they contain. They ensure interoperability beyond BatCAT (e.g., with other ontologies) and can be used as a source for additional metadata. The ontologies are written in Turtle (.TTL) format. Once completed, they will be public and available through a well-known dedicated repository, such as LOV-Linked Open Vocabularies 5 . The entity IRIs will be resolvable. 5. Sovereignty, data sharing, and data access While the Handle PID System is responsible for making data findable and citable in general, the BatCAT DKMS is responsible for sharing data between partners of the consortium and for providing access to metadata and data for partners and external users. The PID Record will provide a pointer to the Landing Page of a data set which is a human-readable and machine-readable representation of the data and will inform any client e,g., browsers, indexers, and crawlers, which access mechanisms are provided and which authentication and authorization is required. The DKMS is responsible for providing the Landing Page in such an interoperable way. Publicly available (meta-)data are accessible via HTTP endpoints serving HTML, JSON, and file downloads. In case of access-restricted data, human users need to login via Identity Management systems, e.g., via ORCID, 5 Linked Open Vocabularies ,LOV, https://lov.linkeddata.es/dataset/lov/ (Note: Accessed on 18 Sep 2025). Version v1 Page 16 of 18 Figure 2: A data lifecycle model shown with crosscutting concerns of the FAIR data principles. In the context of BatCAT we note in particular the provenance recommendations3 and the importance of persistent identifiers for samples, as for all records and digital objects in general. For PIDs, the pertinent RDA recommendations (Weigel, DiLauro, & Zastrow, 2015) are: For explanation, we quote from (Weigel, et al., 2019) “PID Kernel Information is a set of attributes stored within the PID record, i.e., information stored at a global or local PID registry and accessible by a resolver. The primary purpose of PID Kernel Information is in support of smart machine actionable decisions that can be accomplished through inspection of the PID record alone.” Note that a resolver is a globally available infrastructure system that has the capability to resolve a PID into useful, current state information describing the properties of a Digital Object. The Handle PID service used by BatCAT is able to utilise PID Kernel information. 10. Managing and publishing governance specifications BatCAT makes its data stewardship governance actionable by (i) publishing the mandatory metadata kernels and governance artefacts in a public location, and (ii) ensuring a time-bounded metadata change process where every approved update is logged. To ensure transparency, all core artefacts are publicly available and maintained under version control in the BatCAT governance repository. The following artefacts are maintained and versioned for project use: • metadata schema-change workflow, • PID and landing-page policy (including tombstoning), • BatCAT Handle Record Profile (PID Kernel Information), • Retention Playbook, and • minimum metadata kernels. Version v1 Page 17 of 18 All governance documents are made available in the public BatCAT governance repository, which serves as the reference for this document 15 . Most artefacts are provided in Markdown format, while the minimum metadata kernels are also supplied in YAML to enable structured and machineactionable reuse. Where applicable, future tagged releases will include additional machine-readable companions such as JSON-LD templates, RDF/TTL mappings, or YAML/JSON examples, accompanied by release notes documenting approved changes. To operationalise these specifications, BatCAT defines a minimum DCAT-compatible metadata set per record type. This baseline is expressed in community-standard formats and aligned with established frameworks: the FAIR principles (Wilkinson, et al., 2016), MODA/CHADA, PROV-O 16 , and SPDX 17 . The PID kernel remains intentionally minimal in the Handle record to guarantee stability, while the authoritative metadata resides on the landing page or platform and can be exported in interoperable formats such as JSON-LD. 11. References Devaraju, A., & Huber, R. (2025). F-UJI – An Automated FAIR Data Assessment Tool. Zenodo. doi:10.5281/zenodo.15118508 Elmasri, R. &. (2015). Fundamentals of database systems (Vol. 7th ed.). Boston, MA, USA: Pearson. Elmasri, R. &. (2016). Fundamentals of Database Systems (Vol. 7th edition). Boston,MA: Pearson. FDO Forum. (2024). Implementation of Attributes, Types, Profiles and Registries (Working Draft), Version 0.5 (14 September 2024). FDO Forum / Zenodo. doi:10.5281/zenodo.7825572 Silberschatz, A. K. (2019). Database system concepts (Vol. 7th ed.). McGraw-Hill Education. VIMMP Consortium. (2021). D1.6 – Taxonomy editor: Governance of ontologies, taxonomies and metadata standards. Deliverable D1.6, Horizon 2020 project Virtual Materials Marketplace (Grant Agreement No. 760907). Retrieved from https://cordis.europa.eu/project/id/760907 Weigel, T., DiLauro, T., & Zastrow, T. (2015). PID Information Types WG final deliverable. ZENODO. doi:https://doi.org/10.15497/FDAA09D5-5ED0-403D-B97A-2675E1EBE786 Weigel, T., Plale, B., Parsons, M., Zhou, G., Luo, Y., Schwardmann, U., . . . Kurakawa, K. (2019). RDA Recommendation on PID Kernel Information (Version 2). Zenodo. doi:https://doi.org/10.15497/rda00031 Wilkinson, M. D., Dumontier, M., Aalbersberg, I. J., Appleton, G., Axton, M., Baak, A., & … Mons, B. (2016). The FAIR Guiding Principles for scientific data management and stewardship. 3, 160018. doi:10.1038/sdata.2016.18 15 https://github.com/HE-BatCAT/BatCAT-DataStewardship) 16 W3C. (2013). PROV-O: The PROV Ontology. World Wide Web Consortium (W3C Recommendation). https://www.w3.org/TR/prov-o/ 17 ISO/IEC. (2021). Software Package Data Exchange (SPDX™), Version 2.2.1. ISO/IEC 5962:2021. International Organization for Standardization. Available at: https://spdx.dev Version v1 Page 18 of 18 12. Annex Annex Table 1:RDA Kernel Information profile Property identifier Content format Cardinality Explanation 1 PID Handle 1..n Global identifier for the object; external to the PID Kernel Information 2 KernelInformationProfile Handle 1 Handle to the Kernel Information type profile; serves as pointer to profile in DTR. Address of DTR federation expected to be global (common) knowledge. 3 digitalObjectType Handle 1 Handle points to type definition in DTR for this type of object. Distinguishing metadata from data objects is a client decision within a particular usage context, which may to some extent rely on the digitalObjectType value provided. 4 digitalObjectLocation URL 1..n Pointer to the content object location (pointer to the DO). This may be in addition to a pointer to a human-readable landing page for the object. 5 digitalObjectPolicy Handle 1 Pointer to a policy object which documents changes to the object or its Kernel Information record, including particularly object access and modification policies. A caller should be able to determine the expected future changes to the object from the policy, which are based on managed processes the object owner maintains. 6 etag Hex string 1 Checksum of object contents. Checksum format determined via attribute type referenced in a Kernel Information record. 7 dateModified ISO 8601 Date 0..1 Last date/time of object modification. Mandatory if applicable. 8 dateCreated ISO 8601 Date 1 Date/time of object creation 9 version String 0..1 If tracked, a version for the object, which must follow a total order. Mandatory for all objects with at least one predecessor version. 10 wasDerivedFrom Handle 0..n P ROV-DM: Transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-existing entity. Source: Weigel et al. (2019), CC BY 4.0, doi:10.15497/rda00031.