Testbed-15 Call for Participation (CFP)

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:

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.

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

The user is afforded an opportunity under Done Adding Deliverables at the bottom of this page to attach an optional Attached 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.

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 be 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 ("*"):

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.

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:

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.

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.

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.

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:

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:

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).

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.

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

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.

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.

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 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.

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.

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.