Corrigenda

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

Section Description

no entries

Clarifications

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

Question Clarification

no entries

Abbreviations

The following table lists all abbreviations used in this CFP.

CFP

Call for Participation

CR

Change Request

DER

Draft Engineering Report

DWG

Domain Working Group

ER

Engineering Report

IP

Innovation Program

NAS

NSG Application Schema

NEO

NSG Enterprise Ontology

NSG

(US) National System for Geospatial Intelligence

OCL

Object Constraint Language

OGC

Open Geospatial Consortium

ORM

OGC Reference Model

OWS

OGC Web Services

PA

Participation Agreement

PMT

Profile Management Tool

POC

Point of Contact

Q&A

Questions and Answers

RM-ODP

Reference Model for Open Distributed Processing

SHACL

Shapes Constraint Language

SCXML

ShapeChange XML (model-exchange format)

SOW

Statement of Work

SWG

Standards Working Group

SWRL

Semantic Web Rule Language

TBD

To Be Determined

TC

OGC Technical Committee

TEM

Technical Evaluation Meeting

TIE

Technical Interoperability Experiment

UML

Unified Modeling Language

URL

Uniform Resource Locator

WFS

Web Feature Service

WPS

Web Processing Service

WG

Working Group (SWG or DWG)

1. Introduction

The Open Geospatial Consortium (OGC®) is releasing this Call for Participation ("CFP") to solicit proposals for the UML-to-GML Application Schema Pilot (UGAS-2019) Initiative ("Pilot" or "Initiative"). The goal of the initiative is to research and develop solutions for advanced schema mappings and related technologies from application schemas based on the Unified Modeling Language (UML) to ontologies based on the Web Ontology Language (OWL).

This initiative builds on previous OGC Testbed efforts to develop techniques and tools for the development of Resource Description Framework (RDF) based schemas from ISO 19109-conformant application schemas.

This is a research driven initiative. Requirements and tasks will be addressed in parallel or sequential order, depending on their complexity, dependency on other work items, and implementation effort. The specific order and rate of task execution would be negotiated at the kick-off meeting.

1.1. Background

Testbed-14 work on application schema conversion to OWL ontologies primarily focused on three aspects:

  • Analysis of the domain knowledge specified through Object Constraint Language (OCL) constraints in terms of logically-equivalent RDF/OWL expressions and axioms. Prior to Testbed14, the conversion process defined by ISO 19150-2 and extended in OGC Testbed-12 (for details, see OGC Testbed-12 ShapeChange Engineering Report) could transform an OCL constraint only to a simple OWL annotation property, with a textual value containing the constraint description. This information is primarily useful for human consumption. Testbed-14 therefore worked on the transformation of OCL constraints to OWL expressions and axioms to make the domain knowledge - originally encoded in OCL - machine-processable, specifically to reasoners. This helps improving inferencing results as well as the detection of inconsistencies in ontologies and RDF data.

  • Determination how to enrich an application schema to define property characteristics and relationships that can be expressed in OWL, but typically not in UML. Examples are sub-property relationships, and whether a property is symmetric. Through such property enrichment, the application schema modeling and implemented ShapeChange-based conversion process supports a set of OWL expressions and axioms that would otherwise need to be added to the generated ontologies as part of a manual post-processing step.

  • Enhancement of the conversion tool ShapeChange so that new RDF and/or OWL properties can be added to an OWL ontology that is derived from an application schema provided in UML. The resulting new RDF/OWL properties have been implemented with rdfs:subPropertyOf relationships.

The detailed results of this work are available in the OGC document 18-032r2, OGC Testbed-14: Application Schema-based Ontology Development Engineering Report. The ER builds upon, and extends, the analysis and implementation done in Testbed-12; documented in OGC Testbed-12 ShapeChange Engineering Report.

1.2. OGC Innovation Program Initiative

This Initiative 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 100 initiatives have been taking place from in-kind interoperability experiments run by a working group to multi-million dollar testbeds with hundreds of participants. Innovation Program initiatives include testbeds, interoperability experiments, pilots, concept development studies, hackathons, engineering services, and plugfests.

1.3. Benefits of Participation

This Initiative provides a unique opportunity to enhance the automated conversion of UML models to OWL. It allows influencing future standardization work in the form of enhanced conversion processes that will go into a new release of what is currently ISO 19150-2.

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.

2. Initiative Organization and Execution

2.1. Initiative Policies and Procedures

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

2.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"). Additional 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. They are 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.

2.3. Types of Deliverables

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

2.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. It is emphasized that almost documentation in this initiative will be provided as part of the current repository served as HTML pages at https://shapechange.net/. The initiative will provide a pro-forma Engineering Report that summarizes the activities and results briefly.

Note
Participants delivering Engineering Reports should also deliver Change Requests that arise from the documented work.

2.3.2. Implementations

Tools will be delivered in the form of free software, ideally under an Open Source license. All software requires appropriate documentation. A Client software application or component may be used during the Initiative to exercise services and components to test and demonstrate interoperability. This particular initiative requires the development and delivery of ShapeChange implementation supporting tasks 1-6, and the development and delivery of a Profile Management Tool implementation supporting tasks 7-8.

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

2.4.1. Evaluation Process

Proposals will be evaluated according to criteria that can be divided into three areas: Technical, management, 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.

At the Technical Evaluation Meeting (TEM), the IP Team will present Sponsors with 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 will also develop the Statement of Work (SOW) being part of the initiative Participant Agreement for each selected Bidder.

2.4.2. Management Criteria

  • Adequateness and quality of concise descriptions of all proposed activities, including how each activity contributes to achievement of particular 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

2.4.3. Technical Criteria

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

  • Proposed solutions could be executed within available resources

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

  • Where applicable, proposed solutions are OGC-compliant

2.4.4. 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 requesting no cost-share compensation).

2.5. Reporting

Initiative participant business/contract representatives are required (per a term 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 bi-monthly progress reports to Sponsors. Ad hoc notifications may also occasionally be provided for urgent matters. To support this reporting, each Initiative participant must submit (1) a bi-monthly Technical Progress Report and (2) a bi-monthly Business Progress Report by the first working day on or after the 5th of each month. Templates for both of these report types will be provided and must be followed.

The purpose of the Monthly Business Progress Report is to provide initiative management with a quick indicator of project health from the perspective of each Initiative 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.

3. Master Schedule

The following table details the major Initiative milestones and events. Dates are subject to change.

Table 1. Master schedule
Milestone Date  Event

M01

4 February 2019

Release of Call for Participation (CFP)

M02

4 March, 2019

Proposals due

M03

11 March 2019

Participant selection and agreements

M04

18 March 2019

Virtual Kick-off meeting (Go-To-Meeting)

M05

20 December 2019

Documentation and Engineering Report(s) due

M06

31 December 2019

All software and software documentation made available

M07

31 December 2019

Participant(s) Summary Report(s) due

3.1. Miscellaneous

Corrections and Clarifications

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.

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.

Kick-off: The Kickoff is a virtual meeting 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 together with Sponsors. 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.

Regular Teleconference and Interim Meetings After the Kickoff, participants will meet virtually in a frequent basis remotely via web meetings and teleconferences.

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 formed with selected Bidders, ALL Participants will be responsible for contributing content to the ERs. But the ER Editor role will assume the duty of being the primary ER author.

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.

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.

4. Deliverables

The following table summarizes the full set of Initiative deliverables. Technical details can be found in the Appendix B: Technical Architecture. It is emphasized that due to the very tight correlation of the various tasks, bidders are requested to address all reports and components in their proposals.

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

D001

ER

funded

D100

ShapeChange implementation with support for the ISO 19109 GFM «metaclass» ValueAssignment

funded

D101

ShapeChange implementation with improved XSD target to support property stereotypes

funded

D102

ShapeChange implementation with improved conversion of OCL constraints to Schematron assertions, using XSLT2

funded

D103

ShapeChange implementation and complete analysis of translating OCL constraints to OWL expressions

funded

D104

ShapeChange implementation with enhanced SCXML input (loader)

funded

D105

ShapeChange implementation with enhanced XML (SCXML) to support the lossless exchange of NAS content

funded

D106

Profile Management Tool implementation with improved handling of Association Classes

funded

D107

Profile Management Tool implementation with support for additional parameters ("keys")

funded

Appendix A: Proposal Submission Guidelines

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

A.2. What to Submit

The two documents that shall be submitted, with their respective templates are as follows: 1. Technical Proposal: https://portal.opengeospatial.org/files/?artifact_id=82493 2. Cost Proposal: https://portal.opengeospatial.org/files/?artifact_id=82494

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 Initiative Cost-Sharing Funds Request Form

  • Completed Initiative In-Kind Contribution Declaration Form

Additional instructions are contained in the templates themselves.

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

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

Appendix B: Technical Architecture

This appendix provides the technical architecture, which includes descriptions of the OGC baseline and identifies all requirements and corresponding work items.

B.1. Baseline Architecture

B.1.1. OGC Reference Model

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

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

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

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

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

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

refModel
Figure 1. Reference Model for Open Distributed Computing

The Engineering Viewpoint is concerned with the infrastructure required to support system distribution. It focuses on the mechanisms and functions required to:

  1. support distributed interaction between objects in the system, and

  2. hides the complexities of those interactions.

It exposes the distributed nature of the system, describing the infrastructure, mechanisms and functions for object distribution, distribution transparency and constraints, bindings and interactions. The engineering viewpoint will be developed during the Initiative, usually in the form of TIEs, where Participants define the communication infrastructure and assign elements from the computational viewpoint to physical machines used for demonstrating Initiative results.

B.1.2. OGC Standards Baseline

The OCG Standards Baseline is the complete set of member approved Abstract Specifications, Standards including Profiles and Extensions, and Community Standards.

OGC standards are technical documents that detail interfaces or encodings. Software developers use these documents to build open interfaces and encodings into their products and services. These standards are the main "products" of the Open Geospatial Consortium and have been developed by the membership to address specific interoperability challenges. Ideally, when OGC standards are implemented in products or online services by two different software engineers working independently, the resulting components plug and play, that is, they work together without further debugging. OGC standards and supporting documents are available to the public at no cost. OGC Web Services (OWS) are OGC standards created for use in World Wide Web applications. For this Testbed, it is emphasized that all OGC members have access to the latest versions of all standards. If not otherwise agreed with the Testbed architects, these shall be used in conjunction with - in particular - Engineering Reports resulting from previous Testbeds.

Any Schemas (xsd, xslt, etc.) that support an approved OGC standard can be found in the official OGC Schema Repository.

The OGC Testing Facility Web page provides online executable tests for some OGC standards. The facility helps organizations to better implement service interfaces, encodings and clients that adhere to OGC standards.

B.1.3. OGC Best Practices and Discussion Papers

OGC also maintains other documents relevant to Innovation Program initiatives, including Engineering Reports, Best Practice Documents, Discussion Papers, and White Papers.

B.2. Initiative Architecture

transformation

The goal of the initiative is to research and develop solutions for advanced schema mappings and related technologies from application schemas based on the Unified Modeling Language (UML) to ontologies based on the Web Ontology Language (OWL).

This initiative builds on previous OGC Testbed efforts to develop techniques and tools for the development of Resource Description Framework (RDF) based schemas from ISO 19109-conformant application schemas.

This is a research driven initiative. Requirements and tasks will be addressed in parallel or sequential order, depending on their complexity, dependency on other work items, and implementation effort. The specific order and rate of task execution would be negotiated at the kick-off meeting.

B.2.2. Requirements

The research and development activities in this initiative cover eight tasks in total. It is expected that proposals cover each of these eight tasks!

Task 1: Add ShapeChange support for the ISO 19109 GFM «metaclass» ValueAssignment

Description

The ISO 19109:2015 General Feature Model (GFM) defines the «metaclass» ValueAssignment, which in a UML Application Schema acts as a property stereotype. ISO 19109 identifies that OM_Observation (ISO 19156), LI_ProcessStep (ISO 19115-1), and MI_Event (ISO 19115-2) are all instances of this metaclass. Domain-specific Application Schemas may wish to employ these, or define and employ other, instances of this metaclass. The NSG Application Schema (NAS) will define a pair of new «AttMeta» and «RoleMeta» property stereotypes in its UML Profile whose behaviors are in accordance with «metaclass» ValueAssignment and are intended to be determined by corresponding UML Classes AttMeta and RoleMeta.

Requirement

The pilot shall analyze the implications of supporting «metaclass» ValueAssignment and then enhance new ShapeChange changes, to include the ShapeChange XML (SCXML) model-exchange format, as needed in order to flexibly enable the specification of the «AttMeta», «RoleMeta», and similar property stereotypes based on domain-specific requirements. The pilot shall update the documentation published at https://shapechange.net/ to correspond with these enhancements.

See https://shapechange.net/app-schemas/uml-profile/#Stereotypes for the current list of supported UML stereotypes.

Task 2: Development to improve the ShapeChange XML Schema target to support the «AttMeta» and «RoleMeta» property stereotypes

Requirement

The pilot shall design and develop a suitable model transformation and/or encoding rules based on the NSG Application Schema (NAS) «AttMeta» and «RoleMeta» property stereotypes whose result is equivalent, but possibly not identical, to the current NAS XML Schema encoding. This process shall take into account property-specific OCL constraints, possibly requiring that they be transformed in order to remain valid with respect to the revised model. This process shall also be valid for use in the case that the ShapeChange Flattener transform is employed (e.g., in the case of a GML-SF0-conformant encoding). The pilot shall update the documentation published at https://shapechange.net/ to correspond with the enhanced software and process. Execution of this subtask is dependent on the completion of task 1.

Task 3: Development to improve the ShapeChange conversion of OCL constraints to Schematron assertions, using XSLT2

Description

OGC Testbed-14: Application Schema-based Ontology Development Engineering Report (OGC 18-032) documents recommendations for writing OCL constraints that are intended to be translated to OWL expressions. A major aspect of those recommendations is to significantly increase the use of quantifications (exists(…) and forAll(…)) in OCL expressions. These quantifications are readily supported by OWL, however extensive use of such quantifications can be an issue for the translation to Schematron based on XSLT1 - which is what the OCL to Schematron conversion of ShapeChange currently supports. The reason is that Schematron with the XSLT1 query binding does not directly support quantifications. More specifically: XPath 1.0, which is used by XSLT1 and thus also used to define Schematron assertions, does not support them.

The conversion by ShapeChange represents quantifications through equivalent XPath expressions:

x → exists(t|b(t)) is represented by an XPath expression like: boolean(τ(x)[τ(b(.))])

x → forAll(t|b(t)) is represented by an XPath expression like: count(τ(x))=count(τ(x)[τ(b(.))])

Especially the representation of forAll(…) can quickly lead to highly complex and potentially inefficient XPath expressions; a chain of forAll(…) statements would result in a deeply nested tree of count expressions. The situation could significantly be improved if XSLT2 was used as Schematron query binding, since XPath 2.0 directly supports quantified expressions.

Requirement

The pilot shall enhance the current OCL constraint to Schematron assertion conversion capability of ShapeChange to perform the conversion to Schematron based on XSLT2 instead of XSLT1. The pilot shall update the documentation published at https://shapechange.net/ to correspond with this enhancement.

Task 4: Complete the analysis of translating OCL constraints to OWL expressions

Description

Testbed-14 included a requirement for the pilot to “Extend ShapeChange to support transformation of NAS OCL Constraints into OWL, SHACL and/or SWRL (or other ontology rule language) encodings to be used with NEO.” The results from this effort are documented in Section 5 of the Testbed-14 Application Schema-based Ontology Development Engineering Report (OGC 18-032). The pilot found that conversion of OCL to OWL is not as simple a process as had been originally anticipated. Rather, each OCL construct must be individually analyzed and the rules for its’ proper translation derived. OGC 18-032 describes the translation rules for twenty-one (21) OCL constructs used in the NAS. It also identifies seven (7) OCL constructs for which translation is not possible and an explanation of why. Due to the unanticipated complexity of this effort, not all fifty-four (54) OCL constructs used by the NAS could be evaluated.

Requirement

The pilot shall complete the analysis of the translation of the remaining 26 types of OCL constraint to OWL class expressions (see table below). A maximum of six additional types of OCL constraints (to be determined by NGA) may be added to the specified analysis of 26 types. The pilot shall update the documentation published at https://shapechange.net/ to include the results of their analysis.

Table 3. Types of OCL constraints. Section references OGC document 18-032r2, OGC Testbed-14 Application Schema-Based Ontology Development Engineering Report
Number Section Description

1

B.1.8

Property Co-constraint (conditional populated)

2

B.1.10

Property Co-constraint (related entity)

3

B.1.14

Property Complex Type (required listed value)

4

B.1.15

Property Complex Type (well-formed)

5

B.1.19

Property Numeric Range (array)

6

B.1.20

Property Numeric Range (conjunct)

7

B.1.21

Property Required (conditional on related entity, exact listed value)

8

B.1.22

Property Required (conditional, exact listed value, no meta)

9

B.1.23

Property Required (minimum listed value)

10

B.1.25

Property String Length (equal)

11

B.1.26

Property String Length (maximum)

12

B.1.27

Property String Length (complex array)

13

B.1.28

Property String Length (simple array)

14

B.1.29

Property Value Metadata

15

B.1.30

Property Values Count

16

B.1.31

Property Values Metadata

17

B.1.32

Related Entity Property Excluded (multiple)

18

B.1.33

Related Entity Property Excluded (single)

19

B.1.34

Related Entity Property Required

20

B.1.35

Related Entity Property Value (conditional, restricted)

21

B.1.36

Related Entity Property Value (conditional, restricted, array)

22

B.1.37

Related Entity Property Value (guard, conditional, restricted)

23

B.1.38

Related Entity Property Value (specific)

24

B.1.39

Related Entity Required

25

B.1.40

Related Entity Required (at least one)

26

B.1.47

Related Entity, Related Entity Property Required

Task 5: Development to deliver new enhancements of the ShapeChange XML (SCXML) to support the lossless exchange of NAS content

Description

SCXML serves as the representation of the NSG Application Schema (NAS) through all stages of ShapeChange-based transformation. It is essential that this representation is complete and that no information is lost during ShapeChange-based transformation. The prototypical use-case is the generation of Enterprise Architect model files based on either the full the NSG Application Schema (NAS) (as input via the GSIP loader) or a subset of the NAS. A potential example shortfall is the preservation in SCXML of information regarding non-navigable association roles in the NAS.

Requirement

In close coordination with NGA, investigate the use of SCXML for the lossless representation of the NSG Application Schema (NAS) at all stages of ShapeChange-based transformation (e.g., after application of the Profiler). Where shortfalls are identified, the pilot shall enhance the SCXML schema and/or SCXML-related processing. The pilot shall update the documentation published at https://shapechange.net/ to correspond with these enhancements.

Task 6: Develop to deliver new enhancements of the ShapeChange XML (SCXML) input loader

Description

Currently, loading content from an SCXML document into ShapeChange ignores most input configuration parameters and elements.

Requirement

The pilot shall enhance ShapeChange such that loading from SCXML supports the "standard" input configuration parameters and elements; for example, input parameters such as "checkingConstraints" should be honored. The pilot shall update the documentation published at https://shapechange.net/ to correspond with these enhancements.

Task 7: Development to deliver an improved PMT handling of Association Classes

Description

In the Profile Management Tool (PMT) if an association class is removed from the profile, the corresponding association (and roles) should be removed as well. Similar considerations apply when adding an association class. Association class management by the PMT shall be a superset of the logical union of the capabilities for management of UML Classes and UML Associations.

Requirement

The pilot shall enhance the PMT to address each of these concerns regarding support for Association Classes. The pilot shall update the documentation published at https://shapechange.github.io/ProfileManagementTool/ to correspond with these enhancements. For additional information, see OGC document 17-020r1, OGC Testbed-13 NAS Profiling Engineering Report, Section 1.5.4. (Extending the feature set for application schema profiling).

Task 8: Develop an implementation PMT support for additional parameters ("keys")

Requirement

The pilot shall develop a new implementation parameters of the Profile Management Tool (PMT) design developed in Testbed 12 (see OGC 16-020, Testbed 12 ShapeChange Engineering Report, chapter 7) as regards support for additional profile parameters. These included all five types of metadata handling (isAbstract, multiplicity, isOrdered, isUnique, isNavigable). The pilot shall update the documentation published at https://shapechange.github.io/ProfileManagementTool/ to correspond with these enhancements. For additional information, see OGC document 17-020r1, OGC Testbed-13 NAS Profiling Engineering Report, Section 1.5.4. (Extending the feature set for application schema profiling).

B.2.3. Work Items & Deliverables

The following figure illustrates the work items and deliverables of this initiative.

deliverables

The following list identifies all deliverables 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-2019 Summary Report - Engineering Report capturing all results and experiences from this task.

Components

  • D100 - Support for the ISO 19109 GFM «metaclass» ValueAssignment - ShapeChange research and implementation as defined by task 1

  • D101 - Improved XSD target to support property stereotypes - ShapeChange research and implementation as defined by task 2

  • D102 - Improved conversion of OCL constraints to Schematron assertions, using XSLT2 - ShapeChange research and implementation as defined by task 3

  • D103 - Complete analysis of translating OCL constraints to OWL expressions - ShapeChange research and implementation as defined by task 4

  • D104 - Enhanced SCXML input (loader) - ShapeChange research and implementation as defined by task 5

  • D105 - Enhanced XML (SCXML) to support the lossless exchange of NAS content - ShapeChange research and implementation as defined by task 6

  • D106 - Improved handling of Association Classes - Profile Management Tool research and implementation as defined by task 7

  • D107 - Support for additional parameters ("keys") - Profile Management Tool research and implementation as defined by task 8

Appendix C: 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 a Testbed 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 thirdparty subpilots).

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