Open Science Demonstrator 2025: Call for Participation: Call for Participation (CFP)

Open science aims to make scientific research more transparent, reproducible, and reusable. This document outlines an Open Science Demonstrator, a framework for designing and sharing scientific workflows (research processes) and data products. Others can easily reproduce results, adapt the workflow to new problems, or use the output data. By standardizing how we describe data, methods, and results, we enable researchers to reuse and recombine workflows instead of starting from scratch. This not only accelerates innovation but also builds trust: demonstrating reproducibility in research “shows integrity, inspires trust and respect, and encourages reuse”. Key benefits of this approach include (see the 2024 Open Science Pilot for further detail):

In summary, the Open Science Demonstrator provides a template for standardizing scientific workflows. It allows a workflow to be packaged with all necessary information (data inputs, methods, parameters, and outputs) in a way that others can readily execute or modify. Policymakers can support such initiatives to increase the impact of research, ensure better return on investment in science (by avoiding duplicate efforts), and promote trustworthy, open scientific practices on issues of public importance. The initiative is co-sponsored by NASA, ESA, and the European Commission through the FOCAL project (project #101137787).

Modern scientific research often involves complex data workflows – sequences of steps where data is collected, processed, analyzed, and turned into results. Conceptually, a scientific workflow is similar to a data pipeline that transforms inputs (raw data) into outputs (insights, visualizations, etc.). These workflows can be implemented in various forms (computer scripts, notebooks, specialized software), but regardless of implementation, the goal is to test a hypothesis or fulfill a specific analytical task.

However, sharing and reusing such workflows is challenging. Traditionally, researchers publish papers with method descriptions that humans can read and attempt to follow. This narrative approach falls short when we want machine-readable, executable reproducibility. A written description in a paper may omit parameters or environmental details, making it hard for others to rerun the analysis exactly or adapt it to new data. The lack of formal structure also limits transparency, unless one invests heavily in curating data and methods with persistent references.

Several key issues need to be addressed to make scientific workflows truly reusable and interoperable in an open science context:

Reusable Workflow Architecture: A foundational concept in making workflows reusable is separating the planning of the workflow from its execution. In a reference architecture for reusable workflows, we maintain an Execution Plan (which describes the sequence of steps, what data to fetch, and what parameters to use) separately from the actual Workflow Execution Engine that runs the steps. In practice, this means you could prepare a plan (perhaps as a configuration file or script) that is general, and then execute it on different computing platforms or with different input parameters as needed. The workflow engine reads the plan and carries out the analysis. By adjusting the plan (for example, pointing to a different data source or changing a threshold parameter), you can reuse the same core workflow in a new context without modifying the underlying code of the analysis steps.

By adopting such an architecture, we make it possible to adjust workflows to new reuse contexts (for instance, running the same analysis in a different region or with updated data from a later date) simply by tweaking the execution plan. The execution engine can be a “black box” that does not need to change; only the plan and inputs change. This approach requires that the plan be written in a standard, transparent description of the workflow’s requirements (data needed, process steps, etc.). There are clearly many details to describe, and not all can be standardized at once. The strategy is to incrementally standardize the most important elements that enable reuse.

To implement this vision, we propose an incremental plan that starts with a simple workflow and gradually introduces standardization components. The implementation leverages existing standards and tools as building blocks and proceeds through a series of steps, each adding more capability for description and reuse. In work package three, OGC Building Blocks provide blueprints for structuring data services: OGC API - Features building blocks for feature/tabular data and metadata catalogs (alternatively, OGC API - Records), OGC API - Coverages/Tiles building blocks for gridded raster data, possibly OGC API - EDR (or similar) for convenient access to observation data, and OGC API - Processes to trigger various processes such as workflow deployment and execution.

In work package 4, we will dive more deeply into finer granular building blocks and use the OGC Building Blocks framework as a foundation for enhancing interoperability of specific aspects of reusable workflow and data. OGC Building Blocks can represent entire standards or parts thereof, thus we can develop building blocks for example for for vocabulary binding or provenance information expression. The OGC Building Blocks initiative provides modular specifications we can reuse for this purpose.

Using Building Blocks: The OGC Building Blocks (BB) framework offers a collection of reusable standard components and patterns that align with modern web standards. For sure, many other building block frameworks exist and qualify for experiments in this pilot, for example EOEPCA or EarthCODE Building Blocks.

Many elements we need for describing workflows have already been developed or prototyped within OGC and complementary initiatives. By using these, we avoid reinventing the wheel and ensure compatibility with broader community practices. Specifically, OGC Building Blocks provide standardized content and mechanisms for:

With this strong baseline in place, we outline a step-by-step implementation plan. Each step adds a layer of capability or standardization. The process is iterative – one can loop through some steps as needed to refine the approach. The steps are:

1. Identify Candidate Workflows: Select one or a few example scientific workflows that will serve as the test cases for the demonstrator. These should be workflows that are executable in a certain platform (e.g., in a Jupyter Notebook environment, a specific modeling software, or a workflow orchestration system) and representative of real scientific use cases. Choosing well-understood workflows provides a controlled way to develop and test the standards. For instance, we might pick a published analysis from environmental science that we have access to, which involves multiple data sources and steps.

2. Capture Initial Conditions of the Workflows: For each candidate workflow, gather all relevant information about its current form. This includes:

At the end of this step, we should have a clear picture of the workflow’s “as-is” state: what it does, what it needs to run, and how it interacts with external resources.

3. Analyze the Workflows to Identify Key Descriptive Elements: With the collected information, perform an analysis to determine which descriptive elements are needed to formally describe the workflow. Ask: what information would someone (or a machine) need to fully understand or replay this workflow without the original context? For example, you will likely find the need to describe:

From this analysis, extract a list of elements that seem general and important. We are essentially listing what a workflow description standard should cover, based on real needs observed in the workflow. At this stage, we might also notice extraneous or overly specific details that we decide to abstract away – for instance, if a script contains a hard-coded file path, we realize the general description needs a variable for file location, not that specific path.

4. (Optional) Use AI to Enrich Understanding: We can explore using artificial intelligence or machine-learning tools to help parse the workflow and related literature. For example, an AI might read the code or notebook and automatically suggest what each step is doing, or it might parse the research paper associated with the workflow to find described inputs/outputs. AI could also help map the workflow’s steps to known concepts (like recognizing that a certain code cell is doing “outlier removal” on data). This could surface descriptive elements that our manual analysis missed. Additionally, AI text mining on scientific literature might identify common patterns (e.g., many workflows in climate science mention “netCDF file of temperature data” – indicating a common input type that warrants a standard descriptor).

While optional, this step can accelerate the identification of reusable components by leveraging a broader knowledge base than just our own experience.

5. Select High-Value Reusable Aspects: From the list of descriptive elements, prioritize a small set that have high re-use value. These are the aspects of the workflow description that will be useful across multiple workflows and domains. For instance, describing a dataset’s spatial resolution or the provenance of a result are broadly useful concepts. In contrast, a very specific parameter name might be unique to one model and not as reusable. We focus first on aspects like:

6. Define Context-Specific Profiles: For the chosen aspects, we may need to profile them to the specific workflow or domain. A “profile” in this sense means a specialization or restriction of a general standard to fit a particular context. For example, if one chosen aspect is “dataset description”, the general standard might allow describing any kind of dataset; our profile for an Earth observation workflow might require certain fields like coordinate reference system, spatial resolution, and temporal coverage to always be included.

We create a context-specific profile that tailors the general descriptors to our workflow’s domain. This ensures the descriptions are both standardized and relevant to the domain at hand (e.g., environmental science). Profiles help maintain interoperability (by conforming to a base standard) while adding necessary detail for a given context.

7. Develop Building Block Schemas (Sub-schemas) for the Key Aspects: Now, using the OGC Building Blocks approach, create or assemble schema components that formalize the descriptions for each key aspect. Essentially, we’re building the pieces of a standard:

We should not do this from scratch if avoidable. Reusing existing building blocks is ideal. For instance, OGC has ongoing work on “Application Schemas” and JSON schemas with semantic annotations; those can be imported. The goal is to end up with a set of schema building blocks – think of them as LEGO pieces of our workflow description standard.

8. Document Examples and Test the Building Blocks: Take the schemas created in step 7 and apply them to our actual workflow as a test. For example, write a sample description of one input dataset from our workflow using the new schema: fill in its fields with the real info (source URL, format, etc.) and see if the schema captures everything needed. Do the same for an output or a step’s provenance. By creating concrete examples, we can validate whether the building blocks are sufficient or if they need tweaks. This also yields documentation examples that will be useful for others to understand how to use the standard.

Testing might involve using schema validation tools to ensure our example instances conform to the schemas. It could also involve asking someone not involved in development to see if they understand the example – a check on clarity.

9. Integrate the Descriptions into an Application Schema Package: Once the building block schemas are validated in isolation, integrate them into the overall workflow description schema (sometimes called an application schema or target description package). In other words, assemble a complete specification for describing our workflow by combining the relevant blocks. This could be a single JSON Schema or a set of linked schemas that together describe the workflow’s metadata.

For instance, the top-level might be a “Workflow Description” JSON that has sections for “Inputs” (each described by the input schema), “Outputs” (each described by the output schema), “Steps” (each with a reference to inputs/outputs and perhaps a link to a process description if needed), and “Provenance” (which could be a record of how the outputs were generated, linking to each step and input). The integration ensures that all pieces fit together and references among them are consistent (e.g., an output’s provenance can point to the step that created it, which in turn points to the input it used).

At this stage, our candidate workflow has a formal descriptive package that ideally can be published or exchanged. We can think of it as metadata that accompanies the workflow.

10. Apply Vocabulary and Terminology Standards (Qualify with Controlled Vocabularies): To further standardize and avoid ambiguity, we constrain certain fields to use controlled vocabularies. This step involves reviewing our schemas and determining where free text or arbitrary values should be replaced by references to standard terms. For example:

We modify the schema to qualify these fields: essentially adding constraints or annotations that say “this value must come from X vocabulary”. This improves interoperability because different workflows using the same vocabulary will use identical terms for the same concept. It also allows tools to automatically understand relationships (for instance, two outputs labeled with the same ontology term can be recognized as the same kind of thing).

11. Identify and Source the Vocabularies: For each vocabulary we decided to use in step 10, ensure we have a source for it. Many standard vocabularies exist (e.g., ISO, OGC, or domain-specific ones). We should:

For example, OGC’s RAINBOW platform (the OGC Definitions Server) can host such terms. RAINBOW is designed as a repository of concepts and definitions, providing each term a persistent URI and linking to its description in various formats (HTML, JSON-LD, etc.) . We may publish our demonstrator’s custom terms (if any) on a service like RAINBOW, or use RAINBOW’s existing content for standard terms. Using a service like this ensures the terms we reference in our workflow descriptions are FAIR (Findable, Accessible, Interoperable, Reusable) and governed (so that, for example, “Air Temperature” has a consistent definition everywhere).

12. Publish Vocabularies in Machine-Readable Form: Work with the chosen infrastructure (such as RAINBOW or another vocabulary service) to make sure our controlled vocabularies are online and accessible. This may involve uploading definitions or ensuring the terms we need are already present and stable. The outcome should be that any tool or person can resolve a term’s identifier to get its definition. For instance, if our workflow description says the output’s phenomenon is http://www.opengis.net/def/phenomenon/OGC/Atmosphere/AirTemperature (as a made-up example URI), navigating to that URI should provide information that this term means “Air Temperature” in degrees Celsius, etc. This step is about operationalizing the standard terminology aspect.

13. Develop Validation Rules and Tools: To maintain the integrity of our workflow descriptions, we create validation constraints. These could be additional schematron rules, ShACL shapes, or custom scripts that check the consistency and completeness of the descriptions beyond basic schema structure. For example, a rule might enforce that every input dataset listed in the workflow description must have a corresponding entry in the provenance for some output (meaning every input is actually used somewhere), or that the vocabulary terms are used correctly (matching the allowed list). Another rule could check that if an input is from a web service, a URL is provided and responds to a test query.

Validation ensures that when someone writes a new workflow description or modifies one, they haven’t broken the standard. It’s also a step where we test the robustness of our approach: run the validators on the demonstrator’s description to catch any errors or missing pieces.

14. Ensure Data Access Services are Available and Citable: For the demonstrator to be effective, the data sources and services it relies on must be up and reachable by others. This step involves making sure that any web APIs or data servers used in the workflow are properly documented, persistent, and citable. Two scenarios are common:

The phrase “citable” implies that even ephemeral services should have a reference that can be included in scientific publications or documentation. This could mean obtaining DOIs for datasets or using stable naming for APIs. The outcome of this step is that anyone attempting to rerun the workflow can access the required data sources easily, and they can reference those sources in their own work.

15. Execute an Enhanced Version of the Workflow: Now we put everything together by creating a new version of our candidate workflow that follows the open science demonstrator principles. In practice, we modify the original workflow (from step 1) to incorporate standard interfaces and capture metadata during execution. Concretely, the updated workflow should:

This enhanced workflow is now a demonstrator of how to do science in a more open, standard, and reusable way. We should test it by running it in our environment to ensure it still produces the expected scientific result, but now with the bonus that it also produces standardized descriptions and can be adjusted more easily.

16. Validate the Final Outputs and Descriptions: As a final step, we use the validation tools from step 13 and the standards we developed to validate everything:

Any issues found are noted and addressed, leading to improvements in the building blocks or the workflow implementation as needed. After this, we will have a validated example of an open-science-compliant workflow.

Throughout the above plan, certain elements emerged repeatedly as crucial to standardize for any scientific workflow. These candidate aspects for standardization are broadly applicable to many domains and workflows:

By focusing on these areas – terminology, provenance, service description, API usage, quality, and data dimensions – we cover the most critical information needed to make workflows self-describing and reusable. These aspects apply “to all cases” in the sense that any scientific workflow, whether in geosciences, life sciences, social sciences, etc., will need to address most of these in order to be fully shareable. They form a checklist for developing standards and tools in the open science demonstrator and beyond.

The Open Science Demonstrator architecture and implementation plan detailed above provide a roadmap for making complex scientific workflows easier to understand, reproduce, and adapt. By separating the workflow plan from execution, leveraging community standards (like OGC Building Blocks), and incrementally building up a library of reusable descriptive components, we enable a future where researchers can share their work as actionable resources rather than just static reports. Policymakers and research funders stand to gain through improved transparency and efficiency: the same workflow can answer new questions with minimal effort, and results come with built-in lineage and documentation.

This approach does not sacrifice technical depth or rigor – in fact, it demands rigorous documentation – but it encapsulates it in accessible formats. Non-technical stakeholders benefit from clearer high-level documentation (e.g., an executive summary of what the workflow does and requires), while technical users benefit from detailed, machine-readable metadata. Together, these practices move us closer to a more collaborative, reliable, and open scientific ecosystem, where knowledge is not just published, but also actively reused to drive further discovery.

This call defines two different types of platforms:

This pilot offers opportunities for OGC members to participate in different roles. The pilot will try to support several participants per role. Bidders can bid for any number of roles. If selected, it cannot be guaranteed that all roles can be financially supported.

Role 1: Scientist. The Scientist defines workflows on the primary platform. In this pilot, the scientist supports the other participants by explaining all the steps of the workflow and supporting the redeployment and execution of the workflow on another platform. This other platform may not support the primary platform’s native execution environment.

Role 2: Platform Operator. The Platform Operator provides a platform that supports workflow discovery, execution, and result access. The operator ensures that the platform is accessible to other participants in this initiative and supports the deployment of new workflows on the platform as necessary.

Role 3: Platform Developer. The Platform Developer provides technical expertise and develops the necessary modifications that allow a workflow available on a discovery platform to be deployed and executed on the developer’s primary platform. The Platform Developer may support the transformation from one workflow model to another or concentrate on the redeployment and execution of workflows within the same workflow execution environment.

Role 4: Building Block Developer. The Building Block Developer analyzes the various challenges arising from the use of multiple platforms and integrates the findings into a single model. The building block developer abstracts the individual solutions and creates a universal model that follows the OGC building block concept and methodology. This model can serve as a blueprint for all platforms in the future to simplify the reusability of scientific processes. The building block developer works on OGC Building Blocks and is responsible for the definition of the minimum viable product, the OGC Workflow Building Block.

This pilot is organized in two parts, which are executed in parallel and partly connected. The first part concentrates on the discovery, redeployment, and execution of workflows across platforms. Roles 1 to 3 work closely together for that purpose.

The second part focuses on developing the OGC Workflow Building Blocks. This second part is the main field for the building block developers and builds on the common parts as illustrated in the figure below.

Both roles 1-3 and role 4 work together in WP1 and WP2. Then, roles 1-3 focus on the workflow reuse experiments across platforms, whereas role 4 develops OGC Building Blocks for reusable workflows.

The following applies to both parts: The goal is to define a minimum viable product that can be extended in future initiatives. It is not possible to define all aspects of reusable workflows in a single initiative.

The following table defines the master schedule for the initiative.

During the pilot, weekly or biweekly check-ins will be held for participants to discuss progress, highlight challenges, and share perspectives on key issues through video conferences.

Bidders must indicate which role they wish to play in this initiative. Each role has been assigned a unique identifier:

Each bidder may apply for any number of roles. When submitting a bid, please ensure that the costs for each role are listed separately. Further information on the bid submission process can be found below.

Bidders should anticipate that the funding allocated for each work item will typically range between $5,000 USD and $35,000 USD. While this range reflects the standard funding envelope, exceptions may be made in rare and well-justified cases, either above or below this range, subject to the specific scope and strategic importance of the proposed contributions.

Bidders are selected based on the evaluation criteria defined below.

This initiative is being conducted under the OGC Collaborative Solutions and Innovation (COSI) Policy and Procedures. COSI is part of OGC Research, our collaborative lab for experimentation, testing, and innovation. It’s where members come together to explore what works today, evaluate what’s emerging, and shape the future of trusted, interoperable location systems.

The Collaborative Solutions and Innovation Program (COSI) fosters cutting-edge solutions to global challenges by funding and supporting collaborative research and development Initiatives. It brings together broad stakeholders, including individuals, small and large businesses, government agencies, and research institutions, to address critical issues such as natural hazzard and disaster resilience.

OGC COSI initiatives promote rapid prototyping, testing, and validation of technologies, such as location standards or architectures. Within an initiative, OGC Members test and validate draft specifications to address geospatial interoperability requirements in real-world scenarios, business cases, and applied research topics. This approach not only encourages rapid technology development but also determines the technology maturity of potential solutions and increases technology adoption in the marketplace.

The following table lists all abbreviations used in this CFP.

The following table identifies all corrections that have been applied to this CFP compared to the original release. Minor editorial changes (spelling, grammar, etc.) are not included.

Last update: 26 June 2025

The following table identifies all clarifications that have been provided in response to questions received from organizations interested in this CFP.