Open Geospatial Consortium Inc.
Publication Date: 2023-05-17
Approval Date: 2020-03-31
Submission Date: 2020-03-01
Reference number of this document: 05-127r11
Category: Policies and Procedures
Editor: Ingo Simonis
Copyright notice
Copyright © 2023 Open Geospatial Consortium To obtain additional rights of use, visit http://www.opengeospatial.org/legal
Warning
This document is an OGC Policies and Procedures document. The document is subject to change based on membership requirements and motions.
Document type: OGC® Policy; Document subtype: NA; Document stage: Proposal; Document language: English
- 1. Abstract
- 2. OGC Collaborative Solutions and Innovation
- 3. Roles
- 4. COSI Pool
- 5. Initiative Phases
- 6. Types of Deliverables
- 7. Initiative Types
- 8. Engineering Services
- 9. Approval of Initiatives
- 10. Intellectual Property Rights
- 11. Relevance to the OGC Standards Baseline
- 12. Miscellaneous
- 13. Reference Documents
- 14. Revision History
1. Abstract
This document defines OGC Collaborative Solutions and Innovation Policies and Procedures (COSI PnP), formally known as OGC Innovation Program (OGC IP). It describes the various initiative types run by OGC Collaborative Solutions and Innovation and explains the organization of COSI initiative types with respect to a Technology Readiness Level (TRL) scale. The COSI PnP provide an umbrella for all initiative types and define common elements, processes, and roles; as well as the specific characteristics of each initiative type.
2. OGC Collaborative Solutions and Innovation
OGC Collaborative Solutions and Innovation (COSI) is an innovative, collaborative, and hands-on development and rapid prototyping program that leverages the potential of more than 500 OGC members to collaboratively find solutions to spatiotemporal information challenges.
OGC members bring their challenges to COSI. These challenges are extremely diverse. They can be specific technical problems, such as developing a new API or data model, or more complex challenges, such as developing a new architecture, exploring new standards, or profiling them for specific use cases. They can be use case-driven and can be used to clarify which constellation of existing and emerging standards is best suited for a particular use case and how they can be implemented in a cost-effective and sustainable manner.
At the same time, new technologies are explored at COSI, their potential determined, and brought to application maturity. The main feature of COSI is that all challenges are solved collaboratively by participating OGC members. OGC staff takes on an orchestrating and administrative role and also participates in the solution development. COSI provides a neutral research and development environment where the focus is on joint solution development. Over 500 members contribute their knowledge, tools and development capabilities to create efficient and cost-effective solutions for the benefit of the community.
Challenges brought into COSI are refined and mapped to a set of requirements, use cases, and implementation scenarios, and ultimately addressed in different types of initiatives. These types are described in detail below. For most initiatives, OGC members act as sponsors. Mediated by OGC Staff, synergy effects are used to address individual problems as holistically as possible. For this purpose, sponsor funds are pooled and then distributed to OGC members who participate in the solution development within an initiative.
Each initiative aims to incrementally increase the Technology Readiness Level (TRL) for geospatial IT solutions. The work is not limited to technical aspects such as software architecture, interface design, information and data models, and related standards and specifications. It also includes community building and the development of best practices, and thus covers most of the Technology Readiness Ladder as described in Section Technology Maturation Strategy. The globally operated OGC Collaborative Solutions and Innovation starts with the discussion of initial ideas for new technologies, tests them first under laboratory and later under real-world conditions, and only concludes the work by bringing new solutions into the everyday world of decision makers and data and information users. If this work identifies proposed improvements to existing standards or requirements for new standards, they are submitted to the OGC Standards Program for further consideration. Thus, a cycle of standards development, exploration, and application is formed. Existing standards are thus tested in everyday situations, continuously improved and adapted to changing conditions.
OGC Collaborative Solutions and Innovation performs research on the use of information technology (IT), develops reference practices and user guides, develops software, and demonstrates their usage in real world scenarios. All these activities contribute to OGC’s mission to make location information Findable, Accessible, Interoperable, and Reusable (FAIR). COSI performs research on software architectures, explores new concepts and ideas addressed in OGC’s Technology Trends analysis, helps reducing technology risks by solid exploration and testing, and generally supports the geospatial community by advancing geospatial solutions.
OGC Collaborative Solutions and Innovation supports and accelerates the OGC Standards Program by identifying the relevance and ability of standards to help solving geospatial interoperability challenges. OGC COSI is further closely integrated into the OGC program model and fully subscribes to the OGC mission of making location information more findable, accessible, interoperable, and reusable.
2.1. Benefits of OGC Collaborative Solutions and Innovation
For sponsors, the OGC COSI provides a unique opportunity to develop solutions for geospatial IT challenges. OGC COSI provides the ability to determine market interest and validates the willingness of researchers and industry to address specific interoperability issues. The rapid prototype development yields workable interface specifications in months, potentially saving years of time in the standards development processes. Participants test, validate, and demonstrate interface integrity by implementing candidate specifications in their products (reducing the risk that a proposed standard will not perform as intended). The accelerated process encourages rapid time to market for Standards-based solutions with OGC member vendors typically becoming early adopters of draft standards.
Return on Investment for sponsors is substantial: typically for every Euro, Dollar, or other currency equivalent in sponsors funding, initiatives have yielded more than two times as much in terms of level of effort. This return is possible due to the alignment of OGC initiative activities with on-going activities of OGC members. Participants in many COSI initiatives even contribute more in in-kind contributions (e.g., labor, software, infrastructure) than what is funded by sponsors. The results are sustainable as vendors want early influence in specification development as well as skill building, visibility, and opportunity for early market deployment of standards.
For Participants, the benefits focus on the opportunity to cooperatively develop interoperability solutions that might become open standards. Participants gain early insight into user requirements for interoperability and early experience with and influence in developing standards in the context of user business cases. Vendor Participants are able to bring new products and services using OGC Standards into the marketplace earlier. Participation reduces development costs, risks, and lead-time for developing interfaces through a community-wide cost sharing model. The overall result is a broader market reach via products that implement OGC standards.
Another important outcome of OGC COSI initiatives is reduced risk associated with emerging interoperability solutions. The risk reduction is based on creating reference implementations that use draft standards and by validating these technologies with real world business cases in a collaborative environment of sponsors and Participants.
2.2. Technology Maturation Strategy
OGC COSI initiatives promote rapid prototyping, testing, and validation of technologies (e.g., standards or architectures). Within an initiative, OGC Members test and validate draft specifications to address geospatial interoperability requirements in real world scenarios, business cases, and applied research topics. This approach not only encourages rapid technology development, but also determines the technology maturity of potential solutions and increases the technology adoption in the marketplace.
The Technology Readiness Levels (TRL) scale serves as a planning tool for innovation management. The TRL scale was developed during the 1970-80’s by NASA to enable assessment of the maturity of a particular technology and the consistent comparison of maturity between different types of technologies. Since then, the TRL scale has spread to other communities, though with significant adaptation. It is now used by various organizations, from governmental departments to large companies. Indeed, it is the key element of many Technology Readiness Assessment (TRA) methods. OGC has adopted a TRL scale as developed by the European Association of Research and Technology Organisations (EARTO).
Development of high-tech technological systems typically depends on the successful synchronized development of the individual technologies needed. Assessment of the readiness of the individual technologies will allow risk reduction in budget and planning. OGC has adopted the TRL scale to describe the readiness of geospatial IT solutions in the context of standardization and interoperability. The OGC adoption does not focus on a single technology, but takes multi-technological aspects into account where necessary and thus allows the TRL scale to remain one-dimensional. This approach allows estimating technology maturity of individual technology elements that make up the technological building blocks of user scenarios and business processes. The use of TRLs enables consistent, uniform discussions of technical maturity across different types of technology.
Based on the OGC TRL scale, OGC COSI defines various types of initiatives as illustrated in Figure 4. These initiatives follow the TRL scale to allow stepwise development of initial ideas towards robust and mature products, processes, services, or technologies. The various initiative types further differentiate from each other based on the variety of work items within an initiative, duration, and sponsoring concepts.
Initiatives on the lower levels, such as TRL 2-3, focus on research and experimentation. Design Experiments, Sprints, and most of the work performed in Testbeds are located here. The result of the work are reports that eventually serve as content for draft specifications.
Initiatives that take place in the intermediate TRL levels TRL4-7 use adopted standards as a baseline. The main purpose of Pilots, Interoperability Experiments, or Plugfests is to enhance existing technology, explore its readiness for market, test deployments in specific domains, or the execution of cross-product interoperability assessments. Impressive demonstrations and Change Requests towards existing standards are typical outcomes of this types of initiatives.
OGC COSI initiatives usually stop at TRL 8 levels. Here, Operational Exercises allow the exploration of technologies, products, services, or processes to new markets or domains.
The OGC COSI initiative type Engineering Services is the technically more agnostic to Technology Readiness Levels, though specific implementations of this type of initiative usually focus on specific levels as well. The various initiative types feature a common set of initiative roles and often share similar initiative phases, and types of initiative deliverables, which are described in the following sections. Differences for the various initiative types are described in the corresponding sections.
3. Roles
An organization or person who is part of an initiative has one of the following roles.
-
Sponsor: OGC member organization that contributes monetary resources to support the initiative. A sponsor provides requirements and funding for an initiative. Sponsor representatives are available during initiative development to design work items and deliverable descriptions, and during initiative execution for discussions and initiative progress evaluation.
-
Supporter: OGC member organization that contributes non-monetary resources to support the initiative. A supporter provides human resources to lead an initiative, infrastructure, data, tools, meeting space, or catering. In the case of initiatives like Interoperability Experiment or Sprint, an OGC member or a Working Group can become a supporter.
-
Respondent: An organization who responds to a Call for Participation (CFP) or Request for Information (RFI).
-
Participant: OGC member organization that participates in an OGC COSI initiative. Participants can be funded if the initiative provides cost-share funds and the Participant’s proposal has been selected. Participants can also be In-kind Participants in the case when the initiative does not have a sponsor or the Participant is not requesting any cost-share funding.
-
Observer: An individual from an OGC member organization that has agreed to an observer agreement in exchange for the privilege to access initiative communications and intermediate work products. An Observer may contribute recommendations and comments, but the COSI TEAM has the authority to table any of these contributions if there is a risk of interfering with primary Initiative activities.
-
OGC Collaborative Solution and Innovation Team (COSI TEAM): OGC staff team that manages an Initiative. The team includes OGC staff and optionally members of the OGC COSI Pool (see below). COSI TEAM members can perform roles as Initiative Managers, Initiative Architects, or any other support role as required by the initiative.
-
Initiative Manager: Person, member of the COSI TEAM, who is the main contact of the initiative. The Manager is responsible for the conduct, management, financial state, and success of the initiative.
-
Initiative Architect: Person that oversees all technical developments of an initiative.
-
4. COSI Pool
The COSI Pool is a group of individuals that have qualified to serve on the COSI TEAM. Individuals from the COSI Pool are selected per initiative. COSI Pool members usually act as technical support providers for OGC COSI initiatives.
The selection criteria are based on the specific requirements of the COSI initiative. OGC will contact possible candidates with detailed information about the type, content, and context of the planned initiative, the required support type, and an effort estimation.
COSI Pool members always have the right to reject offers to serve on an COSI initiative. If agreement can be established between the individual(s) and the initiative manager, a formal consultancy contract will be executed.
5. Initiative Phases
OGC Collaborative Solutions and Innovation initiatives follow an overall waterfall model from early ideas to final outreach activities. The typical phases are illustrated in the figure below. Not all initiative types necessarily implement all phases. Details are provided in the corresponding initiative type definitions.
All phases either belong to the higher level Preparation or Implementation phases. The Preparation Phase includes the sub-phases Initial Idea / Evaluation, Concept Development (Study), Call for Sponsors, Open Calls: Request for Information / Call for Participation, and Team Formation. The Implementation Phase includes the sub-phases Kickoff, Agile Development, Demonstration, and Outreach.
5.1. Initial Idea / Evaluation
COSI initiatives usually start with either a request or idea from a sponsoring organization or with a request from an OGC board, committee, or Working Group. Alternatively, an OGC member invites OGC to join a consortium that plans to respond to an open tender, or OGC staff decides to initiate an activity on its own. In any case, the OGC COSI Review Board convenes to review and to approve/reject the request/idea.
5.2. Concept Development (Study)
Once an idea or request is approved, the OGC COSI TEAM starts the development of the initiative concept. The concept describes the requirements and outlines a draft technology, system architecture, conceptual model, interface structure, or other technology. As part of the concept development, the COSI TEAM discusses the initiative type with the sponsors. The final decision on the initiative type is with the COSI TEAM. The matured concept then serves as input for the next phase.
A CDS may include a Request for Information to obtain additional information from OGC members or other organizations. A CDS results in an Engineering Report that contains information resulting from the engagement with OGC membership and the broader community of experts. The CDS Engineering Report is delivered to sponsors and released to the public, whereas simple initiative concepts are usually shared among sponsoring organizations only.
If the concept identifies a need or opportunity for additional sponsors, then a Call for Sponsors follows the concept development phase.
Self-Contained Concept Development (Study)
Depending on the expected effort to develop the concept, this phase can be executed as a self-contained Concept Development Study (CDS). A CDS is a sponsored activity where the COSI TEAM develops a comprehensive overview of a given subject. CDS are executed under the umbrella of Engineering Services.
5.3. Call for Sponsors
The Call for Sponsors (CFS) is an optional phase to seek one or more funding organizations to support an initiative. A Call for Sponsors is a formal request that might occur if:
-
The initiative is large or complex enough to require sponsors and the COSI TEAM judges the initiative to be worth performing;
-
One or more organizations have expressed interest in sponsoring an initiative, but more funding or in-kind support is needed; or
-
One or more organizations have expressed interest in sponsoring an initiative, but it is in the best interest of the initiative to have additional sponsor partners; for example, some initiatives benefit from having sponsors form different countries/continents.
Types of Sponsorship
The following types of sponsors are sought:
-
Money to fund the initiative; and
-
In-kind support (e.g., infrastructure, data, facility, personnel time, catering, stipends, travel support).
Call for Sponsors Document Content
A CFS document will include at least the following information:
-
Title of the initiative;
-
General scope of the initiative, understanding that sponsors will work with the COSI TEAM to refine the scope prior to the start of the initiative;
-
Type and approximate amount of sponsors required;
-
Consequences to the initiative if sufficient sponsors is not obtained; and
-
Response deadline.
Sponsor expectations
Because a CFS occurs before contracting, the responding parties are responding in good faith and final negotiation of sponsors details will occur once the CFS closes. Similarly, the CFS deadline may be extended as there are no contractual obligations under a CFS.
The COSI TEAM receives CFS responses and contacts the potential sponsors to understand their interest, offered sponsors, and any requirements from sponsors of the OGC or initiative Participants.
5.4. Open Calls: Request for Information / Call for Participation
Once the concept has been defined and depending on the initiative type, the development of a Request for Information or Call for Participation starts. Both documents are eventually released to the public with the goal to seek interest by the geospatial community in an COSI initiative.
The Request for Information (RFI) is a formal process to gather information from OGC members or broader communities of experts about particular interoperability issues or technologies. The RFI is formulated upon the Concept Development, sponsor requirements, and the existing OGC Standards baseline.
The intention of an RFI is that organizations (i.e., government, industry, universities, and other organizations that work within the geospatial market) will review their technology capabilities, best practices, research and development, and design ideas and respond to the RFI with recommended technological approaches to the issues described in the RFI.
The COSI TEAM will review the RFI responses and develop an Engineering Report that documents the responses to the RFI, the benefits of given recommendations, the probable costs (if possible), an appraisal of where the recommendation seems to fit within the overall context of industry practice, and a draft technical architecture. The RFI report will be handed over to the Sponsors for further consideration. On receipt of the report, the Sponsors are then in a position to make a decision on how best to proceed: whether to fund an initiative or to reconsider the requirements submitted and go through the process again.
The Call for Participation (CfP) defines the technical background, requirements, an initial architecture, and work to be performed within an initiative. The Call for Participation is based on the developed concept or a previously conducted Concept Development Study (Figure 6, Step 1). It also provides stakeholder role descriptions, proposal submission instructions and evaluation criteria, a master schedule, and other project management details.
In the process of CfP development, the COSI TEAM works closely with the sponsors on the scope of the initiative (Figure 6, Step 2). The COSI TEAM formalizes the requirements, designs an initial architecture and corresponding deliverables, and draws up a budget for the activities required to address the requirements. It is the goal for each initiative to have at least two implementations of each software component to test and enhance interoperability most efficiently. The CfP and budget development is an iterative process to allow Sponsors to define the optimal set of requirements and corresponding work items (Figure 6, Step 3).
The Call for Participation provides all necessary information to the general public that is necessary to respond to the call. The CfP allows applicants to explain the technical contribution they intend to make, how their contribution maps to the deliverables and activities, the cost-sharing funds they are requesting to offset their engineering costs, and the in-kind contributions they will make.
The time to respond to the CfP is usually 30 calendar days. All Calls for Participation are released publicly (Figure 6, Step 4).
The responses are sent to the OGC and reviewed by the COSI TEAM (Figure 6, Step 5). Technical proposals are made available to all initiative Sponsors.
5.5. Team Formation
The Team Formation phase starts soon after the CFP has been closed and all proposals have been received (Figure 7, Step 1). This phase identifies and contracts the best organizations to participate in an initiative. After the CFP response deadline, the sponsors and the COSI TEAM perform a review process for the selection of Participants. The criteria for proposal evaluation are defined in the Call for Participation.
The COSI TEAM presents recommended Participants to the sponsors in one or two Technical Exchange Meetings (TEMs). Additional TEMs may be required to solve issues such as no responses received to address a deliverable, submissions which were not clear, or proposals exceeding the initiative budget (Figure 7, Step 7-9). At the final TEM, the COSI TEAM and Sponsors will reach an agreement about the Team formation and the deliverables assignments to the Team members. In case of conflict, the final decision about Team formation is with the COSI TEAM. The COSI TEAM will determine the specific distribution of funding to Team members.
In case of lack of proposals for specific work items, the COSI TEAM works closely with the sponsors to find solutions. Both sponsors and COSI TEAM can suggest OGC members to solicit for interest in taking on the work item(s). During this process, sponsors may even suggest non-member organizations as possible candidates. Principal and Strategic OGC members may make use of their membership assignment options to facilitate the non-member admittance process.
When decisions with regard to Participants’ funding have been made, COSI TEAM will notify the proposing organizations of the outcome of the TEMs. Once the selected Participants have been notified, the OGC will begin negotiations with the selected Participants. These negotiations will discuss funding, tasks to be performed, in-kind contributions that will be provided by the Participant, and the nature of the statement of work. These negotiations will form the basis of an agreed to Statement of Work (SOW) and a contract between OGC and the Participant in question (Figure 7, Step 5). While this process is expected to be iterative as terms of the contract are finalized, the contract is the basis for the relationship between OGC and the Participant.
Participants are expected to be OGC members. If a selected Participant is not an OGC member, that Participant should begin the membership registration process. Membership will be required before the final Participant contract is signed. Once the OGC COSI TEAM has decided that negotiations are at a reasonable state of completion, the COSI TEAM will complete work on the overall architecture, initiative schedule, initiative concept of operations, work packages, and further materials that will be provided to the sponsors and Participants at the Kickoff meeting.
Many COSI initiatives require Participants to provide some level of in-kind contribution (i.e., activities or deliverables offered with no expectation of financial compensation). Where in-kind contributions are required, general guidance is that a proposal should include at least one dollar of in-kind contribution for every dollar of cost-sharing compensation requested, unless otherwise specified in the CFP. Participation may be fully in-kind.
5.6. Kickoff
A Kickoff is a meeting where the initiative scope and schedule is discussed with sponsors and all Participants. The Kickoff meeting offers an opportunity for the COSI TEAM and sponsors to highlight the purpose of the initiative and allows Participants to ask questions to clarify their responsibility. The meeting is led by the Initiative Architect. The meeting can occur physically (face-to-face) or virtually (web- or teleconference), depending on what the COSI TEAM and sponsors deem appropriate. Large initiatives almost always require physical meetings. Participants will be required to attend the Kickoff to be introduced to other Participants, the COSI TEAM, and sponsors.
5.7. Agile Development
The Agile Development phase is the actual execution part of an initiative with all sponsors, Participants, and the COSI TEAM working on the requirements and work items as defined in the Call for Participation. The Agile Development phase follows agile principles where Participants are encouraged to show results as soon as possible. This approach allows timely feedback to the Participants from the COSI TEAM, sponsors, and other Participants. The Agile Development phase starts with the Kickoff meeting. Afterwards, Participants will meet regularly (usually once per week) via web meetings and teleconferences to discuss solutions and report progress.
Depending on the initiative type, the agile development includes several stages, starting with a review and status quo discussion of all work items listed in the Call for Participation. Moderated by the COSI TEAM, Sponsors and Participants can mutually agree to modify work items at this stage (Figure 8, Step 11).
After the initial refinement, all work items are then explored in prototypical implementations. In an agile process, prototypes and design decisions iterate until a satisfying level of maturity has been reached. Design decisions, reasons for technology selections, and other important items are captured in Draft Engineering Reports (Figure 8, Step 12).
Once design and implementation have reached the necessary level of maturity, all components are tested in Technology Integration Experiments (TIEs). The COSI TEAM always tries to have at least two implementations of each component to test and enhance interoperability. TIEs bring the components developed by the various Participants together to test interoperability (Figure 8, Step 13).
If compliance testing is part of an initiative, then components developed are tested through the OGC validation tools. Additional compliance tests may be developed as part of the initiative.
OGC COSI Initiatives demonstrate all results at the end of an initiative. For that reason, COSI TEAM, Sponsors, and Participants develop a Demonstration Concept that may include elements such as live demonstrations, video material that highlights the main achievements of an initiative, blog articles and other form of social media, and other outreach material that helps to communicate the results of the initiative (Figure 8, Step 14).
The formal products of an OGC COSI Initiative are Engineering Reports and Change Requests to existing OGC Standards. Both are developed in a joint effort of all Participants in an COSI initiative, led by a dedicated document editor as main author. Engineering Reports undergo the formal OGC public release process, which includes review periods and votes by OGC committees. The detailed process is defined in the OGC Policies and Procedures. All Engineering Reports and formal Change Requests are handed over to the OGC Standards Program for further consideration (Figure 8, Step 15-16).
The length of the agile development phase depends on the type of initiative. The phase spans from hours at a Sprint activity to several months in the case of Testbeds. Some initiative types foresee Interim Workshops where Participants, sponsors, OGC members, and invited experts meet to discuss a specific technology topic that is key to an COSI initiative.
To support this phase, OGC provides state of the art web collaboration tools, including content management systems, wikis, FTP sites, unlimited web conferences, GitHub/Gitlab repositories, cloud hosting, and mailing lists.
5.8. Demonstration
A demonstration event provides the venue to present the accomplishments of the Initiative. The demonstration event will include a general overview provided by the Initiative Architect and Participants should have the opportunity to showcase the results of their work. The demonstration event also provides the opportunity for sponsors and Participants to interact, discuss any final issues, and plan future efforts. The demonstrations are generally held physically, but in some circumstances can be virtual.
5.9. Outreach
Outreach activities following an initiative will include a persistent landing page on the OGC website detailing the initiative work and results, public Engineering Reports, and optionally, blogs, video material, press releases, and articles/publications. The COSI TEAM coordinates and mentors all outreach and will facilitate permissions for publication of initiative results by sponsors and Participants. Canned videos will be posted in the OGC YouTube channel.
Depending on the explicit requirements stated in the Call for Participation, some prototypes may be available in live servers for a specified period of time beyond the end of an Initiative execution for continued use. The time and conditions are subject to the terms of the Participants agreement.
6. Types of Deliverables
COSI initiatives generate deliverables. All initiatives are intended to develop one or more Engineering Reports (ERs), other deliverables are generated depending on the scope of the initiative.
6.1. Engineering Reports
Engineering Reports (ERs) are prepared in accordance with an OGC published template. ERs are the formal mechanism used to deliver results of OGC Collaborative Solutions and Innovation to Sponsors and to the OGC Standards Program for consideration by Standards Working Groups and Domain Working Groups before ultimate approval by the OGC Technical Committee (TC).
ERs typically contain some or all of the following information. Note that the content of an ER is dependent on the nature of the initiative.
-
Overview, background information, references, and terms and definitions
-
Requirements
-
Experimentation detail
-
Design and concept explanations
-
Testing approach and results
-
Compliance test design
-
Conclusions, lessons learned
-
Next steps
Once initiative Participants and sponsors agree on an ER’s contents and that the ER should be approved by the TC for public release, the ER is posted to Pending Documents on the OGC Portal. ERs do not represent the official position of the OGC, but are endorsed by the OGC Technical Committee.
Engineering Reports may describe best practices or provide user guides for specific technologies.
6.2. Change Requests
Change Requests (CRs) are the formal process by which changes are suggested for OGC standards and evaluated by the Standards Working Group (SWG) controlling any standard. Where existing OGC standards are being used as part of an COSI initiative, the initiative Participants are encouraged to create CRs whenever deficiencies or improvements are identified for OGC standards. CRs are posted by the COSI Participants to the public using the OGC Change Request online tool.
6.3. Feedback to Working Groups
All COSI initiatives are required to provide feedback to relevant OGC Working Groups. Usually, this takes the form of presentations at Technical Committee meetings.
6.4. Implementations
Implementations take the form of Services, Clients, Datasets, and Tools provided by methods suitable to the implementation type and stated requirements. For example, services and components (e.g., a WPS instance) are delivered by deployment of the service or component for use in the Initiative via an accessible URL. A Client software application or component may be used during the Initiative to exercise services and components to test and demonstrate interoperability; however, the application or component is most often not licensed for usage after the initiative ends. Implementations of services, clients, and data instances may be deployed in multiple threads of a complex initiative 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.
6.5. Executable Test Suites
A set of code that implements an Abstract Test Suite of a specification. The test is written to be executed in the OGC Validation Engine.
6.6. Demonstrations
Demonstrations are events or online resources that present the major accomplishments of the initiative. They are one of the mayor outcomes of an initiative.
7. Initiative Types
OGC Collaborative Solutions and Innovation conducts a series of COSI initiatives. These initiatives are organized based on the OGC TRL scale. The following figure illustrates this organization.
OGC Collaborative Solutions and Innovation initiatives further differentiate regarding the variety of technology scope that is addressed within an initiative, the role of the COSI TEAM, the emphases of the various initiative phases, initiative result types, duration of the agile development phase, openness to non-OGC members, and available funding. The following table illustrates differences with respect to:
-
TRL, Technology Readiness Level, describes the position on the TRL scale as discussed in section Technology Maturation Strategy.
-
Scope describes how wide an initiative spans over TRL levels, technologies, or domains.
-
Very narrow focuses on a single technology or domain
-
Narrow focuses on small set of related technologies
-
Wide includes many, partly unrelated technologies and/or domains.
-
-
Role COSI TEAM describes what main function the COSI TEAM executes
-
Management: The COSI TEAM organizes the initiative and provides architects
-
Support: The COSI TEAM facilitates the initiative
-
Varies: Depending on the need of the initiative, COSI TEAM may be involved in a support, management, or active research role
-
-
Emphasis on phases defines to which extent the Initiative Phases are conducted.
-
Relaxed initiative only use a subset of the Initiative Phases and some phases might be executed with reduced effort
-
Fully conducted initiatives execute all Initiative Phases
-
-
Results describes the type of results of an initiative.
-
ERs and CRs initiatives are required to produce formal results
-
Summary Report initiatives may provide informal results only.
-
Varies initiative produce results in a format as required by the concrete initiative.
-
-
Duration describes the duration of the Agile Development phase. The actual duration including planning, preparation, team formation etc. will take longer.
-
Openness defines if an initiative is open to non-members.
-
Funding describes the typical funding situation with
-
Cost share initiatives offering cost-share opportunities
-
Exception initiatives are offering cost-share only in exceptional cases
-
Criterium | Design Experiment | Sprint | Pilot | Plugfest | Operational Exercise (OpEx) | Interoperability Experiment (IE) | Testbed | Engineering Services |
---|---|---|---|---|---|---|---|---|
TRL |
2-4 |
3-4 |
4-6 |
6-8 |
7-8 |
4-7 |
2-6 |
2-8 |
Scope |
Narrow |
Very narrow |
Narrow |
Very narrow |
Narrow |
Narrow |
Wide |
Varies |
Role COSI TEAM |
Management |
Support |
Management |
Support |
Management |
Support |
Management |
Varies |
Emphasis on phases |
Fully conducted |
Relaxed |
Fully conducted |
Relaxed |
Fully conducted |
Relaxed |
Fully conducted |
Varies |
Results |
ERs and CRs |
Summary report |
ERs and CRs |
Summary report |
ERs and CRs |
ERs and CRs |
ERs and CRs |
Varies |
Duration |
2-6 months |
Days to weeks |
3-6 months |
Days to weeks |
3-12 months |
3-12 months |
6-9 months |
1-48 months |
Openness |
Closed |
Open |
Closed |
Open |
Closed |
Closed |
Closed |
Closed |
Funding |
Cost share |
Exception |
Cost share |
Exception |
Cost share |
Exception |
Cost share |
Varies |
Acronyms used in table above:
-
ER Engineering Report
-
CR Change Request
7.1. Design Experiments
OGC Design Experiments qualify at the lower end of the TRL spectrum. Design Experiments seize the idea to develop new specifications, e.g. a new API type, data model, or data container. Design Experiments are very focused initiatives that run the whole gamut of the initiative phases. Design experiments usually provide cost-sharing funds and are managed by the COSI TEAM. Design Experiments are required to deliver their results as Engineering Reports or Change Requests. Design Experiments commonly have an agile development phase of 2-6 months.
7.2. Sprints
OGC Sprints experiment with emerging ideas in the context of geospatial standards, help improve interoperability of existing standards by experimenting with new extensions or profiles, are used as proof of concept for other OGC Collaborative Solutions and Innovation initiatives, or support OGC Standards Program activities.
OGC Sprints are very short and focused initiatives that are often executed within few days to weeks. Sprints put most of their emphasis on the agile development phase that is usually executed during a physical meeting. Located at TRL 3-4, Sprints usually build on existing technology and develop extensions, profiles, or complementing new technology.
At OGC Sprints, technology and domain experts, programmers, and program managers come together to develop new and enhance existing specifications in an agile way. At OGC Sprints, development is pushed forward and at the same time coordinated to ensure minimum redundancy and consistent use of common elements across the growing set of OGC standards.
OGC Sprints are not necessarily managed by the COSI TEAM, but optionally by OGC working groups or OGC member organizations with support from the COSI TEAM. Sprints sometimes include sponsors and provide cost-sharing funds to cover travel expenses. Sprints are often open to non-member organizations and execute shortened initiative phases with less stringent concept developments, calls, team formation, demonstration, and outreach phases. Sprints often provide direct, informal input into OGC working groups and are not required to deliver Engineering Reports as formal results.
OGC Sprints cover activities that are sometimes referred to as "Hackathons". As such, Sprints bring together computer programmers and others involved in software development, e.g. graphic designers, interface designers, project managers, end-users, and subject-matter-experts. Programming-oriented Sprints emphasize rapid programming to support the development of new applications, new software capabilities, and open standards.
Intellectual Property Rights Policy for OGC Sprints
Sprints fall under three different Intellectual property rights (CIPR) domains, depending on where the source code, generated by a Participant during the Sprint, resides after the event.
Participant source code is not shared or transferred to the OGC or another party:
-
Sprint goal is to raise awareness and encourage implementation of technologies based on OGC and complementary open standards – no OGC IPR restrictions; or
-
Sprint goal is to test, validate, or demonstrate OGC and complementary draft or approved standards, ERs, and Best Practices - specific non-code contributions by Participants will fall under the appropriate OGC IPR rules for the Technical Committee or a specific SWG;
-
Sprint goal is to encourage development of reference implementations for use by OGC or others – code is Open Source licensed (e.g., Apache 2.0) or submitted technology to OGC via the OGC IPR transfer process.
OGC Challenges
Special cases of Sprints are OGC Challenges. Challenges are events where Participants advance the development of new applications, new software capabilities, and open standards according to sponsor-defined scenarios or use cases. In some cases, the prizes might be cash.
In contrast to normal Sprints, the physical meeting of Challenges may take place several weeks after the kickoff meeting. Participants are expected to attend a final judging event where the proposed solutions are demonstrated in person. Participants may be required to turn in information about their solution to be evaluated early on, approximately two weeks, before the final demonstration face to face judging event.
Sponsors, OGC Members, outside experts, and OGC staff (in rare occasions) are potential judges for the Challenges. In all cases, attempts will be made to secure a minimum of at least three judges.
Some challenges may include finalists, winners, and prizes. Other challenges might not have winners. Is up to the team (Sponsors and OGC Staff) to decide the structure of the challenge and criteria for selecting finalists, winners and tie breaking.
7.3. Pilots
OGC Pilots apply and test OGC standards in real world environments. Pilot projects are an opportunity for users to understand how to best address their requirements using standards-based architectures. Pilots demonstrate key aspects of the system identified in the Concept Development phase, including the development of key data models and critical workflows to deliver, use, and visualize data.
A Pilot evaluates the feasibility of implementing a standards-based architecture and provides valuable requirements for defining and developing solicitations or tenders for implementation of an operational system. Pilots are, in contrast to higher TRL Operational Exercises, located at TRL 4-6. Thus, Pilots usually work with prototypes or pre-production products that are explored in realistic scenarios. Pilots do not have the goal to deploy technology in real world environments.
A pilot unites technology users with technology solution providers in a fast-paced collaborative prototyping environment to test and evaluate implementation of existing or candidate standards. Pilots serve as an incubator to prioritize, encourage, and accelerate the pace at which standards-based capabilities are deployed to improve interoperability within a specific domain or user community.
Special emphasis in pilots is on demonstrating and validating the capability of standards-based practices to address real world scenarios provided by the user community. Pilot initiatives run the whole gamut of initiative phases. Pilots provide cost-sharing funds and are managed by the COSI TEAM. Pilots are required to deliver their results as Engineering Reports and often in various forms of outreach material. With few exceptions, Pilots have a typical duration of the agile development phase between 3 and 6 months.
7.4. Plugfests
OGC Plugfests are initiatives where vendors cooperatively test (and possibly refine) their OGC standards-based products in a hands-on engineering setting. Plugfests, located at TRL 6-8, are used to (1) assess the degree to which different products in the marketplace interoperate based on their implementation of OGC standards and (2) advance the interoperability of geospatial products and services based on OGC standards in general or within specific communities.
In a Plugfest OGC provides a neutral environment in which developers and data suppliers work together to validate the ability of their products to interoperate with other offerings implementing the same OGC standard(s). Plugfest goals can include:
-
Ensure that different products interoperate as intended;
-
Attain an installed base of maturity in the market with a reliable procedure for assuring that OGC standards-based solutions work together;
-
Promote consistency and compatibility among mainstream products;
-
Demonstrate better understanding of how OGC standards can be used in heterogeneous information and geo-processing environments;
-
Create a persistent set of services for compliance testing; and
-
Create a persistent network of implementations to demonstrate the ability of OGC standards-based solutions to address particular market requirements.
An OGC Plugfest does not certify any combinations of OGC implementing or compliant products will operate error free or guarantee 100% interoperability. A Plugfest is not intended to provide a compliance suite for all portions of all available standards that are used in a Plugfest.
The phases of a Plugfest are depicted in [img-Plugfest].
The Call for Participation usually includes the following requirements:
-
Two service implementations for each standard exercised;
-
Two client implementations for each standard exercised;
-
Service implementations shall pass the OGC CITE test(s) for each standard exercised if a compliance test exists;
-
Definition of a set of Plugfest Test Data (OGC CITE tests use a generic set of test data and only test services, not clients);
-
Definition of a set of service requests that clients shall perform to exercise the Plugfest test data and actions client software operators shall conduct to generate those service requests; and
-
A Plugfest Scenario that uses the Plugfest test data and client service requests to tell a story that articulates the return on investment for interoperability and standards usage.
Plugfests are often short duration initiatives that do not execute all initiative phases in full detail. Instead, Plugfests often have no Call for Sponsors, do not necessarily provide cost-share opportunities for Participants, and blend kickoff, agile development, and demonstration into a single physical meeting.
Plugfests are managed by the COSI TEAM and can be opened to non-OGC members. Plugfests are not required to deliver a formal Engineering Report. Instead, Plugfests usually share results within the group of Participants exclusively.
7.5. Operational Exercises
Operational Exercises (OpEx) target the upper end of the TRL scale at levels 7-8. They focus in particular on the viability of standards and technologies in operational environments where practitioners must fulfill critical roles and responsibilities for mission success. OpEx events validate products, plans, policies, agreements and procedures against real user activities in what are as close as possible to real operational settings. OpEx begin with market-ready products that implement technically proven OGC standards and evaluate whether they can significantly improve out-in-the-world mission performance. The scale and complexity of OpEx may range from small-scale drill-like exercises that test a single, specific function within one organizational entity, to large-scale multi-organizational, multi-jurisdictional, multi-discipline exercises.
OpEx initiatives run the gamut of initiative phases. OpEx are managed by the COSI TEAM, may have agile development phases ranging from 3 to several months, and generally include significant components of organizational outreach and user training. They include significant cost-share opportunities for all Participants to offset the substantial requirements of event preparation. OpEx are open to non-OGC member organizations. OpEx results are captured in Engineering Reports, Best Practice proposals, and possibly Change Requests.
7.6. Interoperability Experiments
An Interoperability Experiment (IE) is an initiative primarily led and executed by OGC members and facilitated by OGC staff. IEs, located at a rather wide span of TRL 3-7, have technical objectives that furthers OGC innovation by addressing requirements identified by members.
An IE is not funded by sponsors. Instead, members play the role of supporters, providing personal to lead the initiative with support from OGC staff. All Participants' efforts, including travel, is viewed as voluntary and supported as in-kind contributions of the participating member organizations. Most initiators provide human resources to help run the initiative or run the scenarios that are documented in the IE concept.
IEs do not implement all initiative phases, as they do not perform Calls for Sponsors or formal Calls for Participation. Instead, IEs use an informal Call for Participation that is announced through OGC communication channels.
IEs are required to deliver their results in formal Engineering Reports. IEs usually focus on a specific topic or technology and run between 6 to 12 months.
7.7. Testbeds
The OGC Testbed is an annual research and development program that explores geospatial technology from various angles. It takes the OGC Standards Baseline into account, though at the same time allows exploration of selected aspects with a fresh pair of eyes. The OGC Standards Baseline is the complete set of OGC Member approved Abstract Specifications, Standards (including profiles and extensions), and Community Standards. The Testbeds integrate requirements and ideas from a group of sponsors, which allows leveraging symbiotic effects and makes the overall initiative more attractive to both Participants and sponsoring organizations.
Testbeds emphasize the evaluation of what should be in a specification, how the specification should act, and how specification-based software should respond. While development is done during testbeds in terms of defining, documenting, and distributing specifications and in terms of developing prototypical software that exercises the specification, this development is generally along the lines of proof-of-concept rather than deliverable software.
Testbeds bring multiple sponsors together with hundreds of Participants. Testbeds go through all phases depicted in Figure 5 and usually run over an annual period with six to nine months of agile development time. The regular schedule of Testbeds allows potential sponsors to plan and properly research interoperability topics that they consider important to bring to the initiative. Managed by the COSI TEAM, Testbeds are run in multiple parallel threads with a dedicated architect per thread and an initiative architect overseeing the initiative. Many ERs can come out a testbed (20+), requiring special coordination with the Standards Program to move the ERs through the OGC TC approval process.
8. Engineering Services
OGC Engineering Services are a special type of COSI initiative. In principle, the services serve two main purposes: first, innovation accelerators for OGC specifications, and second to catalyze adoption by other organizations with the goal to improve understanding and use of OGC standards and technologies and increased demand for products offered by OGC member organizations. The first supports the development of OGC standards and technologies and includes dissemination and exploitation activities. The latter helps other organizations to receive support in evaluating the latest technological trends, optimizing software architectures, setting up of large enterprise systems, or performing compliance tests. Based on organization needs, the Engineering Services facilitate the understanding about how to apply the OGC interoperability framework drawing upon the OGC Reference Model (ORM) and the OGC Standards Baseline. These services also help to stimulate demand for standards-based interoperable technologies offered by the OGC members and others in the technology marketplace. The OGC Engineering Services span a wide range of service types including administrative, organizational, research, or strategic guidance.
At the same time, OGC interoperability engineering services ensure strong links with the OGC Standards Program and serve as the innovation hub of OGC technologies and domain-specific and domain-independent specifications. OGC works with Engineering Services customers to position OGC standards and related best practices in technology, policy, development, and acquisition programs.
8.1. Service Types
Engineering Services can have different focus and embodiment. The following list describes the range of Engineering Services. Thus, Engineering Services include but are not limited to:
-
Assessment, Analysis, and Feasibility Support: to include “As-Is” studies, requirements definition, business plans (including basic Return on Investment (ROI) statements related to the use of standards), use case modeling, analysis, and procurement readiness assessments. These services are focused on providing recommendations to reduce communication, processing, and information distribution bottlenecks through application of standards and related best practices in technology policy, programs, procedures, and acquisitions of OGC-compliant products. Engineering Services of this type are frequently referred to as Concept Development Studies if executed as a sponsored, self-contained initiative.
-
Standards-based reference architecture design, documentation, and review: These services define the organizational environment for standards and results in recommended steps and well-defined profiles needed to expand and sustain an organization’s interoperability capacity. Employing a number of reference models and underlying methodologies (e.g., RM-ODP and functional equivalents), OGC communicates the Enterprise, Information, Engineering Technology, and Computational viewpoints of recommended reference architecture. Engineering Services of this activity can take various forms, including Workshops with invited experts.
-
Operation and enhancement of OGC online compliance facilities and compliance evaluation: These services, offered in conjunction with the OGC Compliance Program, help OGC members to optimize their compliance-testing environment and help detect compliance deficiencies within the organization or within the product portfolio of an organization.
-
Education and Outreach: These services include interoperability training for various target audiences, presentations and seminars at standards/interoperability conferences and symposiums, and support to public relations and communications programs related to the development and uptake of open standards.
-
Innovation & Research Services. These extend the “Assessment, Analysis, and Feasibility Support services” listed above. They are implemented through direct participation in research and development programs with the goal to enhance the OGC technology baseline, experiment with new technologies, and position OGC as an innovation hub within the international research & development community. These services help OGC members to develop sustainable products and ensure state of the art products for customers.
8.2. Service Roles
The Engineering Services described above require a number of roles to be covered. These roles can be applied to any type of activity listed above. Engineering Services are usually executed in individual projects, always with the goal to further the use of OGC standards and benefit the OGC membership. A single project may make use of any number of roles as described below.
-
Project Coordination: OGC coordinates the project as official project coordinator. OGC may decide to act as project coordinator on its own initiative, or can be approached by any OGC member to take on this role for any type of project activity. OGC is responsible to cover all aspects of project coordination. In addition, OGC offers services such as letter requests to OGC members. Those letter requests can be issued for various purposes, e.g., to find additional members to form project consortia, when replying to open tenders, or to identify organizations suitable for other OGC initiative types such as Testbeds or Pilots. The OGC reserves the right to select organizations responding to letter requests based on clearly defined and published criteria. Taking this role allows OGC to organize internal activities, to learn about new trends in emerging markets, and to understand the requirements of particular domains.
-
Technical Coordination: OGC coordinates the technical developments within a project. The role requires a very good overview of all technical developments and an understanding of state-of-the-art technology approaches and trends. The role helps OGC to understand the latest developments in terms of domain-specific research and development and connects with OGC members and external organizations on a technical level.
-
Architecture Development & Research Performing this role, OGC works on architecture developments and specific research topics within projects. This role requires a very good technical expertise and skills in architecture design and documentation and a solid understanding of the latest technology trends, applications, tools, and products. This role strengthens the connection with the OGC Standards Program, as existing standards are tested and explored, and new requirements, ideas, and technologies are added to existing specifications. This role, which is applied in tight connection with OGC members, serves an OGC innovation purpose to ensure sustainable and forward-looking specifications, technologies, and standards.
-
Knowledge Transfer This role focuses on knowledge transfer from OGC to other organizations. OGC makes its experiences and know-how available and helps other organizations to understand both details about OGC standards and technologies as well as general aspects of distributed computing, software architectures, compliance testing, and other fields of expertise. This role allows other organizations to profit from the technical expertise of OGC and accelerates knowledge transfer among OGC members. The work of this role also helps organizations with strategy-formulation, enabling them to better gauge the trajectory and momentum of OGC standards and technologies.
-
Exploitation and Dissemination OGC is continuously engaged in dissemination activities at various events and can leverage its network for the benefit of other organizations. Using its wide field of contacts and engagements, OGC can help organizations to optimize their product and technology exploitation strategies and to disseminate (research) developments at various events. This role requires strong networks and connections into domains and communities and adaptability to new domains and players.
8.3. General Principles of Operation
The OGC will follow principles of service engagement and operation as defined below.
-
OGC provides Engineering Services to all organizations.
-
OGC provides Engineering Services in a non-exclusive and non-discriminatory manner. If necessary, OGC staff is fire-walled to support as many OGC member organizations as possible.
-
OGC will notify the membership when a project is identified, as necessary, to avoid conflict of interest in engineering service provision as long as a contract does not require confidentiality. Such release may or may not include the organization or work details.
-
OGC will inform the Board of Directors Executive Committee, under Non-Disclosure Agreement, of planned/active Engineering Services.
-
Engineering Services will not involve in any assessment or recommendations regarding specific products and services.
-
As required, personnel involved in Engineering Services will sign non-disclosure agreements with contracting organizations to protect their intellectual property rights and trade secrets.
OGC subsidiaries also apply these principles according to the laws, customs, and procedures of their respective regions.
9. Approval of Initiatives
Every initiative that includes sponsors requires approval of the OGC COSI Review Board prior to its implementation. The OGC COSI Review Board is made up of all the leaders of the OGC. For initiatives without sponsors, an initiative review is provided by the OGC Architecture Board (OAB). Both review boards ensure that
-
The initiative is aligned with the OGC Technology Strategy, goals and policies;
-
The initiative is aligned with the OGC member interests;
-
The initiative can be completed in the time allocated;
-
The initiative can we be completed with expected resources within the time allocated; and
-
The initiative does not raise any ethical issues.
The ethics review focuses on issues as:
-
Human rights & protection of human beings
-
Data protection & privacy
-
Environmental protection
-
Malevolent use of research results
-
Compliance with international, EU & national law
10. Intellectual Property Rights
OGC Collaborative Solutions and Innovation initiatives shall be subject to the OGC COSI Intellectual Property Rights Rules.
Non-Disclosure and Public Discussions during an Initiative
All information generated and shared within an initiative must remain confidential until released through the OGC process, unless sponsors and the COSI TEAM agree on making the initiative publicly open. Interim work may be promoted or shared in a public forum if approved by Sponsors, Participants, and the COSI TEAM.
All Participants in an OGC initiative are encouraged to advertise their participation and have such information on their web sites or other public communications. As the initiatives do not represent consensus consortium positions, certain information must not be publicly-stated. The following items are acceptable to be announced publicly:
-
Statements that an organization has been selected and funded (if relevant) to participate in an initiative;
-
Statements that the initiative is underway and disclose the master schedule dates, e.g., “kickoff workshop in June”;
-
Quotes from the CFP with the qualification that initiative work items might change;
-
Statements that a Participant has contributed specific technical items to an initiative and those items are under consideration in the initiative; and
-
Links to the OGC page for the initiative.
The following items are topics that should not be discussed publicly by a Participant:
-
Statements that decisions have been made in the initiative regarding OGC standards and draft specifications; and
-
Disclosure of technical information put forward by Participants in the initiative, unless there is consensus among the group and approval by COSI TEAM to share this information.
11. Relevance to the OGC Standards Baseline
While the goal of OGC Collaborative Solutions and Innovation is the development and evaluation of technology to meet interoperability needs, the work must consider the existing OGC Standards Baseline. If the current Standards Baseline does not meet the requirements of the initiative, then new development should be pursued that may influence the development or revision of standards or Best Practices. One of the goals of COSI is to augment the OGC Standards Baseline. Engineering Reports resulting from an initiative are posted as pending documents for the OGC Standards Program to consider for approval as OGC documents per the procedures of the Standards Program.
The Standards Program is an important source for defining activities for experimentation in OGC Collaborative Solutions and Innovation initiatives. The Standards Program can use OGC Collaborative Solutions and Innovation to develop prototype specifications, to validate core concepts being considered in candidate standards, and to test interoperability amongst standards. Similarly, results of work completed in OGC Collaborative Solutions and Innovation may be considered for further development as a standard through assessment of Change Requests or Engineering Reports.
12. Miscellaneous
12.1. Announcements
All COSI Initiatives are announced to the OGC membership before the initiative begins. The pipeline of initiatives will be briefed to the OGC Planning Committee (PC) at each quarterly PC Meeting. Working Groups (WG) whose scope overlaps with the subject of an COSI initiative will be notified of the scope and potential deliverables of the initiative by the COSI Initiative Manager via OGC mailing lists or briefed at a Working Group meeting.
12.2. Initiative Page
Every initiative shall have its own landing page available at the OGC website. The page shall be created before or during the concept development phase. The page will capture:
-
Main Goal of the initiative;
-
Objectives of the initiative;
-
Schedule;
-
Links to Calls and Press Releases; and
-
Links to the other sources as relevant
12.3. Coordination
The OGC provides a framework that enables overall coordination between OGC Staff, OGC COSI TEAM, Sponsors, Participants, and other TC/PC Members as required. Initiative management includes the following activities.
-
Collaborative Environment - OGC provides synchronous and asynchronous collaboration environments for cross-organizational, globally distributed, virtual teams working interdependently to execute initiative orders. Activities include following virtual discussions (e.g., via email, Slack, Gitter, or issues discussion in tracking systems) and running regular teleconferences.
-
Management - The COSI TEAM performs the following management activities:
-
Ensures that the contracted deliverables (in the Statement of Work) are being made in a timely manner; and
-
Coordinates reports to the sponsors in frequent basis.
-
-
Communications - Includes drafting communication plans and performing outreach activities during the execution of the initiative. This activity also includes communicating ongoing and planned initiatives and work item status reports to OGC and other organizations such as other standards organizations or groups outside OGC upon request. This task does not include COSI business development functions.
-
Technology - OGC provides the following technical support to support the COSI Program:
-
Web sites;
-
Collaborative work sites including Wikis;
-
OGC content management tools;
-
Email reflector lists;
-
On-line project management tool: tasks, calendars, actions, etc.;
-
Code and document repositories such as e.g., Gitlab/Github; and
-
Teleconferencing lines.
-
12.4. Source Code
In general, the Participant Agreements will not require delivery of any component source code to OGC. What is delivered instead is the behavior of the component installed on the Participant’s machine and the corresponding documentation of findings, recommendations, and technical artifacts as contributions to the initiative’s Engineering Report(s).
In some rare cases, 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.
12.5. Release of Engineering Reports
Engineering Reports are member-privileged information and are not released outside of the membership unless a) the release is approved by OGC Staff for limited, non-public distribution or b) the document is made public by a motion and vote in the OGC Standards Program.
12.6. Open to Observers
Initiatives shall be open to OGC members as observers without exception. OGC members can observe any initiative free of charge. Non-member organizations are invited to join initiatives as observers at a fee. Any organizations can make a request to join an initiative with observer status at any point after the initiative has been announced. Depending upon sponsor requirements, there may be limitations on what data may be viewed by observers.
12.7. Status of Deliverables
The technical deliverables of an initiative shall not be construed to have any official status within the OGC. Specifically, documents that are generated within an initiative shall not be referred to as anything other than Engineering Reports (ERs). Status other than that can only be conferred by action of the OGC Technical and Planning Committees.
13. Reference Documents
The following resources and documents are referenced in this document. In all cases, the latest version of the referenced documents applies.
-
OGC Reference Model. http://www.opengeospatial.org/standards/orm
-
OGC COSI Intellectual Property Rights Rules https://www.ogc.org/ogc/policies/innovation-ipr.html
-
OGC Policies, in particular:
14. Revision History
Date | Version | Editor | Primary clauses modified and description |
---|---|---|---|
2005-11-01 |
0.1 |
George Percivall |
Initial Version |
2006-02-07 |
0.2 |
George Percivall |
Edits throughout |
2006-03-20 |
1.0 |
George Percivall |
Slight edits to release the document as approved by the SMAC, e.g., version number, dates, document references, etc. |
2010-8-23 |
2.0 |
George Percivall |
New Section 3 and 7. Edits throughout Added Section 3, “Technology Maturation Strategy.” Added Section 7, “Benefits of Interoperability Program” Edits by the OGC Interoperability Program Staff: Nadine Alameh, David Arctur, Raj Singh. |
2010-09-17 |
2.1 |
George Percivall |
Edits Review and edits by Carl Reed, Jim Stephens, Luis Bermudez. |
2011-07-22 |
2.2 |
George Percivall |
Edits in Policies section and throughout Added Policy regarding Standards Program coordination, including Change Requests Removed Plugfests, which are now in Compliance Program The OGC SMAC approved V2.2 during meeting on 2011-09-07 |
2014-02-26 |
2.3 |
Nadine Alameh |
Edits to Sec 4 Added Plugfests |
2015-04-13 |
2.3 |
Terry Idol, Ingo Simonis |
Edits to Sec 2 and 4 Added Engineering Services |
2019-08-07 |
3.0 |
Luis Bermudez |
folded all COSI initiatives and refractor the document |
2019-09-27 |
3.1 |
Luis Bermudez |
Updates based on OGC staff comments. |
2019-10-21 |
3.2 |
Luis Bermudez |
Updates figures to initiatives types. Added more details about Plugfests |
2019-10-25 |
3.3 |
Luis Bermudez |
Updates on the coordination section about manager roles, formatting of history table. |
2019-11-13 |
3.4 |
Luis Bermudez |
Changed in-kind sponsor to supporter, simplified TRL section, added more details about challenges, added section about approvals, and general edits. |
2019-11-14 |
3.5 |
Luis Bermudez |
Removed Eng Services for types, clarified roles in Challenges, added a new deliverable type (feedback to WG), added more internal links, clarified compliance needs in Plugfests |
2020-02-25 |
4.0 |
Ingo Simonis |
Full revision of the entire document |
2020-04-01 |
4.1 |
Ingo Simonis |
Sections 3: supporter further clarified, section 5.5 paragraph added, section 7 explanations added; figures 3 and 7 changes to caption |
2020-04-15 |
4.2 |
Ingo Simonis |
Abstract: Clarifications |
2020-04-20 |
4.3 |
Ingo Simonis |
Section 6.1: Clarification added that ERs may provide user guides or describe best practices for specific technologies |
2020-04-24 |
4.4 |
Ingo Simonis |
Section 8.3: Clarifications |
2020-06-02 |
4.5 |
Ingo Simonis |
Section 7: New logos |
2020-07-17 |
4.6 |
Ingo Simonis |
Sections 5.2, 8.1: Text modified to emphasize that Concept Development Studies can be executed as self-contained activities under the umbrella of Engineering Services. |
2020-11-09 |
4.7 |
Ingo Simonis |
Section 5: Introduction of high-level phases "Preparation" and "Implementation" to help differentiating the two phases with and without Participants |
2022-02-15 |
4.8 |
Ingo Simonis |
Section 12.6 changed |
2022-09-07 |
5.0 |
Ingo Simonis |
OGC Innovation Program renamed to OGC Collaborative Solutions and Innovation |
2023-02-28 |
5.1 |
Martin Klopfer |
Spellcheck |
2023-05-17 |
5.2 |
Ingo Simonis |
Section 9: Ethical review and composition of the OGC Review board added |