OGC Testbed-15: Catalogue and Discovery Engineering Report

Publication Date: 2019-12-12

Approval Date: 2019-11-22

Submission Date: 2019-10-15

Reference number of this document: OGC 19-020r1

Reference URL for this document: http://www.opengis.net/doc/PER/t15-D010

Category: OGC Public Engineering Report

Editor: Yves Coene

Title: OGC Testbed-15: Catalogue and Discovery Engineering Report

OGC Public Engineering Report

COPYRIGHT

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

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.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Subject
2. Executive Summary
3. References
- 3.1. Normative references
- 3.2. Other references
4. Terms and definitions
5. Overview
6. Catalogue Service Specification
7. Data Model
- 7.1. GeoJSON EOPAD Metadata Encoding
- 7.2. GeoJSON Search Response Encoding
  - 7.2.1. Requirements class: FeatureCollection
    - FacetedResults
    - DataSource
    - Facet
    - Term
8. Software Design
9. Arctic Discovery Catalogue
Appendix A: Abstract Test Suite
Appendix B: Interpreting JSON as JSON-LD
- B.1. Introduction
- B.2. JSON-LD @context definition
Appendix C: Encoding Examples
- C.1. Service Interfaces
- C.2. Metadata Examples
Appendix D: JSON Schema Documents
Appendix E: OGC API - Processes, Transactional Profile OpenAPI 3.0 specification
Appendix F: Revision History

1. Subject

This OGC Testbed-15 Engineering Report (ER) describes the results of the Earth Observation (EO) Process and Application (EOPAD) Task in the Cloud Processing and Portrayal (CPP) thread of OGC Testbed-15. The ER presents the data model and service interface of the catalogue service allowing for discovery of EO applications and related processing services for subsequent deployment and/or invocation in a distributed environment.

The ER also provides the architectural and implementation details of the software components that were developed as part of the activity and which interact through the described data model. These software components include catalogue clients, catalogue servers and transactional Web Processing Service (WPS-T) servers.

2. Executive Summary

2.1. Problem Statement

Several platforms have emerged that provide access to Earth Observation data and processing capacities. These platforms host very large datasets, which makes a paradigm shift from data download and local processing towards application upload and processing close to the physical location of the data more and more important. To interpret peta- and exascale scientific data, capabilities of these platforms need to be combined in future.

OGC Testbed-13 and Testbed-14 Engineering Reports proposed solutions for packaging, deployment and execution of applications in cloud environments that expose standardized interfaces such as the OGC Web Processing Service (WPS). As long as a dedicated standardized interface such as an OGC WPS instance, a container execution environment (e.g. Docker), and data access are provided, the proposed approach was agnostic to the target cloud platform. In order for end-users to exploit such applications and already deployed processing capacities, facilities must be provided for users to discover the applications and to be provided with detailed descriptions and invocation instructions. This includes both applications to be deployed as well as already deployed applications that are available behind WPS interfaces.

The purpose of the current ER is to define the building blocks through which such applications and related services can be exposed through a Catalogue service:

Data model,
Service interface,
Service management interface.

2.2. Requirements

The following requirements were provided as input for the Catalogue and Discovery activity:

The Data Model should provide:

A unique identifier for each application or service.
Descriptive information such as title/abstract etc.
Classification information that could be used for faceted search / browse.
Descriptions of the data types / constraints of the processing inputs and outputs. These should be formally described such that machine-decisions can be made regarding suitability of input data and pipelining of tool workflows.
Accuracy / error information regarding the algorithms.
Version information and associated application provenance.
Interactive or non-interactive.
Execution environment constraints (e.g. Docker version, hardware requirements) or Execution end-points (e.g. URLs).
Metrics for costs estimation (data sizing, processing costs).
Any other element as mutually agreed upon at the kick-off meeting.

The Service Interface should provide the following capabilities:

Search interface for discovery by facet and free-text in combination.
Request interface for retrieval of facet dictionary to support browse.
Request interface for retrieval of Application detailed metadata, e.g. for display of an application landing page in catalogue web User Interface (UI).
Management interface for the Creating, Update and Deletion of records in the catalogue.

2.3. Achievements

The bindings for the Catalogue and GeoJSON Data Model proposed in this ER are consistent with existing OGC Standards related to OWS Context and OGC Extensions of OpenSearch, namely [OGC 10-032r8], [OGC 13-026r9], [OGC14-055r2] and [OGC17-047]. Support for facet discovery and faceted search responses was borrowed from existing OASIS SRU specifications and the SRU extension of OpenSearch.

The proposed Data Model relies on OGC OWS Context [OGC14-055r2] Offerings to describe service or application access mechanisms and endpoints. Additional offering types were needed to represent services based on the OGC API - Common draft specification. These no longer have the concept of "operation" and applications accessible for deployment as Docker images. The Application Package defined in Testbed-14 is included in the application metadata as a "WPS DeployProcess" offering. In this way, inputs and outputs of the processing are formally described as part of the processDescription which is part of the Application Package. This allows for input/output compatibility checks during process workflow modelling.

In addition to the GeoJSON-based model, the corresponding JSON-LD representation is proposed as well in this ER. A service or application described in the catalog is modelled as a dcat:DataService in [DCAT-2]. This allows for quality related information to be associated using the Data Quality Vocabulary [DQV]. Where possible, the Data Model was aligned with [GeoDCAT-AP].

For the required transactional capabilities of the Catalogue interface, the OpenAPI Specification (formerly Swagger Specification, is an API description format for REST APIs) and the emerging OGC API - Common draft specification were considered.

The different interfaces described in this Engineering Report were implemented by multiple organizations and interoperability tests between client and server component implementations from participating organizations were successfully performed.

2.3.1. Key Use Cases

The following key use cases were successfully covered:

Use Case A: "As owner of an application (still to be deployed or already deployed) or operator of a service, I shall be able to register my application in the Catalogue Service. I shall be able to update the metadata about the application stored in the Catalogue. Finally, at the end of life of the application, I shall be able to remove its metadata from the catalogue".

Use Case B.1: "As owner of an application, I shall be able to deploy the application on a cloud platform, using for instance an Execution Management Service (EMS) as defined in Testbed-14. After the deployment, the cloud platform shall be able to register the application information in the Catalogue Service via a machine-to-machine interface".

Use Case B.2: "As owner of an application, I shall be able to un-deploy the application from the cloud platform which shall therefore delete the metadata record relative to the application from the Catalogue Service via a machine-to-machine interface".

Use Case C: "As a user of applications, I shall be able to use the Catalogue Service to find an application to perform a specific processing algorithm such as a normalized difference vegetation index (NDVI). I shall be able to fill a form with the available search criteria or uses a free text form to specify some keywords and then the Catalogue service shall return all the applications which match the specified criteria. The interaction between the user and the Catalogue Service shall be mediated by a client of the service which shall provide a GUI to ease the user experience".

Use Case D: "As a user of applications, I shall be able to use the Catalogue Service to first find an application to perform a processing algorithm (e.g. classification) and then another application which can be fed with the output of the previous one (e.g. change detection) in order to create a complex application (a workflow or chain) to run systematically over a certain area of interest. The interaction between the user and the Catalogue Service or the cloud platform on the other hand shall be mediated by a client of the Catalogue service which provides a GUI to ease the user experience. The client shall support the user in verifying that the two applications are compatible (i.e. the input type of the second correspond to the output of the first) thanks to the information returned by the Catalogue Service".

2.4. Findings and Recommendations

2.4.1. Alignment with the OGC API - Features standard

The proposed OpenSearch Catalogue binding and GeoJSON Data Model with OGC API - Features - Part 1: Core [OGC17-069r2] and the draft OGC API - Common cannot fully be harmonized due to a number of incompatibilities:

The Testbed-15 team supports the recommendation made in the OGC API Hackaton Engineering report OGC 19-062 to align the time and bbox related search parameters from the OGC OpenSearch Geo and Time Extensions (OGC 10-032r8) and the OGC API - Features - Part 1: Core standard.
Also, additional work is needed to harmonise the link model and OpenSearch response metadata in GeoJSON (OGC 17-047) with the OGC API Features Standard. This may require an update to OGC 14-055r2 (which defines a link model incompatible with OGC API Features) and the specifications that are based on the OGC 14-055r2 specification, including Earth Observation Product (OGC 17-003), Earth Observation Collection (OGC 17-084) and OpenSearch Response (OGC 17-047).

2.4.2. Offerings defined in OGC 14-055r2

The Testbed-15 team recommends extending the offering types defined in [OGC14-055r2] with additional offerings such as a Docker image, or resources defined in the draft OGC API - Processes draft specification and OGC API - Features standard which were used in the activities described in this ER.

2.4.3. OpenSearch

There is currently no search parameter defined in [OGC13-026r9] supporting the retrieval of features (e.g. services/applications, EO collections, EO products) based on an available offering. In other words, return all applications available as Docker images. Similarly, there is no search parameter defined in OpenSearch Discovery [OGC13-026r9] to retrieve resources of a specific kind, which may be useful if a single resource catalog includes different kinds of features, such as EO services/applications, EO collections and EO products.

While it is currently possible to distinguish the URL templates in a single OpenSearch Description Document (OSDD) to be used for searching "products" and "collections" by their "rel" attribute ("results" or "collection" respectively), there is currently no agreed "rel" attribute value for searching "services" or "applications".

2.5. Document contributor contact points

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

Contacts

Name	Organization	Role
Yves Coene	Spacebel s.a.	Editor
Ken Geange	Compusult	Contributor
Mark Lawrence	Compusult	Contributor
Christian Autermann	52°North GmbH	Contributor
Benjamin Proß	52°North GmbH	Contributor
Koushik Panda	Deimos	Contributor
David Cordeiro	Deimos	Contributor
Eugene Genong Yu	George Mason University	Contributor

Name

Organization

Role

Yves Coene

Spacebel s.a.

Editor

Ken Geange

Compusult

Contributor

Mark Lawrence

Compusult

Contributor

Christian Autermann

52°North GmbH

Contributor

Benjamin Proß

52°North GmbH

Contributor

Koushik Panda

Deimos

Contributor

David Cordeiro

Deimos

Contributor

Eugene Genong Yu

George Mason University

Contributor

2.6. Foreword

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

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.

3.1. Normative references

3.2. Other references

4. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard [OGC06-121r9] shall apply. In addition, the following terms and definitions apply.

● compaction: While expansion removes context from a given input, compaction’s primary function is to perform the opposite operation: to express a given input according to a particular context. In JSON-LD, compaction applies a context that specifically tailors the way information is expressed for a particular person or application. This simplifies applications that consume JSON or JSON-LD by expressing the data in application-specific terms, and it makes the data easier to read by humans [JSON-LD 1.0 Processing Algorithms and API].
● context: A set of rules for interpreting a JSON-LD document as specified in the section "The Context" of the JSON-LD specification [JSON-LD].
● facet: Category according to which search results can be categorized. See faceted search.
● faceted search: Faceted results for a query correspond to an analysis of how the search results are distributed over various categories (or "facets"). For example the analysis may reveal how the results are distributed by organization. The user might then refine the query to one particular organization among those listed [OASIS-SR-3].
● GeoJSON: A geospatial data interchange format based on JavaScript Object Notation (JSON) [GeoJSON].
● JSON: A lightweight, text-based, language-independent data interchange format, based on the JavaScript programming language.
● JSON Schema: JSON Schema is a JSON media type for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it [JSON Schema].
● OpenAPI Document: A document (or set of documents) that defines or describes an API. An OpenAPI definition uses and conforms to the OpenAPI Specification [OpenAPI].
● OpenSearch: Draft specification for web search syndication, originating from Amazon’s A9 project and given a corresponding interface binding by the OASIS Search Web Services working group.
● OSDD: OpenSearch Description Document — An XML document available at a consistent location describing metadata for the service and providing templates for queries.
● service interface: Shared boundary between an automated system or human being and another automated system or human being (source: ISO 19101).

4.1. Abbreviated terms

ADES Application Deployment and Execution Service
APD Abstract Protocol Definition
API Application Programming Interface
ATS Abstract Test Suite
CEOS Committee on Earth Observation Satellites
CPP Cloud Processing and Portrayal
EMS Execution Management Service
EO Earth Observation
EOPAD Earth Observation Process and Application Discovery
ER Engineering Report
HATEOAS Hypermedia As The Engine Of Application State
HTTP HyperText Transfer Protocol
IRI Internationalised Resource Identifier
ISO International Organisation for Standardisation
JSON JavaScript Object Notation
JSON-LD JavaScript Object Notation for Linked Data
LDP Linked Data Protocol
OASIS Organization for the Advancement of Structured Information Standards
OGC Open Geospatial Consortium
OWC OGC Web Services Context
RDF Resource Description Framework
REST Representational State Transfer
SRU Search/Retrieval via URL
SWG Standards Working Group
UML Unified Modeling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
W3C World Wide Web Consortium
WGISS Working Group on Information Systems and Services
WKT Well-Known Text
WPS Web Processing Service
WPS-T Transactional Web Processing Service
XML eXtensible Markup Language
XSD XML Schema Definition Language

4.2. Symbols

4.2.1. JSON Schema diagrams

The schema diagrams included in the document show the JSON structure expressed in JSON Schema. Section 5.2.1 of [OGC17-047] gives a brief overview of the notation used.

4.2.2. JSONPath

The data dictionary tables in the current document use the [JSONPath] notation. A brief overview of this notation is included in section 5.2.2 of [OGC17-047].

4.2.3. Unified Modeling Language

The Unified Modeling Language (UML) is used in some of the diagrams in the current document. Stereotypes from the REST profile are used as well.

4.3. Data dictionary tables

This document includes data dictionary tables with information as per sub-clause 5.5 of [OGC06-121r9]. The following comment applies:

Column 1 provides the JSON property name as well as the corresponding [JSONPath] expression.

5. Overview

Chapter 3 lists the normative and informative references used in this document.

Chapter 4 defines the main terms used in the document.

Chapter 5 gives an overview of the document.

Chapter 6 presents the Catalog Service specification defined in this testbed.

In Chapter 7, the metadata model is defined in detail.

Chapter 8 describes the software design and implementation of the software components deployed in the EOPAD task of the Testbed-15 thread.

Finally, Chapter 9 presents the work related to the Arctic Discovery Catalogue, an evergreen catalogue of relevant Arctic circumpolar Web services from OGC and ESRI REST Web services that have some relevance to circumpolar science.

Annex B explains how the GeoJSON encoding can be interpreted as JSON-LD and includes the corresponding JSON-LD @context definitions.

Annex C contains the complete listing of examples illustrating the encodings defined in this document.

Annex D includes the JSON schema definitions defining the GeoJSON encoding.

Annex E includes a draft specification for OGC API - Processes, Transactional Profile OpenAPI 3.0 as was used in the EOPAD Task.

Annex F provides the revision history of this document.

6. Catalogue Service Specification

6.1. Introduction

The discovery solution proposed in Testbed-15 comprises building blocks through which applications and related services can be exposed through a Catalogue service. The service consists of the following interfaces:

Service Interface: Providing the call interface through which a catalogue client or another application can discover applications and services through faceted search and textual search, and then retrieve application/service metadata providing more detail.
Service Management Interface: Providing the call interface through which a catalog client or other application can create, update and delete information about applications/services.

Each of the above interfaces is discussed in more detail in the following sections. The metadata model provides the data structure through which the application and/or service is described and presented as a resource in the catalog. This is defined in chapter 7.

6.2. Service Interface

Testbed-15 has selected the OpenSearch interface with [GeoJSON] response that supports considerable reuse of existing OGC Standards. This choice avoids the creation of yet another catalog specification.

6.2.1. OpenSearch Description Document

The call interface is defined in the OpenSearch Description Document as defined in OGC 13-026r9 and OGC 10-032r8. Testbed-15 uses the URL template corresponding to the application/geo+json response.

The following request returns the OpenSearch Description Document representation.

GET https://fedeo.esa.int/api
Accept: application/opensearchdescription+xml

OSDD Example

<?xml version="1.0" encoding="UTF-8"?><OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:eo="http://a9.com/-/opensearch/extensions/eo/1.0/" xmlns:geo="http://a9.com/-/opensearch/extensions/geo/1.0/" xmlns:os="http://a9.com/-/spec/opensearch/1.1/" xmlns:param="http://a9.com/-/spec/opensearch/extensions/parameters/1.0/" xmlns:semantic="http://a9.com/-/opensearch/extensions/semantic/1.0/" xmlns:sru="http://a9.com/-/opensearch/extensions/sru/2.0/" xmlns:time="http://a9.com/-/opensearch/extensions/time/1.0/">
<ShortName>FEDEO</ShortName>
<Description>Provides interoperable access, following ISO/OGC interface guidelines, to Earth Observation metadata.</Description>
<Tags>FEDEO, ESA, Earth Observation, Digital Repository, HMA, HMA-S, HMA-SE, CEOS-OS-BP-V1.1/L1.</Tags>

<Url rel="self" template="http://fedeo.esa.int/api"
type="application/opensearchdescription+xml"/>

<Url indexOffset="1" pageOffset="1" rel="results"
template="http://fedeo.esa.int/services?subject={eo:keyword?}&amp;query={searchTerms?}&amp;startRecord={startIndex?}&amp;startPage={startPage?}&amp;maximumRecords={count?}&amp;startDate={time:start?}&amp;endDate={time:end?}&amp;title={eo:title?}&amp;publisher={dc:publisher?}&amp;bbox={geo:box?}&amp;uid={geo:uid?}&amp;organisationName={eo:organisationName?}&amp;productType={eo:productType?}&amp;platform={eo:platform?}&amp;instrument={eo:instrument?}&amp;classifiedAs={semantic:classifiedAs?}&amp;facetLimit={sru:facetLimit?}"
type="application/geo+json">

<param:Parameter name="platform" pattern="[a-z|A-Z|1-9|\-|_]+" title="Search by name of the satellite or platform." value="{eo:platform}">
<param:Option label="ENVISAT (58)" value="ENVISAT"/>
<param:Option label="ERS-1 (10)" value="ERS-1"/>
<param:Option label="ERS-2 (22)" value="ERS-2"/>
<param:Option label="SENTINEL-1A (6)" value="SENTINEL-1A"/>
<param:Option label="SENTINEL-1B (4)" value="SENTINEL-1B"/>
</param:Parameter>

<param:Parameter name="organisationName" pattern="[a-z|A-Z|1-9|\-|_]+" title="Search by name of the organization providing the service." value="{eo:organisationName}">
<param:Option label="DLR (15)" value="DLR"/>
<param:Option label="ESA/ESRIN (26)" value="ESA/ESRIN"/>
<param:Option label="VITO (30)" value="VITO"/>
</param:Parameter>

</Url>

<Query eo:platform="Envisat" role="example"/>
<LongName>Earth Observation Catalogue</LongName>

<OutputEncoding>UTF-8</OutputEncoding>
<InputEncoding>UTF-8</InputEncoding>
</OpenSearchDescription>

Tip	The `rel` attribute of the `Url` element is set to `results`. Future versions of [OGC13-026r9] could extend the list in section 7.1 (`collection`, `results`) with a `services` value to allow clients to distinguish the URL template to be used for services/applications.

Any combination of search parameters from the [OpenSearch] specification and the following OpenSearch extensions can be used by implementations:

[OpenSearch]
[OGC10-032r8] (Geo and time)
[OGC13-026r9] (Earth Observation)
[OGC13-068] (Correlated search)
SRU Extension of OpenSearch (Faceted search)
Semantic Extension of OpenSearch

The table below lists a number of useful search parameters originating from the above specifications. The list is non-exhaustive and any combination of parameters from the above specifications can be advertised by a catalogue server.

Table 1. Search parameters
Search Parameter	Description	Metadata mapping	Examples
os:searchTerms _{query={searchTerms?}}	Free text search.	_{$.properties.abstract} _{$.properties.title} _{$.properties.categories} _{$.properties.keyword} _{$.properties.contactPoint[*].name}	query=vegetation
eo:keyword _{subject={eo:keyword?}}	Search for matching keyword.	_{$.properties.keyword} _{$.properties.categories}	keyword=vegetation
eo:title _{title={eo:title?}}	Search for matching title.	_{$.properties.title}
geo:uid _{uid={geo:uid?}}	Retrieve metadata for service or application via its identifier.	_{$.properties.identifier}
sru:facetLimit _{facetLimit={sru:facetLimit?}}	Number of counts that should be reported per facet field.	Not applicable	facetLimit=0 (Do not return facets) facetLimit=10 (Return maximum 10 counts per facet) facetLimit=eo:organisationName (Return default number of counts for eo:organisationName facet) facetLimit=eo:organisationName:20 (Return maximum 20 counts for eo:organisationName facet)

Testbed-15 identified the need for the following additional search parameters which could not be found in existing standards/specifications that are needed to implement the EOPAD uses cases:

Table 2. Additional search parameters
Search Parameter	Description	Metadata mapping	Examples
eopad:offering	Retrieve services based on type of "offering", filter based on input or output parameters to "chain" etc.	_{$.properties.offerings[*].code}
eopad:type	Retrieve resources of a specific kind. This is useful if the same catalogue contains metadata for EO collections, EO products and EO services/applications.	_{$properties.kind}

6.2.2. Facet Discovery

Although the OSDD can advertise possible values for search parameters (e.g. eo:organisationName) using the Parameter Extension as depicted below, it does not advertise which facets (categories) the server can provide faceted results in the responses for.

<param:Parameter name="organisationName" pattern="[a-z|A-Z|1-9|\-|_]+" title="Search by name of the organization providing the service." value="{eo:organisationName}">
<param:Option label="DLR (15)" value="DLR"/>
<param:Option label="ESA/ESRIN (26)" value="ESA/ESRIN"/>
<param:Option label="VITO (30)" value="VITO"/>
</param:Parameter>

The OASIS searchRetrieve Explain specification defines an XML encoding that includes a dedicated searchInfo/facets section.

Choosing between different representations of the same /api resource is a matter of using HTTP content negotiation.

The following request returns the OSDD representation.

GET https://fedeo.esa.int/api
Accept: application/opensearchdescription+xml

The following request returns the Search/Retrieval via URL (SRU) Explain representation.

GET https://fedeo.esa.int/api
Accept: application/sru+xml

<explain xmlns="http://explain.z3950.org/dtd/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://explain.z3950.org/dtd/2.0/ http://docs.oasis-open.org/search-ws/searchRetrieve/v1.0/os/schemas/explain.xsd">
        <serverInfo>
                <host>fedeo.esa.int</host>
                <port>80</port>
                <database>/services</database>
        </serverInfo>
        <indexInfo>
                <set identifier="http://a9.com/-/opensearch/extensions/eo/1.0/" name="eo"/>
                <index search="true">
                        <title lang="en">Organisation</title>
                        <map>
                                <name set="eo">organisationName</name>
                        </map>
                        <configInfo>
                                <supports type="value">VITO</supports>
                                <supports type="value">EUMETSAT</supports>
                                <supports type="value">ESA/ESRIN</supports>
                                <supports type="value">NASA</supports>
                                <supports type="value">CNES</supports>
                                <supports type="value">DLR</supports>
                        </configInfo>
                </index>
        </indexInfo>
        <searchInfo>
                <facets>
                        <facet>
                                <facetType>eo:organisationName</facetType>
                                <limit>
                                        <limitDefault>100</limitDefault>
                                        <otherLimit>true</otherLimit>
                                </limit>
                                <start>
                                        <startDefault>1</startDefault>
                                        <otherStart>false</otherStart>
                                </start>
                        </facet>
                </facets>
        </searchInfo>
</explain>

Testbed-15 proposes a JSON encoding for the Explain document which is shown below and defined in Annex D.3.

WARNING: As both the Explain document and the OpenAPI document have a JSON representation, a more specific media type is required in the HTTP Accept header (See https://tools.ietf.org/html/rfc7231#section-5.3.2.)

application/sru+xml (Explain document in XML)
application/json;profile="http://explain.z3950.org/dtd/2.0/" (Explain document in JSON)
text/yaml (OpenAPI document in YAML)
application/openapi+json;version=3.0 (OpenAPI document in JSON)

The JSON Schema for the Explain document encoding is included as Annex D.3. The following request returns the JSON representation.

GET https://fedeo.esa.int/api
Accept: application/json;profile="http://explain.z3950.org/dtd/2.0/"

{
        "serverInfo": {
                "host": "fedeo.esa.int",
                "port": 80,
                "database": "/services"
        },
        "indexInfo": [
                {
                        "set": [
                                {
                                        "identifier": "http://a9.com/-/opensearch/extensions/eo/1.0/",
                                        "name": "eo"
                                }
                        ],
                        "index": [
                                {
                                        "search": true,
                                        "map": [
                                                {
                                                        "set": "eo",
                                                        "name": "organisationName"
                                                }
                                        ],
                                        "configInfo": {
                                                "supports": [
                                                        {
                                                                "type": "value",
                                                                "value": "CNES"
                                                        },
                                                        {
                                                                "type": "value",
                                                                "value": "DLR"
                                                        },
                                                        {
                                                                "type": "value",
                                                                "value": "ESA/ESRIN"
                                                        },
                                                        {
                                                                "type": "value",
                                                                "value": "NASA"
                                                        },
                                                        {
                                                                "type": "value",
                                                                "value": "VITO"
                                                        }
                                                ]
                                        }
                                }
                        ]
                }
        ],
        "searchInfo": {
                "facets": [
                        {
                                "facetType": "eo:organisationName",
                                "limit": {
                                        "limitDefault": 100,
                                        "otherLimit": true
                                },
                                "start": {
                                        "startDefault": 1,
                                        "otherStart": false
                                }
                        }
                ]
        }
}

6.3. Service Management Interface

The OSDD can only be used to advertise the search interface. To include the service management interface supporting the creation, update and deletion of metadata records in the catalogue, a more complete interface is required.

Figure 1. Resource Definition Diagram

The following paths are defined in the OpenAPI description:

/
/api
/conformance
/collections
/collections/{collection-id}
/services
/services/{service-id}

The following paths are included to comply with the Core requirements class of the OGC API - Common draft specification. The paths are discovered via the Landing Page.

/
/api
/conformance
/collections

An example of a complete OpenAPI description implementing the Service Management Interface is available in Annex C. The https://editor.swagger.io/ tool can be used for visualising the OpenAPI file.

Figure 2. OpenAPI description visualisation

6.3.1. Landing Page

The / (Landing Page) path is required to comply with the OGC API-Common draft specification.

ResourceSpecificationDiagram LandingPage

Figure 3. LandingPage Resource Specification Diagram

The following request returns the Landing Page.

GET https://fedeo.esa.int/
Accept: application/json

Landing Page response document

{
  "links": [
    { "href": "http://fedeo.esa.int/",
      "rel": "self", "type": "application/json", "title": "this document" },
    { "href": "http://fedeo.esa.int/api",
      "rel": "service", "type": "application/openapi+json;version=3.0", "title": "OpenAPI definition" },
    { "href": "http://fedeo.esa.int/api",
      "rel": "service", "type": "text/yaml", "title": "the OpenAPI definition" },
    { "href": "http://fedeo.esa.int/api",
      "rel": "service", "type": "application/opensearchdescription+xml", "title": "OpenSearch Description Document" },
    { "href": "http://fedeo.esa.int/api",
      "rel": "service", "type": "application/sru+xml", "title": "Explain Document" },
    { "href": "http://fedeo.esa.int/api",
      "rel": "service", "type": "application/json;profile=\"http://explain.z3950.org/dtd/2.0/\"", "title": "Explain Document" },
    { "href": "http://fedeo.esa.int/conformance",
      "rel": "conformance", "type": "application/json", "title": "OGC conformance classes implemented by this API" },
    { "href": "http://fedeo.esa.int/collections",
      "rel": "data", "type": "application/json", "title": "Collection metadata" }
  ]
}

6.3.2. API definition

WARNING: The latest version of [OGC17-069r2] defines "rel": "service-desc" (and "rel": "service-doc") instead of "rel": "service" which was used in previous versions of the [OGC17-069r2] specification. Testbed-15 EOPAD implementations were not yet updated and use the original relation name "service".

The /api (API definition) path is required to comply with in development OGC API-Common draft specification. Content negotiation is used to select the desired representation. The actual paths are found in the above LandingPage response document.

ResourceSpecificationDiagram APIDefinition

Figure 4. APIDefinition Resource Specification Diagram

The following request returns the OpenSearch Description Document representation of the APIDefinition.

GET https://fedeo.esa.int/api
Accept: application/opensearchdescription+xml

The following request returns the OpenAPI representation of the APIDefinition.

GET https://fedeo.esa.int/api
Accept: application/openapi+json;version=3.0

The following request returns the SRU Explain representation of the APIDefinition (in JSON format). The use of the profile parameter as part of the media type is proposed as in https://www.w3.org/TR/json-ld/#application-ld-json. See also [RFC-Profile].

GET https://fedeo.esa.int/api
Accept: application/json;profile="http://explain.z3950.org/dtd/2.0/"

The diagram below shows the interaction with the Landing Page and APIDefinition resources to discover information about the Catalogue API. Simple read-only catalogue clients only require the information in the OSDD document.

Figure 5. Sequence Diagram - Discover API

6.3.3. Conformance statements

The /conformance (Conformance statements) path is required to comply with the in development OGC API - Common draft specification.

ResourceSpecificationDiagram Conformance

Figure 6. Conformance Resource Specification Diagram

The following request returns the Conformance statements.

GET https://fedeo.esa.int/conformance
Accept: application/json

Conformance response document

{
  "conformsTo": [
    "http://www.opengis.net/spec/owc-geojson/1.0/req/core",
    "http://www.opengis.net/spec/os-geojson/1.0/req/core",
    "http://www.opengis.net/spec/eopad-geojson/1.0/req/core",
    "http://www.opengis.net/spec/OAPI_Common/1.0/req/oas30",
    "http://www.opengis.net/spec/OAPI_Common/1.0/req/geojson"
  ]
}

6.3.4. Collections

The /collections path is required to comply with the in development OGC API-Common draft specification. Note that these are collections as defined in [OAPI-Common] and not Earth Observation collections.

ResourceSpecificationDiagram Collections

Figure 7. Collections Resource Specification Diagram

The following request returns the Collections metadata.

GET https://fedeo.esa.int/collections
Accept: application/json

Collections response document

{
        "collections": [
                {
                        "description": "Metadata records representing EO services and applications.",
                        "links": [
                                {
                                        "rel": "items",
                                        "href": "http://fedeo.esa.int/services",
                                        "type": "application/geo+json",
                                        "title": "Services and applications"
                                },
                                {
                                        "rel": "describedBy",
                                        "href": "http://schemas.opengis.net/eopad-geojson/1.0/eopad-geojson-schema.json",
                                        "type": "application/schema+json",
                                        "title": "JSON schema for items belonging to this collection"
                                },
                                {
                                        "rel": "search",
                                        "href": "http://fedeo.esa.int/api",
                                        "type": "application/opensearchdescription+xml",
                                        "title": "Search interface"
                                }
                        ],
                        "id": "services",
                        "title": "EO services and applications"
                }
        ],
        "links": [
                {
                        "rel": "self",
                        "href": "http://fedeo.esa.int/collections",
                        "type": "application/json",
                        "title": "Collection metadata according to OGC API Common conventions"
                }
        ]
}

6.3.5. Services

The /services path corresponds to a (filtered) list of services and application metadata. This path is discovered by the client in the <Url> element of the OSDD document or in the OpenAPI description (via the Landing Page) depending on the complexity of the Catalogue client. Content negotiation is used to select the desired representation. The /services path can also be discovered via the rel="items" link in the corresponding collection in the above Collections response document.

Figure 8. Services Resource Specification Diagram

The following diagram shows the interaction with the above resources to search, create, update or delete metadata items in the catalogue.

Figure 9. Sequence Diagram - Metadata discovery and management

The description of the GET operation on /services should match with the <Url> element information provided in the OSDD. The x-value attribute (in combination with x-@context) makes the relation with the corresponding OpenSearch search parameter from the OSDD explicit in the description. It allows defining the semantics of the query parameters appearing in the OpenAPI document by linking them to their definition in the OGC OpenSearch Standards. An example is shown below.

{
  "name": "organisationName",
        "in": "query",
        "x-value": "{eo:organisationName}",
        "description": "Name of data provider {eo:organisationName}.",
        "required": false,
        "schema": {
                "type": "string",
                "enum": [
                        "ESA",
                        "VITO",
                        "JAXA",
                        "DLR"
                ]
        }
}

The following request returns a list of services or applications corresponding to the result of a free text search.

GET https://fedeo.esa.int/services?query=vegetation
Accept: application/geo+json

The response returned is a [GeoJSON] FeatureCollection object and is defined in the Data Model section 7.2.

6.3.6. Brief, summary responses

The OpenSearch interface with JSON response does not have the equivalent of the Catalogue Service for the Web (CSW) csw:ElementSetName parameter (brief, summary [default], full) to adjust verbosity of metadata record responses. This is typically less necessary as the JSON metadata encoding is less verbose than the XML encoding.

However, catalogue servers may decide to return less optional Feature properties and exploit the $.properties.links.alternates or $.properties.links.via properties to include references to alternative or original metadata in ISO or other metadata formats.

{
                "links": {
                        "alternates": [
                                {
                                        "href": "http://fedeo.esa.int/services/MultiSensorNDVI?httpAccept=application/vnd.iso.19139-2%2Bxml",
                                        "type": "application/vnd.iso.19139-2+xml",
                                        "title": "ISO 19139-2 metadata"
                                }
                        ]
                }
}

In case the GeoJSON response becomes large, the sru:recordSchema parameter (See [OGC13-026r9]) could be used to reduce/extend the content of the Feature object.

OpenSearch clients might also request to receive the response in Atom format which may contain an atom:link allowing to retrieve EOPAD GeoJSON metadata records in a separate request. Testbed-15 does recommend use of the GeoJSON response instead.

<entry>
<id>http://geo.spacebel.be/services/MultiSensorNDVI</id>
<title>Multi Sensor NDVI</title>
<summary type="html"></summary>
<content type="html">NDVI is calculated after the two bands values Near Infrared and red. It is calculated by this formula : NDVI = (NIR-Red)/(NIR+Red).</content>
<updated>2019-05-21T12:09:39Z</updated>
<dc:identifier>MultiSensorNDVI</dc:identifier>
<dc:date>2019-05-21T12:09:39Z</dc:date>
<georss:polygon>-90 -180 -90 180 90 180 90 -180 -90 -180</georss:polygon>

<link href="http://geo.spacebel.be/services/MultiSensorNDVI" rel="alternate" title="ISO 19139-2 metadata" type="application/vnd.iso.19139-2+xml"/>
<link href="http://geo.spacebel.be/services/MultiSensorNDVI" rel="alternate" title="EOPAD metadata" type="application/geo+json;profile=http://www.opengis.net/spec/eopad-geojson/1.0"/>

</entry>

7. Data Model

This chapter defines the GeoJSON encoding of the different parts of the Data Model. The EOPAD metadata is defined as a JSON-LD compaction through a normative context. Therefore, the JSON-LD encoding can also be applied to other Resource Description Framework [RDF] encodings including RDF/XML and RDF Turtle.

The data model makes no assumptions as to the "service" interfaces through which the metadata are accessed and applies equally well to a Service Oriented Architecture as well as a Resource Oriented or RESTful Architecture. The documented approach can be applied in combination with the following technologies:

OGC OpenSearch [OGC13-026], [OGC17-047]
OpenAPI
OGC API Features [OGC17-069r2]
W3C Linked Data Platform
OASIS searchRetrieve
OGC (Geo)SPARQL
Discovery as Structured Data by mass market search engines
Metadata serialised as a label in a Dockerfile

A presentation is used which is similar to the GeoJSON Encoding Specifications in [OGC17-003], [OGC17-047] and [OGC17-084]. The JSON Schema encoding is included in Annex D.1.

7.1. GeoJSON EOPAD Metadata Encoding

7.1.1. Design Approach

The EOPAD metadata encoding defined in this chapter consists of a Feature-based GeoJSON model. The implementation is derived from the conceptual models defined in [OGC11-035r1], itself based on ISO19115:2003, ISO19139:2007 and ISO19139-2. The model maximizes reuse of pre-existing standardized property names. Whenever possible, existing JSON properties from [GeoJSON] and OWS Context [OGC14-055r2] are used for modelling properties instead of new EO-specific property names. If additional properties are required, they are borrowed from [DCAT], [DCAT-AP], [GeoDCAT-AP], [DCMI], [PROV-O] and schema.org (in that order) with their namespace omitted while the namespace appears in the expanded JSON-LD representation. Useful types and properties from DCAT Version 2, in particular related to dcat:DataService, are already used in combination with [DCAT-AP], [GeoDCAT-AP] even though these specifications are based on the original version of [DCAT].

7.1.2. Requirements class: Feature

The Feature object represents the EO application/service metadata a.k.a. EOPAD metadata. The object inherits all properties of the GeoJSON Feature object. In addition, it may contain an optional @context property. The @context properties shall typically be absent in the GeoJSON encoding and implicitly refer to the normative @context defined in Annex B.

Figure 10. Feature Schema

Service/applications can be distinguished from EO collections and EO products via their Feature type. The feature type corresponds to the dct:type property (JSON-LD) as per the resource type and spatial data service type defined in [GeoDCAT-AP] and its JSON equivalent kind that is defined in OGC 17-047. A code list for services/application similar to INSPIRE Classification of Spatial Services allows distinguishing different service categories, including human interaction services.

Table 3. Resource types
Resource	$.type	JSON-LD @type	$.properties.kind or JSON-LD dct:type
EO Service/Application	Feature	dcat:DataService	http://purl.org/dc/dcmitype/Service http://inspire.ec.europa.eu/metadata-codelist/ResourceType/service http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view
EO Collection (OGC 17-084)	Feature	dcat:Dataset	http://purl.org/dc/dcmitype/Collection http://inspire.ec.europa.eu/metadata-codelist/ResourceType/series
EO Product (OGC 17-003)	Feature	gj:Feature eop:EarthObservation	http://purl.org/dc/dcmitype/Dataset http://inspire.ec.europa.eu/metadata-codelist/ResourceType/dataset

The complete description of Feature is given in Table 4. Most properties are inherited from the Feature object defined in [OGC14-055r2].

Table 4. Feature object properties
JSON Property	Definition	Data type and values	Multiplicity and use
@context _$.@context	Optional context property either embedding an actual context or a reference to the normative JSON-LD context defined in Annex B.	Property	Zero or one (optional)
type _$.type	Type of the element. This property is a string with fixed value "Feature".	Property Range: String	One (mandatory)
id _$.id	Unique identifier for the application or service (URI).	Property Domain: Feature Range: String (URI)	One (mandatory)
bbox _$.bbox	Information on the coordinate range of the geometry object representing the footprint. The value is an array of length 4 (assuming the number of dimensions represented in the contained geometries is 2). Typically, south-west point and north-east point coordinates in the World Geodetic System 1984 (WGS84) coordinate reference system. The value defines a shape with edges that have constant longitude and latitude.	Property Domain: Feature Range: Array	Zero or one (optional)
geometry _$.geometry	Contains the description of the geometry of the feature. The value shall be either a Geometry object or a JSON null value.	Property Domain: Feature Range: Geometry or null value	One (mandatory)
properties _$.properties	Groups all other properties of the feature not covered by the properties higher in this table as imposed by [GeoJSON].	Property Domain: Feature Range: Properties (See Table 5)	One (mandatory)

Feature encoding example

{
        "type": "Feature",
        "id": "http://fedeo.esa.int/services/MultiSensorNDVI",
        "bbox": [
                -180,
                -90,
                180,
                90
        ],
        "geometry": {...},
        "properties": {...}
}

Feature encoding example (with explicit @context property)

{
        "@context": "https://www.opengis.net/eopad-geojson/1.0",
        "type": "Feature",
        "id": "http://fedeo.esa.int/services/MultiSensorNDVI",
        "bbox": [
                -180,
                -90,
                180,
                90
        ],
        "geometry": {...},
        "properties": {...}
}

In the remainder of the document, the @context property is not included in the GeoJSON encoding in which case it is implied as explained in Annex B.2.

Properties

The Properties block contains the service or application properties and hypermedia links to related objects. It inherits all MetadataInformation (Table 6), ServiceIdentification (Table 7), DescriptiveKeywords (Table 21) and RelatedUrl (Table 23) properties.

Figure 11. Properties Schema

The complete description of Properties is given in Table 5.

Table 5. Properties object properties
JSON Property	Definition	Data type and values	Multiplicity and use
acquisitionInformation _{$.properties.acquisitionInformation}	Related acquisition information (related platform and instruments).	Property Domain: Properties Range: Array of AcquisitionInformation	Zero or one (optional)
spatial _{$.properties.spatial}	Alternative geometry information compliant with typical [GeoDCAT-AP] encoding.	Property Domain: Properties Range: Location	Zero or one (optional)
priceSpecification _{$.properties.priceSpecification}	Price information according to multiple dimensions. Defined in [schema.org].	Range: CompoundPriceSpecification (Table 17)	Zero or one (optional)

7.1.3. Requirements class: Metadata Information

The MetadataInformation properties are inherited by the Properties block.

Figure 12. MetadataInformation Schema

The complete description of MetadataInformation is given in Table 6.

Table 6. MetadataInformation object properties
JSON Property	Definition	Data type and values	Multiplicity and use
updated _{$.properties.updated}	Date of creation or last update of the metadata record. DateTime representation as defined by RFC3339 section 5.6. Property defined in [OGC14-055r2].	Range: DateTime	One (mandatory)
published _{$.properties.published}	Date of first availability of the metadata record.	Range: DateTime	Zero or one (optional)
lang _{$.properties.lang}	Metadata language, not empty with an RFC-3066 code as defined in [OGC14-055r2].	Range: String	Zero or one (optional)

MetadataInformation encoding example

{
        "updated": "2019-02-01T00:00:00Z",
        "lang": "en"
}

7.1.4. Requirements class: Service Identification

The ServiceIdentification properties are inherited by the Properties block. The ServiceIdentification inherits all properties of the ServiceContact (Table 8) object.

Figure 13. ServiceIdentification Schema

The complete description of ServiceIdentification is given in Table 7.

Table 7. ServiceIdentification object properties
JSON Property	Definition	Data type and values	Multiplicity and use
title _{$.properties.title}	Human readable title given to the service or processing application. Defined in [OGC14-055r2].	Range: String	One (mandatory)
identifier _{$.properties.identifier}	Identifier given to the service or processing application. Defined in [OGC14-055r2].	Range: String	One (mandatory)
kind _{$.properties.kind}	Unique identifier (URI) for the type of the resource. Defined in [OGC17-047], [DCAT-2018] and [GeoDCAT-AP] (dct:type).	Range: String	Zero or one (optional)
date _{$.properties.date}	Range of dates relevant for the resource (RFC-3339). Formatted as <datetime> "/"<datetime> or "<datetime>/" or "/<datetime> or <datetime> or "/". Defined in [OGC14-055r2].	Range: String or DateTime.	Zero or one (optional)
abstract _{$.properties.abstract}	Description of the service or processing application content or purpose as defined in [OGC14-055r2].	Range: String	Zero or one (optional)
doi _{$.properties.doi}	Digital Object Identifier identifying the service or processing application (see https://www.doi.org). Defined in [DCAT-2018] (adms:identifier).	Range: String	Zero or one (optional)
bibliographicCitation _{$.properties.bibliographicCitation}	A bibliographic reference for the resource. Equivalent to mandatory ServiceCitation in [UMM-S] §2.2.1.16.	Range: String	Zero or one (optional)
versionInfo _{$.properties.versionInfo}	Version number or other version designation of the service or processing application. Defined in [DCAT-AP] 1.2 (owl:versionInfo).	Range: String	Zero or one (optional)
versionNotes _{$.properties.versionNotes}	Description of the differences between this version and a previous version of the service or processing application. Defined in [DCAT-AP] 1.2 (adms:versionNotes).	Range: String	Zero or one (optional)
provenance _{$.properties.provenance}	Encoding of provenance information.	Range: Array of ProvenanceStatement (Table 11)	Zero or more (optional)
wasUsedBy _{$.properties.wasUsedBy}	Description of the conformity of the metadata (DQ_ConformanceResult).	Range: Array of Activity (Table 12)	Zero or more (optional)

ServiceIdentification encoding example (Multi Sensor NDVI)

{
        "identifier": "MultiSensorNDVI",
        "kind": "http://inspire.ec.europa.eu/metadata-codelist/ResourceType/service",
        "title": "Multi Sensor NDVI",
        "abstract": "NDVI is calculated after the two bands values Near Infrared and red. It is calculated by this formula : NDVI = (NIR-Red)/(NIR+Red)",
        "versionInfo": "3.0",
        "versionNotes":"Updated for use in OGC Testbed-15."
}

ServiceIdentification encoding example (Rasdaman)

{
        "identifier": "59c3b4fae4b00685883826d7",
        "kind": "http://inspire.ec.europa.eu/metadata-codelist/ResourceType/service",
        "title": "C05.01: Rasdaman",
        "doi": "10.5281/zenodo.1040170",
        "bibliographicCitation": "Peter Baumann, email: p.baumann@jacobs-university.de, & website: rasdaman.org. (2018, January 31). rasdaman - raster data manager (Version 9.5.0). Zenodo. http://doi.org/10.5281/zenodo.1163021",
        "abstract": "Rasdaman (raster data manager) is an open source array database system, which provides flexible, fast, scalable geo services for multi-dimensional spatio-temporal sensor, image, simulation, and statistics data of unlimited volume. ... data with all geo data in the PostgreSQL database, support for the raster-relevant OGC standards, Reference Implementation for WCS Core and WCPS\",
}

ServiceContact

The ServiceContact properties are inherited by the ServiceIdentification (and Properties) block. The encoding depends on the "role" (ISO19115:2003) of the service contact. For the “publisher” and “author” roles, the OGC 14-055r2 encoding is available. Encoding for all roles is aligned with [GeoDCAT-AP] §II.16,

Figure 14. ServiceContact Schema

The complete description of ServiceContact is given in Table 8.

Table 8. ServiceContact object properties
JSON Property	Definition	Data type and values	Multiplicity and use
publisher _{$.properties.publisher}	An entity or agent responsible for publishing the resource (role is "Publisher"). Defined in [OGC14-055r2].	Property Domain: Properties Range: String	Zero or one (optional)
authors _{$.properties.authors}	Entities or persons primarily responsible as authors of the resource (role is "Author"). Defined in [OGC14-055r2].	Property Domain: Properties Range: Array of Agent (Table 10)	Zero or one (optional)
contactPoint _{$.properties.contactPoint}	Entities or persons acting as primary contact point (role is "Point of Contact"). Defined in [DCAT].	Property Domain: Properties Range: Array of Agent (Table 10)	Zero or one (optional)
qualifiedAttribution _{$.properties.qualifiedAttribution}	Specifies the relationship between the resource and the responsible organizations (role is "Resource Provider", "Custodian", "User", "Distributor", "Originator", "Principal Investigator" or "Processor"). Defined in [GeoDCAT-AP].	Property Domain: Properties Range: Array of Attribution (Table 9)	Zero or one (optional)

ServiceContact encoding example

{
        "authors": [
                {
                        "type": "Organization",
                        "email": "mailto:eohelp@eo.esa.int",
                        "name": "ESA/ESRIN",
                        "phone": "tel:+39 06 94180777"
                }
        ],
        "contactPoint": [
                {
                        "type": "Organization",
                        "email": "mailto:eohelp@eo.esa.int",
                        "name": "ESA/ESRIN",
                        "phone": "tel:+39 06 94180777",
                        "uri": "http://www.earth.esa.int",
                        "hasAddress": {
                                "country-name": "Italy",
                                "postal-code": "00044",
                                "locality": "Frascati",
                                "street-address": "Via Galileo Galilei CP. 64"
                        }
                }
        ],
        "qualifiedAttribution": [
                {
                        "type": "Attribution",
                        "agent": [
                                {
                                        "type": "Organization",
                                        "email": "mailto:eohelp@eo.esa.int",
                                        "name": "ESA/ESRIN",
                                        "phone": "tel:+39 06 94180777",
                                        "uri": "http://www.earth.esa.int",
                                        "hasAddress": {
                                                "country-name": "Italy",
                                                "postal-code": "00044",
                                                "locality": "Frascati",
                                                "street-address": "Via Galileo Galilei CP. 64"
                                        }
                                }
                        ],
                        "role": "originator"
                }
        ]
}

Attribution

The Attribution object represents a responsible party and its role and is based on W3C [PROV-O].

Figure 15. Attribution Schema

The complete description of Attribution is given in Table 9.

Table 9. Attribution object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.qualifiedAttribution[*].type}	Type of the element. This property is a string with fixed value "Attribution".	Property Domain: Attribution Range: String Fixed value: "Attribution"	Zero or one (optional)
role _{$.properties.qualifiedAttribution[*].role}	Role of the responsible party corresponding to ISO19115:2003 responsible party role. See values at See values at http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole. Values: - resourceProvider - custodian - owner - user - distributor - originator - pointOfContact - principalInvestigator - processor - publisher - author	Property Domain: Attribution Range: String	One (mandatory)
agent _{$.properties.qualifiedAttribution[*].agent}	Organization or person fulfilling the above "role". Any properties allowed by vcard:Kind are allowed.	Property Domain: Attribution Range: Array of Agent (Table 10)	One (mandatory)

Attribution encoding example

{
             "type": "Attribution",
        "agent": [ {
                "type": "Organization",
                "email": "mailto:eohelp@eo.esa.int"
                "name": "ESA/ESRIN"
                "phone": "tel:+39 06 94180777",
                "uri": "http://www.earth.esa.int",
                "hasAddress":  {
                        "country-name": "Italy",
                        "postal-code": "00044",
                        "locality": "Frascati",
                        "street-address": "Via Galileo Galilei CP. 64"
                }
               } ],
        "role": "originator"
}

Agent

The Agent object is a parent class which can contain the properties of a person or organization entity. This object is based on vcard:Kind and foaf:Agent (depending on the context) and some of its properties were defined/renamed in [OGC14-055r2].

Figure 16. Agent Schema

The complete description of Agent is given in Table 10.

Table 10. Agent object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _$..type	Type of the element. This property can have one of the following fixed values "Agent" (or "Kind"), "Person" (or "Individual"), "Organization".	Domain: Agent Range: String	Zero or one (optional)
name _$..name	Human readable name of author (or entity). Defined in section 7.1.1.7 of [OGC14-055r2].	Domain: Agent Range: String	Zero or one (optional)
email _$..email	Email address of author (or entity). Defined in [OGC14-055r2].	Domain: Agent Range: String	Zero or one (optional)
uri _$..uri	URI of author (or entity). Defined in [OGC14-055r2].	Domain: Agent Range: String (URI)	Zero or one (optional)

Agent encoding example

{
     "type":   "Agent",
     "name":   "Earth Observation Helpdesk",
     "email":  "EOHelp@esa.int",
     "uri":    "http://earth.esa.int"
}

ProvenanceStatement

The proposed encoding is aligned with [GeoDCAT-AP] §II.12 and [DCMI].

Figure 17. ProvenanceStatement Schema

The complete description of ProvenanceStatement is given in Table 11.

Table 11. ProvenanceStatement object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.provenance[*].type}	Type of the element. This property has the fixed value "ProvenanceStatement".	Property Domain: ProvenanceStatement Range: String	Zero or one (optional)
label _{$.properties.provenance[*].label}	Free text content of the corresponding ISO19139-2 metadata property gmd:lineage (for EO collections) or [UMM-S] Service/ServiceQuality/Lineage information for EO services and applications.	Property Domain: ProvenanceStatement Range: String	One (mandatory)

ProvenanceStatement encoding example

{
     "type":   "ProvenanceStatement",
     "label":  "The software has been reviewed for quality according to the ISO9001:2015 compliant software verification process and no issues were reported.”
}

Activity

The proposed encoding is aligned with [GeoDCAT-AP] §II.14 and [PROV-O].

Figure 18. Activity Schema

The complete description of Activity is given in Table 12.

Table 12. Activity object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.wasUsedBy[*].type}	Type of the element. This property has the fixed value "Activity".	Property Domain: Activity Range: String	Zero or one (optional)
generated _{$.properties.wasUsedBy[*].generated}	Refers to the conformity result which is encoded as an Entity.	Property Domain: Activity Range: Entity (Table 13)	One (mandatory)
qualifiedAssociation _{$.properties.wasUsedBy[*].qualifiedAssociation}	Refers to the specification against which conformity is expressed, encoded as an Association.	Property Domain: Activity Range: Association (Table 14)	One (mandatory)

Activity encoding example

{
     "type":   "Activity",
     "generated": {
         "type":   "Entity",
         "degree":   "http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant",
         "description": "See the referenced specification"
     },
     "qualifiedAssociation": {
         "type":   "Association",
         "hadPlan": {
             "type":   "Plan",
             "wasDerivedFrom": {
                 "type":   "Standard",
                 "title":  "COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services",
                 "issued":   "2010-12-08"
             }
         }
    }
}

Entity

The proposed encoding is aligned with [GeoDCAT-AP] §II.14 and [PROV-O].

Figure 19. Entity Schema

The complete description of Entity is given in Table 13.

Table 13. Entity object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.wasUsedBy[*].generated.type}	Type of the element. This property has the fixed value "Entity".	Property Domain: Entity Range: String	Zero or one (optional)
degree _{$.properties.wasUsedBy[*].generated.degree}	URI defining the degree of conformity. The INSPIRE Registry maintains a URI set at http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity.	Property Domain: Entity Range: String (URI)	One (mandatory)
description _{$.properties.wasUsedBy[*].generated.description}	Description of the result.	Property Domain: Entity Range: String	Zero or one (optional)

Entity encoding example

{
        "type":   "Entity",
        "degree":   "http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant",
        "description": "See the referenced specification"
}

Association

The proposed encoding is aligned with [GeoDCAT-AP] §II.14 and [PROV-O].

Figure 20. Association Schema

The complete description of Association is given in Table 14.

Table 14. Association object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.wasUsedBy[*].qualifiedAssociation.type}	Type of the element. This property has the fixed value "Association".	Domain: Association Range: String	Zero or one (optional)
hadPlan _{$.properties.wasUsedBy[*].qualifiedAssociation.hadPlan}	Set of actions or steps intended by one or more agents to achieve some goals.	Domain: Association Range: Plan (Table 15)	One (mandatory)

Plan

The proposed encoding is aligned with [GeoDCAT-AP] §II.14 and [PROV-O].

Figure 21. Plan Schema

The complete description of Plan is given in Table 15.

Table 15. Plan object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.wasUsedBy[*].qualifiedAssociation.hadPlan.type}	Type of the element. This property has the fixed value "Plan".	Domain: Plan Range: String	Zero or one (optional)
wasDerivedFrom _{$.properties.wasUsedBy[*].qualifiedAssociation.hadPlan.wasDerivedFrom}	Refers to the specification against which conformity is expressed, encoded as a Standard.	Domain: Plan Range: Standard (Table 16)	One (mandatory)

Plan encoding example

{
     "type":   "Plan",
     "wasDerivedFrom": {
         "type":   "Standard",
         "title":  "COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services",
         "issued":   "2010-12-08"
     }
}

Standard

The proposed encoding is aligned with [GeoDCAT-AP] §II.14 and [DCMI].

Figure 22. Standard Schema

The complete description of Standard is given in Table 16.

Table 16. Standard object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.wasUsedBy[*].qualifiedAssociation.hadPlan.wasDerivedFrom.type}	Type of the element. This property has the fixed value "Standard".	Domain: Standard Range: String	Zero or one (optional)
title _{$.properties.wasUsedBy[*].qualifiedAssociation.hadPlan.wasDerivedFrom.title}	/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result Title of the specification against which conformity is expressed.	Domain: Standard Range: String	One (mandatory)
issued _{$.properties.wasUsedBy[*].qualifiedAssociation.hadPlan.wasDerivedFrom.issued}	/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result Issued date of the specification against which conformity is expressed.	Domain: Standard Range: DateTime	Zero or one (optional)

Standard encoding example

{
     "type":   "Standard",
     "title":  "COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services",
     "issued":   "2010-12-08"
}

CompoundPriceSpecification

The CompoundPriceSpecification element allows representing metrics for costs estimation (e.g. data size, processing cost). It groups multiple prices that all apply in combination for different dimensions of the service or application consumption. The name property of the attached unit price specification indicates the dimension of a price component. The proposed encoding is aligned with the CompoundPriceSpecification defined at https://schema.org/CompoundPriceSpecification.

Figure 23. CompoundPriceSpecification Schema

The main properties of CompoundPriceSpecification are listed in Table 17. For additional properties, please refer to [schema.org].

Table 17. CompoundPriceSpecification object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.priceSpecification.type}	Type of the element. This property has the fixed value "CompoundPriceSpecification".	Domain: CompoundPriceSpecification Range: String	Zero or one (optional)
description _{$.properties.priceSpecification.description}	Textual description.	Domain: CompoundPriceSpecification Range: String	Zero or one (optional)
priceComponent _{$.properties.priceSpecification.priceComponent}	Price components according to multiple dimensions that apply in combination to determine the total price.	Domain: CompoundPriceSpecification Range: array of UnitPriceSpecification	Zero or one (optional)

CompoundPriceSpecification encoding example

{
        "type": "CompoundPriceSpecification",
        "description": "Service cost elements include processing time and input data size.",
        "priceComponent": [
                {
                        "type": "UnitPriceSpecification",
                        "name": "data",
                        "billingIncrement": 1,
                        "unitText": "km2",
                        "price": 0.001,
                        "priceCurrency": "EUR",
                        "valueAddedTaxIncluded": true,
                        "description": "Service cost element proportional to the surface represented by the processed imagery data."
                },
                {
                        "type": "UnitPriceSpecification",
                        "name": "processing",
                        "billingIncrement": 0.1,
                        "unitCode": "SEC",
                        "unitText": "vCPU seconds",
                        "price": 0.00002400,
                        "priceCurrency": "EUR",
                        "valueAddedTaxIncluded": true,
                        "description": "Service cost element proportional to processing time."
                }
        ]
}

7.1.5. Requirements class: Rights Information

The proposed encoding is aligned with [DCAT-2].

Figure 24. RightsInformation Schema

The complete description of RightsInformation is given in Table 18.

Table 18. RightsInformation object properties
JSON Property	Definition	Data type and values	Multiplicity and use
license _{$.properties.license}	Information about licensing terms for the application or service. For example the encoding of the corresponding ISO19139-2 metadata property gmd:useLimitation.	Domain: Properties Range: Array of LicenseDocument (Table 19)	Zero or one (optional)
accessRights _{$.properties.accessRights}	Information about access conditions for the application or service. For example the encoding of the corresponding ISO19139-2 metadata properties gmd:accessConstraints and gmd:otherConstraints.	Domain: Properties Range: Array of RightsStatement (Table 20)	Zero or one (optional)
rights _{$.properties.rights}	Information about rights held in and over the application or service. See [OGC14-055r2] §7.1.2.7. Also defined in [DCAT-2] as a statement that concerns all rights not addressed with license or accessRights, such as copyright statements.	Property Domain: Properties Range: String	Zero or one (optional)

LicenseDocument

The proposed encoding is aligned with [GeoDCAT-AP] §II.15.

Figure 25. LicenseDocument Schema

The complete description of LicenseDocument is given in Table 19.

Table 19. LicenseDocument object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.license[*].type}	Type of the element. This property has the fixed value "LicenseDocument".	Property Domain: LicenseDocument Range: String	Zero or one (optional)
label _{$.properties.license[*].label}	Free text content of the corresponding ISO19139-2 metadata property gmd:useLimitation.	Property Domain: LicenseDocument Range: String	One (mandatory)

RightsStatement

The proposed encoding is aligned with [GeoDCAT-AP] §II.15 and [DCMI].

Figure 26. RightsStatement Schema

The complete description of RightsStatement is given in Table 20.

Table 20. RightsStatement object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.accessRights[*].type}	Type of the element. This property has the fixed value "RightsStatement".	Property Domain: RightsStatement Range: String	Zero or one (optional)
label _{$.properties.accessRights[*].label}	Free text content of the corresponding ISO19139-2 metadata properties gmd:accessConstraints and gmd:otherConstraints.	Property Domain: RightsStatement Range: String	One (mandatory)

Use Constraints

Use Constraints shall be implemented through the LicenseDocument (Table 19) object.

Use constraints encoding example

{
        "license": [
                {
                "type": "LicenseDocument",
                "label": "Fast Registration with immediate access Data is available via EOLI-SA upon registration. For information on access and use of the On-The-Fly service please refer to the OTF FAQ page and news of 28 July 2016."
                }
        ]
}

Access Constraints

Access Constraints shall be implemented through the RightsStatement (Table 20) object.

Access constraints encoding example

{
        "accessRights": [
                {
                "type": "RightsStatement",
                "label": "Utilisation of this application is subject to ESA's Earth Observation Terms and Conditions"
                }
        ]
}

7.1.6. Requirements class: Descriptive Keywords

The DescriptiveKeywords properties are inherited by the Properties block.

[GeoDCAT-AP] §II.8.2 models keyword information from services differently than keywords for datasets as [DCAT] did not cover services. This is solved in [DCAT-2018], allowing the same representations (dcat:theme and dcat:keyword) to be used for keywords in service and collection (dataset series in [GeoDCAT-AP] metadata. To align with [GeoDCAT-AP] §II.8.1, three kinds of keywords are distinguished.

Figure 27. DescriptiveKeywords Schema

The complete description of DescriptiveKeywords is given in Table 21.

Table 21. DescriptiveKeywords object properties
JSON Property	Definition	Data type and values	Multiplicity and use
subject _{$.properties.subject}	ISO topic categories related to the service or application. Defined in [GeoDCAT-AP].	Range: Array of Category (Table 22)	Zero or one (optional)
categories _{$.properties.categories}	Keywords belonging to a controlled vocabulary related to the service or application. Defined in [OGC14-055r2].	Range: Array of Category (Table 22)	Zero or one (optional)
keyword _{$.properties.keyword}	Free keywords not belonging to a controlled vocabulary related to the service or application. Defined for dcat:DataService in [DCAT-2018].	Range: Array of String	Zero or one (optional)
theme _{$.properties.theme}	Keywords belonging to a controlled vocabulary related to the service or application. Defined for dcat:DataService in [DCAT-2018].	Range: Array of Concept (Table 22).	Zero or one (optional)

DescriptiveKeywords encoding example

{
        "categories": [
                {
                "term": "http://www.eionet.europa.eu/gemet/concept/3650",
                "scheme": "http://www.eionet.europa.eu/gemet/",
                 "label":  "Geology"
                },
                {
                "term": "https://gcmdservices.gsfc.nasa.gov/kms/concept/03f0c0a3-04a7-4ef8-8ec0-3c2266510815",
                 "scheme": "https://gcmdservices.gsfc.nasa.gov/kms/concepts/concept_scheme/sciencekeyword",
                 "label":  "VISIBLE IMAGERY"
                },
                     {
                "term": "https://gcmdservices.gsfc.nasa.gov/kms/concept/98dc8278-fe0a-4e36-a638-9d7a5b0ed826",
                 "scheme": "https://gcmdservices.gsfc.nasa.gov/kms/concepts/concept_scheme/projects",
                 "label":  "FedEO"
                }
        ],
        "keyword": [
                "NDVI"
        ],
        "subject": [
                {
                "term": "http://inspire.ec.europa.eu/metadata-codelist/TopicCategory/geoscientificInformation",
                 "label":  "Geoscientific Information"
                },
                     {
                "term": "https://gcmdservices.gsfc.nasa.gov/kms/concept/d9cd5b7e-e9e7-4746-bbc8-bc69f7b606c7",
                 "label":  "GEOSCIENTIFIC INFORMATION",
                 "scheme": "https://gcmdservices.gsfc.nasa.gov/kms/concepts/concept_scheme/isotopiccategory"
                }
        ],
        "theme": [
                {
                "id": "https://gcmdservices.gsfc.nasa.gov/kms/concept/03f0c0a3-04a7-4ef8-8ec0-3c2266510815",
                 "inScheme": "https://gcmdservices.gsfc.nasa.gov/kms/concepts/concept_scheme/sciencekeyword",
                 "prefLabel":  "VISIBLE IMAGERY"
                }
        ]
}

Table 22. Category object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.categories[*].type}	Type of the element. This property has the fixed value "Category".	Domain: Category Range: String	Zero or one (optional)
scheme _{$.properties.categories[*].scheme}	Identification of the code-list defining the keyword. Defined in section 7.1.1.15 of [OGC14-055r2].	Domain: Category Range: String (URI)	Zero or one (optional)
term _{$.properties.categories[*].term}	Identification of the keyword. See also OGC 08-167r2 for using of URI as string value.	Domain: Category Range: String	One (mandatory)
label _{$.properties.categories[*].label}	Human readable representation of the keyword.	Domain: Category Range: String	Zero or one (optional)

Concept

7.1.7. Requirements class: Related URL

Figure 29. RelatedUrl Schema

The complete description of RelatedUrl is given in Table 23. Note that the encoding of the links property differs depending on the applicable service binding specification.

Table 23. RelatedUrl object properties
JSON Property	Definition	Data type and values	Multiplicity and use
links _{$.properties.links}	Refers to related, actionable resources including alternative metadata. Property defined in [OGC14-055r2].	Range: Links (Table 24)	Zero or one (optional)
links _{$.properties.links}	Refers to related, actionable resources including alternative metadata. Property defined in [OGC17-069r2] (OGC API Features).	Range: Array of Link_ (Table 26)	Zero or one (optional)
offerings _{$.properties.offerings}	Service or online content offering for the resource targeted at OGC compliant clients. See [OGC14-055r2].	Range: Array of Offering (Table 27)	Zero or one (optional)
hasPart _{$.properties.hasPart}	Property to link a service to the target datasets or collections. Defined in [GeoDCAT-AP] §II.6 (dct:hasPart).	Range: Array of String (URI)	Zero or more (optional)

RelatedUrl encoding example (OGC14-055r2)

{
        "hasPart": [
                "http://fedeo.esa.int/series/EOP:ESA:Sentinel-2"
        ],

        "links": {
                "profiles": [ ... ],
                "alternates": [ ... ],
                "describedby": [ ... ]
        },

        "offerings": [ ... ]
}

When the Data Model is used in combination with the OGC API-Features, the links property has to be encoded as per [OGC17-069r2] as a foreign member <xy>.links and is not a subproperty <xy>.properties.links as in [OGC14-055r2].

RelatedUrl encoding example (OGC17-069r2)

{
        "type": "Feature",

             "properties": {
                "hasPart": [
                        "http://fedeo.esa.int/series/EOP:ESA:Sentinel-2"
                ],
                "offerings": [ ... ]

        },

        "links": [
                { "rel":"profile", ... },
                { "rel":"alternate", ... },
                { "rel":"describedby", ... },
                ...
            ]
}

Links

The Links block contains references to related resources as hypermedia links. They include specification references and references to alternative representations of the metadata. The GeoJSON encoding of the Links object uses the property names adopted by section 7.1.2 of the GeoJSON encoding for OWS Context [OGC14-055r2] or "link relation types" as defined in RFC8288.