The OGC Abstract Specification is comprised of a number of Topic volumes. This document (Topic 0) is an overview of the OGC Abstract Specification. Each Topic addresses a specific set of abstract models, such as for metadata or geometry, as a foundation unit upon which to build OGC standards. The complete set of Topic volumes collectively form the OGC Abstract Specification[2].

OGC Abstract Specification Topics may originate from within the OGC membership or from another authoritative Standards Development Organization (SDO) or may be joint standards activities between OGC and the authoritative SDO. An authoritative SDO is an organization which operates on a consensus basis to develop standards.

The Abstract Specification is broken into Topics in order to enable parallel development and maintenance of different topics by different Standards Working Groups (SWGs) of the OGC membership. Figure 1 shows the Abstract Specification topics grouped into categories.

The current topic volumes are not all written at the same level of detail. Some are mature and some are less mature. Many have been harmonized with the work of ISO / TC 211 – Geographic Information/Geomatics ^[1]. The level of maturity of a topic reflects the level of understanding and discussion occurred within the Technical Committee, often in collaboration with ISO / TC 211. Refer to the OGC Technical Committee Policies and Procedures for more information on the OGC standards development process.

OGC Abstract Specifications are available at http://www.opengeospatial.org/standards/as.

In Sections 2.2 – 2.7, below, some Topic Names have no corresponding Topic Number: these Names are recommended for future approval as Abstract Specification Topics.

AS Topics related to space and time along with the group tasked with maintaining each standard are listed in the following table.

AS Topics related to features, coverages, and geometries along with the group tasked with maintaining each standard are listed in the following table.

AS Topic related to semantics along with the group tasked with maintaining each standard are listed in the following table.

AS Topics related to metadata and quality along with the group tasked with maintaining each standard are listed in the following table.

AS Topics related to sensors and observations along with the group tasked with maintaining each standard are listed in the following table.

AS Topics related to services and interfaces along with the group tasked with maintaining each standard are listed in the following table.

The purpose of the Abstract Specification is to create and document a conceptual model that enables the creation of the consistent, interoperable, and high-quality Implementation Standards.

Specific purposes of the Abstract Specification include:

The Abstract Specification is used in all of these capacities. Primarily, the Abstract Specification, while being implementation-neutral, provides robust technical concepts for discussing issues of interoperability.

The OGC recognizes that the standards it develops depend upon connections with other SDOs. This is exemplified in the Abstract Specification, where several Topics are developed and maintained by external organizations. Of particular note is the relationship between OGC and ISO / TC 211.

ISO / TC 211 is a de-jure^[2] SDO whose focus is in the field of digital geographic information. Their work aims to establish a structured set of standards for information concerning objects or phenomena that are directly or indirectly associated with a location relative to the Earth. These standards may specify, for geographic information, methods, tools, and services for data management (including definition and description), acquiring, processing, analyzing, accessing, presenting, and transferring such data in digital/electronic form between different users, systems, and locations. The work must provide links to appropriate standards for information technology and data where possible and provide a framework for the development of sector-specific applications using geographic data.

In the fall of 1998, OGC and ISO / TC211 signed an agreement establishing a Class A Liaison relationship that allows both organizations to take full advantage of the contributions of the other. Since then, the two organizations have collaborated in a number of areas. These include incorporating ISO / TC 211 documents as part of the OGC Abstract Specification as well as OGC providing OGC Implementation Standards to ISO for consideration for adoption as International Standards. The ISO / TC211-OGC coordinating group is called the Joint Advisory Group (JAG). This group meets during either or both OGC Technical Committee and ISO / TC 211 Plenary meetings.

OGC has formal relationships with other SDOs and recognizes that many fundamental principles which are part of the Abstract Specification originate and should be maintained outside the OGC. For instance, OGC Web Service standards rely upon basic web functions codified by the Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C). Thus, OGC Abstract Specification topics may originate in Authoritative Standards Organizations as defined in the OGC Technical Committee Policies and Procedures (TC PnP) [05-020r26 or later].

Each Abstract Specification Topic is approved by the OGC Technical Committee and Planning Committee for adoption. The Topic might originate from an external organization, in which case members of the OGC propose the Topic for inclusion. A Topic originating in the OGC will be worked through the SWG process per the TC PnP. All Abstract Specification Topics are voted for approval using the same processes as other OGC standards per the TC PnP.

The OGC Specification Model - A Standard for Modular specifications (08-131r3) – also referred to as the “Mod Spec” standard – specifies desirable characteristics of a standard that will encourage implementations by minimizing difficulty determining requirements, mimicking implementation structure, and maximizing usability and interoperability.

The Modular Specifications for Modular Systems ^[3] describes the logical structure behind the design of the OGC Mod Spec. The paradigm used during the writing of the specification was the view of writing a specification as part of a modular design. Most issues raised stem from a lack of understanding of the core paradigm explained in the Mod Spec standard.

Conceptual Modeling addresses the following questions.

Conceptual models are independent of implementation technology specifics.

Conceptual modeling provides these benefits:

The choice of a modeling approach is optional in OGC standards and best practices. The decision is up to a submission team or SWG. The Unified Modeling Language (UML) has been used successfully by many standards developers for conceptual modeling. The OpenAPI approach has been successful in defining APIs with multiple language bindings.

OGC recognizes that the best standards are as simple as possible. A luxury would be if “the simple standard” could always be the first standard developed. Ideally, standard development would iterate several standards based on use cases. Less complex use cases used to create simpler standards aimed at satisfying the largest user base possible; While also addressing the need for extensibility to address more comprehensive use cases. The OGC approach to this iterative development is based on the Abstract Specification and the Modular Specification.

The market has to innovate with freedom. Through standardization, multiple organizations facing the same problem solve it in the same way. When this does not occur, this result is a “tension” between the different alternatives. where a common set of requirements must be derived and be as inclusive as possible of the solutions, while still providing the least complex solution to the problem.

The approach of iterative development is reflected in Figure 1. The process recognizes the need for broad understanding of the scope of applications when developing a new standard. Complexity may be needed for some applications. “Simple” is defined based upon the problem a community is addressing. The iterative process develops a well-defined problem space with use cases and a roadmap for standard development. Then the standard developers and initial implementers can focus on “simple first.” This requires discipline to reduce the number the edge cases that are addressed in initial work. Focusing on the main cases while designing for extensibility is an art. A standard that prohibits restrictions as future extensions violates the OGC Modular Specification policy.

In 2014, the OGC Planning Committee endorsed this statement regarding innovation and the development of OGC Standards:

To support this challenging environment, OGC:

The Innovation Guidance impacts the Abstract Specification in two ways.

The OGC consensus process has resulted in the adoption of numerous Abstract Specification topic volumes (described above) and numerous implementation standards. Further, through the work of the membership, much of the ongoing effort of the OGC is harmonized with the work of other standards organizations, such as ISO, IETF, OASIS, and the W3C. In order to capture the essence of the work of the OGC in a structured manner, the OGC has developed and continues to maintain the OGC Reference Model (ORM)

The ORM supersedes the technology and architecture sections of the original 1996 OpenGIS Guide. The ORM provides an architecture framework and reference model that documents the current OGC Technical Baseline. The ORM also documents the current thinking regarding the technology and interoperability for on-going work in the OGC.

The ORM has the following purposes:

The ORM is based on the Reference Model for Open Distributed Processing (RM-ODP, ISO/IEC 10746), a widely used international standard for architecting open, distributed processing systems. The RM-ODP provides an overall conceptual framework for building distributed systems in an incremental manner. The ORM provides an overall conceptual framework for building geoprocessing into distributed systems in an incremental manner.

Regular updates of the ORM are required for maintenance in describing the OGC specifications.

All questions regarding this submission should be directed to the editor or the contributors: