Corrigenda

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.

Date Section Description

2019-01-09

Appendix A, Management Requirements

Term "memorialized" replaced with "developed"

2019-01-09

 B5.4

"CGDI list of Web" replaced by "list of Web services provided by the CGDI"

2019-01-09

B6.1

Paragraph "OGC Third Generation API (OpenAPI) provides the ability for OGC standards, to incorporate delta updates utilising Feature ID and Timestamp elements of OpenAPI. This allows for data such as raster or vector to be updated reflecting the changes in the original version." replaced by "Emerging OGC interface specifications that use OpenAPI provide the ability for OGC standards to incorporate delta updates utilizing the Feature ID and Timestamp elements of OpenAPI. This allows for raster or vector data to be updated while still reflecting the changes in the original version."

2019-01-09

B7.2

"Implement a Data Centric Security approach using existing OGC standards and OGC third generation API (OpenAPI) implementation work as being documented in Testbed 14." has been replaced by "Implement a Data Centric Security approach using existing OGC standards and emerging OGC standards such as WFS 3.0 or WPS 3.0 that make use of OpenAPI) as being documented in Testbed 14."

2019-01-09

B7.4

"Testbed-15 shall develop an OGC Third Generation API (OpenAPI) implementation based on work in OGC Testbed 14." is replaced by "Testbed-15 shall develop an implementation of WFS 3.0 with support for data centric security.".

2019-01-09

B8.1

Added paragraph: "Of particular interest in this context are three aspects. Firstly, the handling of security in federations. Second, how the Testbed-13 and Testbed-14 research results of "bringing applications to the data" relate to SCALE and SEED. SCALE is an open source system that provides management and scheduling of automated processing on a cluster of machines. It uses the SEED specification to aid in the discovery and consumption of processes packaged in a Docker containers. Third, the role of blockchain and distributed ledger technologies in the context of handling provenance in federations."

2019-01-11

B5.4

Link added to "list "list of Web services provided by the CGDI"

2019-01-14

B9.1 & B9.4

"Vector Tiles" replaced by "tiled vector data"

2019-01-15

Beginning of CFP

Clarifications table added

2019-01-15

Main Body, Introduction

Link to ITT on EMITS added

Clarifications

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

Question Clarification

no entries

Abbreviations

The following table lists all abbreviations used in this CFP.

3DPS

3D Portrayal Service

ABI

Activity Based Intelligence

AOI

Area of Interest

AMQP

Advanced Message Queuing Protocol

AR

Augmented Reality

AtomPub

Atom Publishing Protocol

AVI

Aviation

BBOX

Bounding Box

BPMN

Business Process Model and Notation

CDR

Content Discovery and Retrieval

CIS

Coverage Implementation Schema

CITE

Compliance Interoperability and Testing

CF

Climate and Forecasting

CFP

Call for Participation

CMD

Command Center

CSMW

Community Sensor Model Working Group

CSW

Catalog Service Web

CTL

Compliance Testing Language

DAAC

Distributed Active Archive Centers

DAP

Data Access Protocol

DASS

NASA’s Data Analytics and Storage System

DCAT

Data Catalog Vocabulary

DDIL

Denied, Degraded, Intermittent, or Limited Bandwidth

DGIWG

Defense Geospatial Information Working Group

DISA

Defense Information System Agency

DWG

Domain Working Group

EMITS

EMITS is the system used by ESA for publishing Invitations To Tender and information about the ESA procurement process

EO

Earth Observation

EOWCS

Earth Observation Profile Web Coverage Service

ER 

 Engineering Report

ESA

European Space Agency

ESGF

(US Department of Energy) Earth System Grid Federation

EXI

Efficient XML Interchange format

FGDC

Federal Geographic Data Committee

FIXM

Flight Information Exchange Model

FO

Field Operations

GDAL

Geospatial Data Abstraction Library

GEOINT

Geospatial intelligence

GeoXACML

Geospatial XACML

GIBS

Global Imagery Browse Services

GML

Geography Markup Language

GUI

Graphical User Interface

HDF

Hierarchical Data Format

HTTP

Hypertext Transfer Protocol

HTTPS

Hypertext transfer protocol secure

ISO

International Organization for Standardization

ITT

Invitation to Tender

JSON

JavaScript Object Notation

JSON-LD

JSON Linked Data

KML

Keyhole Markup Language

LiDAR

Light detection and ranging

MEP

Mission Exploitation Platform

MTOM

Message Transmission Optimization Mechanism

NASA

National Aeronautics and Space Administration

NetCDF

Network Common Data Form

NetCDF-CF

NetCDF Climate Forecasting

NSG

National System for Geospatial Intelligence

OAuth

Open Authorization

OBP

Object Based Production

OGC

Open Geospatial Consortium

OPeNDAP

Open-source Project for a Network Data Access Protocol

PKI

Public Key Infrastructure

PMT

(ShapeChange) Profile Management Tool

POI

Points-of-interest

PubSub

Publication Subscription

RDF

Resource Description Framework

SAML

Security Assertion Markup Language

SOS

Sensor Observation Service

SPARQL

SPARQL Protocol and RDF Query Language

SSO

Single Sign On

STAC

SpatioTemporal Asset Catalog specification

SWAP

Size, Weight, and Power

SWE

Sensor Web Enablement

SWG

Standards Working Group

T-nn

Testbed-nn

TEAM

Test, Evaluation, And Measurement Engine

TEP

Thematic Exploitation Platform

TSPI

Time-Space-Position-Information Standard

TWMS

Tiled Web Mapping Service

US

United States

UML

Unified Modeling Language

USGS

U.S. Geological Survey

W3C

World Wide Web Consortium

WCPS

Web Coverage Processing Service

WCS

Web Coverage Service

WFS

Web Feature Service

WIS

Web Integration Service

WKT

Well Known Text

WMS

Web Mapping Service

WMTS

Web Mapping Tile Service

WPS

Web Processing Service

WS

Web Service

WSDL

Web Services Description Language

XACML

eXtensible Access Control Markup Language

XOP

XML-binary Optimized Packaging

XXE

XML External Entity Injection

Main Body - Introduction

The Open Geospatial Consortium (OGC®) is releasing this Call for Participation ("CFP") to solicit proposals for the OGC Testbed-15 initiative ("Testbed" or "initiative") under the OGC Innovation Program (OGC-IP).

The OGC-IP provides global, hands-on, collaborative prototyping for rapid development and delivery of proven candidate specifications to the OGC Standards Program, where these candidates can then be considered for further action. Participants in OGC-IP initiatives collaborate to examine specific geo-processing interoperability questions posed by the initiative’s sponsors. These initiatives include testbeds, experiments, pilots, and plugfests – all designed to foster the rapid development and adoption of open, consensus-based standards.

The OGC recently reached out to potential initiative sponsors to review the OGC standards baseline (also see Standards Baseline), discuss results of prior initiatives, and identify this initiative’s particular requirements.

This CFP is soliciting proposals from "Bidders" to address these requirements in the initiative. Received proposals ("bids") will be evaluated, and selected Bidders will become cost-share "Participants" to receive funding to help offset the cost of performing initiative work.

Please note the Requirement to Propose an In-Kind Contribution for making a cost-share request for a funded deliverable. In-kind contributions are an important part of the proposal evaluation criteria.

It is expected that most deliverable proposals will include a combination of a cost-share request and an in-kind contribution. However, any proposed deliverable offering a purely in-kind contribution (i.e., requesting no cost-sharing at all for that deliverable) will certainly be welcomed.

The solicitation is being issued in two parts due to specialized sponsor procurement requirements:

Part 2 ITT is described separately from this document and has distinct response requirements. So any Bidder wishing to respond to both Part 2 ITT (described externally) and the Part 1 CFP (described herein) should deliver two separate proposals, one for each set of response requirements. A Bidder wishing to respond to one or the other (but not both) would submit only one proposal.

Important

To provide a complete description of the Testbed scope, this CFP combines all deliverables from both parts (Part 1 CFP and Part 2 ITT). All work items marked as belonging to Part 2 ITT have distinct response requirements that are provided as part of the ITT. Bidding on these ITT requirements and work items requires an independent proposal! ITT requirements and work items are only copied into the Part 1 CFP solicitation documents for completeness.

The response requirements described here in the CFP body and in Appendix A Management Requirements apply to Part 1 CFP requirements and deliverables only.

Under this Part 1 CFP, the OGC will provide cost-sharing funds on behalf of sponsoring organizations ("Sponsors") to partially offset expenses uniquely associated with this initiative. This CFP requests proposals from organizations ("Bidders") wishing to participate in delivery and, in some cases, to receive cost-sharing funds. Any Bidder interested in initiative participation should respond by submitting a proposal per the instructions provided in the Proposal Submission Procedures.

In general, Bidders should propose specifically against the list of deliverables described under the Summary of Deliverables section below. Only content that directly addresses CFP requirements should be included in a Proposal. These are the only items that will be eligible for cost-sharing funds.

Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in initiative scope or not. Items deemed out-of-initiative-scope might be more appropriate for inclusion in another OGC-IP initiative.

Important

Discussions are ongoing for potential sponsorship of additional requirements that are not yet firm enough for inclusion in this CFP. Should funding for these additional requirements be provided later, a follow-on CFP with a compressed response timeline might also be issued if the work can be included without interfering with the original Master Schedule or Appendix B Technical Architecture.

1. Benefits of Participation

This initiative provides a business opportunity for stakeholders to mutually define, refine, and evolve service interfaces and protocols in the context of hands-on experience and feedback. The outcomes are expected to shape the future of geospatial software development and data publication. The Sponsors are supporting this vision with cost-sharing funds to partially offset the costs associated with development, engineering, and demonstration of these outcomes. This offers selected Participants a unique opportunity to recoup a portion of their initiative expenses.

2. Policies and Procedures

The initiative will be conducted within the framework of OGC’s Bylaws and Intellectual Property Rights Policy, as agreed to in each selected Participant’s Membership Agreement, and in accordance with the OGC-IP Policies and Procedures and the OGC Principles of Conduct, the latter governing all related personal and public interactions.

Two key requirements are summarized below for ready reference:

  • Each selected Participant will be required to agree to notify OGC staff if it is aware of any claims under any issued patents (or patent applications) which would likely impact an implementation of the specification or other work product which is the subject of the initiative. Participant need not be the inventor of such patent (or patent application) in order to provide notice, nor will Participant be held responsible for expressing a belief which turns out to be inaccurate. Specific requirements are described under the "Necessary Claims" clause of the Intellectual Property Rights Policy.

  • Each selected Participant will be required to refrain from making any public representations that draft Engineering Report (ER) content has been endorsed by OGC before the ER has been approved in an OGC Technical Committee (TC) vote.

OGC will create a Participation Agreement (PA) contract with each selected Participant. With regard to any overlapping subject matter, the PA Statement of Work (SOW) will take precedence over CFP Clarifications, which will take precedence over this CFP. Each Participant will also be required to provide more-detailed description of the requirements for its assigned deliverables (and to coordinate with other initiative Participants) at the Kickoff Workshop.

One initiative objective is to support the OGC Standards Program in the development and publication of open standards. Each Participant will be required to allow OGC to copyright and publish documents based in whole or in part upon intellectual property contributed by the Participant during initiative execution. Specific requirements are described under the "Copyrights" clauses of the OGC Intellectual Property Rights Policy.

2.1. Initiative Roles

The roles generally played in any OCG-IP initiative are defined in the OGC-IP Policies and Procedures, including Sponsors, Bidders, Participants, Observers, and the Innovation Program Team ("IP Team"). Additional explanations are provided in the Tips for New Bidders.

The IP Team for this initiative will include an Initiative Director (also sometimes called "initiative manager"), an Initiative Architect, and multiple Thread Architects. Unless otherwise stated, the Initiative Director will serve as the primary point of contact (POC) for the OGC.

Thread Architects will work with Participants, Sponsors, and each other to ensure that initiative activities and deliverables are properly assigned and performed. They are responsible for scope and schedule control, as well as for within-thread and cross-thread communications. They will also provide timely escalation to the Initiative Director regarding any serious issues or risks that arise.

3. General Proposal Submission Guidelines

This section presents general guidelines for submitting a CFP proposal. Detailed instructions for submitting a response proposal using the Bid Submission Form web page can be found in Appendix A Management Requirements.

Proposals must be submitted before the appropriate response due date indicated in the Master Schedule.

Bidders responding to this CFP must be OGC members and must be familiar with the OGC mission, organization, and process. Proposals from non-members will be considered provided that a completed application for OGC membership (or a letter of intent to become a member) is submitted prior to (or with) the proposal.

Information submitted in response to this CFP will be accessible to OGC and Sponsor staff members. This information will remain in the control of these stakeholders and will not be used for other purposes without prior written consent of the Bidder. Once a Bidder has agreed to become a Participant, they will be required to release proposal content (excluding financial information) to all initiative stakeholders. Commercial confidential information should not be submitted in any proposal and should generally not be disclosed during initiative execution.

Bidders will be selected to receive cost sharing funds on the basis of adherence to the requirements stipulated in this CFP and the overall quality of their proposal. The general initiative objective is for the work to inform future OGC standards development with findings and recommendations surrounding potential new specifications. Bidders are asked to formulate a path for producing executable interoperable prototype implementations that meet the stated CFP requirements, and for documenting the findings and recommendations arising from those implementations. Bidders not selected for cost sharing funds may still be able to participate in addressing the stated CFP requirements on a purely in-kind basis.

However, to help maintain a manageable process, Bidders are advised to avoid attempts to use the initiative as a platform for introducing new requirements not included in Appendix B Technical Architecture. Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in initiative scope or not. Items deemed out-of-initiative-scope might be more appropriate for inclusion in another OGC-IP initiative.

Each selected Participant (including pure in-kind Participants) will be required to enter into a Participation Agreement contract ("PA") with the OGC. The reason this requirement applies to pure in-kind Participants is that other Participants will be relying upon their delivery to show component interoperability across organizational boundaries.

Each PA will include a Statement of Work ("SOW") identifying Participant roles and responsibilities. The purpose of the PAs is to encourage and enable Participants to work together to realize initiative goals for the benefit of the broader OGC community.

3.1. Questions and Clarifications

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Clarifications page. Instructions for accessing this page are included under Proposal Submission Procedures.

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk (techdesk@opengeospatial.org). Question submitters will remain anonymous, and answers will be regularly compiled and published in the clarifications.

OGC may also choose to conduct a Bidder’s question-and-answer webinar to review these clarifications and invite follow-on questions in real-time.

4. Proposal Evaluation Criteria

Proposals will be evaluated according to criteria that can be divided into two areas: Management and Technical.

4.1. Management Criteria

  • Bidder willingness and ability to comply with Appendix A Management Requirements,

  • Feasibility of proposed solution utilizing proposed resources,

  • Proposed in-kind contribution in relation to proposed cost-share funding request.

4.2. Technical Criteria

  • Understanding of and compliance with requirements as stated in Appendix B Technical Architecture,

  • Quality and suitability of proposed design, and

  • Where applicable, proposed solutions are OGC-compliant.

5. Master Schedule

The following table details the major initiative milestones and events:

Table 1. Master schedule
Milestone Date (2019)  Event

M01

7 January

CFP Release (ITT release expected 7 Jan.)

M02

31 January

Questions for CFP Bidders Q&A Webinar Due (ITT details forthcoming)

M03

4 February

(tentative) CFP Bidders Q&A Webinar (ITT details forthcoming)

M04

11 February

CFP Proposal Submission Deadline (11:59pm U.S. Eastern time)

M05

31 March

All CFP Participation Agreements Signed

M06

2-4 April

Kickoff Workshop

M07

31 May

Initial Engineering Reports (IERs)

M08

June (precise dates TBD)

Interim Workshop (new for Testbed-15)

M09

30 June

Component Interface Designs

M10

31 July

IER-to-DER status check; TIE Connectivity Test; Early implementations of any component on which another component depends

M11

31 August

TIE Readiness Review

M12

30 September

TIE-Tested Component Implementations completed; Preliminary DERs complete & clean, ready for internal reviews

M13

31 October

Ad hoc TIE demonstrations (as requested during the month) & Demo Assets posted to Portal; Near-Final DERs posted to Pending & WG review requested

M14

November (specific date TBD)

Final DERs (incorporating WG feedback) posted to Pending to support WG & TC vote

M15

30 November

Participant Final Summary Reports

M16

December (specific dates TBD)

Focused Demonstration Events

6. Sequence of Events, Phases, and Milestones

The following diagram provides a notional schedule of major initiative events and milestones, and their approximate sequence of occurrence. The initiative will use rolling-wave project management whereby more detailed scheduling will take place as each milestone draws near.

Milestones
Figure 1. Overview of Events and Milestones

Participant Selection and Agreements: Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Clarifications page. Instructions for accessing this page are included under Proposal Submission Procedures.

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk (techdesk@opengeospatial.org). Question submitters will remain anonymous, and answers will be regularly compiled and published in the clarifications.

OGC may also choose to conduct a Bidder’s question-and-answer webinar to review these clarifications and invite follow-on questions.

Following the closing date for submission of proposals, OGC will evaluate received proposals, review recommendations with Sponsors, and negotiate Participation Agreement (PA) contracts, including statements of work (SOWs), with selected Bidders. Participant selection will be complete once PA contracts have been signed with all Participants.

Kickoff Workshop: A Kickoff Workshop ("Kickoff") is a face-to-face meeting where Participants, guided by thread architects, will refine the initiative architecture and settle upon specific interface models to be used as a baseline for prototype component interoperability. Participants will be required to attend the Kickoff, including the breakout sessions of each thread for which they were selected. Participants will be expected to use these breakouts to collaborate with other Participants and confirm the intended Component Interface Designs (broadly defined to include other types of design such as user-interfaces for portrayal).

After the face-to-face Kickoff, many initiative activities will be conducted remotely via teleconferences except the (new) Interim Meeting and possibly also SWG/DWG presentations at the TC Meetings.

Important

The Interim Workshop is new for Testbed-15.

Interim Workshop: One innovation for Testbed-15 will be to conduct an Interim Workshop for Participants and other stakeholders. The purpose will be to conduct face-to-face discussions to refine our shared understanding of requirements, and to use this information to improve the quality and value of the deliverables.

The workshop is optional but highly recommended for all stakeholders able to attend, particularly those responsible for designing, agreeing, and documenting the interoperability interfaces.

The Interim Workshop for this initiative is likely to be held at a European location in the June timeframe.

Development of Engineering Reports, Change Requests, and Other Document Deliverables: Development of Engineering Reports (ERs), Change Requests (CRs) and other document deliverables will commence during or immediately after Kickoff. Participants will deliver an Initial Engineering Report (IER) plus several iterations of a Draft Engineering Report (DER). Full process details can be found in the OGC Testbed ER Development Process.

Under the Participation Agreement (PA) contracts to be formed with selected Bidders, ALL Participants will be responsible for contributing content to the ERs. But the ER Editor role will assume the duty of being the primary ER author.

Important

ER Editors should adopt a proactive approach to consuming and documenting the knowledge being generated during component implementation. In other words, ER Editors will serve as primary authors in addition to their editor role. All Participants are required to support the editors by making necessary documentation material available.

Component Design, Development, and Preliminary Testing: Participants will continue documenting detailed and final Component Interface Designs (broadly defined to include other types of design such as user-interfaces for portrayal) using the selected collaboration tool (e.g., a GitHub wiki). This documentation will allow task Participants to confirm a mutual understanding of each other’s interfaces so that subsequent interoperability testing can take place. A preliminary Technology Integration Experiment ("TIE", sometimes also referred to as a "Technology Interoperability Experiment") Connectivity Test milestone will be used to ensure that initiative service endpoints can be reached by initiative clients.

Important

Each proposed service component implementation deliverable should be accompanied by identification of one or more particular datasets that would be suitable for the proposed service. Details are provided under Data Requirements for Proposing Service Component Implementation Deliverables.

The label "Component Interface Designs" is preferred over "Component Implementation Designs" because it’s the interfaces between components that will have to be synchronized for the TIE experiments. The specifics of what is going on internally within any particular component is often irrelevant to the TIEs (i.e., an encapsulation approach). So, technically speaking, the full design of any particular component often does not need to be shared. Instead, what will be desirable in the TIEs is agreed interfaces that will enable seamless plug-and-play for all combinations of client-service instances. Ideally each interface design could be handed to two different developers (e.g., for one client + one service) who could then go off and start writing code independently, and then come back in a month or two with interoperating code. As a practical matter, these designs will still have to undergo some “agile” adjustment before being finalized.

TIE Readiness Review: A TIE Readiness Review will be conducted with a Thread Architect to confirm that each TIE Participant is prepared to start conducting TIE testing with counterpart Participants.

Component Interoperability Testing, and Acceptance: Participants should deliver completed and fully TIE-tested component implementations no later than the 30 September milestone (unless an earlier milestone is identified in Appendix B Technical Architecture). The primary acceptance criterion for a component implementation deliverable is the conduct and recording of the TIE test. This test can also help in the development of Demo Assets such as video recordings.

Draft Engineering Reports: Participants should also deliver complete and clean Draft Engineering Report (DERs) by the 30 September milestone. A complete DER is one for which all major clauses have been populated with meaningful content. A clean is one where all known editorial defects have been repaired. This milestone will impact ALL initiative Participants, even component implementers, who will be responsible for making necessary documentation material available to the ER Editor for use in authoring the ER. Initiative Sponsors and Thread Architects will review these DERs in the weeks following delivery.

DER Rework and SWG/DWG Reviews: Participants will be required to perform rework based on the reviews from Sponsors and Thread Architects. The ER editor will then make a request to the selected OGC SWG or DWG to perform its review and to consider making a request that the DER be voted on by the OGC Technical Committee (TC) for publication. The OGC 3-week rule must be followed if the DER is to receive a face-to-face vote at a TC Meeting. The DER must be posted to the members-only OGC Pending Documents directory to enable this TC vote. Participants will likely have to perform one final round of rework based on SWG/DWG feedback. The further along the DER is when submitted to the WG, the less rework will be required.

Final Summary Reports and Demonstration Events: Participants Final Summary Reports will constitute the close of funded activity. Further development work might take place to prepare and refine Demo Assets (see the Demo Asset Requirements for details), which will be used to support various demonstration events such as presentations at OGC Technical Committee Meetings.

Assurance of Service Availability: Participants selected to implement service components must maintain availability for a period of no less than one year after the Final Delivery Milestone. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

Detailed requirements for meeting all these milestones are provided in Appendix A Management Requirements.

7. Summary of Initiative Deliverables

The following tables show the full set of initiative deliverables, including ID, deliverable name, task, and funding status.

A deliverable’s funding status can be funded ("F"), unfunded ("U"), or under negotiation ("Un-Neg"), depending on the current state of sponsor funding.

  • For a deliverable with a funding status of "F", sponsor funding has already been confirmed.

  • A deliverable with a funding status of "U" is within CFP scope, but has a lower priority and does not have any sponsor funding. It’s possible that a Sponsor might later agree to provide funding. But no Sponsor funding is currently available, and any bids for these deliverables would necessarily be purely in-kind.

  • A deliverable with a funding status of "Un-Neg" is one for which a sponsor intends to provide funding, but a final commitment of this funding is still pending.

Please also note the Requirement to Propose an In-Kind Contribution for bidding on any funded deliverable.

Note

A deliverable with a funding status of "ITT" can only be proposed under the Part 2 ITT solicitation. See the Main Body Introduction for details regarding how to bid on these deliverables.

Please note that each deliverable indicated as "F" or "Un-Neg" would be funded at most once. No deliverable should be interpreted as offering multiple instances. For any deliverable still under negotiation ("Un-Neg"), if funding for that deliverable ends up not being committed, any bid for cost-sharing on that deliverable will be dismissed. The deliverable would change to an unfunded "U" status, and a Bidder could potentially choose to contribute it purely in-kind.

Important

Discussions are ongoing for potential sponsorship of additional requirements that are not yet firm enough for inclusion in this CFP. Should funding for these additional requirements be provided later, a follow-on CFP with a compressed response timeline might also be issued if the work can be included without interfering with the original Master Schedule or Appendix B Technical Architecture.

Initiative deliverables are organized into threads, which are described in detail in Appendix B Technical Architecture.

The task abbreviations are as follows:

  • ML: Machine Learning

  • DCS: Data-Centric Security

  • DU: Delta Updates

  • EOPAD: Earth Observation Process and Application Discovery

  • FCA: Federated Cloud Analytics

  • POR: Portrayal

7.1. CFP Deliverables Summary Table

The following table provides a summary of CFP deliverables and their funding status. Additional technical details can be found in the Technical Architecture. The following

Table 2. CFP Deliverables Summary and Funding Status
ID Document / Component T Funding Status

D001

Semantic ER

ML

F

D002

Machine Learning ER

ML

F

D010

Catalog ER (same deliverable as D010 listed below)

ML

ITT

D100

Petawawa cloud mosaicing ML model

ML

F

D101

Petawawa land cover classification ML model

ML

F

D102

New Brunswick forest ML model

ML

F

D103

Semantic Web link builder and triple generator

ML

F

D104

Quebec river-lake vectorization ML mode

ML

F

D105

Quebec model MapML WFS3.0

ML

F

D106

Quebec model MapML WFS3.0 Client

ML

F

D107

Arctic Discovery Catalog

ML

F

 — 

 — 

 — 

 — 

D004

Data Centric Security ER

DCS

F

D114

Data Centric Security Client

DCS

F

D115

Data Centric Security WFS

DCS

F

 — 

 — 

 — 

 — 

D005

Delta Updates ER

DU

F

D111

Delta Updates Client

DU

F

D112

Delta Updates WPS

DU

F

D113

Delta Updates WFS

DU

F

 — 

 — 

 — 

 — 

D121

Catalogue & Discovery Service SERVER (1 of 2)

EOPAD

F

D122

Catalogue & Discovery Service WEB CLIENT

EOPAD

F

D123

Catalogue & Discovery Service CONSOLE/DESKTOP CLIENT

EOPAD

F

D124

Web Processing Service (1 of 2)

EOPAD

F

D117

Catalogue & Discovery Service SERVER (2 of 2)

EOPAD-ITT

ITT

D118

Web Processing Service (2 of 2)

EOPAD-ITT

ITT

D010 (same deliverable as D010 listed above)

Engineering Report

EOPAD-ITT

ITT

 — 

 — 

 — 

 — 

D019

Federated Clouds Security ER

FCA

F

D020

Federated Clouds Analytics ER

FCA

F

D021

EOC, SCALE, and SEED ER

FCA

F

D022

Federated Clouds Provenance ER

FCA

F

D143

Federation Manager #1

FCA

F

D144

Federation Manager #2

FCA

F

D145

Scale Datacenter Environment

FCA

F

D146

WPS Analytics

FCA

F

D147

Federated Cloud Data Services

FCA

F

 — 

 — 

 — 

 — 

D011

Concept Model for Style Encoding & Metadata Model ER

POR

F

D012

Style API for WFS, WMTS, GeoPackage ER

POR

F

D013

WMTS ER

POR

F

D014

WMTS draft specification

POR

F

D015

WMTS-T ER

POR

F

D016

WMTS draft specification

POR

F

D017

Portrayal Summary Report

POR

F

D126

Visual Style Editor #1

POR

F

D127

Visual Style Editor #2

POR

F

D128

GeoPackage with Styles Encodings #1

POR

F

D129

GeoPackage with Styles Encodings #2

POR

F

D130

GeoPackage with Styles Encodings client #1

POR

F

D131

GeoPackage with Styles Encodings client #2 (mobile)

POR

F

D132

WMTS-T w Styles API #1

POR

F

D133

WMTS-T w Styles API #2

POR

F

D134

WMTS-T w Styles Client #1

POR

F

D135

WMTS-T w Styles Client #2

POR

F

D136

WFS 3.0 w Styles API #1

POR

F

D137

WFS 3.0 w Styles API #2

POR

F

D138

WFS 3.0 w Styles Client #1

POR

F

D139

WFS 3.0 w Styles Client #2 (mobile)

POR

F

< end of main body >

Appendix A: Management Requirements

This appendix presents detailed CFP management requirements for submitting a bid. It also covers procedures for participation during initiative execution. The Appendix B Technical Architecture presents the detailed CFP technical requirements.

All potential Bidders, even experienced initiative Participants, should read this appendix carefully from end-to-end (and notify OGC immediately if any defects are discovered). Bidders who are new to OGC initiatives are also encouraged to review the Tips for New Bidders.

The following sections describe the processes for a Bidder to submit a proposal and for a Participant (i.e., a selected Bidder) to perform against a Participation Agreement (PA) contract. The order of topics roughly parallels the sequence described in the Master Schedule. In general, the term "activity" is used as a verb describing work to be performed and the term "deliverable" is used as a noun describing artifacts to be developed, documented and delivered for inspection and use.

A.1. Proposal Submission Procedures

The process for a Bidder to complete a proposal is essentially embodied in the online Bid Submission Form. Once this site is fully prepared to receive submissions (likely within several days of the CFP release), it will include a series of web forms, one for each deliverable of interest. A summary is provided here for the reader’s convenience.

Clicking on the Clarifications link will navigate to the CFP Clarifications page, which is available to the public. Other functions will require that an account be created.

Once an online account has been created, the user will be taken to a home page indicating the "Status of Your Proposal." If any defects in the form are discovered, this page includes a link for notifying OGC. The user can return to this page at any time by clicking the OGC logo in the upper left corner.

Important

Because the Bid Submission Form is still relatively new, it might contain some areas that are still brittle or in need of repair. Please notify OGC of any discovered defects. Periodic version updates will be provided as needed.

Please consider making backup local copies of all inputs in case any of them need to be re-entered.

Please also note that once this form goes "live", any submitted bids will be treated as earnest submissions, even those submitted well before the response deadline. Be certain that you intend to submit your proposal before you click the Submit button on the Review page.

A.1.1. High-Level Overview

Clicking on the Propose link will navigate to the Bid Submission Form. The first time through, the user should complete all the organizational information fields and click Update and Continue.

This will navigate to an "Add Deliverable" page that will resemble the following:

AddDeliverable snapshot of bid submission form
Figure 2. Sample "Add Deliverables" Page

The user should complete this form for each proposed deliverable.

On the far right, the Review link navigates to a page summarizing all the deliverables the Bidder is proposing. Note that this Review tab won’t appear until the user has actually submitted at least one deliverable under the Propose tab first.

Tip

Consider regularly creating printed output copies of this Review page at various checkpoints during proposal creation in case an input error is made later.

Once a submission has been received, the system will send an email to the bidder and to OGC staff.

Tip

In general, up until the time that the user clicks this Submit button, the proposal may be edited as many times as the user wishes. However, this initial version of the form contains no "undo" capability, so please use caution in over-writing existing information.

The user is afforded an opportunity under Done Adding Deliverables at the bottom of this page to attach an optional document of explanation. If this attachment is provided, it is limited to one per proposal and there is a 5Mb file size limitation.

This document could conceivably contain any specialized information that wasn’t suitable for entry into a Proposed Contribution field under an individual deliverable. It should be noted, however, that this additional documentation will only be read on a best-effort basis. There is no guarantee it will be used during evaluation to make selection decisions; rather, it could optionally be examined if the evaluation team feels that it might help in understanding any specialized (and particularly promising) contributions.

A.1.2. Detailed Instructions

The Propose link takes the user to the first page of the proposal entry form. This form contains fields to be completed once per proposal such as names and contact information.

It also contains an optional Organizational Background field where Bidders (particularly those with no experience participating in an OGC initiative) may provide a description of their organization. It also contains a click-through check box where each Bidder will required (before entering any data for individual deliverables) to acknowledge its understanding and acceptance of the requirements described in this appendix.

Clicking the Update and Continue button then navigates to the form for submitting deliverable-by-deliverable bids. On this page, existing deliverable bids can be modified or deleted by clicking the appropriate icon next to the deliverable name. Any attempt to delete a proposed deliverable will require scrolling down to click a Confirm Deletion button.

To add a new deliverable, the user would scroll down to the Add Deliverable section and click the Deliverable drop-down list to select the particular deliverable of interest.

The user would then enter the required information for each of the following fields (for this deliverable only). Required fields are indicated by an asterisk ("*"):

  • Estimated Projected Labor Hours* for this deliverable

  • Funding Request*: total U.S. dollar cost-share amount being requested for this deliverable (to cover burdened labor only)

  • Estimated In-kind Labor Hours* to be contributed for this deliverable

  • Estimated In-Kind Contribution: total U.S. dollar estimate of the in-kind amount to be contributed for this deliverable (including all cost categories)

Cost-sharing funds may only be used for the purpose of offsetting burdened labor costs of development, engineering, and demonstration of initiative outcomes related to the Participant’s assigned deliverables. By contrast, the costs used to formulate the Bidder’s in-kind contribution may be much broader, including supporting labor, travel, software licenses, data, IT infrastructure, etc.

Theoretically there is no limit on the size of the Proposed Contribution for each deliverable (beyond the raw capacity of the underlying hardware and software). But bidders are encouraged to incorporate content by reference where possible (rather than inline copying and pasting) to avoid overloading the amount of material to be read in each proposal. There is also a textbox on a separate page of the submission form for inclusion of Organizational Background information, so there is no need to provide this information for each deliverable.

A Bidder proposing to deliver a Service Component Implementation should use the Proposed Contribution (Please include any proposed datasets) field to identify what suitable datasets would be contributed (or what data should be acquired from another identified source) to support the proposed service. Additional guidelines for this requirement can be found under Data Requirements.

This field Proposed Contribution (Please include any proposed datasets) could also be used to provide a succinct description of what the Bidder intends to deliver for this work item to meet the requirements expressed in Appendix B Technical Architecture. This language could potentially include a brief elaboration on how the proposed deliverable will contribute to advancing the OGC standards baseline (also see Standards Baseline), or how implementations enabled by the specification embodied in this deliverable could add specific value to end-user experiences.

However, to help maintain a manageable process, Bidders are advised to avoid attempts to use the initiative as a platform for introducing new requirements not included in the Technical Architecture. Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in initiative scope or not. Items deemed out-of-scope might be more appropriate for inclusion in another OGC-IP initiative.

The statements of work (SOWs) in the Participation Agreement (PA) contracts will ultimately require performance during initiative execution against the deliverables as described in the Technical Architecture plus any subsequent Corrigenda.

A single bid may propose deliverables arising from any number of threads. To ensure that the full set of sponsored deliverables are made, OGC might negotiate with individual Bidders to drop and/or add certain deliverables from their proposals.

A.2. Conditions for Participation

A selected Bidder will become an initiative Participant by executing a Participation Agreement (PA) contract with OGC. But in order to be selected for cost-share funding for a particular deliverable in the first place, a bid must also meet the requirement to propose an in-kind contribution.

A.2.1. Requirement to Propose an In-Kind Contribution

Each cost-share request (i.e., a bid on a funded deliverable) is required to provide at least some level of in-kind contribution (i.e., activities requesting no cost-share compensation). As a rough guideline, a proposed deliverable should include at least one dollar of in-kind contribution for every dollar of cost-sharing compensation requested. All else being equal, higher levels of in-kind contributions will be considered more favorably during evaluation.

Some participation may be fully in-kind. However, to help maintain a manageable process, Bidders are advised to avoid attempts to use the initiative as a platform for introducing new requirements not included in the Technical Architecture. Any additional in-kind scope should be offered outside of the formal bidding process, where an independent determination can be made as to whether it should be included in initiative scope or not. Items deemed out-of-initiative-scope might be deemed more appropriate for inclusion in another OGC-IP initiative.

Any item proposed as a purely in-kind contribution to meet a requirement already included in the Technical Architecture will likely be accepted if it meets all the other evaluation criteria.

Assuming that this in-kind requirement has been met for every proposed deliverable, a Bidder must also meet the following conditions in order to enter a PA contract:

  • Each Bidder should use the Bid Submission Form to make their proposal.

  • Proposals from non-OGC-members will be considered provided that a completed application for OGC membership (or a letter of intent to become a member) is submitted prior to (or with) the proposal. A non-member Bidder could conceivably defer payment of its membership application fee until after it has learned whether it has been selected for cost-share funds or not.

  • No work facilities will be provided by OGC. Each Participant will be required to perform its PA obligations at its own provided facilities and to interact remotely with other initiative stakeholders.

  • In general, a proposed component deliverable based on a product that has earned OGC Certification will be evaluated more favorably than one which has not.

  • Bidders proposing to build interoperable components should be prepared to test and demonstrate interoperability with components supplied by other Participants. In particular, server-endpoints must be accessible over the public Internet during TIE experiments.

  • Participants selected to implement component deliverables will be expected to participate in the full course of interface and component development, TIEs, and demonstration support activities throughout initiative execution.

  • Participants selected as document Editors will also be expected to participate in the full course of activities throughout the initiative, recording implementation findings & recommendations and ensuring document delivery.

  • Participants should remain aware of the fact that the components will be developed across many organizations. To maintain interoperability, each Participant should diligently adhere to the latest technical specifications so that other Participants may rely on the anticipated interfaces during the TIEs.

  • All Selected Participants (both cost-share and purely in-kind) must send at least one technical representative per assigned thread to the Kickoff Workshop.

    • Participant representatives are encouraged to attend the Interim Workshop.

    • Participant representatives may also have opportunities to attend focused demonstration events that are likely to take place near the end of initiative execution.

Please note that although the bid submission form requires labor-hour estimates for each deliverable, the Participation Agreement (PA) will almost never be a time-and-materials contract to reimburse labor-hours. Instead, each PA will be a fixed-price contract with a particular Statement of Work (SOW) listing the required deliverable(s). A payment schedule will be established so that Participants may submit invoices at various milestones.

A.3. Proposal Evaluation and Invitations to Selected Bidders

Specific proposal evaluation criteria were presented earlier. Several process steps to be conducted by the IP Team are presented below to aid readers in understanding the overall process.

Soon after the proposal submission deadline, the IP Team and Sponsors will begin reviewing proposals, examining suitability of the proposed deliverables in light of the CFP requirements. During this analysis, the IP Team might need to contact Bidders to obtain clarifications and better understand what is being proposed.

At the Decision Technical Evaluation Meeting I (TEM I), the IP Team will present Sponsors with draft recommendations regarding which parts of which proposals should be offered cost-share funding. Sponsors will use this opportunity to suggest modifications.

The IP Team will notify each Bidder of their selection, including a description of the particular deliverables being offered, and OGC’s intent to enter into a Participation Agreement (PA) with them. Selected Bidders must be available for these contacts to be made to enable confirmation of continued interest. Bidder acceptance of the offer essentially locks in the high-level scope that will be used to form the SOW to be attached to the forthcoming PA. A Bidder may reject the offer (for example, if the offer is to deliver only a small subset of its proposed deliverables).

A Decision Technical Evaluation Meeting II (TEM II) meeting will be conducted to review the outcomes of initial offers to selected Bidders, and any modifications that were needed due to Bidder rejections.

Following TEM II, the IP Team will develop the formal SOW and attach it to the full PA for each selected Bidder. Selected Bidders must be available to enable finalization of their PA contract.

Each PA will include a final identification of all assigned deliverables. The specific requirements that these deliverables must meet will be those documented in Appendix B Technical Architecture (plus any subsequent corrigenda).

Because testbeds tend to deal with the lowest maturity level of OGC standards technology, they operate under the principle that “interoperable running code wins” (based loosely on an Internet Engineering Task Force founding belief).

In contrast with ordinary commercial contracts, which often focus on delivering a single-customer solution, the Participation Agreement contracts will encourage Participants to work in the broader interests of the OGC community. These interests are generally represented in the OGC Standards Working Groups (SWGs) and Domain Working Groups (DWGs). Initiative sponsorship enables a selected subset of these interests to be brought to bear on the production of interoperable running code and the reporting back of findings and recommendations as Change Requests (CRs) and document deliverables under the OGC Testbed ER Development Process.

In general, at least one Participant will be assigned for each client-server pair as an Engineering Report (ER) Editor, who will be responsible for authoring the ER, though there might be exceptions. See Requirements for Proposing Deliverables for details. An ER Template will be provided to assist in the breakdown of content into multiple chapters describing specific findings and recommendations, a summary chapter, and supporting chapters (e.g., containing references and revision history).

Important

ER Editors should adopt a proactive approach to consuming and documenting the knowledge being generated during component implementation. In other words, ER Editors will serve as primary authors in addition to their editor role. All Participants are required to support the editors by making necessary documentation material available.

OGC members who who are not selected to make any deliverables may still observe all initiative activities by visiting the (members-only) OGC Observer Agreements page and registering to become an initiative Observer. The Observer Agreement will require that Observers follow the same intellectual property protection rules as apply to other initiative stakeholders (e.g., to avoid sharing other stakeholder’s confidential information with individuals outside the initiative).

Stakeholders should also avoid making any representations that any of the intermediate technical decisions made internally during initiative execution reflect any sort of endorsed position of the OGC. Formal initiative recommendations will become "official" once the containing ER has received approval to be made public.

A.4. Kickoff Workshop

Initiative execution will commence with a Kickoff Workshop event ("Kickoff"). In general, the Kickoff ensures a common Participant understanding of the overall Technical Architecture and of all interfaces relevant to their assigned deliverables. Under the initiative’s rapid pace, and guided by the Thread Architect, periods of development will be followed by synchronization among component developers, so that the likelihood of interoperation is maximized at each iteration. To maintain interoperability, each Participant should diligently adhere to the latest agreed specifications so that other Participants may rely on the anticipated interfaces in subsequent TIE testing.

Since Participants will be relying on one another to deliver interoperable components, all Participation Agreement (PA) contracts should be settled by the start of Kickoff. Any Participant that has not yet executed a PA by start of Kickoff will be required to attest to its commitment to a PA Statement of Work (SOW). The full PA must then be executed with OGC no later than Kickoff completion (two days after Kickoff start).

The Kickoff will include both plenary and thread-based breakout sessions. Thread breakouts will be used to ensure a mutual understanding of the detailed interfaces that will support component interoperability. The Kickoff will also present an opportunity to finalize regularly scheduled thread and subthread teleconferences ("telecons").

All selected Participants must send at least one technical representative per assigned thread to the Kickoff Workshop, and a representative should be present at the breakout sessions for every thread for which the Participant has been assigned a deliverable.

Important

In-person attendance at these breakout meetings has been found to be critical to later initiative success. Remote attendance will not be an option.

These requirements will also apply to Participants not requesting any cost-share funding (i.e., purely in-kind contribution) since their deliverables are still being relied upon by other Participants.

A.5. Participant Communication and Reporting

A.5.1. Points of Contact

Each selected Participant should designate a primary point of contact ("Primary POC") who must remain available throughout initiative execution for communications regarding status. The POC should identify at least one alternative point of contact to support the Primary POC as needed. The POCs should provide contact information including their e-mail addresses and phone numbers.

All proposals should include a statement attesting to the POCs’ understanding and acceptance of the duties described herein. This statement will be enabled by a simple check-box in the Bid Submission Form.

A.5.2. Kickoff Status Report

Selected Participants should provide a one-time Kickoff Status Report that includes a list of personnel assigned to support the initiative and assurance that the Participants understand the schedule for all of its deliverables. This report should be submitted in electronic form to a designated email address no later than the last day of the Kickoff event.

A.5.3. Monthly Progress Reports

Participant Business and Technical POCs should provide, respectively, monthly business and technical progress and status reports due on the 3rd of each month (or the first working day thereafter) and covering the previous month.

Monthly Technical Reports will be accessible to all Stakeholders and should contain no confidential information (e.g., labor rates). Monthly Business Reports may contain confidential information and should be shared only with identified OGC POCs.

Any Participant who has a reliable forecast of what will take place in the remaining days of any particular reported month may submit its report early and subsequently report any urgent, last-minute updates via a follow-on email.

Detailed monthly reporting requirements and procedures will be provided during PA contract negotiation. It is likely that the Portal-based Actions feature will continue to be used for monthly technical reporting.

The IP Team Thread Architects will review action item status on a weekly basis with assigned Participants, who should be available for these contacts to be made. Additional details regarding project management activities during initiative execution can be found at Project Monitoring and Control.

As a preview, monthly technical reports will likely require the following information for each deliverable:

  • Deliverable ID and Name

  • Health: G, Y, R (green, yellow, red)

  • %complete (0%-100%)

  • Work accomplished in reporting period (last month)

  • Work anticipated in reporting period+1 (current month)

  • Any known risks or issues (see definitions under Project Monitoring and Control)

  • Response to mitigate the risk or remedy the issue

A.5.4. Final Summary Report

Participants should provide a Final Summary Report near the end of initiative execution. Detailed requirements and procedures will be provided during PA contract negotiation. These reports will likely require the following information:

  • Describe, in detail, the work completed to fulfill the PA SOW items,

  • Summarize Participant’s overall contribution to the project, and

  • Present recommendations for future OGC-IP and Standards Program efforts.

Any timely Participant who is up-to-date with all the Monthly Technical Status Reports in the Portal will likely be permitted to optionally satisfy the first "in detail" requirement by merely referencing the detail already contained in the Monthly Technical Reports. Timely Participants may also be permitted choose to build their Final Summary Report in the body of an email if desired (or, alternatively, submitted as a document attachment).

A.5.5. Regular Teleconferences

At least one of Participant Technical POC should be available for regularly scheduled telecons for each thread in which it is participating. Weekly thread telecons will be conducted and recorded, (with occasional exceptions for events such as for OGC Technical Committee Meetings).

These telecons are intended to accelerate understanding and action regarding relevant initiative activities, particularly status of any risks or issues that might block or are blocking progress toward timely delivery.

Participants assigned as ER Editors may, with permission from the relevant Thread Architect, lead the substantive discussions during any ad hoc or regularly scheduled sub-thread telecons.

A.5.6. Correspondence and Collaboration

Participants should be able to utilize the following correspondence and collaboration tools:

  • Send and receive emails to/from thread-based email broadcast lists,

  • Contribute technical content using the selected collaboration tool (e.g., GitHub Wiki),

  • Participate in telecons using the GoToMeeting tool,

  • Edit ER source files in the Asciidoc format using the OGC ER Template,

  • Upload ER source files to the initiative GitHub repository.

A.6. Requirements for Proposing Deliverables

In general, Participants will be required to make deliverables meeting the requirements stated in CFP Appendix B Technical Architecture.

Under the Participation Agreement (PA) contracts to be formed with selected Bidders, all Participants will be responsible for contributing content to the ERs.

But the ER Editor role will assume the duty of being the primary ER author. ER Editors should adopt a proactive approach to consuming and documenting the knowledge being generated during component implementation. In other words, ER Editors will serve as primary authors in addition to their editor role. All Participants are required to support the editors by making necessary documentation material available.

In addition, component implementers (Participants selected to deliver component implementations) will be responsible for contributing completed technical artifacts for inclusion as ER annexes. These include UML diagrams, XML schemas and instances, and abstract test suites, all of which have their own specialized clauses in the ER Template. Component implementers will also be responsible for contributing demo assets such as video recordings of component operation.

ER Editors will be responsible for observing the component implementation work and documenting (in the assigned ER) all findings and recommendations (except the technical artifacts identified above). They will also be responsible for ensuring the document’s overall integrity, authoring summary material and ensuring that global sections (e.g., References, Terms, Revision History, Bibliography) have all been completed.

ER Editors will also be responsible for enabling all required ER reviews (and subsequent rework), including internal reviews by Thread Architects and Sponsors, as well as requests for reviews by an appropriate OGC Standard Working Group (SWG) or Domain Working Group (DWG).

ER Editors will also be responsible for creating (and referencing) any Change Requests (CRs) arising from the work described in the assigned ER. CRs can be created using the OGC CR system.

A.6.1. Specific Requirements for Proposing Document Deliverables

The primary acceptance criterion for a document deliverable (e.g., an ER) will be approval from a Thread Architect to post the document to an OGC (members-only) folder called the OGC Pending directory. Permission to post will not be granted until the full OGC Testbed ER Development Process has been followed, including the step to request a review from an OGC SWG or DWG. All appropriate tooling should also have been utilized (ER Template, Asciidoc, GitHub), and the document should have achieved a satisfactory level of consensus among all assigned Participants.

A.6.2. Specific Requirements for Proposing Component Implementation Deliverables

In general, prototype component implementation deliverables (including services, clients, datasets, and tools) will be provided by methods suitable to its type and stated requirements. A service (e.g. a WFS instance or even an intermediary component) will be delivered by deployment for use in the initiative via an accessible URL. A client will be used to exercise a service to test and demonstrate interoperability. Components will be developed and deployed in all threads for integration and interoperability testing in support of agreed-upon thread scenario(s) and technical architecture. The Kickoff will provide the opportunity to establish many of the agreed-upon details. These technical artifacts could also be utilized for cross-thread scenarios in demonstration events.

More specifically, the first acceptance criterion for any component implementation deliverable will be a successful demonstration of capability in a Technology Integration Experiment ("TIE") test.

The next acceptance criterion will be assurance that the work-package ER Editor has access to sufficient documentation material to record all findings and recommendations in the ER and associated CRs.

Another criterion will be evidence that the implementer has directly authored full ER content for any relevant Abstract Test Suite (ER Template Annex A), XML Schema Document (ER Template Annex B), or UML Model (ER Template Annex C).

A Participant assigned to deliver a client component implementation should, in addition, record TIE test execution (as evidence of delivery).

A Participant assigned to deliver a service component implementation should, in addition, provide assurance that the service endpoint will remain available to OGC and Sponsors for a period of no less than one year after initiative execution. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

A Participant assigned to deliver a service component implementation should, in addition, identify of one or more particular datasets that would be suitable for the proposed service. Details are provided under Data Requirements for Proposing Service Component Implementation Deliverables.

Some requirements might request delivery of a packaged prototype component (e.g., using a virtual machine or container). Consult the specific language in the Appendix B Technical Architecture for details regarding these requirements.

A.6.3. Demo Asset Requirements for Proposing Component Implementation Deliverables

Important

Demo requirements might vary between the Part 1 CFP and the Part 2 ITT. The guidelines here refer just to the CFP.

Under the CFP, all selected component implementers will be required to contribute "Demo Assets". These Demo Assets will be used to help compose outreach and communication artifacts toward the end of the initiative. There may also be other demonstration opportunities such as during an ER Editor’s presentation to a Working Group (e.g., the target SWG/DWG that agreed to review the ER). It might also appear in a focused event such as an ESIP Meeting.

These Demo Assets are not required to be professional-grade videos (which are not easily produced and can consume a lot of time and effort). Here a representative example of a Demo Asset from Testbed-13.

Also, some component implementers may seek permission to simply point to another Participant’s Demo Asset (e.g., a video recording of a client interacting with a back-end service that was delivered by that Participant).

Component implementers will also be permitted to create more intricate demo assets that will be considered for upload to the OGC YouTube channel. But these additional videos will be optional, not mandatory.

There will be no independent dedicated initiative "Demo Event" as has taken place in some prior initiatives.

A.6.4. Data Requirements for Proposing Service Component Implementation Deliverables

A Bidder proposing to deliver a prototype service component implementation should provide detailed information regarding what data would be contributed (or what data should be acquired from another identified source) to support the proposed service. Some initiative Sponsors might provide data, but it might also be necessary to complement these with additional datasets.

A Bidder may propose any option that would be suitable to meet the technical requirement stated in the Appendix B Technical Architecture. Here are some examples to illustrate what options might be suitable:

Any datasets that are not intended to be made public can be protected by a click-through license which restricts access solely for use in support of the initiative and which proscribes any additional release, reproduction, or use.

A.7. Project Monitoring and Control

Monitoring and control of initiative execution will follow an encapsulation principle. As long as a Participant continues [1] supporting activities on which other initiative stakeholders are relying (e.g., telecons, TIEs, ER inputs) and [2] making timely delivery of their own deliverables, the question of what’s "going on" inside the Participant organization will likely not be raised.

Otherwise, any issues (or risks) that block (or threaten to block) timely delivery will enter a remediation status requiring the following responses:

  • Development, implementation, and reporting of a credible mitigation or recovery response to get back on track,

  • Recording in the Monthly Participant Technical Status Report a "Red Flag" Action Status indicating that the deliverable is in remediation (plus either "Red" or "Yellow" health in the Action Description),

  • Notification of the relevant Thread Architect(s), who will review the recovery plan and report status to the Initiative Director and Sponsors.

The following definitions will be used to communicate and track deliverable status:

  • For purposes of this initiative, a risk can be defined as any uncertain future event that has a sufficiently high exposure to threaten Participants' ability to make on-time delivery of the promised deliverable scope.

  • An issue is a risk that has actually occurred (no longer any uncertainty surrounding whether it will occur or not).

  • A mitigation response is one that reduces a risk’s exposure (e.g., finding an alternative source for meeting a data dependency).

  • A recovery response is one that remedies the damage caused by the issue (e.g., getting the deliverable back on schedule or being excused from delivery of some particular requirement).

  • A deliverable whose timely delivery is threatened should have an overall status of being in remediation and should reflect a Red or Yellow health.

  • A Red deliverable health is appropriate when the response has not yet been created and agreed, or it has been created and agreed but is not believed to be sufficient to make timely delivery.

  • A Yellow deliverable health is appropriate when the response has been created and agreed, and is in the process of execution (but not yet fully completed).

  • Once the response has been fully completed, the deliverable health should return to Green and the deliverable would no longer be considered in remediation.

In general, risks and issues that are contained within a particular thread will be monitored and managed by the assigned Thread Architect, who will report ongoing status to other stakeholders. Any risks or issues that cross threads should be brought to the attention of all relevant Thread Architects and the Initiative Director.

A.8. Tips for New Bidders

Bidders who are new to OGC initiatives are encouraged to review the following tips, many of which have been drawn from the clarifications of prior initiatives.

  • The roles generally played in any OCG-IP initiative are defined in the OGC-IP Policies and Procedures, from which the following definitions are derived and extended.

    • Sponsors are OGC member organizations that contribute financial resources to steer initiative requirements toward rapid development and delivery of proven candidate specifications to the OGC Standards Program. These requirements take the form of the deliverables described herein. Sponsors representatives help serve as "customers" during initiative execution, helping ensure that requirements are being addressed and broader OGC interests are being served.

    • Bidders are organizations who submit proposals in response to this CFP. A Bidder selected to participate will become a Participant through the execution of a Participation Agreement contract with OGC. Most Bidders are expected to propose a combination of cost-sharing request and in-kind contribution (though purely in-kind contributions are also welcomed).

    • Participants are OGC member organizations that generate empirical information through the definition of interfaces, implementation of prototype components, and documentation of all related findings and recommendations in Engineering Reports, Change Requests and other artifacts. They also make substantial in-kind contributions to an initiative. Participants assign business and technical representatives to represent their interests throughout initiative execution.

    • Observers are individuals from OGC member organizations that have agreed to OGC intellectual property requirements in exchange for the privilege to access initiative communications and intermediate work products. They may contribute recommendations and comments, but the IP Team has the authority to table any of these contributions if there’s a risk of interfering with any primary initiative activities.

    • The Innovation Program Team (IP Team) is the management team that will oversee and coordinate the initiative. This team is comprised of OGC staff, representatives from member organizations, and OGC consultants. The IP Team communicates with Participants and other stakeholders during initiative execution, provides initiative scope and schedule control, and assists stakeholders in understanding OGC policies and procedures.

    • The term Stakeholders is a generic label that encompasses all initiative actors, including representatives of Sponsors, Participants, and Observers, as well as the IP Team. Initiative-wide email broadcasts will often be addressed to "Stakeholders".

    • Suppliers are organizations (not necessarily OGC members) who have offered to supply specialized resources such as capital or cloud credits. OGCs role is to assist in identifying an initial alignment of interests and performing introductions of potential consumers to these suppliers. Subsequent discussions would then take place directly between the parties.

  • Non-OGC member organizations must become members in order to be selected as Participants.

  • Any individual wishing to gain access to initiative intermediate work products in the restricted area of the Portal (or attend the private initiative working meetings / telecons) must be a member-approved user of the OGC Portal system.

    • The reason for this restriction is that members are bound by the OGC bylaws, which offer protections to other members. Affording the same privileges to non-members could have a chilling effect on what are intended to be free and innovative initiative discussions.

  • Individuals from any OGC member organization that does not become an initiative Sponsor or Participant may still (as a benefit of membership) quietly observe all initiative activities by registering as an Observer.

  • Prior initiative participation is not a direct bid evaluation criterion.

    • However, prior participation could accelerate and deepen a Bidder’s understanding of the information presented in the CFP.

  • All else being equal, preference will be given to proposals that include a larger proportion of in-kind contribution.

  • All else being equal, preference will be given to proposed components that are certified OGC compliant.

  • All else being equal, a proposal addressing all of a deliverable’s requirements will be favored over one addressing only a subset.

    • Each Bidder is at liberty to control its own proposal, of course. But if it does choose to propose only a subset for any particular deliverable, it might help if the Bidder prominently and unambiguously states precisely what subset of the deliverable requirements are being proposed.

  • Sponsors will be given an opportunity to review selection results and offer advice, but ultimately the Participation Agreement (PA) contracts will be formed bilaterally between OGC and each Participant organization. No multilateral contracts will be formed.

    • Beyond this, there are no restrictions regarding how a Participant chooses to accomplish its deliverable obligations so long as the Participant’s obligations are met in a timely manner (e.g., with or without contributions from third-party subcontractors).

  • In general, only one organization will be selected to receive cost-share funding per deliverable, and that organization will become the Assigned Participant upon which other Participants will rely for delivery.

    • Optional in-kind contributions may be made provided that they don’t disrupt delivery of the required, reliable contributions from Assigned Participants.

  • A Bidder may propose against any or all threads.

    • Participants in past initiatives have often been assigned to make only a single deliverable. At the other extreme, there is theoretically no upper limit on the number of deliverables a single organization could be assigned to make.

  • The period of performance for PAs is expected to run through December.

  • In general, the PAs will not require delivery any component source code to OGC.

    • What is delivered instead is the behavior of the component in the TIEs, and the corresponding documentation of findings, recommendations, and technical artifacts in the related ER(s).

    • In some instances, a Sponsor might expressly require a component to be developed under open-source licensing, in which case the source code would become publicly accessible outside the initiative as a by-product of implementation.

  • Results of other recent OGC initiatives can be found in the OGC Public Engineering Report Repository.

  • A Bidders Q&A Webinar will likely be conducted shortly before the proposal submission deadline. The webinar will be open to the public, but prior registration will be required.

< end of appendix >

Appendix B: Technical Architecture

B.1. Introduction

This Annex B provides background information on the OGC baseline, describes the Testbed architecture and thread-based organization, and identifies all requirements and corresponding work items. For general information on the Testbed, including deadlines, funding requirements and opportunities, please be referred to the CFP Main Body.

Each thread aggregates a number of tasks. Each task specifies a number of requirements that need to be fulfilled by work items. The work items are funded by different sponsors.

An overview of all threads and assigned tasks is provided further below.

B.2. Testbed Baseline

B.2.1. Types of Deliverables

OGC Testbed threads require several types of deliverables. Deliverable indications "funded" or "unfunded" are provided in the CFP Main Body. Please make sure you understand your tasks and provision requirements according to Annex A.

Documents

Engineering Reports (ER) and Change Requests (CR) will be prepared in accordance with OGC published templates. Engineering Reports will be delivered by posting on the OGC Portal Pending Documents list when complete and the document has achieved a satisfactory level of consensus among interested participants, contributors and editors. Engineering Reports are the formal mechanism used to deliver results of the Innovation Program to sponsors and to the OGC Standards Program and OGC Standard Working Group or Domain Working Groups for consideration.

Important

It is emphasized that participants delivering Engineering Reports must also deliver Change Requests that arise from the documented work.

Implementations

Services, Clients, Datasets, Models and Tools will be provided by methods suitable to its type and stated requirements. For example, services and components (e.g. a WFS instance) are delivered by deployment of the service or component for use in the Testbed via an accessible URL. A Client software application or component may be used during the Testbed to exercise services and components to test and demonstrate interoperability; however, it is most often not delivered as a license for follow-on usage. Implementations of services, clients and data instances will be developed and deployed in all threads for integration and interoperability testing in support of the agreed-up thread scenario(s) and technical architecture. The services, clients, and tools may be invoked for cross-thread scenarios in demonstration events.

B.2.2. OGC Reference Model

The OGC Reference Model (ORM) version 2.1, provides an architecture framework for the ongoing work of the OGC. Further, the ORM provides a framework for the OGC Standards Baseline. The OGC Standards Baseline consists of the member-approved Implementation/Abstract Specifications as well as for a number of candidate specifications that are currently in progress.

The structure of the ORM is based on the Reference Model for Open Distributed Processing (RM-ODP), also identified as ISO 10746. This is a multi-dimensional approach well suited to describing complex information systems.

The ORM is a living document that is revised on a regular basis to continually and accurately reflect the ongoing work of the Consortium. We encourage respondents to this CFP to learn and understand the concepts that are presented in the ORM.

This Annex B refers to the RM-ODP approach and will provide information on some of the viewpoints, in particular the Enterprise Viewpoint, which is used here to provide the general characterization of work items in the context of the OGC Standards portfolio and standardization process, i.e. the enterprise perspective from an OGC insider.

The Information Viewpoint considers the information models and encodings that will make up the content of the services and exchanges to be extended or developed to support this Testbed. Here, we mainly refer to the OGC Standards Baseline, see section Standards Baseline.

The Computational Viewpoint is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution. It captures component and interface details without regard to distribution and describes an interaction framework including application objects, service support objects and infrastructure objects. The development of the computational viewpoint models is one of the first tasks of the Testbed, usually addressed at the kick-off meeting.