Table of Contents

1. Introduction

The Open Geospatial Consortium (OGC®) is releasing this Call for Participation ("CFP") to solicit proposals for the OGC UML-to-GML Application Schema Pilot 2020 (UGAS-2020) (also called "Pilot"). The goal of this Pilot is to advance the state-of-the-art in UML-to-GML Application Schema (UGAS) transformations and related technologies.

pilotLogo

To achieve these goals, the OGC UML-to-GML Application Schema Pilot 2020 (UGAS-2020) will improve and enhance the present capabilities of the open source tool ShapeChange with repository on Github in order to meet current and emerging technology requirements. These requirements fall into five areas, as follows:

  1. Develop JSON-based model implementations to enable enhanced support for NGA analytic tradecrafts, achieved through the addition of ShapeChange-based support for JSON-based data specification, exchange, and validation;

  2. Define and implement a JSON-based NSG core profile for key external community conceptual schemas, particularly those used to enable data discovery, access, control, and use in data exchange in the NSG;

  3. Develop enhancements to ShapeChange that enable the retention of UML model structure and accomplish improved error handling and reporting;

  4. Engineering analysis to determine the applications of Shapes Constraint Language (SHACL) expressions to validate linked data; and,

  5. Design an approach to generating OpenAPI definitions using the UGAS methodology and then using the NSG Application Schema (NAS) to implement that approach for the non-schema portions of an OpenAPI definition.

1.1. Background

This pilot supports one of the modernization goals for the National System for Geospatial Intelligence (NSG). The National Geospatial-Intelligence Agency (NGA) Future State Vision (FSV) has a stated goal for increased partnership with international, commercial, Intelligence Community, Department of Defense and academic institutions, and focuses NSG-wide analysis on unique and essential content creation. Critical to this goal is the establishment of GEOINT based Open Standards. The T Directorate, Architecture and Engineering Group (TA), Director and Chief of Enterprise Engineering Office (TAE) of the National Geospatial-Intelligence Agency (NGA) has the responsibility for evaluation, development and identification of standards supporting the Department of Defense (DoD)/Intelligence Community (IC) GEOINT requirements.

ShapeChange an open-source implementation of the UGAS methodology that has emerged as a key technological underpinning of the National System for Geospatial-Intelligence (NSG) GEOINT Content Semantics Resource (GCSR) Standards and their application to the issues of data standardization, validation, and exchange in the NSG.

International Organization for Standardization (ISO) 19109:2015 Geographic information – Rules for application schema Clause 2.3 UML application schema, defines a Unified Modeling Language (UML) metaschema for feature-based data. That General Feature Model (GFM) serves as the key underpinning for a family of ISO standards employed by members of the NSG community to define the structure and content of GEOINT data.

ISO 19136:2007 Geographic information – Geography Markup Language (GML) Annex E UML-to-GML application schema encoding rules, defines a set of encoding rules that may be used to transform a GFM-conformant UML concept model to a corresponding XML Schema (XSD) based on the structure and requirements of GML. The resulting XSD file(s) may be used to define the structure of, and validate the content of, XML instance documents used in the exchange of GEOINT data among systems in the NSG. This methodology for deriving technology-specific encodings of GFM-conformant UML concept models based on formalized sets of encoding rules has been successfully applied in other contexts than GML (e.g., technologies based on Resource Description Framework (RDF) encodings) and has come to be known generically known as “UGAS”.

1.2. OGC Innovation Program Initiative

This Pilot is being conducted under the OGC Innovation Program. The OGC Innovation Program provides a collaborative agile process for solving geospatial challenges. Organizations (sponsors and technology implementers) come together to solve problems, produce prototypes, develop demonstrations, provide best practices, and advance the future of standards. Since 1999 more than 120 initiatives have been conducted.

1.3. Benefits of Participation

This Initiative provides a unique opportunity to enhance the capabilities of automated model conversion with support for JSON, Shapes Constraint Language (SHACL) expressions to validate linked data, and OpenAPI definition generation using the UGAS methodology.

The outcomes are expected to shape the future of geospatial software development and data publication through enhanced model handling and processing. The sponsorship supports this vision with cost-sharing funds to largely offset the costs associated with development, engineering, and demonstration of these outcomes. This offers selected Participants a unique opportunity to recoup a high portion of their initiative expenses.

1.4. Master Schedule

The following table details the major Initiative milestones and events.

Table 1. Master schedule
Milestone Date Activity

M01

11 November 2019

Release of Call for Participation (CFP)

M02

17 December 2019

Responses due

M03

20 December 2019

Participant selection and agreements

M04*

03 or 07 Januar 2020

 Virtual kick-off meeting

M05*

31 March 2020

Report on UGAS OpenAPI design for use in OGC Testbed-16

M06*

31 March 2020

Initial ShapeChange enhancements for Testbed-16 usage

M07*

30 September 2020

Reference JSON Schema

M08*

30 November 2020

Final ShapeChange implementations and documentation

M09*

07 December 2020

Presentation of summarizing Engineering Report at Technical Committee meeting

M10*

15 December 2020

Participant(s) Summary Report(s) due

*Dates depend on incoming sponsor contracts and are subject to change.

2. Technical Architecture

This section provides the draft technical architecture and identifies all requirements and corresponding work items. It references the OGC Standards Baseline, i.e., the complete set of member approved Abstract Specifications, Standards including Profiles and Extensions, and Community Standards. Further information on the OGC standards baseline can be found online.

The goal of this Pilot is to advance the state-of-the-art in UML-to-GML Application Schema (UGAS) transformations and related technologies.

NGA uses ShapeChange and related open source tools to support the modeling of ISO 19109-conformant Application Schemas and from there derive a variety of profiles, apply model transformations, and produce technology-specific technical artifacts for use in a range of systems and applications. This pilot will implement enhancements to these tools to better support the needs of the Geospatial and NSG communities.

The capabilities of ShapeChange and its’ associated tools are not sufficient to meet the full range of NGAs’ technology requirements. NGA addresses this evolving shortfall through a series of incremental investigations, analyses, and prototype implementations. Each of these efforts address a portion of the backlog of technology requirements. Knowledge resulting from each increment shapes, focuses, and refines subsequent efforts.

The activities described in this section execute specific research and development efforts required in order to advance ShapeChange and its’ associated tools toward an objective system state that meets the needs of NGA and the NSG community. The present work builds on a previous body of work documented, in part, by the Engineering Reports identified in section Previous work. The pilot is organized in a number of tasks that define specific requirements. All tasks are described in section Pilot Tasks.

2.1. Previous Work

This Pilot builds on previous work from other OGC Innovation Program initiatives as well as OGC Standards Program efforts. The following documents serve as foundational references for this Pilot activity. Some items listed below are not yet released to the public. Draft versions of these documents can be made available on request. The final versions of these documents may change from the currently provided versions. Participants are advised to check the OGC website for updates on these documents.

  • OGC Testbed-14: Application Schema-based Ontology Development Engineering Report (OGC 18-032r2)

  • OGC Testbed-14: Application Schemas and JSON Technologies Engineering Report (OGC 18-091r2)

  • OGC Testbed-13: NAS Profiling Engineering Report (OGC 17-020)

  • OGC Testbed 12: ShapeChange Engineering Report (OGC 16-020)

  • OGC Testbed 9: System Security Interoperability (SSI) UML-to-GML-Application-Schema Conversion Engineering Report (OGC 12-093)

  • OGC OWS-8: CCI Schema Automation Engineering Report (OGC 11-064)

  • OGC OWS-7: Schema Automation Engineering Report (OGC 10-088)

2.2. Pilot Tasks

2.2.1. Task 1: Update and enhance the ShapeChange JSON Schema target based on JSON Schema version 2019-09.

Description

JSON Schema is a specification that enables the annotation and validation of JavaScript Object Notation (JSON) data instances. The intended use of JSON Schema is analogous to that of XML Schema, which is used to annotate and validate Extensible Markup Language (XML) data instances. Both XML and JSON data instances are used for data exchange in the NSG. The current ShapeChange target for deriving JSON Schema from an application schema in UML is restricted to producing JSON Schemas that correspond to GeoServices JSON feature data. The target produces schemas that comply with JSON Schema draft 03.

Since the development of the ShapeChange JSON Schema target in OGC Testbed 9 (OGC 12-093 OGC OWS-9 System Security Interoperability (SSI) UML-to-GML-Application-Schema Conversion Engineering Report), both ShapeChange and the JSON Schema specification have evolved significantly. The analysis of JSON Schema in OGC Testbed 14 (OGC 18-091r2 OGC Testbed-14: Application Schemas and JSON Technologies Engineering Report) has identified multiple areas of improvement for producing draft-07 JSON Schemas using ShapeChange. Additionally it is a known shortfall that the current ShapeChange JSON Schema target ignores mixin types and basic types.

Requirements

The Participant shall enhance the ShapeChange JSON Schema target to realize improvements based on the current JSON Schema 2019-09 specification and the analysis documented in OGC 18-091r2. The Participant shall add support for all types (to include special mixin and basic types) that occur in the NSG Application Schema (NAS). The Participant shall update the documentation published at https://shapechange.net/ to correspond with the enhanced software and process.

Deliverables

Enhanced ShapeChange software for the JSON Schema target.

2.2.2. Task 2: Improve ShapeChange to support the «propertyMetadata» property stereotype in the derivation of a JSON Schema

Requirements

Based on the results from the UGAS-2019 Pilot regarding the use and encoding of the NSG Application Schema (NAS) UML[propertyMetadata] stereotype, the Participant shall enhance the ShapeChange JSON Schema target to incorporate appropriate support for the UML[propertyMetadata] stereotype in application schemas. According to the analysis performed during the UGAS-2019 Pilot, a new ShapeChange model transformation will need to be implemented. The Participant shall update the documentation published at https://shapechange.net/ to correspond with the enhanced software and process. Execution of this task is dependent on the completion of Task 1.

Dependencies

Execution of this subtask is dependent on the completion of Task 1.

Deliverables

Enhanced ShapeChange software supporting the «propertyMetadata» property stereotype in the derivation of a JSON Schema.

2.2.3. Task 3: Define a NSG core profile for key community conceptual schemas, particularly those used to enable data discovery, access, control, and use

Description

Previous engineering reports (OGC 12-093 OGC OWS-9 System Security Interoperability (SSI) UML-to-GML-Application-Schema Conversion Engineering Report, and OGC 16-020 OGC Testbed 12: ShapeChange Engineering Report) recommended that JSON Schemas be developed for high-value ISO 19100-series conceptual schemas – or profiles of those conceptual schemas (e.g., ISO 19107 Geographic information – Spatial schema or ISO 19115 Geographic information – Metadata). Such JSON Schemas would facilitate interoperability in JSON-based data exchanges in general and in particular the JSON-based implementations of application schemas that rely on these ISO conceptual schemas, in particular those involving metadata such as the NSG Metadata Foundation (NMF).

An important issue with preparing JSON-based implementations of the comprehensive ISO 19100-series conceptual schemas is the significant implementation effort that is often difficult to justify since in practice only a small subset of the complete schema(s) are needed or used. For example, while Geography Markup Language (GML) implements only a subset of all curve segments or surface patches specified by ISO 19107, it is still a comprehensive subset and most of that subset is not, or is only very rarely, used in practice. To address this, the GML Simple Features Profile has been specified to identify a small subset that is sufficient for most use cases. Likewise, many of the metadata elements specified in the ISO 19139/19115-3 XML encoding standards are optional and not used in most metadata XML instance documents – and most communities have defined profiles of the comprehensive ISO metadata schemas to meet their narrower requirements.

Historically it has been the case that defining complete implementation schemas in XML Schema for these ISO standards, and then specifying a multiplicity of community-specific simpler, tailored profiles has limited the extent to which those complete implementation schemas are supported in software and thus contribute to effective interoperability.

The approach to generating JSON Schemas for these ISO standards should benefit from lessons learned with XML Schemas. These lessons include that the implementation schema should make use of the capabilities of the implementation language (e.g., XML Schema, JSON Schema) to represent the concepts in a developer-friendly way. An example in GML is how gml:posList implements a GM_PointArray from ISO 19107 with only direct positions, which is both a clearer and more efficient encoding.

Potential JSON-based implementation schemas for these ISO standards should consider other relevant conceptual schemas, in particular for concepts that are not specific to geographic data; for example, Data Catalog Vocabulary (DCAT) could be useful to specify dataset and distribution concepts as DCAT elements are understood by a larger community than that of geospatial data users.

Requirements

In close coordination with the Sponsor, the Participant shall identify a (simple) profile of ISO 19107, ISO 19108, ISO 19115-1/2 and ISO 19157 that is useful for a large number of use cases. For ISO 19107 the current Simple Feature geometries should be the starting point, for example, extended with arcs (as in GML Simple Features) and support for solids (3D). Either the first edition of ISO 19107 (from 2003) or the second edition (in publication) may be used to specify the profile of ISO 19107. The Participant shall consider other relevant conceptual schemas for concepts that are not specific to geographic data, e.g., DCAT. The definition of the profile shall consider NAS requirements based on spatial geometries, temporal information and metadata as it is typically included in existing NAS data. The results and recommendations from this investigation shall be documented in an Engineering Report.

Dependencies

Execution of this task may benefit from the completion of Task 1.

Deliverables

Documentation of a core profile of ISO 19107, ISO 19108, ISO 19115-1/2 and ISO 19157 that meets sponsor use-case requirements.

2.2.4. Task 4: Develop reference JSON Schema for the NSG core profile for key community conceptual schemas

Requirements

The Participant shall develop draft JSON Schemas for the profile specified in Task 3 taking into consideration the results of Task 1. In general priority should be given to (1) re-using established JSON encodings, where available, and (2) using optimized encodings, where this improves the usability (e.g., the existing geometry encodings of GeoJSON). The JSON schemas shall be specified in a manner that enables extensions to support additional information, but those extensions can be easily ignored by software implementations that are based strictly on the profile.

The draft JSON Schemas shall take into account that there are dependencies among various ISO conceptual schemas (and their existing XML Schemas). The profile and corresponding JSON Schemas shall either eliminate such dependencies (e.g., by excluding such elements from the profile) and/or manage the dependencies during the mapping to JSON Schema (e.g., Coordinate Reference System references could use URI identifiers or re-use the Well Known Text encoding).

The Participant shall develop sample data that illustrates all options included in the draft JSON Schemas. The Participant shall prepare to present the reference JSON Schemas along with their basis to applicable OGC working groups for potential use as a basis for adoption and standardization of the draft JSON Schemas. The results and recommendations from this development shall be documented in an Engineering Report.

Dependencies

Execution of this task is dependent on the completion of Task 1 and Task 3.

Deliverables

Reference JSON Schema for the NSG core profile determined in Task 3.

2.2.5. Task 5: Implement the preservation of UML package hierarchies when generating Enterprise Architect (EA) model files using ShapeChange

Description

The current ShapeChange implementation of the Enterprise Architect (EA) model file target only includes UML Packages which contain UML Classes; UML Packages that contain other UML Packages that contain UML Classes are dropped and the subordinate UML Package(s) "elevated" in the package hierarchy. The end result is a set of non-empty UML Packages all at a single level in the resulting EA model file regardless of their actual organization in the original UML model.

Requirements

The Participant shall enhance ShapeChange such that when generating an Enterprise Architect (EA) model file the existing UML Package hierarchy (e.g., as specified in ShapeChange XML) is retained where there is a leaf UML Package that is non-empty. It is desired that the ability to retain all UML Packages, regardless of their content, be supported by ShapeChange through a suitable configuration parameter. The Participant shall update the documentation published at https://shapechange.net/ to correspond with this enhancement.

Deliverables

Enhanced ShapeChange software preserving UML package hierarchies when generating Enterprise Architect (EA) model files.

2.2.6. Task 6: Implement improved error handling and reporting mechanisms in ShapeChange

Description

In the current ShapeChange, log messages that describe the process flow, e.g., that transformation (rule) or target xyz is being processed, are typically logged on INFO level. In the resulting log report, when only log level WARNING or ERROR is displayed, these process flow messages are no longer visible, making it difficult to determine at which point in the overall workflow a certain warning or error occurred. Furthermore, the current logging mechanism does not always log messages in the same order as they actually occur during processing; this can make debugging difficult.

One approach to improving the current situation is to treat process flow-related log messages separate from process-specific log messages. A new log level (or maybe multiple levels) should be introduced for process flow-related messages, and the log report should support enabling/disabling these process flow-related messages, independently from enabling/disabling process-specific log messages (so that a user who may not be interested in process flow messages can suppress them). See: https://github.com/ShapeChange/ShapeChange/issues/166

Requirements

The Participant shall enhance ShapeChange such that its logging mechanism distinguishes between process flow-related and process-specific messages, ensuring that they are kept in an order that directly reflects the sequence of ShapeChange actions and that the amount of logging for each of these two categories of messages can be independently determined. The Participant shall update the documentation published at https://shapechange.net/ to correspond with these enhancements.

Deliverables

Enhanced ShapeChange software implementing improved error handling and reporting mechanisms.

2.2.7. Task 7: Analyze the potential use of SHACL expressions ("shapes") to validate linked data

Description

The Shapes Constraint Language (SHACL) is designed for use in validating Resource Description Framework (RDF) graphs against a set of conditions. These conditions are provided as “shapes” and other constructs expressed in the form of an RDF graph. RDF is the standard description language for “linked data” and serves as the basis for other W3C Recommendations including Web Ontology Language (OWL) and Simple Knowledge Organization System (SKOS).

The use of SHACL in RDF-based validation of linked-data is described in OGC 16-020 OGC Testbed 12: ShapeChange Engineering Report, Section 1.3.3, Validation of RDF Data.

The potential use of SHACL in re-expressing NSG Application Schema (NAS) Object Constraint Language (OCL) constraints for use in validating NSG Enterprise Ontology (NEO) data instances is described in OGC 18-032r2 OGC Testbed-14: Application Schema-based Ontology Development Engineering Report, Section 1.2.2, Deriving SHACL with ShapeChange, along with Chapter 5: Conversion of OCL Constraints and Annex B: Conversion of NAS OCL Constraints to OWL

Requirements

The Participant shall leverage OGC 16-020 and 18-032r2 to perform an analysis of how validation of linked data conforming to a logical model, e.g., the NSG Application Schema (NAS), can be achieved using SHACL. Attention should also be given to the possibility of translating OCL expressions which cannot be translated to OWL (see 18-032r2 Annex B). The Participant shall determine if automatic derivation of SHACL validation constructs from a UML-based application schema is feasible and if so, define and document conversion rules by which such derivations could be obtained. The results and recommendations from this analysis shall be documented in an Engineering Report.

Deliverables

Documentation of an analysis of the potential use of SHACL expressions ("shapes") to validate linked data.

2.2.8. Task 8: Design an approach to generating OpenAPI definitions using the UGAS methodology

Description

The OpenAPI Specification defines a standard, programming language-agnostic interface description for Representational State Transfer (REST) APIs, which allows both humans and computers to discover and understand the capabilities of a web service. When properly defined via an OpenAPI definition, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.

An OpenAPI definition consists of multiple sections: info (service metadata); servers (base URL of servers supporting the API); paths (to resources and their HTTP methods); tags (used to group path entries); security (security requirements relevant for deployment); parameters (path and query parameters); and schemas. The schemas section specifies service interface schemas (e.g., as stated in OGC API specifications) at a minimum, but may also include content schemas (e.g., a feature model). Schemas of both types are specified using either a variant of JSON Schema or the YAML (“YAML Ain’t Markup Language”) data serialization language – effectively a superset of JSON.

The UGAS methodology for deriving technology-specific encodings of GFM-conformant UML concept models has direct application to the generation of OpenAPI content schemas. Task 1 enhances the legacy ShapeChange JSON Schema target to realize improvements based on the current JSON Schema specification.

A similar UGAS-based methodology can be used to generate documentation for service interfaces. An example application of this method has been prototyped using ShapeChange based on the OGC Web Feature Services 2.0 specification and PostgreSQL/PostGIS databases (see https://shapechange.net/targets/ldproxy/) . These non-content sections of the OpenAPI definition are determined by the OGC API specifications (e.g., paths, parameters) and deployment specific configurations (e.g., info, servers, security).

Pre-defined building blocks from the OGC API specifications may be extended or changed (for example, see draft OGC 17-069r2 OGC API - Features - Part 1: Core: http://docs.opengeospatial.org/DRAFTS/17-069r2.html#_references_to_openapi_components_in_normative_statements). Building blocks implemented by an API instance that are based on the OGC API specifications are determined by the selection of conformance classes that a given API should support (exclusive of any consideration for extensions or changes to the building blocks for that API instance).

The scope of this design task is restricted to the minimal solution for ShapeChange-based generation of OpenAPI definitions for sections other than that for content schemas. For example, the list of OGC API conformance classes might be manually specified using their URIs, in consequence of which a ShapeChange OpenAPI target might then create a minimal OpenAPI definition based on the default building blocks from the referenced OGC API specifications, with suitable placeholders for the interface specifications (e.g., paths, parameters) and deployment specific configurations (e.g., info, servers, security). The result would be an initial OpenAPI definition that will require some editing (either accomplished manually or perhaps by using a deployment specific script) before use.

As only Parts 1 (Core) and 2 (Extension for Coordinate Reference Systems (by reference)) of the draft OGC API Features specification are sufficiently stable for effective prototyping, this task is based on the building blocks identified in just those two specifications.

Requirements

The Participant shall determine all differences between the capabilities of the ShapeChange JSON Schema target implemented in Task 1 and the requirements of the OpenAPI Specification (currently Version 3.0.2; possibly Version 3.1 at the time of task execution), document those differences, and identify an approach to enabling the ShapeChange JSON target to generate OpenAPI-conformant content schemas. The Participant shall investigate alternative strategies for representing feature collections (e.g., whether to employ a path parameter to distinguish feature collections), recommend a strategy of greatest utility, and identify an approach to enabling the ShapeChange JSON target to generate corresponding content schemas. The Participant shall identify an extensible approach to enabling a ShapeChange OpenAPI target to generate a minimal solution for OpenAPI definition sections other than that for content schemas. The results and recommendations from these investigations shall be documented in an Engineering Report. A preliminary report on the UGAS OpenAPI target design shall be released for use in OGC Testbed-16, i.e. prior to April 2020.

Execution of this task is dependent on the completion of Task 1.

Deliverables

Documentation of an approach to generating OpenAPI definitions using the UGAS methodology.

2.2.9. Task 9: Implement the prototype ShapeChange Open API target design from Task 8

Requirements

Based on the design identified in Task 8, the Participant shall enhance the ShapeChange JSON Schema target to support the OpenAPI variant of JSON Schema (currently specified by https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#schema-object but possibly Version 3.1 at the time of task execution). Based on the design identified in Task 8 the Participant shall implement a prototype ShapeChange OpenAPI target capable of producing conformant OpenAPI Version 3.0.2 (possibly Version 3.1 at the time of task execution) documentation using JSON. The Participant shall release the prototype implementation for use in OGC Testbed 16. The implementation shall be available by April 2020.

Dependencies

Execution of this task is dependent on the completion of Task 8.

Deliverables

Enhanced ShapeChange software implementing the prototype ShapeChange Open API target design from Subtask 8.

2.2.10. Work Items & Corresponding Deliverables

The following figure illustrates the work items and deliverables of this initiative. Participants need to implement all tasks. Results of the tasks provided as deliverables. A summary report shall describe the initiative and its main outcomes in the OGC Engineering Report format.

deliverables
Figure 1. Work items (blue), deliverables (black: components, green: reports) of the OGC UML-to-GML Application Schema Pilot 2020 (UGAS-2020)

The following list identifies all work items that are part of this initiative. Detailed requirements are stated above. It is emphasized that due to the very tight correlation of the various tasks, bidders are requested to address all tasks in their proposals.

Engineering Reports

  • D001 UGAS-2020 Summary Report - Engineering Report capturing all results and experiences from this task.

Components & Documentation

  • D101: Task 1: Update and enhance the ShapeChange JSON Schema target based on JSON Schema version 2019-09 - as specified in Task 1.

  • D102: Task 2: Improve ShapeChange to support the «propertyMetadata» property stereotype in the derivation of a JSON Schema - as specified in Task 2.

  • D103: Task 3: Define a NSG core profile for key community conceptual schemas, particularly those used to enable data discovery, access, control, and use - as specified in Task 3.

  • D104: Task 4: Develop reference JSON Schema for the NSG core profile for key community conceptual schemas - as specified in Task 4.

  • D105: Task 5: Implement the preservation of UML package hierarchies when generating Enterprise Architect (EA) model files using ShapeChange - as specified in Task 5.

  • D106: Task 6: Implement improved error handling and reporting mechanisms in ShapeChange - as specified in Task 6.

  • D107: Task 7: Analyze the potential use of SHACL expressions ("shapes") to validate linked data - as specified in Task 7.

  • D108: Task 8: Design an approach to generating OpenAPI definitions using the UGAS methodology - as specified in Task 8.

  • D109: Task 9: Implement the generation of non-content-schema portions of an OpenAPI definition using ShapeChange - as specified in Task 9.

3. Deliverables Summary & Funding Status

The following table summarizes the full set of deliverables. It is expected that funding will be available for all work items. Currently, all work items are marked as funding pending due to outstanding contract from sponsor. Updates to sponsor status will be provided in section Corrigenda & Clarifications.

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

D001

ER

funding pending

D101

Component

funding pending

D102

Component

funding pending

D103

Component

funding pending

D104

Component

funding pending

D105

Component

funding pending

D106

Component

funding pending

D107

Component

funding pending

D108

Component

funding pending

D109

Component

funding pending

4. Miscellaneous

4.1. Call for Participation

The CFP consists of stakeholder role descriptions, proposal submission instructions and evaluation criteria, a master schedule and other project management artifacts, Sponsor requirements, and an initiative architecture. The responses to this CFP should include the proposing organization’s technical solution, cost-sharing requests for funding, and proposed in-kind contributions to the initiative.

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Corrigenda Table and the CFP Clarifications Table.

4.2. Participant Selection and Agreements

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk. Question submitters will remain anonymous and answers will be regularly compiled and published in the CFP Clarifications page.

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

Following the closing date for submission of proposals, OGC will evaluate received proposals, review recommendations with the Sponsor, 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.

4.3. Kick-off

The Kickoff is a virtual meeting (using GoToMeeting) where Participants, guided by the Initiative Architect, will refine the Initiative architecture and settle upon specific use cases and interface models to be used as a baseline for prototype component interoperability. Participants will be required to attend the Kickoff, including breakout sessions, and will be expected to use these breakouts to collaborate with other Participants and confirm intended Component Interface Designs.

4.4. Regular Teleconference and Interim Meetings

After the Kickoff, participants will meet on a frequent basis remotely via web meetings and teleconferences.

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

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

4.6. Final Summary Reports, Demonstration Event, and Other Stakeholder Meetings

Participant Final Summary Reports will constitute the close of funded activity. Further development work might take place to prepare and refine assets to be shown at the Demonstration Event and other stakeholder meetings.

4.7. Assurance of Service Availability

Participants selected to implement service components must maintain availability for a period of no less than six months after the Participant Final Summary Reports milestone. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

Appendix A: Pilot Organization and Execution

A.1. Initiative Policies and Procedures

This initiative will be conducted under the following OGC Policies and Procedures.

A.2. Initiative Roles

The roles generally played in any OGC Innovation Program initiative include Sponsors, Bidders, Participants, Observers, and the Innovation Program Team ("IP Team"). Explanations of the roles are provided in Annex: Tips for New Bidders.

The IP Team for this Initiative will include an Initiative Director and an Initiative Architect. Unless otherwise stated, the Initiative Director will serve as the primary point of contact (POC) for the OGC.

The Initiative Architect will work with Participants and Sponsors to ensure that Initiative activities and deliverables are properly assigned and performed. The Initiative Architect is responsible for scope and schedule control and will provide timely escalation to the Initiative Director regarding any severe issues or risks that happen to arise.

A.3. Types of Deliverables

All activities in this Pilot will result in a Deliverable. These Deliverables can take the form of Documents, Implementations, or Videos.

A.3.1. 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 (members-only) OGC Pending directory 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 for consideration by way of Standards Working Groups and Domain Working Groups.

A.3.2. Implementations

Services, Clients, Datasets, Schemas, API documentation, and Tools will be provided by methods suitable to each 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 client software is most often not delivered licensed 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.

A.3.3. Videos

Each participant shall develop and deliver or participate in the production of a short video that can be used in outreach activities on a royalty-free basis. The videos will be free and clear to be placed on the OGC YouTube Channel and Project page with no restrictions. The video shall illustrate the initial challenge(s) and developed solutions. The video can be done using screen-capturing of clients or slides with voice over. Good examples for videos are available from previous initiatives, such as Arctic Spatial Data Pilot (video 1, video 2), Vector Tiles Pilot (video), or Testbed-13 (video 1, video 2).

A.4. Proposals & Proposal Evaluation

Proposals are expected to be short and precisely addressing the work items a bidder is interested in. A proposal template will be made available. The proposal, including technical and financial details, has a page limit as defined in Appendix A. Details on the proposal submission process are provided in Appendix A: Proposal Submission Guidelines. The proposal evaluation process and criteria are described below.

A.4.1. Evaluation Process

Proposals will be evaluated according to criteria based on three areas: management, technical, and cost. Each review will commence by analyzing the proposed deliverables in the context of the Sponsor priorities, examining viability in light of the requirements and assessing feasibility against the use cases.

The review team will then create a draft Initiative System Architecture from tentatively selected proposals. This architecture will include the proposed components and relate them to available hardware, software, and data. Any candidate interface and protocol specification received from a Bidder will be included.

At the Technical Evaluation Meeting (TEM), the IP Team will present Sponsors with draft versions of the initiative system architecture and program management approach. The team will also present draft recommendations regarding which parts of which proposals should be offered cost-sharing funding (and at what level). Sponsors will decide whether and how draft recommendations in all these areas should be modified.

Immediately following TEM, the IP Team will begin to notify Bidders of their selection to enter negotiations for potentially becoming initiative Participants. The IP Team will develop for each selected bidder a Participant Agreement (PA) and a Statement of Work (SOW).

A.4.2. Evaluation Criteria

Management Criteria
  • Adequate, concise descriptions of all proposed activities, including how each activity contributes to achievement of particular requirements and deliverables. To the extent possible, it is recommended that Bidders utilize the language from the CFP itself to help trace these descriptions back to requirements and deliverables.

  • Willingness to share information and work in a collaborative environment.

  • Contribution toward Sponsor goals of enhancing availability of standards-based offerings in the marketplace.

Technical Criteria
  • How well applicable requirements in this CFP are addressed by the proposed solution.

  • Proposed solutions can be executed within available resources.

  • Proposed solutions support and promote the initiative system architecture and demonstration concept.

  • Where applicable, proposed solutions are OGC-compliant.

Cost Criteria
  • Cost-share compensation request is reasonable for proposed effort.

  • All Participants are required to provide at least some level of in-kind contribution (i.e., activities or deliverables offered that do not request cost-share compensation). As a rough guideline, a proposal 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. Participation may be fully in-kind.

A.5. Reporting

Initiative participant business/contract representatives are required (per the terms in the Participation Agreement contract) to report the progress and status of the participant’s work. Detailed requirements for this reporting will be provided during contract negotiation. Initiative accounting requirements (e.g., invoicing) will also be described in the contract.

The IP Team will provide progress reports to Sponsors. Ad hoc notifications may also occasionally be provided for urgent matters. To support this reporting, each Pilot participant must submit (1) a Technical Progress Report and (2) a Business Progress Report. Both reports shall be delivered every second month by the first working day on or after the 4th of that month. Templates for both of these report types will be provided and must be followed.

The purpose of the Business Progress Report is to provide initiative management with a quick indicator of project health from the perspective of each Pilot participant. The IP Team will review action item status on a weekly basis with the Initiative participants assigned to complete those actions. Initiative participants must be available for these contacts to be made.

Appendix B: Proposal Submission Guidelines

B.1. General Requirements

The following requirements apply to the proposal development process and activities.

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

  • Proposing organizations must be an OGC member and familiar with the OGC Mission, Vision, and Goals. Proposals from non-members will be considered, if a completed application for OGC membership or a letter of intent to become a member if selected for funding is submitted prior to or along with the proposal. If you are in doubt about membership, please contact OGC at techdesk@opengeospatial.org.

  • Proposals may address selected portions of the initiative requirements as long as the solution ultimately fits into the overall initiative architecture. A single proposal may address multiple requirements and deliverables. To ensure that Sponsor priorities are met, the OGC may negotiate with individual Bidders to drop, add, or change some of the proposed work.

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

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

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

  • Participants should remain aware of the fact that the Initiative 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 pure in-kind) must attend with at least one technical representative to the Kickoff. Participants are also encouraged to attend at least with one technical representative the Demonstration Event.

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

  • Information submitted in response to this CFP will be accessible to OGC staff members and to Sponsor representatives. 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 an Initiative Participant, it 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, in general, should not be disclosed during Initiative execution).

  • Bidders will be selected to receive cost sharing funds on the basis of adherence to the requirements (as stated in the CFP Appendix B Technical Architecture) 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 by addressing the stated CFP requirements on a purely in-kind basis.

  • Bidders are advised to avoid attempts to use the Initiative as a platform for introducing new requirements not included in the 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-scope might still be appropriate for inclusion in a later OGC Innovation Program initiative.

  • Each Participant (including pure in-kind Participants) that is assigned to make a deliverable 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. Each PA will include a statement of work ("SOW") identifying Participant roles and responsibilities.

B.2. What to Submit

The two documents that shall be submitted, with their respective templates are as follows:

A Technical Proposal should be based on the Response Template and must include the following:

  • Cover page

  • Overview (Not to exceed one page)

  • Proposed contribution (Basis for Technical Evaluation; not to exceed 1 page per work item)

  • Understanding of interoperability issues, understanding of technical requirements and architecture, and potential enhancements to OGC and related industry architectures and standards

  • Recommendations to enhance Information Interoperability through industry-proven best practices, or modifications to the software architecture defined in Appendix B: Technical Architecture

  • If applicable, knowledge of and access to geospatial data sets by providing references to data sets or data services

The Cost Proposal should be based on the two worksheets contained in the Cost Proposal Template and must include the following:

  • Completed Pilot Cost-Sharing Funds Request Form

  • Completed Pilot In-Kind Contribution Declaration Form

Additional instructions are contained in the templates themselves.

B.3. How to Transmit the Response

Guidelines:

  • Proposals shall be submitted to the OGC Technology Desk (techdesk@opengeospatial.org).

  • The format of the technical proposal shall be Microsoft Word or Portable Document Format (PDF).

  • The format of the cost proposal is a Microsoft Excel Spreadsheet.

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

B.4. Questions and Clarifications

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring this CFP.

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

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

Update to this CFP including questions and clarifications will be posted to the original URL of this CFP.

B.5. Tips for new bidders

Bidders who are new to OGC initiatives are encouraged to review the following tips:

  • In general, the term "activity" is used as a verb describing work to be performed in an initiative, and the term "deliverable" is used as a noun describing artifacts to be developed and delivered for inspection and use.

  • The roles generally played in any OGC Innovation Program initiative are defined in the OGC Innovation Program 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 solely in-kind contributions are also welcomed).

    • Participants are selected 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 might be receiving cost-share funding, but they can also make purely in-kind contributions. 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. Non-members are welcomed to submit proposals as long as the proposal is complemented by a letter of intent to become a member if selected for.

  • Any individual wishing to gain access to the Initiative’s intermediate work products in the restricted area of the Portal (or attend private working meetings / telecons) must be a member-approved user of the OGC Portal system. Intermediate work products that are intended to be shared publicly will be made available as draft ER content in a public GitHub repository.

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

  • The Sponsor(s) 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 subParticipants).

  • 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 deliverables. Participants in past initiatives have often been assigned to make only a single deliverable. At the other extreme, it’s theoretically possible that a single organization could be selected to make all available deliverables.

  • In general, the Participant Agreements will not require delivery 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 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 soon after CFP issuance. The webinar will be open to the public, but prior registration will be required.

Appendix C: Abbreviations

The following table lists all abbreviations used in this CFP.

API 

 Application Programming Interface

CDRL

Contract Data Requirements List

CFP

Call for Participation

COR

Contracting Officer’s Representative

CR

Change Request

DWG

Domain Working Group

ER

Engineering Report

GCSR

GEOINT Content Semantics Resource

GFM

General Feature Model

GML

Geography Markup Language

IP

Innovation Program

ISO

International Organization for Standardization

JSON

JavaScript Object Notation

NAS

NSG Application Schema

NGA

National Geospatial-Intelligence Agency

NSG

National System for Geospatial-Intelligence

OCL

Object Constraint Language

ODC

Other Direct Costs

OGC

Open Geospatial Consortium

OWL

Web Ontology Language

PA

Participation Agreement

POC

Point of Contact

PWS

Performance Work Statement

Q&A

Questions and Answers

RDF

Resource Description Framework

SOW

Statement of Work

SWG

Standards Working Group

TAES

GEOINT & IT Standards Division

TBD

To Be Determined

TC

OGC Technical Committee

TEM

Technical Evaluation Meeting

TIE

Technology Integration / Technical Interoperability Experiment

UGAS

UML-to-GML Application Schema

UML

Unified Modeling Language

URL

Uniform Resource Locator

WG

Working Group (SWG or DWG)

XML

Extensible Markup Language

Appendix D: Corrigenda & Clarifications

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.

Section Description

 — 

 — 

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

Question Clarification

 — 

 —