4.1.  Summary

The Open Science domain requires highly detailed metadata for multiple aspects, and these in turn require common patterns to be extended with relevant details. This leads to highly complex schemas, irrespective of how these are defined and managed.

The use of Building Blocks to decompose this complexity and create encapsulated, reusable solutions that can be combined to meet the descriptive power was introduced to a set of participants and explored. Each participant was able to make some progress towards understanding and utilizing this approach, and some significant success was achieved in developing new Building Blocks for the emerging decision to support testing the WF4ever design to meet OSPD needs, integrating with the extensive libraries based on existing OGC standards.

In addition, the OSPD project supported deeper testing and refinement of the STAC Building Blocks in particular, and has already raised awareness of the potential for this approach to solve the same types of problems in other communities.

Finally, the use of Building Blocks to support semantically enriched descriptions of schemas has been shown to provide significant advantages in the use of AI approaches to extract and translate reports, code and other metadata formats into a common interoperable workflow description model.

These results are quite preliminary in nature, but provide a qualitative assessment that refactoring complex requirements for workflow and data descriptions into a set of simplified Building Blocks provides a powerful enabler to address the long term challenges around effective interoperability in scientific and other complex information processing contexts.

4.2.  Building Blocks Principles

The Open Science Building Blocks developed in OSPD 2025 follow the principles defined by the OGC Specification Building Blocks framework. These principles aim to ensure that specification artefacts remain reusable, extensible, and applicable across different domains and implementation contexts.

In particular, the following principles are applied.

These principles allow the Building Blocks to evolve incrementally while remaining compatible with broader OGC standardization activities.

4.3.  Registers and Identification

The Building Blocks described in this report are published through the OGC Incubator Building Blocks infrastructure. Each Building Block is intended to be uniquely identifiable within a register, allowing it to be referenced by specifications, documentation, and validation artefacts.

The use of registers enables:

At the time of writing, the identifiers and versions of the Building Blocks are provisional. They may be refined as the demonstrator progresses and as feedback is collected from implementation and validation activities.

4.4.  Overview of Open Science Building Blocks

OSPD 2025 focuses on a core set of Building Blocks that are considered essential for representing scientific workflows and their execution environments in an open-science context. These Building Blocks reflect recurring specification patterns observed across different platforms and scientific domains.

The project team decide to base the OSPD solution around the OGC API Processes model, as the most viable and relevant option for describing interoperable processes. Scientific workflows can be described as chains of such processes.

The initial focus was describing workflows through use of standard metadata records for data inputs, outputs, the workflows themselves and “experiments” — or workflow execution records.

The pragmatic choice for a short term project was to leverage the ESA EarthCODE model, and the specific metadata profiles for “Product”, “Workflow” and “Experiment.”

By binding these to the OGC API Process model an abstract profile can be defined that specifies interoperability of all these descriptive sub-components of the OSPD.

This architecture is enabled by the OGC Building Blocks that uses a common packaging for available standards for each aspect, enabling the building of a comprehensive interoperability specification from standardized components.

Two key advantages accrue:

At the highest level therefore the “Open Science Profile of OGC API Processes” consists of specifications for:

The generic concept of a “Process” is refined with the following Building Blocks to standardize how workflows are described:

Additional Building Blocks may be introduced to describe additional aspects as required, such as:

The following diagram (generated automatically from the OpenScience Profile of OGC API Processes shows some of the key relationships between such elements as well as the registers of reusable Building Blocks that are leveraged to create this model.

Figure 1

4.5.  Building Block registers being re-used

The full suite of components is thus extensive, and OSPD is able to create a comprehensive interoperable descriptive framework in a short project by reusing all these elements.

4.6.  OSPD contribution and scope

The particular contribution of OSPD is thus to explore how these various existing standards can be effectively combined to describe the complexities of workflow descriptions. The degree of “granularity” of workflow description has been explored at different levels of detail:

In addition to architectural exploration, OSPD participants conducted hands-on validation exercises using the Building Blocks to describe existing workflows, executions, and resulting data products. These exercises demonstrated that while baseline provenance representations based on W3C PROV are useful, they are insufficient on their own to fully describe workflow inputs, outputs, and their relationships in a workflow-engine-agnostic manner. As a result, participants combined PROV with the WF4Ever family of ontologies (including WFDesc and WFProv), as well as OGC API – Processes ‘inputDescription’ and ‘outputDescription’ schemas, to achieve a more complete and navigable representation of workflows, executions, and products.

The OSPD phase 2 scope has shown that all these levels of description are possible using a common mechanism, however further work remains to explore the feasibility of a high level of semantic description for common concepts for highly detailed description of workflow elements.

Preliminary investigations of use of LLMs and AI to assist in generating highly detailed description suggests that the use of modular, semantically described Building Blocks can substantially increase the potential to use AI to generate candidate descriptions and support interpretation of legacy scientific workflows and outputs. Further work is required to establish the optimum level of detail in workflow description to be supported by standardized Building Blocks and the level of effort required to validate these models as detail increases.

4.7.  Relationships Between Workflow Description Building Blocks

The Building Blocks are designed to interact through explicit relationships rather than through hierarchical containment. This approach supports flexible composition while preserving a clear separation of concerns.

Typical relationships include:

These relationships allow different Building Blocks to evolve independently while remaining interoperable.

4.8.  Application Building Block

4.9.  ApplicationPackage Building Block

4.10.  Parameter Building Block

4.11.  Platform Building Block

4.12.  Profiles and Composition

Profiles represent constrained combinations of Building Blocks tailored to specific contexts or communities of practice. The OSPD scope is based on a profile supporting the EarthCODE environment. The Building Blocks presented here are designed to support future profiles using the same pattern, or for extensions to support richer descriptions needed for sub-domains for the EarthCODE environment

4.13.  Validation Through Use Cases

The Open Science Building Blocks are validated through their application in workflow reuse experiments conducted as part of OSPD 2025. These use cases provide evidence of:

Validation activities also highlighted practical constraints in existing schema definitions. In several cases, schemas were found to be overly permissive, limiting their effectiveness as validation mechanisms. Participants therefore used the Building Blocks not only as descriptive components but as a syntactic and semantic “ground truth” layer against which generated or transformed metadata could be checked. This approach proved effective for detecting ambiguity and noise in workflow metadata and for identifying areas requiring tighter definitions.

Validation activities also included partial end-to-end demonstrations of workflow lifecycles, starting from exploratory notebook environments, through workflow formalization and deployment, and concluding with access to execution provenance via standardized APIs. These exercises highlighted both the feasibility of such lifecycles using existing Building Blocks and the remaining manual steps required for full automation.

The results of these validation activities will inform future revisions of the Building Blocks and guide their potential transition towards more formal OGC specifications.

4.14.  Participant Contributions and Feedback

Participant contributions were delivered through concrete implementations and updates to Building Block repositories, including submitted and merged pull requests, example records, and tooling enhancements. These artefacts informed the validation findings summarized in the preceding sections and provide traceable evidence of participant engagement beyond conceptual design. The collected feedback will be used to inform refinements of the Building Blocks and to guide future standardization activities.

Participants from Kurrawong AI, GeoLabs, Starling Foundries, Lampata, RMIT University, and Telespazio VEGA UK Ltd contributed technical inputs to the OSPD 2025 Building Blocks Report through practical application, validation, and extension of the Open Science Building Blocks. These contributions were provided through the use of GeoDCAT, STAC, EarthCODE, OGC API – Processes, and provenance-related Building Blocks to describe existing workflows, workflow executions, and resulting data products. The activities included the preparation of concrete example records and validation exercises used to assess the suitability and limitations of the current Building Block definitions.

A significant focus of participant contributions concerned provenance modeling. GeoLabs reported that while W3C PROV-based Building Blocks were useful, they were insufficient on their own to represent workflow inputs, outputs, and their relationships in a workflow-engine-agnostic manner. To address these limitations, PROV was combined with the WF4Ever family of ontologies, including WFDesc and WFProv, and supplemented with OGC API – Processes inputDescription and outputDescription schemas. This combined approach enabled more complete representations of workflows, workflow executions, and produced datasets, while preserving compatibility with clients supporting only PROV or PROV together with WF4Ever.

Participants also identified concrete interoperability and validation issues arising from the interaction of provenance Building Blocks with Records, STAC, and EarthCODE profiles. In particular, conflicts related to required identifier and type fields were observed, preventing simultaneous validation against multiple specifications. These findings highlighted the need for clearer guidance on integrating provenance-oriented Building Blocks with Records-based metadata models and for the possible use of alternative patterns or extensions to resolve these conflicts.

Kurrawong AI assessed the use of Building Blocks as a validation layer for both manually created and automatically generated metadata. In this work, the Building Blocks were treated as a “ground truth” against which workflow metadata could be checked. While the validation mechanisms were found to be effective for syntactic compliance, several schemas were reported to be overly permissive, limiting their effectiveness for automated discovery and reasoning. This feedback emphasized the need for clearer definitions and stricter constraints, particularly for AI-assisted metadata generation scenarios.

Starling Foundries contributed validation experience focused on workflow reuse and composability. Their work demonstrated that the adoption of standardized Building Blocks for common parameters, particularly bounding boxes, enabled workflows to be chained and reused across different spatial and temporal contexts without custom adapters. This validation showed that consistent use of simple, shared Building Blocks can significantly improve interoperability and reuse across workflows and platforms .

Additional contributions from Lampata, RMIT University, and Telespazio VEGA UK Ltd were provided through example workflows, validation feedback, and engagement with Building Block repositories. Across all participating organizations, contributions included submitted and merged pull requests, development of example workflows and metadata records, enhancements to visualization and discovery tooling (including ontology and provenance visualization), and partial end-to-end demonstrations of workflow lifecycles from notebook-based development through deployment via OGC API – Processes and access to execution provenance endpoints. These artefacts informed the validation findings summarized in this report and supported the identification of remaining gaps and future work .

5.1.  Findability

OGC Blocks and related schema artifacts benefit from strong structural transparency, which improves their discoverability by both humans and machines. The use of modular JSON Schema constructs such as allOf, oneOf, and anyOf enables complex definitions to be decomposed into smaller, well‑defined blocks that can be independently identified, referenced, and reasoned about. Within the OGC Blocks ecosystem, this “jigsaw puzzle” style of schema assembly is actively encouraged and supports the clear identification of individual components and their roles.

Even in the absence of full compositional automation, OGC Blocks implementations can already declare conformance to specific profiles. These declarations do not enforce composition at the API or schema level, but they provide valuable metadata that improves discoverability and interpretability. By explicitly signaling profile conformance, implementations enable both users and tooling to more easily identify relevant standards, profiles, and extensions, thereby improving semantic clarity across the ecosystem. OGC Blocks implementations can already declare that they implement specific profiles, and even in the absence of full composition support, these declarations provide valuable information to both human readers and automated tooling, by making profile conformance explicit and improving the discoverability, interpretability, and semantic clarity of the definitions.

As part of the OSPD work, significant effort has focused on demonstrating OGC Blocks not only as abstract building blocks, but as practical enablers of semantic interoperability in operational, end‑to‑end solutions. By integrating OGC Blocks into running services and user‑facing applications, this work makes semantically enriched resources visible and discoverable in practice, rather than confining them to documentation or theoretical models. This approach is illustrated by a running pygeoapi instance in which examples from multiple OGC Blocks repositories are compiled and re‑published as part of a single deployment. By surfacing blocks authored and maintained in different registers through one operational API, the demonstration shows how distributed semantic assets can be discovered and explored coherently by both human users and client applications.

At the governance level, the OGC Blocks framework deliberately avoids imposing a centralized model for OGC Blocks registers. Any organization may create and maintain its own registers, allowing adoption to scale organically across different institutional and project contexts. Registers may be publicly accessible or privately maintained, and within a single organization, registers can also be subdivided or modularized to enable fine‑grained control over ownership, review responsibilities, and release management. This decentralized approach supports independent publication while still enabling blocks to be discovered and referenced across organizational boundaries.

At the same time, the proliferation of independently governed registers introduces a clear risk of fragmentation. Without additional mechanisms, it may become increasingly difficult for users to discover existing blocks, assess their maturity, or determine which registers are authoritative or widely adopted. Improving findability is therefore a key governance challenge. OGC Blocks can be automatically published in OGC RAINBOW definition services, which provides a partial solution to discoverability. However, this approach requires the existence of a suitable service capable of accepting and publishing externally provided definitions (e.g., from community‑led or project‑specific registers) and proper interlinking between services to enable traversal and discovery across registers. In the absence of such links, standalone registers containing otherwise reusable blocks are likely to remain difficult to find.

In OSPD 2025, in parallel with specification work, contributors implemented tooling improvements to enhance the visualization and exploration of Building Blocks and associated ontologies. These efforts focused on improving ontology display and dependency visualization in user-facing interfaces, and on extending OGC RAINBOW capabilities to better surface semantic relationships and provenance information.

Addressing these limitations will likely require the development of a dedicated, register‑agnostic findability mechanism. One possible source of inspiration is the software package ecosystem, where repositories aggregate contributions from multiple authors and organizations and provide rich search and filtering capabilities based on descriptive metadata. Comparable mechanisms could enable discovery of OGC Blocks based on textual search, block type, author or owning organization, maturity level, declared profiles, or dependencies. A potential technical and governance model is provided by services such as w3id.org, which issues persistent identifiers for the semantic web using a lightweight redirection mechanism, with definitions maintained in a public GitHub repository that accepts third‑party pull requests. Each contributor controls its own namespace while adhering to shared governance rules. A similar approach for OGC Blocks could involve a curated index of metadata records pointing to distributed registers, combined with a web application that consumes this metadata, retrieves the referenced registers, and offers unified query and discovery capabilities across a federated OGC Blocks environment.

In addition to findability, there remains the unresolved issue of official adoption or endorsement of externally developed blocks. During OSPD, participants created individual registers containing blocks that may be of broader relevance and interest to the OGC community. At present, no formal mechanism exists to support the transition of such registers or individual blocks into an officially recognized or OGC‑maintained status. In practice, the closest available option has been to fork selected repositories under one of the official OGC GitHub organizations (such as opengeospatial or ogcincubator). Establishing a clearer pathway for official adoption or endorsement—analogous to processes used for OGC Community Standards—would improve trust, visibility, and findability of blocks that demonstrate value beyond their original project context.

5.2.  Accessibility

JSON Schema’s widespread adoption and mature tooling make schema definitions broadly accessible across platforms and communities. Its well‑established composition mechanisms allow schemas to be shared and reused using standard tooling, without requiring specialized infrastructure. As a result, base definitions and extensions remain readable, processable, and usable by a wide range of existing validators, editors, and development environments.

An additional accessibility challenge emerged during OSPD in the context of Denied, Degraded, and Disrupted Space Operational Environments (D3SOE). OGC Blocks make extensive use of references, both internally and across registers, and in typical deployments these references—such as JSON Schema documents, JSON‑LD contexts, and linked data URIs—are resolved dynamically at runtime. In D3SOE scenarios, network connectivity may be limited, intermittent, or entirely unavailable, making such runtime resolution unreliable or impossible. As a result, schemas, contexts, or linked definitions that are normally accessible through standard network mechanisms may become unreachable, directly affecting an application’s ability to access the resources required for validation, interpretation, or semantic enrichment. Several mitigation strategies can be considered: eager or early resolution of references during build or deployment time, caching of schemas, contexts, and linked resources, and the use of edge‑node or local storage to ensure that all required dependencies are available within the operational environment. More broadly, these considerations highlight the importance of deployment‑aware tooling and guidance for OGC Blocks, particularly for use cases in which assumptions about continuous connectivity do not hold.

5.3.  Interoperability

Interoperability within the OGC Blocks ecosystem is fundamentally supported by the modular design of JSON Schema, which promotes consistent reuse of shared components across domains. Composition mechanisms such as allOf, oneOf, and anyOf allow base schemas to expose extension points that can be specialized in a controlled and semantically consistent manner. In principle, dynamic references further extend this model by enabling late binding of constraints, allowing different communities to build interoperable profiles on top of common foundations without hard‑coding domain‑specific assumptions.

In practice, however, interoperability is constrained by uneven tool support and by limitations at the API layer. Dynamic references, while powerful, are not currently supported by OGC Blocks tooling, nor by OpenAPI at the document level. These limitations complicate the extension of complex blocks such as the Provenance Schema, where repeated references to Entity, Activity, and Agent definitions and the intentional use of cyclical references to support directed graph–like structures make profiling difficult. As a result, extensions are often applied manually and inconsistently, reducing interoperability across profiles and implementations.

For example, interoperability challenges were observed at the schema level when combining provenance-related Building Blocks with Records, STAC, and EarthCODE profiles. In particular, conflicting requirements on type and identifier fields limited simultaneous validation against multiple specifications. These conflicts indicate a need for clearer guidance on the interaction between PROV-based Building Blocks and Records-oriented schemas, potentially through the exclusive use of ‘prov:type’ or dedicated provenance extensions.

To address some of these challenges, an extension mechanism for OGC Blocks was developed as part of the OSPD project. This mechanism allows extension points to be declared for a base block in a purely declarative manner. For JSON Schema–based blocks, the mechanism operates by compiling an annotated schema in which declared extension points are resolved and combined with their respective targets using allOf. As a result, the generated schema transparently incorporates the constraints of both the base and extension blocks. An important consequence of this approach is that the JSON‑LD context generated from the compiled schema automatically includes the bindings contributed by the target blocks involved in the extension. Conceptually, this provides functionality similar to what could be achieved using dynamic references, but without requiring native tool support for them.

Beyond schema‑level mechanisms, OGC Blocks act as practical enablers of semantic interoperability by relying on widely adopted standards such as RDF, JSON‑LD, and SPARQL. In alignment with the core principles of the OGC RAINBOW methodologies, this semantic layer builds on established technologies and practices rather than introducing bespoke or isolated solutions, facilitating integration with existing tools, services, and data infrastructures. Concrete integrations developed within OSPD have also stimulated broader discussions within the pygeoapi community on how JSON‑LD resources and semantics could be supported more generally. Although these discussions are ongoing, they illustrate how applied use of OGC Blocks can act as a catalyst for upstream improvements, contributing to improved interoperability across the open‑source ecosystem.

A concrete outcome of the OSPD effort has been the development of enhancements to the pygeoapi server that improve support for JSON‑LD‑enabled resources. These enhancements include, for example, the semantic annotation of the properties table rendered in HTML pages for GeoJSON features and STAC items, allowing property semantics to be explicitly exposed to human users as well as to machine clients ( Figure 2). By integrating semantics directly into familiar representations, this work makes semantic information easier to access and understand in operational services. These enhancements illustrate how existing service implementations can be augmented to expose semantic information derived from OGC Blocks without fundamentally altering their core architecture. By embedding semantics into user‑facing interfaces that developers and users already interact with, the approach significantly lowers the barrier to accessing and interpreting semantic metadata.

Figure 2 — Semantically enabled pygeoapi instance with property and object lookups

Interoperability is further supported at the governance level by the fact that the OGC Blocks framework does not impose a central authority over registers. Multiple governance regimes—ranging from simple, lightweight setups to more formal, multi‑level workflows—can coexist while still producing blocks that are compatible and combinable within the broader ecosystem. This is illustrated by the OSPD project itself, where several partners have established and maintained their own registers alongside OGC‑maintained blocks. Shared conventions and tooling enable blocks originating from different governance contexts to interoperate across organizational boundaries. In addition, the use of Git‑based repositories as the primary technical foundation allows existing version control practices, access controls, and contribution workflows to be reused without requiring specialized infrastructure.

At the same time, inconsistent or underspecified versioning practices pose a significant risk to interoperability. OGC Blocks include a version metadata property, which allows individual blocks to declare their version identifier. However, at present there is no standardized mechanism for publishing, referencing, or discovering multiple versions of the same logical block within or across registers. This complicates evolution over time, particularly when downstream users or profiles depend on different versions, and creates uncertainty around compatibility, deprecation, and parallel maintenance of older versions. These observations highlight the need for an official specification of the OGC Blocks format itself—one that clearly defines the expected structure, metadata properties, and generated outputs of blocks, and explicitly addresses versioning concepts and workflows. Providing a standardized approach to version identification, compatibility signaling, and version coexistence would significantly improve interoperability across registers and implementations.

Finally, the reliance on external reference resolution introduces additional interoperability challenges in operational environments where robustness and autonomy are critical. OGC Blocks frequently depend on externally resolved resources, including schemas, JSON‑LD contexts, and linked data URIs. If these resources cannot be resolved consistently at runtime, validation, interpretation, or semantic enrichment processes may fail or behave unpredictably. While mitigation is discussed under Accessibility (D3SOE), from an interoperability standpoint, divergent runtime resolution behavior can undermine predictable and interoperable operation across platforms and deployments. Looking ahead, future versions of OpenAPI are expected to introduce improved support for modularity and composition, which may address some of these shortcomings; however, further research is necessary to better understand how extension and profiling mechanisms can be improved in practice, and how schema and API composition can be more effectively automated or supported within the OGC Blocks ecosystem.

5.4.  Reusability

Reusability is a core strength of JSON Schema and a guiding principle of the OGC Blocks ecosystem. By enabling schemas to be composed from smaller, reusable building blocks, JSON Schema supports the creation of extensible base components that can be adapted to different domains and use cases.

In OSPD 2025, reusability benefits were particularly evident where standardized spatial parameters were adopted. The use of a shared bounding-box Building Block enabled workflows to be composed and chained without custom adapters, allowing the same workflow implementation to be reused across multiple geographic locations and temporal scenarios. This demonstrated that even simple, well-defined Building Blocks can significantly enhance composability and reuse when consistently applied.

Dynamic references in JSON Schema are also highly relevant from a reusability perspective. By allowing constraints to be bound late, they enable base schemas to be designed as genuinely reusable foundations rather than as artifacts tied to a specific profile or domain. A base block can expose well‑defined semantic and structural “hooks” without anticipating how or where it will be reused, making it possible for downstream profiles to impose additional constraints while preserving a single, shared definition. This significantly increases the long‑term value and applicability of base schemas, even though limited tooling support currently constrains practical adoption. The extension mechanism developed within the OSPD project enhances reusability by allowing base blocks to be extended without modification. Declared extension points are resolved automatically at compile time, producing schemas that transparently incorporate both base and extension constraints. An important consequence of this approach is that derived artifacts, such as JSON‑LD contexts, also inherit the semantic bindings contributed by extension blocks, further increasing the value of reuse across applications and domains.

Despite these strengths at the schema level, reusability at the API level remains limited. OpenAPI does not support composition of complete API definitions, making it difficult to reuse or combine APIs and profiles without duplicating paths and manually integrating components. Two concrete examples illustrate the current limitations and challenges. In the first example ( Figure 3), a custom OGC API – Processes instance defines its own schemas for process inputs and outputs. Integrating these schemas into the API responses is cumbersome and requires manual wiring into the relevant OpenAPI paths. Multiple distinct blocks must be defined to represent a single process definition, and although extension points can be declared, there is no tooling support for automatically producing a bundled OpenAPI document that combines all required components.

OSPD 2025 Contributors also assessed the suitability of Building Blocks for automated metadata generation and reasoning, including AI-assisted approaches. These experiments indicated that while Building Blocks provide a strong structural foundation, insufficiently constrained schemas can introduce ambiguity and noise, reducing their effectiveness for automated interpretation. This reinforces the need for clearer definitions and stricter constraints in future iterations.

Figure 3 — Custom OGC API - Processes instance with inputs and outputs schemas

In the second example ( Figure 4), an IPT‑enabled profile of OGC API – Processes is defined. If this profile were to be combined with the custom process definition from the previous example, the integration would again have to be performed manually, highlighting the current lack of automation and limited reuse across profiles. While future versions of OpenAPI may address some of these shortcomings, additional research and tooling are required to fully realize reusable and composable APIs within the OGC Blocks ecosystem.

Figure 4 — IPT-enabled profile of OGC API - Processes

The proof‑of‑concept pygeoapi deployment developed during OSPD demonstrates how OGC Blocks originating from different repositories can nonetheless be composed, processed, and reused within a single operational service. This reuse extends beyond schemas themselves to include JSON‑LD contexts and semantic mappings, enabling consistent interpretation of data across multiple applications and deployments. In practice, integration effort can be minimal: in some cases it is sufficient to add mappings to relevant OGC Blocks, or even to reuse only their JSON‑LD contexts, to make schemas, relationships, and metadata machine‑interpretable. More advanced integrations can build on this foundation incrementally, demonstrating that meaningful reuse does not require large‑scale reengineering of existing systems.

Governance flexibility further contributes to reusability. Registers can be subdivided or modularized within a single organization, enabling fine‑grained control over ownership, review responsibilities, and release management. By building on Git‑based repositories and established development practices, blocks can be versioned, reviewed, and reused using familiar workflows. At the same time, reusability is affected by the lack of a clear pathway for official adoption or endorsement of externally developed blocks. In practice, the closest available option has been to fork selected repositories under official OGC GitHub organizations such as opengeospatial or ogcincubator. Establishing a clearer adoption or endorsement pathway—analogous to processes used for OGC Community Standards—would improve trust, visibility, and long‑term sustainability of blocks that prove broadly useful beyond their original project context.

Versioning emerged as a recurring concern during OSPD, reflecting its importance for reuse and long‑term maintenance. While OGC Blocks include a version metadata property, there is currently no standardized mechanism for publishing, referencing, or discovering multiple versions of the same logical block within or across registers. This complicates evolution over time, particularly when downstream users or profiles depend on different versions, and creates uncertainty around compatibility, deprecation, and parallel maintenance of older versions. These challenges highlight the need for an official OGC Blocks format specification that explicitly defines versioning concepts and workflows (including compatibility signaling and version coexistence), as well as expected structures, metadata properties, and generated outputs.

Finally, reuse in operational environments must also account for deployment constraints such as Denied, Degraded, and Disrupted Space Operational Environments (D3SOE). Several mitigation strategies can support reuse in such contexts, including eager resolution of references at build or deployment time, caching of schemas, JSON‑LD contexts, and linked resources, and the use of edge‑node or local storage to ensure required dependencies remain available. More broadly, these considerations underscore the importance of deployment‑aware guidance and tooling. When assumptions about continuous connectivity do not hold, reusable blocks must be supported by practices that ensure they remain reliable and dependable across a wide range of operational scenarios.