12. Blueprint Governance¶
The governance model defines how this Blueprint could be maintained, updated and kept aligned with community needs over time. Governance is the mechanism through which the community retains ownership of the specification and ensures it remains open, accurate and useful.
12.1 Ownership and Stewardship¶
This version of the Blueprint (v1.0) is created and owned by the RDA community, with the RDA positioned as an appropriate steward to keep the work open, transparent and neutral. Research institutions, infrastructures and vendors are positioned as contributors and implementers, rather than owners or governors. Ownership and governance of the Blueprint itself remain with the RDA community regardless of how the Blueprint is adopted. Separately, if the Blueprint develops into a standard, it would be useful to gather structured feedback from implementers who adopt it. This could include a forum where issues that become divisive among vendors could be discussed and reported back to the RDA community, helping to maintain the integrity and shareability of data for collaboration and metadata crosswalks.
12.2 Maintenance and Continuity¶
Stewardship could transition from the current time-limited Working Group to a standing maintenance function, or the Working Group could be re-formed on a time-limited basis for future iterations. Some form of ongoing maintenance presence within RDA structures may be needed, for example, a working group operating in a maintenance mode, or an interest group, with a rotating Chair and Co-Chair responsible for scheduling meetings, maintaining tools, working on improvements and updating policies, with rotation helping to address the risk of people losing interest over time. Either way, who carries out the work and how resources are provided would need to be addressed concretely, including how and where to recruit people to maintain the Blueprint within existing RDA structures.
Agentic models could support basic maintenance tasks, such as checking and updating links and flagging where referenced ontologies have changed. This refers to tooling that supports maintenance of the Blueprint document itself, such as checking external links or flagging changes to referenced ontologies and is separate from the Data Director as a deployed tool.
12.3 Platform and Transparency¶
The Blueprint could be maintained on GitHub,1 allowing changes to be tracked, monitored and versioned, an approach supported by several contributors. A machine-readable, open format, such as Markdown, was suggested to reduce the risk of proprietary format changes affecting it over time, with GitHub potentially synced to Zenodo2 or a similar platform for DOI minting and versioning. Wherever managed, the Blueprint should be openly accessible to all relevant stakeholders.
12.4 Review and Evolution¶
Feedback could be gathered from research institutions, infrastructures and vendors who have implemented the Blueprint, to inform updates over future review cycles, dependent on a future group or facilitated programme. There is potential to learn from how other organisations have approached the maintenance of similar technical solutions, including commercial editors such as Springer,3 Elsevier4 and MDPI5 who have implemented data repositories, AI developers with an interest in the scientific sector, and W3C,6 where examples exist of retro-compatibility being maintained between implementations and a specification. The Blueprint could evolve based on feedback from real-world implementations. Separately, and prior to any implementation, feedback gathered during the v1.0 community review period has already been assessed for consideration in v2.0; a record of how this was addressed is provided in Appendix G.
12.5 Scope and Sustainability¶
A question was raised as to whether this document is a seed point for implementers to build on as they see fit, or a technical specification that continues to be updated, the latter requiring considerably more ongoing work. Future iterations of the Blueprint would benefit from more explicitly distinguishing between normative requirements that all implementations must satisfy, implementation guidance that supports but does not constrain implementation choices, and optional examples or future considerations that are illustrative or deferred. If the Blueprint continues as an ongoing activity, a sustainability model would be needed, including a concrete answer to how maintenance is resourced.