Open Geospatial Consortium

Submission Date: <yyyy-mm-dd>

Approval Date:  <yyyy-mm-dd>

Publication Date:  <yyyy-mm-dd>

External identifier of this OGC® document: http://www.opengis.net/doc/IS/ogcapi-features-5/1.0

Internal reference number of this OGC® document:    23-058r1

Version: 1.0.0-draft.2

Latest Published Draft: n/a

Category: OGC® Implementation Standard

Editors: Clemens Portele, Panagiotis (Peter) A. Vretanos

OGC API - Features - Part 5: Schemas

Copyright notice

Copyright © 2024 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:    OGC® Standard

Document subtype:    Interface

Document stage:    Draft

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

i. Abstract

OGC API Standards define modular API building blocks to spatially enable Web API implementations in a consistent way. The OpenAPI specification is used to define the API building blocks.

OGC API - Features Standard defines building blocks to create, modify and query features on the Web. The OGC API - Features Standard is comprised of multiple parts. Each part is a separate standard.

The OGC API - Features - Part 5: Schemas Standard (hereafter also referred to as "this Standard" or "this document") specifies how geospatial data such as features can be described by a logical schema and how such schemas are published in an OGC Web API implementation.

As logical schemas, the schemas describe the data independent of a particular format to represent the data.

To use a schema for data validation, the schema must be converted into a schema representation suitable for validating data in the specific data format. For example, an XML Schema that is a GML application schema or a JSON Schema for GeoJSON or the draft OGC Features and Geometries JSON (JSON-FG).

While the schema is a logical schema, a machine-readable representation is needed. Instead of specifying a custom schema language for geospatial data, this Standard uses JSON Schema as the schema language with:

  • Extensions for additional aspects that are common in geospatial data; and

  • Recommendations for restricting the use of JSON Schema capabilities in order to simplify parsing a schema.

That is, JSON Schema is primarily used as a data description language.

The main reasons for using JSON Schema are:

  • Web developers are often familiar with JSON Schema and JSON;

  • JSON data types (string, number, boolean, array, object, null) are simple and easy to understand; and

  • JSON is often used for encoding geospatial data, i.e., the schema of a property can be used to validate property values without conversion.

This Standard first specifies basic provisions for schemas that are applicable to any type of geospatial data. These provisions are not specific to features and as such could be moved to OGC API - Common in the future.

Additional provisions are added for schemas for feature data as well as provisions for references to other features.

In OGC Web APIs, geospatial data is shared in collections (path /collections/{collectionId}). The schema of items in a collection provides information as to how to interact with the collection.

Examples of interactions, where information about the schema are required, include:

  • An application that wants to fetch data often needs information about the properties included in the data to process, present, or store the data properly ("returnable" properties or "Returnables").

  • An application that wants to fetch data restricted to a subset of the available properties needs the list of the properties in the data (again, "returnable" properties or "Returnables").

  • An application that wants to fetch a subset of the data needs information about the properties that can be used to filter the data ("queryable" properties or "Queryables").

  • An application that wants to fetch data in a specific order needs information about the properties that can be used to sort the data ("sortable" properties or "Sortables").

  • An application that wants to create or update data needs information about the required or acceptable properties of the data ("receivable" properties or "Receivables").

This Standard specifies the schema resources listed in Table 1 to support these interactions.

Table 1. Overview of resources, applicable HTTP methods and links to the document sections
Resource Path HTTP method Document reference

Returnables and Receivables

/collections/{collectionId}/schema

GET

Requirements Class "Returnables and Receivables"

Queryables

/collections/{collectionId}/queryables

GET

Requirements Class "Queryables"

Sortables

/collections/{collectionId}/sortables

GET

Requirements Class "Sortables"

Finally, the query parameter profile is specified to support requesting variations in the representation of data in the same feature format, depending on the intended use of the data.

Three profiles are specified how to encode a reference to another feature: by the featureId of the referenced feature, by its URI, or as a web link.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

OGC, schema, JSON Schema, OGC API, features, queryables, sortables, returnables, receivables

iii. Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

The following organizations submitted this document to the Open Geospatial Consortium (OGC):

  • CubeWerx Inc.

  • interactive instruments

v. Submitters

All questions regarding this submission should be directed to the editors or the submitters:

Name

Affiliation

Panagiotis (Peter) A. Vretanos (editor)

CubeWerx Inc.

Clemens Portele (editor)

interactive instruments

1. Scope

This Standard specifies an extension to the OGC API - Features - Part 1: Core Standard that defines the behavior of a server that provides information about the schema of the geospatial data, for example, of the features in each collection.

This document specifies:

  • Schemas describing geospatial data; and

  • API building blocks for the support of schemas describing geospatial data in deployed Web APIs implementing one or more OGC API requirements classes.

2. Conformance

This Standard defines the following requirements classes, grouped by their standardization target type:

Conformance with this Standard shall be checked using all the relevant tests specified in Annex A of this document for each conformance class. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

Table 2. Conformance class URIs
Conformance class URI

Schemas

http://www.opengis.net/spec/ogcapi-features-5/1.0/conf/schemas

Core roles for features

http://www.opengis.net/spec/ogcapi-features-5/1.0/conf/core-roles-features

Feature references

http://www.opengis.net/spec/ogcapi-features-5/1.0/conf/feature-references

Returnables and Receivables

http://www.opengis.net/spec/ogcapi-features-5/1.0/conf/returnables-and-receivables

Queryables

http://www.opengis.net/spec/ogcapi-features-5/1.0/conf/queryables

Sortables

http://www.opengis.net/spec/ogcapi-features-5/1.0/conf/sortables

Profile query parameter

http://www.opengis.net/spec/ogcapi-features-5/1.0/conf/profile-parameter

Profiles for feature references

http://www.opengis.net/spec/ogcapi-features-5/1.0/conf/profile-references

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

4. Terms, Definitions, Symbols and Abbreviated Terms

4.1. Terms and Definitions

This document used the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the 'ModSpec'. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

collection

a body of resources that belong or are used together; an aggregate, set, or group of related resources (OGC API - Common - Part 2: Collections).

endpoint

a web address (URI) at which access can be gained to a service or resource

<JSON> key

the name of a member

<JSON> member

a name/value pair in a JSON object

logical model

an abstracted representation of domain knowledge that could feasibly be used in Model Driven Architecture to generate physical artifacts (OGC Conceptual Modeling Discussion Paper)

OGC Web API

A Web API that implements one or more Conformance Classes from an OGC API Standard (OGC API - Features - Part 1: Core)

primary geometry

the geometry that the publisher considers as the most important spatial characteristic of a feature

Note
 A feature can be described by multiple spatial properties. For example, a radio tower can have a property with a point value that describes the location of the tower and another property with a multi-polygon value that describes the area of coverage. Some feature formats can represent only a single geometry per feature. In those cases, the primary geometry will be used when the feature is encoded in such a format.
Note
 The primary geometry of a feature can also vary depending on the zoom level. At a smaller scale, the primary geometry could be a point while a polygon could be used at a larger scale.
primary temporal information

the time instant or time interval that the publisher considers as the most important temporal characteristic of a feature

Note
 A feature can be described by multiple temporal properties. For example, an event can have a property with an instant or interval when the event occurred or will occur and another property when the event was recorded in the dataset. The primary temporal information can also be built from two properties, e.g., when the feature has two properties describing the start and end instants of an interval.
publisher

entity responsible for making a resource available (Dublin Core Metadata Initiative - DCMI Metadata Terms)

Note
 As content of OGC API standards, a resource is typically published at an endpoint.
queryable

the name of a property of a resource that can be used in a filter expression

receivable

the name of a property of a web resource that can be included in representations of the resource when creating or updating a resource

resource

entity that might be identified (Dublin Core Metadata Initiative - DCMI Metadata Terms)

Note
 The term "resource", when used in the context of an OGC API standard, should be understood to mean a web resource unless otherwise indicated.
returnable

the name of a property of a web resource that is available in representations of the resource when fetching the resource

sortable

the name of a property of a resource that can be used to sort resources of the same type

web resource

a resource that is identified by a HTTP URI (OGC API - Features - Part 1: Core)

4.2. Abbreviated terms

API

Application Programming Interface

HTTP

Hypertext Transfer Protocol

HTTPS

Hypertext Transfer Protocol Secure

IANA

Internet Assigned Numbers Authority

JSON

JavaScript Object Notation

OGC

Open Geospatial Consortium

URI

Uniform Resource Identifier

YAML

YAML Ain’t Markup Language

5. Conventions

5.1. General remarks

See OGC API - Features - Part 1: Core, Clauses 5 and 6.

5.2. Identifiers

The normative provisions in this Standard are denoted by the URI http://www.opengis.net/spec/ogcapi-features-5/1.0.

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

5.3. Additional link relation types

The following OGC link relation types are introduced in this document (no applicable link relation type in the IANA link relation type register could be identified):

  • http://www.opengis.net/def/rel/ogc/1.0/schema: Refers to a resource that lists the properties of geospatial data in the collection represented by the link’s context.

  • http://www.opengis.net/def/rel/ogc/1.0/queryables: Refers to a resource that lists properties that can be used to filter sub-resources of the link’s context.

  • http://www.opengis.net/def/rel/ogc/1.0/sortables: Refers to a resource that lists properties that can be used to sort sub-resources of the link’s context.

As an alternative, the Compact URI (CURIE), e.g., [ogc-rel:schema], can also be used when a CURIE is an allowed value.

Note
 This link relation type needs to be registered in the OGC Link Relation Type Register as well as in the OGC CURIE Register. This note has to be removed before publication.

5.4. HTTP URIs

If URIs include reserved characters that are delimiters in the URI subcomponent, these must be percent-encoded. See Clause 2 of RFC 3986 Uniform Resource Identifier (URI): Generic Syntax for details. Not all URIs in this document are properly percent-encoded for better readability.

6. Overview

This Standard specifies two types of requirements classes.

6.1. Requirements and recommendations for schemas

The schemas describing geospatial data specified by this Standard are logical schemas describing the data, independent of a particular format to represent the data.

In order to use the schema for data validation, the schema first has to be converted into a schema representation suitable for validating data in the specific data format. For example, an XML Schema that is a GML application schema or a JSON Schema for GeoJSON or JSON-FG.

While the schema is a logical schema, a machine-readable representation is needed. Instead of specifying a custom schema language for geospatial data, this Standard uses JSON Schema as the schema language with:

  • Extensions for additional aspects that are common in geospatial data,

  • Recommendations for restricting the use of JSON Schema capabilities to simplify parsing a schema.

That is, JSON Schema is primarily used as a data description language.

The main reasons for using JSON Schema are:

  • Web developers are often familiar with JSON Schema and JSON;

  • JSON data types (string, number, boolean, array, object, null) are simple and easy to understand; and

  • JSON is often used for encoding geospatial data, i.e., the schema of a property can be used to validate property values without conversion.

6.2. Requirements and recommendations for schemas in OGC Web APIs

These requirements classes specify API building blocks related to schemas.

In OGC Web APIs, geospatial data is shared in collections (path /collections/{collectionId}). The schema of items in a collection provides information about how to interact with the collection.

Examples of interactions, where information about the schema are required, include:

  • An application that wants to fetch data often needs information about the properties included in the data to process, present, or store the data properly ("returnable" properties or "Returnables").

  • An application that wants to fetch data restricted to a subset of the available properties needs the list of the properties in the data (again, "returnable" properties or "Returnables").

  • An application that wants to fetch a subset of the data needs information about the properties that can be used to filter the data ("queryable" properties or "Queryables").

  • An application that wants to fetch data in a specific order needs information about the properties that can be used to sort the data ("sortable" properties or "Sortables").

  • An application that wants to create or update data needs information about the required or acceptable properties of the data ("receivable" properties or "Receivables").

This Standard specifies the following schema resources to support these interactions.

  • Returnables and Receivables at path: /collections/{collectionId}/schema

  • Queryables at path /collections/{collectionId}/queryables

  • Sortables at path /collections/{collectionId}/sortables

7. Requirements Class "Schemas"

The Requirements Class "Schemas" specifies basic provisions for schemas of items in a collection of geospatial data, such as features, and the representation of a schema in JSON Schema. The schema represents a logical model, independent of the format in which the feature is encoded.

Requirements Class

http://www.opengis.net/spec/ogcapi-features-5/1.0/req/schemas

Target type

Web resource

Dependency

JSON Schema: A Media Type for Describing JSON Documents

Indirect Dependency

JSON Schema Validation: A Vocabulary for Structural Validation of JSON

Indirect Dependency

Simple feature access - Part 1: Common architecture

Indirect Dependency

The Unified Code for Units of Measure

Indirect Dependency

QUDT Units Vocabulary

7.1. Schema representation

Requirement 1

/req/schemas/json-schema

A

The schema SHALL be a valid JSON Schema.

B

The schema SHALL have the following characteristics:

  • "$schema" is "https://json-schema.org/draft/2020-12/schema";

  • "$id" is a HTTP(S) URI without query parameters that returns the schema, if requested with the header "Accept: application/schema+json"; and

  • "type" is "object".

In addition to the JSON Schema data types, geospatial data typically also uses spatial and temporal data types.

Requirement 2

/req/schemas/properties

A

Each property SHALL include a "type" member, except for spatial properties.

B

Each spatial property SHALL not include a "type" or "$ref" member.

C

Each spatial property SHALL include a "format" member with a string value "geometry", followed by a hyphen, followed by the name of the geometry type in lower case. I.e., the values for the Simple Feature geometry types are: "geometry-point", "geometry-multipoint", "geometry-linestring", "geometry-multilinestring", "geometry-polygon", "geometry-multipolygon", and "geometry-geometrycollection". In addition, the following special values are supported: "geometry-any" as the wildcard for any geometry type, "geometry-point-or-multipoint" for a Point or MultiPoint, "geometry-linestring-or-multilinestring" for a LineString or MultiLineString, and "geometry-polygon-or-multipolygon" for a Polygon or MultiPolygon.

D

Each temporal property SHALL be a "string" literal with the appropriate format (e.g., "date-time" or "date" for instances, depending on the temporal granularity).

E

Properties that are only applicable when creating new data or updating existing data SHALL include "writeOnly: true".

F

Properties that are only applicable when data is fetched SHALL include "readOnly: true".

G

The "additionalProperties" member with a value of "true" (the default) or "false" is used to state the expected behavior with respect to properties that are not explicitly declared in the schema. If "additionalProperties" is set to "false", properties that are not explicitly declared in the schema SHALL NOT be allowed, otherwise they SHALL be allowed.

The following recommendations are intended to simplify parsing a schema and to help understanding the meaning of the properties:

Recommendation 1

/rec/schemas/properties

A

Each property SHOULD have a human readable title ("title") and, where necessary for the understanding of the property, a description ("description").

B

The "type" SHOULD be one of the following values: "string" (string or temporal properties), "number"/"integer" (numeric properties), "boolean" (boolean properties), "object" (object properties) or "array" (array properties).

C

Properties that represent a URI SHOULD be represented as a string with format "uri" or "uri-reference".

D

Properties that represent a URI template SHOULD be represented as a string with format "uri-template".

E

Properties that represent a UUID SHOULD be represented as a string with format "uuid".

F

For string properties that are, "minLength", "maxLength", "enum" and/or "pattern" SHOULD be provided, where applicable.

G

For numeric properties, "multipleOf", "minimum", "exclusiveMinimum", "maximum", "exclusiveMaximum" SHOULD be provided, where applicable.

H

For integer properties that represent enumerated values, "enum" SHOULD be provided.

I

For array properties, the property SHOULD consist of items that are strings or numbers.

J

Required properties SHOULD be included in "required".

K

The JSON Schema keywords SHOULD be constrained to the those mentioned in this recommendation and requirement /req/schemas/properties.

7.2. Additional keywords

In order to be able to map the logical schema to a format-specific schema, extensions to the JSON Schema vocabulary are needed.

Requirement 3

/req/schemas/additional-keywords

A

Additional keywords SHALL start with "x-ogc-".
Caution
 The next version of JSON Schema will likely restrict the use of additional keywords. As a result, this Standard may need to change the prefix or change the way as to how the vocabulary is extended.

Requirement 4

/req/schemas/role

A

The keyword "x-ogc-role" SHALL be used to declare a specific role of the property.

B

The value of the keyword "x-ogc-role" SHALL be a string.

Requirement 5

/req/schemas/role-id

A

A property with "x-ogc-role" set to "id" SHALL be the identifier of the item in the collection that contains the item.

B

A property with role "id" SHALL either be a string or integer.

C

Only one property in a schema SHALL have "x-ogc-role" with a value "id".

For cases, where the properties of the data have to be ordered in some representations of the data, the sequence of the properties can be expressed using a keyword "x-ogc-propertySeq".

Requirement 6

/req/schemas/property-seq

A

The keyword "x-ogc-propertySeq" SHALL be used to declare a specific relative position of the property.

B

The value of the keyword "x-ogc-propertySeq" SHALL be an integer representing the relative position in ascending order.

C

Each value of the keyword SHALL be unique for all members of a "properties" object in the JSON Schema.

In geospatial data, numeric property values often represent a measurement and have a unit of measure. For fixed units, this can be expressed in the schema using the keyword "x-ogc-unit".

Requirement 7

/req/schemas/unit

A

The keyword "x-ogc-unit" SHALL be used to declare the unit of measure of the property.

B

The value of the keyword "x-ogc-unit" SHALL be a string representing the unit of measure.

C

The value of the keyword "x-ogc-unit" SHALL be the case sensitive UCUM representation ("c/s") unless a different language / register for units is identified in keyword "x-ogc-unitLang".

D

The value for UCUM, if explicitly declared as the language for units in keyword "x-ogc-unitLang", SHALL be "UCUM".

E

The value for the QUDT Units Vocabulary, if declared as the language for units in keyword "x-ogc-unitLang", SHALL be "QUDT".

F

The value of the keyword "x-ogc-unit" SHALL be the URI of the unit for values from the QUDT Units Vocabulary.

Communities or other OGC Standards can specify additional values for other unit languages, e.g., units registered in the OGC Rainbow. For each language it must be specified how units have to be represented in the "x-ogc-unit" value.

Note
 UCUM provides a language to define units while QUDT provides a units vocabulary. The term "language" is used as it is the broader term.
Note
 For example, the value for hectopascal is hPa in UCUM and https://qudt.org/vocab/unit/HectoPA in QUDT.

Requirement 8

/req/schemas/definition

A

The keyword "x-ogc-definition" SHALL be used to identify the semantic definition for the property.

B

The value of the keyword "x-ogc-definition" SHALL be a URI.

7.3. Examples

The following example is the schema of a feature type representing cultural entities. The schema includes additional keywords that apply to feature data (specified in the next Clause).

Example 1. Schema of a "Cultural (Points)" feature type
{
  "$schema" : "https://json-schema.org/draft/2020-12/schema",
  "$id" : "https://demo.ldproxy.net/daraa/collections/CulturePnt/schema",
  "type" : "object",
  "title" : "Cultural (Points)",
  "description" : "Information about features on the landscape that have been constructed by man.",
  "properties" : {
    "FID" : {
      "readOnly" : true,
      "x-ogc-role" : "id",
      "type" : "integer",
      "x-ogc-propertySeq": 1
    },
    "F_CODE" : {
      "title" : "Feature Type Code",
      "x-ogc-role" : "type",
      "enum" : [ "AK121", "AL012", "AL030", "AL130", "BH075" ],
      "type" : "string",
      "x-ogc-propertySeq": 2
    },
    "geometry" : {
      "x-ogc-role" : "primary-geometry",
      "format" : "geometry-point",
      "x-ogc-propertySeq": 3
    },
    "ZI001_SDV" : {
      "title" : "Last Change",
      "x-ogc-role" : "primary-instant",
      "format" : "date-time",
      "type" : "string",
      "x-ogc-propertySeq": 4
    },
    "UFI" : {
      "title" : "Unique Entity Identifier",
      "type" : "string",
      "x-ogc-propertySeq": 5
    },
    "ZI005_FNA" : {
      "title" : "Name",
      "type" : "string",
      "x-ogc-propertySeq": 6
    },
    "FCSUBTYPE" : {
      "title" : "Feature Subtype Code",
      "type" : "integer",
      "x-ogc-propertySeq": 7
    },
    "ZI037_REL" : {
      "title" : "Religious Designation",
      "enum" : [ -999999, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 ],
      "type" : "integer",
      "x-ogc-propertySeq": 8
    },
    "ZI006_MEM" : {
      "title" : "Memorandum",
      "type" : "string",
      "x-ogc-propertySeq": 9
    },
    "ZI001_SDP" : {
      "title" : "Source Description",
      "type" : "string",
      "x-ogc-propertySeq": 10
    }
  }
}

The next example is the schema of a feature type representing observations of atmospheric pressure.

Example 2. Schema of an "Atmospheric Pressure Observation" feature type
{
  "$schema" : "https://json-schema.org/draft/2020-12/schema",
  "$id" : "https://api.example.org/foo/bar/collections/atmospheric-pressure-obs/schema",
  "type" : "object",
  "title" : "Atmospheric Pressure Observation",
  "properties" : {
    "id" : {
      "readOnly" : true,
      "x-ogc-role" : "id",
      "type" : "integer",
      "x-ogc-propertySeq": 1
    },
    "location" : {
      "x-ogc-role" : "primary-geometry",
      "format" : "geometry-point",
      "x-ogc-propertySeq": 2
    },
    "phenomenonTime" : {
      "title" : "Phenomenon Time",
      "x-ogc-role" : "primary-instant",
      "type" : "string",
      "format" : "date-time",
      "x-ogc-propertySeq": 3
    },
    "result" : {
      "title" : "Atmospheric Pressure [hPa]",
      "description": "The pressure exerted by the weight of the air above it at any point on the earth's surface. At sea level the atmosphere will support a column of mercury about 760 mm high. This decreases with increasing altitude. The standard value for the atmospheric pressure at sea level is 1.01325 hectopascal.",
      "type" : "number",
      "x-ogc-definition": "https://qudt.org/vocab/quantitykind/AtmosphericPressure",
      "x-ogc-unit": "https://qudt.org/vocab/unit/HectoPA",
      "x-ogc-unitLang": "QUDT",
      "x-ogc-propertySeq": 4
    },
  }
}

8. Requirements Class "Core roles for features"

The Requirements Class "Core roles for features" specifies additional property roles for feature data.

Requirements Class

http://www.opengis.net/spec/ogcapi-features-5/1.0/req/core-roles-features

Target type

Web resource

Dependency

Requirements Class "Schemas"

To understand how features are encoded in a specific format, additional property roles need to be identified in the logical schema. These roles depend on the format.

For example, the role "primary-geometry" is needed in feature types with multiple spatial properties to decide:

  • Which geometry is encoded as the geometry of a feature in formats such as FlatGeobuf, Shapefile or Mapbox Vector Tiles, which only support a single geometry; or,

  • Which geometry is encoded in the "geometry" member in GeoJSON.

The other roles specified in this requirements class support feature formats that support representing primary temporal information or the type of the feature, such as JSON-FG.

8.1. Primary geometry

If the features have multiple spatial properties, the role "primary-geometry" can be used to identify the primary geometry of the features.

Requirement 9

/req/core-roles-features/role-primary-geometry

A

A property with "x-ogc-role" set to "primary-geometry" SHALL be a spatial property.

B

At most one property in a schema SHALL have "x-ogc-role" with a value "primary-geometry".

C

If the schema has only one spatial property, the property SHALL be the primary geometry even if the property is not explicitly tagged with the role "primary-geometry".
Note
 Since only a single property can be tagged in the schema as the primary geometry, varying primary geometries at different zoom levels are currently not supported. This would require the capability to assign the role depending on the zoom level.

8.2. Primary temporal information

If the features have multiple temporal properties, the roles "primary-instant", "primary-interval-start" and "primary-interval-end" can be used to identify the primary temporal information of the features.

Requirement 10

/req/core-roles-features/role-primary-instant

A

A property with "x-ogc-role" set to "primary-instant" SHALL be a temporal property.

B

At most one property in a schema SHALL have "x-ogc-role" with a value "primary-instant".

C

If the schema has only one temporal property, the property SHALL be the primary temporal information even if the property is not explicitly tagged with the role "primary-instant".

Requirement 11

/req/core-roles-features/role-primary-interval-start

A

A property with "x-ogc-role" set to "primary-interval-start" SHALL be a temporal property.

B

At most one property in a schema SHALL have "x-ogc-role" with a value "primary-interval-start".

Requirement 12

/req/core-roles-features/role-primary-interval-end

A

A property with "x-ogc-role" set to "primary-interval-end" SHALL be a temporal property.

B

At most one property in a schema SHALL have "x-ogc-role" with a value "primary-interval-end".

Requirement 13

/req/core-roles-features/primary-temporal-constraints

A

If a schema has a property with role "primary-instant", the schema SHALL NOT have properties with role "primary-interval-start" or "primary-interval-end".

B

If a schema has properties with both roles "primary-interval-start" and "primary-interval-end", both properties SHALL have the same temporal granularity ("date" or "date-time").
Note
 FUTURE WORK? Consider adding a role "primary-interval" with a proper representation of an interval, e.g., the interval representation in JSON-FG (an array with two dates or timestamps).

8.3. Feature type

If the features have a property that represents the feature type, the role "type" can be used for this property.

Requirement 14

/req/core-roles-features/role-type

A

A property with "x-ogc-role" set to "type" SHALL be a string property.

B

At most one property in a schema SHALL have "x-ogc-role" with a value "type".

8.4. Examples

The previous Clause includes an example with the roles "id", "primary-geometry", "primary-instant" and "type".

The following example is the schema of a feature type with the roles "id", "primary-geometry", "primary-interval-start" and "primary-interval-end".

Example 3. Schema example of a feature type
{
  "$schema" : "https://json-schema.org/draft/2020-12/schema",
  "$id" : "https://demo.ldproxy.net/cshapes/collections/boundary/schema",
  "title" : "Historical Country Boundaries",
  "description" : "Core territories of the given country, excluding colonies and other dependent territories, between the start and end date.",
  "type" : "object",
  "properties" : {
    "fid" : {
      "title" : "Unique identifier",
      "readOnly" : true,
      "x-ogc-role" : "id",
      "type" : "integer"
    },
    "name" : {
      "title" : "Country name",
      "type" : "string"
    },
    "area_km2" : {
      "title" : "Area (km²)",
      "description" : "The polygon area in square kilometers, computed using an Eckert VI projection.",
      "type" : "number",
      "x-ogc-unit": "km2"

    },
    "capname" : {
      "title" : "Country capital",
      "description" : "The name of the country capital.",
      "type" : "string"
    },
    "caplong" : {
      "title" : "Longitude of the capital",
      "description" : "Longitude of the capital, in decimal degrees",
      "type" : "number"
    },
    "caplat" : {
      "title" : "Latitude of the capital",
      "description" : "Latitude of the capital, in decimal degrees",
      "type" : "number"
    },
    "gwsdate" : {
      "title" : "Start date",
      "description" : "Start date of the entry.",
      "x-ogc-role" : "primary-interval-start",
      "format" : "date",
      "type" : "string"
    },
    "gwedate" : {
      "title" : "End date",
      "description" : "End date of the entry.",
      "x-ogc-role" : "primary-interval-end",
      "format" : "date",
      "type" : "string"
    },
    "gwcode" : {
      "title" : "Source identifier",
      "description" : "Numeric identifier code in the source data.",
      "type" : "integer"
    },
    "geometry" : {
      "x-ogc-role" : "primary-geometry",
      "format" : "geometry-multipolygon"
    }
  }
}

9. Requirements Class "Feature references"

The Requirements Class "Feature references" specifies additional provisions for properties that reference another feature.

Note
 This requirements class can probably be generalized to cover also other types of references, but this requires a better understanding about the types of references that must be supported.

Requirements Class

http://www.opengis.net/spec/ogcapi-features-5/1.0/req/feature-references

Target type

Web resource

Dependency

Requirements Class "Schemas"

If the features have a property that represents a reference to another feature in the same or another OGC Web API, the role "reference" can be used for this property. The property is a foreign key, the featureId of the referenced feature.

Requirement 15

/req/feature-references/role-reference

A

A property with "x-ogc-role" set to "reference" SHALL be a string or integer property.

B

If the property is of type "integer", the property with role "id" of the referenced feature type SHALL be of type "integer", too.

C

If all instances of the property reference another feature in a fixed collection of the same server, the id of that collection SHALL be provided in "x-ogc-collectionId".

D

If Requirement C does not apply, but all instances of the property reference another feature in the same server, the list of the ids of the collections that can be referenced SHALL be provided as an array in "x-ogc-collectionId".

E

If Requirements C and D do not apply, the URI template SHALL be provided in "x-ogc-uriTemplate" with a template parameter featureId.

F

If Requirement E applies, and the referenced features can be in different collections, the URI template SHALL also include a template parameter collectionId.

G

If Requirement F applies, the list of the ids of the collections that can be referenced SHALL be provided as an array in "x-ogc-collectionId".
Example 4. Schema example

This is the schema of a road accident feature type. The "roadSegment" property is a reference to the road segment on which the accident occurred.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/apis/roads/collections/accidents/schema",
  "type": "object",
  "title": "Road accidents",
  "properties": {
    "id": {
      "title": "Feature identifier",
      "readOnly": true,
      "x-ogc-role": "id",
      "type": "integer"
    },
    "timeOfAccident": {
      "title": "Time of the accident",
      "x-ogc-role": "primary-instant",
      "format": "date-time",
      "type": "string"
    },
    "roadSegment": {
      "title": "Road segment",
      "description": "Road segment on which the accident occured, identified by its 16-character code (8 characters for the start and end node).",
      "x-ogc-role": "reference",
      "x-ogc-collectionId": "roadsegments",
      "type": "string"
    },
    "distanceFromStart": {
      "title": "Distance from start [m]",
      "description": "Distance from the start node of the road segment. The unit is meter.",
      "minimum": 0.0,
      "type": "number",
      "x-ogc-unit": "m"
    },
    "geometry": {
      "x-ogc-role": "primary-geometry",
      "format": "geometry-point"
    }
  }
}

10. Requirements Class "Returnables and Receivables"

The Requirements Class "Returnables and Receivables" specifies the web resources representing the schema with the returnable and receivable properties of a collection in OGC Web APIs.

Requirements Class

http://www.opengis.net/spec/ogcapi-features-5/1.0/req/returnables-and-receivables

Target type

Web API

Dependency

Requirements Class "Schemas"

This requirements class supports clients that want to discover the list of resource properties with their types and constraints that is returned when fetching a representation of the resource or when creating a new or updating an existing resource.

Requirement 17

/req/returnables-and-receivables/op

A

The Returnables and Receivables resource SHALL support the HTTP GET operation and the media type application/schema+json.

Requirement 18

/req/returnables-and-receivables/response

A

A successful execution of the operation SHALL be reported as a response with a HTTP status code 200.

B

For responses that use application/schema+json as the Content-Type of the response, the response SHALL conform to Requirements Class "Schemas".

11. Requirements Class "Queryables"

The Requirements Class "Queryables" specifies the web resources representing the schema with the queryable properties of a collection in OGC Web APIs.

Requirements Class

http://www.opengis.net/spec/ogcapi-features-5/1.0/req/queryables

Target type

Web API

Dependency

Requirements Class "Schemas"

This requirements class supports clients that want to discover the list of resource properties with their types and constraints that may be used to construct filter expressions on a collection of resources, for example, a set of features.

OGC API Standards do not assume that the content schema of a resource being queried is available for inspection. Therefore, a means needs to exist to interrogate an endpoint to determine the names and types of the properties that may be used to construct a filter expression ("queryables").

In addition, a publisher may want to support queryables that are not directly represented as resource properties in the content schema of the resource. Or the publisher may want to restrict filtering on certain properties. For example, because the backend datastore has not been configured to allow high-performance queries on those properties.

Requirement 20

/req/queryables/op

A

The Queryables resource SHALL support the HTTP GET operation and the media type application/schema+json.

Requirement 21

/req/queryables/response

A

A successful execution of the operation SHALL be reported as a response with a HTTP status code 200.

B

For responses that use application/schema+json as the Content-Type of the response, the response SHALL conform to Requirements Class "Schemas".

C

If additionalProperties is not included or has the default value true, any property name is valid in a filter expression on the collection that is evalutated by the Web API and the property reference SHALL evaluate to null, if the property does not exist for a resource.

If additionalProperties is set to false, property references that are not explicitly declared in the queryables schema SHALL result in a 400 response.
Note
 Depending on the filter language, some properties cannot be supported in filter expressions. For example, if the filter language does not support predicates on object-valued properties, using such properties in a filter expression will result in an error.
Example 5. Filtering on complex data structures

Queryables also support simplified filtering on complex data structures. This example illustrates one potential approach to define a queryable on specific SpatioTemporal Asset Catalog (STAC) assets. The following is a STAC snippet:

"features": [
  {
    "type": "Feature",
    "assets": {
      "B5": {
        "eo:bands": [
          {
            "common_name": "nir",
            "name": "B5"
          }
        ],
        "href": "https://landsat-pds.s3.us-west-2.amazonaws.com/c1/L8/060/247/LC08_L1TP_060247_20180905_20180912_01_T1/LC08_L1TP_060247_20180905_20180912_01_T1_B5.TIF",
        "type": "image/tiff; application=geotiff; profile=cloud-optimized"
      }
    }
  }
]

A common type of filter is to fetch only resources that have in their assets object a value that has an eo:bands value that contains a common_name value of "nir".

This could be implemented using a queryable common_band_names defined as an array of strings:

{
  "$schema": "https://json-schema.org/draft/2019-09/schema",
  "$id": "https://example.net/stac/collections/landsat/queryables",
  "type": "object",
  "title": "A STAC item",
  "properties": {
    "common_band_names": {
      "title": "Common band names",
      "description": "an array of common band names included in the assets",
      "type" : "array",
      "items": {
        "type": "string"
      }
    }
  }
}

Internally this could be mapped to the following JSON Path for a STAC item (item):

item['assets'][*]['eo:bands'][\*]['common_name']

Note that the JSON Path is just included here to clarify the mapping. An implementation would use a mapping that fits its backend datastore, but these details are hidden from the user.

A client can now use, e.g., the CQL2 array predicates to filter with the queryable. Examples using the CQL2 text encoding:

  • A_CONTAINS(common_band_names, ["nir"]) - includes at least a 'nir' band

  • A_EQUALS(common_band_names, ["nir","blue"]) - 'nir' and 'blue' exist for the feature, but no other band

12. Requirements Class "Sortables"

The Requirements Class "Sortables" specifies the web resources representing the schema with the sortable properties of a collection returned by Web API endpoint(s) implementing OGC API Standards.

Requirements Class

http://www.opengis.net/spec/ogcapi-features-5/1.0/req/sortables

Target type

Web API

Dependency

Requirements Class "Schemas"

This requirements class supports clients that want to discover the list of resource properties with their types and constraints that may be used to sort the resources in a collection.

OGC API Standards do not assume that the content schema of a resource being queried is available for inspection. Therefore, a means needs to exist to interrogate an endpoint to determine the names and types of the properties that may be used to sort data ("sortables").

In addition, a publisher may want to support sortable that are not directly represented as resource properties in the content schema of the resource. Or the publisher may want to restrict sorting on certain properties. For example, because the backend datastore has not been configured to allow high-performance queries on those properties.

Requirement 23

/req/sortables/op

A

The Sortables resource SHALL support the HTTP GET operation and the media type application/schema+json.

Requirement 24

/req/sortables/response

A

A successful execution of the operation SHALL be reported as a response with a HTTP status code 200.

B

For responses that use application/schema+json as the Content-Type of the response, the response SHALL conform to Requirements Class "Schemas".

C

No property SHALL be of type "object" or "array".

D

No property SHALL be a spatial property.

E

If additionalProperties is not included or has the default value true, any property name is valid in a sorting expression on the collection that is evaluated by the server and the property reference SHALL evaluate to null, if the property does not exist for a resource.

If additionalProperties is set to false, property references that are not explicitly declared in the sortables schema SHALL result in a 400 response.

13. Requirements Class "Profile query parameter"

The Requirements Class "Profile query parameter" specifies additional provisions for properties that reference another resource.

Requirements Class

http://www.opengis.net/spec/ogcapi-features-5/1.0/req/profile-parameter

Target type

Web API

Some properties may be represented in multiple representations in the same format, depending on the intended use of the data. One example are references to another web resource (see the Requirements Class "Profiles for feature references").

RFC 6906 The 'profile' Link Relation Type defines the concept of a profile to support such use cases.

A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.

To request one or more profiles, a query parameter "profile" can be used:

Requirement 25

/req/profile-parameter/profile-param

A

The GET operation on selected resources SHALL support a query parameter "profile" with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: profile
in: query
required: false
schema:
  type: array
  items:
    type: string
style: form
explode: false

B

Each item SHALL be one of the follwoing:

  • A HTTP(S) URI of a profile, e.g., in the OGC Profile Register (http://www.opengis.net/def/profile);

  • A Safe CURIE of a profile in the OGC Profile Register (e.g., [ogc-profile:my-profile]);

  • A profile identifier (the profileId value in the URI template http://www.opengis.net/def/profile/OGC/0/{profileId})

Permission 1

/per/profile-parameter/profile-param-default

A

The server MAY specify a default value for the query parameter "profile".

Determining the profile(s) of the response is part of the content negotiation process after the proactive content negotiation as specified by the HTTP RFC has been completed. The server determines the applicable profile(s) for the selected media type.

Different media types have different characteristics. A consequence is that it can be impossible to support a profile for a media type or it can be against the design goals of a media type to support a profile.

Permission 2

/per/profile-parameter/profiles-of-media-type

A

For any media type that can represent a resource, the server MAY support only a subset of the profiles offered for the resource.

B

The subset of supported profiles for a media type MAY be empty, too.

The server will select the profile(s) of the response, if any, from the list of profiles supported for the media type and resource.

Recommendation 2

/rec/profile-parameter/profile-negotiation

A

If the server supports one or more of the requested profile(s) for the media type and resource, these profiles SHOULD be used for the response.

B

The profile negotiation SHOULD NOT result in an error, e.g., because a requested profile cannot be provided.

Requirement 26

/req/profile-parameter/profile-param-response

A

The query parameter is not required, that is, omitting the parameter in a request SHALL not result in an error.

B

If the media type of the response supports web links in accordance with RFC 8288 Web Linking, the response SHALL include links to the selected profile(s) with the link relation type "profile".

14. Requirements Class "Profiles for feature references"

The Requirements Class "Profiles for feature references" specifies three profiles for representing references to other features.

Note
 As with Requirements Class "Feature references", this requirements class can probably be generalized to cover also other types of references, but this requires a better understanding about the types of references that have to be supported.

Requirements Class

http://www.opengis.net/spec/ogcapi-features-5/1.0/req/profile-references

Target type

Web resources

Dependency

Requirements Class "Returnables and Receivables"

Dependency

Requirements Class "Profile query parameter"

Indirect Dependency

Requirements Class "Feature references"

Requirement 27

/req/profile-references/ref-profiles

A

If the Returnables and Receivables schema of a collection includes a property with role „reference“, the GET operation at /collections/{collectionId}/items and /collections/{collectionId}/items/{featureId} SHALL provide the query parameter profile.

Requirement 28

/req/profile-references/rel-as-key

A

In the profile "rel-as-key" (http://www.opengis.net/def/profile/OGC/0/rel-as-key) a feature reference in the response SHALL be represented by:

  • The featureId of the referenced feature (a string or integer, depending on the type of the identifier property in the referenced collection), if the property with role "reference" has the keyword "x-ogc-collectionId" with a string value (a fixed collection).
Note
 What should be provided, if "x-ogc-collectionId" is an array (that is, the referenced features may be in different collections)? A string that combines the collectionId and featureId? An object with collectionId and featureId properties?
Example 6. Encoding of a road accident feature in GeoJSON and profile "rel-as-key"

The examples in this Clause use the example road accident feature schema.

{
  "type": "Feature",
  "id": 1,
  "geometry": {
    "type": "Point",
    "coordinates": [
      7.2789399,
      50.7772485
    ]
  },
  "properties": {
    "timeOfAccident": "2019-02-05T07:00:00Z",
    "roadSegment": "5209062A5209047O",
    "distanceFromStart": 851.0
  },
  "links": [
    {
      "href": "http://www.opengis.net/def/profile/ogc/0/rel-as-key",
      "rel": "profile",
      "title": "Profile used in the response"
    }
  ]
}

Requirement 29

/req/profile-references/rel-as-uri

A

In the profile "rel-as-uri" (http://www.opengis.net/def/profile/OGC/0/rel-as-uri) a feature reference in the response SHALL be represented by an HTTP(S) URI.
Example 7. Encoding of the same road accident feature for the profile "rel-as-uri"
{
  "type": "Feature",
  "id": 1,
  "geometry": {
    "type": "Point",
    "coordinates": [
      7.2789399,
      50.7772485
    ]
  },
  "properties": {
    "timeOfAccident": "2019-02-05T07:00:00Z",
    "roadSegment": "https://example.com/apis/roads/collections/roadsegments/items/5209062A5209047O",
    "distanceFromStart": 851.0
  },
  "links": [
    {
      "href": "http://www.opengis.net/def/profile/ogc/0/rel-as-uri",
      "rel": "profile",
      "title": "Profile used in the response"
    }
  ]
}

How the object is represented in a media type will depend on the media type. For example, in HTML it could be <a href="{href}">{title}</a>, in XML it could be an XLink, in JSON it could be an object with the properties.

Example 8. Encoding of a road accident feature in GeoJSON and profile "rel-as-link"

The feature includes a "roadSegment" property that is a reference to the road segment on which the accident occurred.

{
  "type": "Feature",
  "id": 1,
  "geometry": {
    "type": "Point",
    "coordinates": [
      7.2789399,
      50.7772485
    ]
  },
  "properties": {
    "timeOfAccident": "2019-02-05T07:00:00Z",
    "roadSegment": {
        "href": "https://example.com/apis/roads/collections/roadsegments/items/5209062A5209047O",
        "title": "Road L333, Segment 5209062A5209047O, Hennef"
    },
    "distanceFromStart": 851.0
  },
  "links": [
    {
      "href": "http://www.opengis.net/def/profile/ogc/0/rel-as-link",
      "rel": "profile",
      "title": "Profile used in the response"
    }
  ]
}

Servers will typically not support the profile "rel-as-link" for media types that do not have an adequate representation for such an object. Examples include CSV or FlatGeobuf.

"rel-as-link" will typically be the most useful representation, if a human user interacts with the feature. This is because of the possibility to include a descriptive label of the referenced feature. Of course, this only applies if the server can provide a meaningful title for each link, in which case this information can help the user to understand the referenced feature.

Recommendation 4

/rec/profile-references/default

A

The default value of the query parameter "profile" SHOULD include the profile "rel-as-link", if the server can provide meaningful link titles.

15. Media Types

The media type for JSON Schema documents is "application/schema+json".

16. Security Considerations

See

Annex A: Abstract Test Suite (Normative)

Note
 Conformance classes and test cases for all requirements classes and requirements will be added once the requirements classes and requirements are final.

Annex B: Revision History

Date Release Editor Primary clauses modified Description

2023-10-22

1.0.0-SNAPSHOT

C. Portele

all

initial version

2024-03-07

1.0.0-draft.1

C. Portele

all

draft for OAB review

2024-06-04

1.0.0-draft.2

P. Vretanos, C. Portele

all

draft for Public Comment

Annex C: Bibliography

Internet Assigned Numbers Authority (IANA). Link Relation Types [online, viewed 2023-10-14], Available at https://www.iana.org/assignments/link-relations/link-relations.xml

Open Geospatial Consortium (OGC). OGC Link Relation Type Register [online, viewed 2023-10-14], Available at http://www.opengis.net/def/rel

Open Geospatial Consortium (OGC). OGC CURIE Register [online, viewed 2023-10-14], Available at http://www.opengis.net/def/curie

OpenAPI Initiative (OAI). OpenAPI Specification 3.0 [online, viewed 2023-10-14]. 2020. Available at http://spec.openapis.org/oas/v3.0.3

Internet Engineering Task Force (IETF). RFC 6906: The 'profile' Link Relation Type. Edited by E. Wilde. 2013. Available at https://www.rfc-editor.org/rfc/rfc6906.html

Internet Engineering Task Force (IETF). RFC 8288: Web Linking. Edited by M. Nottingham. 2017. Available at https://www.rfc-editor.org/rfc/rfc8288.html