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.

Figure 30. Links Schema

The Links object is a map containing descriptions of potential Links. The key is a "link relation type" as defined in RFC8288 or a relation defined in [OGC14-055r2]. The Link objects are grouped in arrays according to the "relation" they represent. Implementers may add additional properties if additional "relations" need to be represented. For consistency, all relations refer to arrays of Link objects and not to single Link objects. This allows to have similar references with different media types included for the same relation. The general pattern is thus $.properties.links.relation[*].href. It should be noted that also in Atom, multiple Atom links are allowed by the response syntax, whatever the value of the "rel" attribute. Clients shall use the combination of "rel" and "type" attribute to select the proper Link.

A transactional WPS server (WPS-T) and an application package may be represented as two different resources in the catalog. The hosts link relation can be used to refer to the catalog record representing the application package from the catalog record representing the WPS-T server.

The complete description of Links is given in Table 24.

Table 24. Links object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.links.type}	Type of the element. This property has the fixed value "Links".	Range: String Fixed value: Links	Zero or one (optional)
alternates _{$.properties.links.alternates}	Reference to a description of the resource in an alternative format (rel="alternate")). Property defined in [OGC14-055r2] §7.1.2.	Range: array of Link (Table 25)	Zero or one (optional)
describedby _{$.properties.links.describedby}	Reference to a description of the resource or documentation or (human readable) information related to the resource. Such link can also be used to associate the response document with the corresponding JSON Schema file.	Range: array of Link (Table 25)	Zero or one (optional)
enclosure _{$.properties.links.enclosure}	Reference to the download location for the resource.	Range: array of Link (Table 25)	Zero or one (optional)
hosts _{$.properties.links.hosts}	Refers to the record representing the application package from the catalog record describing the WPS-T service hosting the corresponding service, i.e. on which the application package has been deployed.	Range: array of Link (Table 25)	Zero or one (optional)
previews _{$.properties.links.previews}	Reference to a quick-look or browse image representing the resource (rel="icon"). Property defined in [OGC14-055r2] §7.1.2.10.	Range: array of Link (Table 25)	Zero or one (optional)
profiles _{$.properties.links.profiles}	Specification references identifying which specifications the metadata document complies with. Property defined in [OGC14-055r2] §7.1.1.1.	Range: array of Link (Table 25)	Zero or one (optional)
related _{$.properties.links.related}	Reference to a related resource. Is also used to return results of correlated search as per [OGC13-068].	Range: array of Link (Table 25)	Zero or one (optional)
via _{$.properties.links.via}	Reference to a description of the resource of which the response document is derived (e.g. source of information). Property defined in [OGC14-055r2] §7.1.1.14.	Range: array of Link (Table 25)	Zero or one (optional)

hosts Link encoding example (OGC API Processes)

{
        "id": "http://fedeo.esa.int/services/org.52north.dev.testbed.javaps-eopad.rest",
        "type": "Feature",
        "geometry": null,
        "properties": {
                "identifier": "org.52north.dev.testbed.javaps-eopad.rest",
                "kind": "http://inspire.ec.europa.eu/metadata-codelist/ResourceType/service",
                "title": "Processing API at testbed.dev.52north.org",
                ...
                "links": {
                        "profiles": [
                                {
                                        "href": "http://www.opengis.net/spec/owc-geojson/1.0/req/core"
                                },
                                {
                                        "href": "http://www.opengis.net/spec/eopad-geojson/1.0/req/core"
                                }
                        ],
                        "hosts": [
                                {
                                        "href": "http://fedeo.esa.int/services/org.n52.project.tb15.eopad.NdviCalculation",
                                        "type": "application/json",
                                        "title": "Application Package description"
                                },
                                {
                                        "href": "http://fedeo.esa.int/services/org.n52.project.tb15.eopad.SentinelQualityAreaOfInterest",
                                        "type": "application/json",
                                        "title": "Application Package description"
                                }
                        ]
                }
        }
}

Link

The Link block contains the properties of a hypermedia link to a resource identified by its URI [OGC14-055r2].

Figure 31. Link Schema

The complete description of Link is given in Table 25.

The GeoJSON encoding of each Link object uses the encoding defined in section 7.1.10 of the GeoJSON encoding for OWS Context [OGC14-055r2]. The equivalent JSON-LD encoding is consistent with section 6.1.2.2 of OGC 15-053.

Table 25. Link object properties
JSON Property	Definition	Data type and values	Multiplicity and use
href _{$.properties.links.[].href}	URI describing the related resource. Property defined in [OGC14-055r2] §7.1.10.	Domain: Link Range: String (URI)	One (mandatory)
type _{$.properties.links.[].type}	Hint about the type of the representation that is expected to be returned when the value of href is dereferenced. Property defined in [OGC14-055r2] §7.1.10.	Domain: Link Range: String (contains a media type)	Zero or one (optional)
title _{$.properties.links.[].title}	Human readable information about the link. Property defined in [OGC14-055r2] §7.1.10.	Domain: Link Range: String	Zero or one (optional)
length _{$.properties.links.[].length}	Hint about the content length (in bytes) of the representation that is expected to be returned when the value of href is dereferenced. Property defined in [OGC14-055r2] §7.1.10.	Domain: Link Range: Integer	Zero or one (optional)
lang _{$.properties.links.[].lang}	Language of the resource pointed to by the href attribute. String type, not empty with an RFC-3066 code. Property defined in [OGC14-055r2] §7.1.10.	Domain: Link Range: String	Zero or one (optional)

An alternative representation is required when the Data Model is used in combination with an OGC API Features service binding.

Figure 32. Link_ Schema

Table 26. Link_ object properties
JSON Property	Definition	Data type and values	Multiplicity and use
href _{$.properties.links[*].href}	URI describing the related resource. Property defined in [OGC17-069r2].	Domain: Link Range: String (URI)	One (mandatory)
rel _{$.properties.links[*].rel}	Link relation type as defined in RFC8288. Property defined in [OGC17-069r2].	Domain: Link Range: String (URI)	Zero or one (optional)
type _{$.properties.links[*].type}	Hint about the type of the representation that is expected to be returned when the value of href is dereferenced. Property defined in <OGC17-069r2>>.	Domain: Link Range: String (contains a media type)	Zero or one (optional)
title _{$.properties.links[*].title}	Human readable information about the link. Property defined in <OGC17-069r2>>.	Domain: Link Range: String	Zero or one (optional)
length _{$.properties.links[*].length}	Hint about the content length (in bytes) of the representation that is expected to be returned when the value of href is dereferenced. Property defined in <OGC17-069r2>>.	Domain: Link Range: Integer	Zero or one (optional)
hreflang _{$.properties.links[*].hreflang}	Language of the resource pointed to by the href attribute. String type, not empty with an RFC-3066 code. Property defined in <OGC17-069r2>>.	Domain: Link Range: String	Zero or one (optional)

A possible JSON-LD encoding for the above alternative Link encoding could be:

Alternative Link encoding in JSON-LD

"dcat:qualifiedRelation": [
        {
                      "@type": "dcat:Relationship",
                      "dct:format": "application/vnd.iso.19139-2+xml",
                      "dct:language": {
                        "@id": "http://id.loc.gov/vocabulary/iso639-1/en"
                      },
                      "dct:relation": "http://fedeo.esa.int/services/NdviCalculation?httpAccept=application/vnd.iso.19139-2%2Bxml",
                      "dct:title": "ISO 19139-2 metadata",
                      "dcat:hadRole": {
                        "@id": "http://www.iana.org/assignments/relation/alternate"
                      }
        },
        ...
]

This requires the following changes to the normative JSON-LD @context.

Alternative Link encoding in JSON-LD @context

"links": {
        "@id": "dcat:qualifiedRelation",
        "@context": {
                "@base": "http://www.iana.org/assignments/relation/",
                      "Link": "dcat:Relationship",
                "rel": {
                        "@id": "dcat:hadRole",
                           "@type": "@id"
                },
                "type": "dct:format",
                "href": "dct:relation"
        }
}

Offering

The Offering block is defined in OGC 14-055r2. This block describes a service endpoint or inline content offering for the EO service/application and is intended to be consumed by clients that support OGC standards. In Testbed-15, the Offering block is also used to describe some non-OGC endpoints and offerings.

Figure 33. Offering Schema

In the context of the current ER, an Offering can be used to describe:

View services allowing visualization via OGC Web Map Service (WMS) or Web Map Tiling Service (WMTS) interfaces,
Reference to download or ordering endpoints according to specific OGC protocols e.g. Web Coverage Service (WCS),
Reference to processing endpoints including Web Processing Service (WPS) or hosted processing services (WPS-T).

These are covered "out-of-the-box" using OGC 14-055r2. Testbed-15 has also identified additional needs which include:

Application available as a deployable Docker container.
Application available as application package (i.e. Process Description)
Reference to an OpenDAP endpoint.

The complete description of Offering is given in Table 27.

Table 27. Offering object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.properties.offerings[*].type}	Type of the element. This property has the fixed value "Offering".	Domain: Offering Range: String	Zero or one (optional)
code _{$.properties.offerings[*].code}	URI identifying the type of offering, e.g. requirement class identifier (URI) defining the offering listed in §7.2 to 7.12 of [OGC14-055r2]. Is defined by [OGC14-055r2] §7.1.3.1.	Domain: Offering Range: String (URI)	One (mandatory)
operations _{$.properties.offerings[*].operations}	Array of operations used to invoke the service. Is defined by [OGC14-055r2] §7.1.3.2.	Domain: Offering Range: array of Operation	Zero or more (optional)
contents _{$.properties.offerings[*].contents}	Array of contents (inline or by reference). Is defined by [OGC14-055r2] §7.1.3.3 and §7.1.5.	Domain: Offering Range: array of Object	Zero or more (optional)
styles _{$.properties.offerings[*].styles}	Array of style sets. Is defined by [OGC14-055r2] §7.1.3.4 and §7.1.6.	Domain: Offering Range: array of Object	Zero or more (optional)

Offering encoding example for a WMS endpoint

{
        "type": "Offering",
        "code": "http://www.opengis.net/spec/owc-geojson/1.0/req/wms",
        "operations": [
                {
                        "code": "GetCapabilities",
                        "method": "GET",
                        "type": "application/xml",
                        "href": "http://eumetview.eumetsat.int/geoserv/wms?REQUEST=GetCapabilities&version=1.3.0&service=WMS"
                }
        ]
}

Offering encoding example for a WPS instance

{
        "type": "Offering",
        "code": "http://www.opengis.net/spec/owc-geojson/1.0/req/wps",
        "operations": [
                {
                        "code": "GetCapabilities",
                        "method": "GET",
                        "type": "application/xml",
                        "href": "http://tep.esa.int/wps/processing?REQUEST=GetCapabilities&SERVICE=WPS",
                            "result": {
                                "type": "application/xml",
                                    "content": "<wps:Capabilities>...</wps:Capabilities>"
                            }
                }
        ]
}

The offering code is defined in OGC 14-055r2 as the requirement class identifier (URI) for the extension defining the offering/operation. “code” can be an OGC Web Services Context (OWC) extension or one defined in a profile. Testbed-15 defined a number of new offering codes to cover its different use cases. These are identified as

http://www.opengis.net/spec/eopad-geojson/1.0/req/

Offering encoding example (Docker image)

{
        "type": "Offering",
        "code": "http://www.opengis.net/spec/eopad-geojson/1.0/req/docker/image",
        "contents": [
                {
                        "type": "text/plain",
                        "content": "docker.52north.org/eopad/snap-sentinel-2-ndvi:latest"
                }
        ]
}

In the above example, the content property corresponds to a reference to the Docker image. This property shall not include any protocol and includes an optional registry host name, an optional username, the image ID and then an optional tag (i.e. syntax used by the Docker engine REST API):

[registry.host.name/user/]NAME[:TAG|@DIGEST]

Seed compliant Docker images can be described as offerings as shown below. In this case, the reference to the Docker image is derived from the information in the manifest: <name>-<jobVersion>-seed:<packageVersion>.

Offering encoding example (Seed-compliant Docker image)

{
        "type": "Offering",
        "code": "http://www.opengis.net/spec/eopad-geojson/1.0/req/seed/manifest",
        "contents": [
                {
                        "type": "application/json",
                        "content": {
                                "seedVersion": "1.0.0",
                                "job": {
                                        "name": "MultiSensorNDVI",
                                        "jobVersion": "1.0.0",
                                        "packageVersion": "1.0.0",
                                        "title": "Multi Sensor NDVI",
                                        "description": "NDVI is calculated after the two bands values Near Infrared and red. It is calculated by this formula : NDVI = (NIR-Red)/(NIR+Red)",
                                        "timeout": 3600,
                                        "maintainer": {
                                                "name": "ESA/ESRIN",
                                                "email": "eohelp@eo.esa.int"
                                        },
                                        "resources": {
                                        },
                                        "interface": {
                                        },
                                        "errors": [
                                        ]
                                }
                        }
                }
        ]
}

In the following example, the content property of the DescribeProcess operation result provides access to the Process Description object for the application which is the recommended encoding for the Application Package. It is shortened for readability (See Annex C.2 for the complete application package). The Process Description defines the inputs and outputs of the application. It is the main part of the Application Package encoding defined in [OGC18-049r1] and [OGC18-050r2].

Offering encoding example for a WPS DescribeProcess call

{
        "type": "Offering",
        "code": "http://www.opengis.net/spec/owc-geojson/1.0/req/wps",
        "operations": [
                {
                        "code": "DescribeProcess",
                        "method": "GET",
                        "type": "application/json",
                        "href": "http://52north.org/eopad/wps/processes/NdviCalculation",
                        "result": {
                                "type": "application/json",
                                "content": {
                                        "processDescription": {
                                                "process": {
                                                        "id": "NdviCalculation"
                                                }
                                        }
                                }
                        }
                }
        ]
}

Offering encoding example for an OGC API Processes request

{
        "type": "Offering",
        "code": "http://www.opengis.net/spec/eopad-geojson/1.0/req/ogc-api-processes",
        "operations": [
                {
                        "code": "LandingPage",
                        "method": "GET",
                        "href": "https://testbed.dev.52north.org/javaps-eopad/rest",
                        "type": "application/json"
                },
                {
                        "code": "Service",
                        "method": "GET",
                        "href": "https://testbed.dev.52north.org/javaps-eopad/rest/api/",
                        "type": "application/openapi+json;version=3.0"
                },
                {
                        "code": "Conformance",
                        "method": "GET",
                        "href": "https://testbed.dev.52north.org/javaps-eopad/rest/conformance/",
                        "type": "application/json"
                },
                {
                        "code": "Processes",
                        "method": "GET",
                        "href": "https://testbed.dev.52north.org/javaps-eopad/rest/processes/",
                        "type": "application/json"
                },
                {
                        "code": "DeployProcess",
                        "method": "POST",
                        "href": "https://testbed.dev.52north.org/javaps-eopad/rest/processes/",
                        "type": "application/json"
                },
                {
                        "code": "DescribeProcess",
                        "method": "GET",
                        "href": "https://testbed.dev.52north.org/javaps-eopad/rest/processes/org.n52.project.tb15.eopad.NdviCalculation",
                        "type": "application/json",
                        "result": {
                                "type": "application/json",
                                "content": {
                                        "process": {
                                                "id": "org.n52.project.tb15.eopad.NdviCalculation",
                                                "title": "Calculation of NDVI using the SNAP toolbox for Sentinel-2",
                                                ...
                                        }
                                }
                        }
                }
        ]
}

If a full Application Package as defined in [OGC18-049r1] needs to be embedded in the metadata, then the Offering can refer to the DeployProcess operation request instead. The (mandatory) href property in this case has no meaning as the Application Package may not yet be deployed and may be deployed in multiple places, and therefore the data URI scheme is used.

Offering encoding example (Application Package)

{
        "type": "Offering",
        "code": "http://www.opengis.net/spec/owc-geojson/1.0/req/wps",
        "operations": [
                {
                        "code": "DeployProcess",
                        "method": "POST",
                        "type": "application/json",
                        "href": "data:,",
                        "request": {
                                "type": "application/json",
                                "content": {
                                        "processDescription": {
                                                "process": {
                                                        "id": "MultiSensorNDVIStackGenerator"
                                                },
                                        "executionUnit": [
                                        {
                                                    "href": "https://some-host/CWL/MultiSensorStackGenerator.cwl"
                                        }
                                            ],
                                            "deploymentProfileName": "http://www.opengis.net/profiles/eoc/workflow"
                                        }
                                }
                        }
                }
        ]
}

Note	Option The property $.properties.endpointDescription (i.e. dcat:endpointDescription) defined in [DCAT-2018] might be used to refer to the description of an endpoint, e.g. an OpenAPI document, OGC GetCapabilities response, OGC DescribeProcess response or OpenSearch Description Document.

Feature encoding example (with endpointDescription)

{
        "type": "Feature",
        "id": "http://fedeo.esa.int/services/NdviCalculation",
        "bbox": [...],
        "geometry": {...},
        "properties": {
            ...
            "endpointDescription": [ "http://52north.org/eopad/wps/processes/NdviCalculation" ]
        }
}

Feature JSON-LD encoding example (with endpointDescription)

{
        "@context": {
                "owc": "http://www.opengis.net/ont/owc/1.0/",
                "dcat": "http://www.w3.org/ns/dcat#"
        },
        "@type": "dcat:DataService",
        "dcat:endpointDescription": {
                "@type": "owc:Offering",
                "@id": "http://www.spacebel.be/offering/0001",
                "owc:code": "http://www.opengis.net/spec/eopad-geojson/1.0/req/docker/image",
                "owc:contents": [
                        {
                                "owc:type": "text/plain",
                                "owc:content": "xxx/yyy/ZZZ:latest"
                        }
                ]
        }
}

Operation

The Operation block is fully defined in OGC 14-055r2. This block describes an operation of a service or inline content offering and is intended to be consumed by OGC-compliant clients. The "code" property identifies the OGC operation name, e.g. GetCapabilities, GetMap etc.

Figure 34. Operation Schema

The complete description of Operation is given in Table 28.

Table 28. Operation object properties
JSON Property	Definition	Data type and values	Multiplicity and use
code _{$.properties.offerings[].operations[].code}	URI identifying the type of operation, Typically the OGC Service request type, e.g. “GetCapabilities” or “GetMap”. Is defined by [OGC14-055r2] §7.1.4.1.	Domain: Operation Range: String	One (mandatory)
method _{$.properties.offerings[].operations[].method}	Code identifying the HTTP verb type of Operation. Examples: GET, POST, PUT, HEAD, PATCH, DELETE. Is defined by [OGC14-055r2] §7.1.4.2.	Domain: Operation Range: String	One (mandatory)
type _{$.properties.offerings[].operations[].type}	MIME type of the expected results. Is defined by [OGC14-055r2] §7.1.4.3.	Domain: Operation Range: String	Zero or one (optional)
href _{$.properties.offerings[].operations[].href}	Service request URL. Is defined by [OGC14-055r2] §7.1.4.4.	Domain: Operation Range: String (URI)	One (mandatory)
request _{$.properties.offerings[].operations[].request}	Optional request body content. Is defined by [OGC14-055r2] §7.1.4.5.	Domain: Operation Range: Object	Zero or one (optional)
result _{$.properties.offerings[].operations[].result}	Optional result payload of the operation. Is defined by [OGC14-055r2] §7.1.4.6.	Domain: Operation Range: Object	Zero or one (optional)

For examples, please refer to the Offering examples given in the previous section.

7.1.8. Requirements class: Spatial Information

Spatial Extent

Geometry

The Geometry object is defined in [GeoJSON] and contains a type property and coordinates property. The object can be any of the specializations described below. The expected value for the coordinates property depends on the type of the geometry.

Figure 35. Geometry Schema

The complete description of the Geometry properties is given in [GeoJSON].

7.1.9. Requirements class: Acquisition Information

The acquisition information applicable to EO processing services and applications (See e.g. [UMM-S] §2.2.1.14) is a subset of the acquisition information applicable to EO products. The JSON encoding of this subset is identical to the encoding defined in [OGC17-003] and [OGC17-084]. It should be noted that the forthcoming revision of the Unified Metadata Model Services (UMM-S) specification [UMM-S] will use collection-service association to infer this information (platform and instrument).

The AcquisitionInformation block can appear multiple times and contains information about the related platform (i.e. satellite) and the instrument.

Figure 36. AcquisitionInformation Schema

The complete description of the AcquisitionInformation properties is given in [OGC17-003].

7.2. GeoJSON Search Response Encoding

7.2.1. Requirements class: FeatureCollection

The search interface returns search responses in [GeoJSON] format as defined in OGC 17-047 and depicted in Figure 37. A response is represented as a FeatureCollection and each Feature represents an EO processing application/service matching the search criteria and is encoded as EOPAD metadata presented in Section 7.2.

Figure 37. GeoJSON search response structure

Chapter 10 of OGC 17-047 shows where the facetedResults fit in the GeoJSON response but left the detailed definition of the FacetedResults object as future work. Testbed-15 defines the expected response in Annex E.2 of the current document compliant with section 8.2 of OASIS searchRetrieve Part 3 SRU.

Figure 38. FeatureCollection Schema

The complete description of FeatureCollection is given in [OGC17-047]. Testbed-15 extends the definition with the properties shown in Table 29. All other properties are defined in [OGC17-047].

Table 29. FeatureCollection object properties
JSON Property	Definition	Data type and values	Multiplicity and use
facetedResults _{$.facetedResults}	Representation of the faceted results.	Property Range: FacetedResults as defined in Table 30.	Zero or one (optional)

FeatureCollection encoding example

{
        "type": "FeatureCollection",
        "id": "http://fedeo.esa.int/services?startRecord=1&maximumRecords=10&query=Vegetation",
        "totalResults": 2,
        "startIndex": 1,
        "itemsPerPage": 10,
        "queries": {
                "request": [
                        {
                                "count": 10,
                                "searchTerms": "Vegetation",
                                "startIndex": 1
                        }
                ]
        },
        "facetedResults": {
                 "datasource": [
          ...
       ]
        },

        "properties": {
                "title": "FEDEO Clearinghouse - Search Response",
                "creator": "FEDEO Clearinghouse",
                "updated": "2019-09-27T11:27:19Z",
                "lang": "en",
                "rights": "Copyright 2016-2019, European Space Agency",
                "links": {
                        "profiles": [
                                {
                                        "href": "http://www.opengis.net/spec/owc-geojson/1.0/req/core"
                                },
                                {
                                        "href": "http://www.opengis.net/spec/os-geojson/1.0/req/core"
                                }
                        ],
                        "first": [
                                {
                                        "href": "http://fedeo.esa.int/services?startRecord=1&maximumRecords=10&query=Vegetation",
                                        "type": "application/geo+json",
                                        "title": "first results"
                                }
                        ],
                        "last": [
                                {
                                        "href": "http://fedeo.esa.int/services?startRecord=1&maximumRecords=10&query=Vegetation",
                                        "type": "application/geo+json",
                                        "title": "last results"
                                }
                        ],
                        "search": [
                                {
                                        "href": "http://fedeo.esa.int/api",
                                        "type": "application/opensearchdescription+xml",
                                        "title": "search"
                                }
                        ]
                }
        },
        "features": [
                {
                        "type": "Feature",
                        "id": "http://fedeo.esa.int/services/MultiSensorNDVI",
                        ...

                },
                {
                        "type": "Feature",
                        "id": "http://fedeo.esa.int/services/NdviCalculation",
                        ...
                }
        ]
}

FacetedResults

The server can supply faceted results for a query: i.e. 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 client might then refine the query to one particular organization among those listed.

If a catalog federates the offering of multiple (exploitation) platforms, then in the faceted results, multiple data sources may be exposed.

Figure 39. FacetedResults Schema

The complete description of FacetedResults is given in Table 30.

Table 30. FacetedResults object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$.facetedResults.type}	Type of the object. This property has the fixed value "FacetedResults".	String Fixed value: "FacetedResults"	Zero or one (optional)
datasource _{$.facetedResults.datasource}	List of distributed data sources providing faceted search results and corresponding faceted search results.	Domain: FacetedResults Range: array of DataSource as defined in Table 31.	Zero or one (optional)
facets _{$.facetedResults.facets}	List of facets and corresponding faceted search results.	Domain: FacetedResults Range: array of Facet as defined in Table 32.	Zero or one (optional)

The example below shows the encoding of faceted search results compliant with [OGC17-047] and includes a “facetedResults” JSON object. The example shows the possible values for the facet “eo:platform”. The OASIS facetedResults XML schema and the JSON Schema in Annex D.2 of the current document allow removing several optional elements to simplify the representation depicted below to obtain a more compact notation.

FacetedResults encoding example

{
        "datasource": [
                {
                        "displayLabel": "FedEO",
                        "description": "Federated Earth Observation",
                        "baseURL": "http://fedeo.esa.int/opensearch",
                        "facets": [
                                {
                                        "displayLabel": "Platform",
                                        "index": "eo:platform",
                                        "relation": "=",
                                        "terms": [
                                                {
                                                        "actualTerm": "PROBA-V",
                                                        "query": {
                                                                "count": 1,
                                                                "searchTerms": "vegetation",
                                                                "startIndex": 1,
                                                                "sru:recordSchema": "server-choice",
                                                                "eo:platform": "PROBA-V"
                                                        },
                                                        "requestUrl": "http://fedeo.esa.int/opensearch/request?query=vegetation&startRecord=1&maximumRecords=1&httpAccept=application/geo%2Bjson&&platform=PROBA-V",
                                                        "count": 24
                                                },
                                                {
                                                        "actualTerm": "Aqua",
                                                        "query": {
                                                                "count": 1,
                                                                "searchTerms": "vegetation",
                                                                "startIndex": 1,
                                                                "sru:recordSchema": "server-choice",
                                                                "eo:platform": "Aqua"
                                                        },
                                                        "requestUrl": "http://fedeo.esa.int/opensearch/request?query=vegetation&startRecord=1&maximumRecords=1&httpAccept=application/geo%2Bjson&&platform=Aqua",
                                                        "count": 1
                                                },
                                                {
                                                        "actualTerm": "ENVISAT",
                                                        "query": {
                                                                "count": 1,
                                                                "searchTerms": "vegetation",
                                                                "startIndex": 1,
                                                                "sru:recordSchema": "server-choice",
                                                                "eo:platform": "ENVISAT"
                                                        },
                                                        "requestUrl": "http://fedeo.esa.int/opensearch/request?query=vegetation&startRecord=1&maximumRecords=1&httpAccept=application/geo%2Bjson&&platform=ENVISAT",
                                                        "count": 1
                                                }
                                        ]
                                }
                        ]
                }
        ]
}

DataSource

The following figure shows the DataSource schema.

Figure 40. DataSource Schema

The complete description of DataSource is given in Table 31.

Table 31. DataSource object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$..datasource.type}	Type of the object. This property has the fixed value "DataSource".	Range: String Fixed value: "DataSource"	Zero or one (optional)
displayLabel _{$..datasource.displayLabel}	Display label for data source.	Domain: DataSource Range: string	Zero or one (optional)
description _{$..datasource.description}	Description of data source.	Domain: DataSource Range: string	Zero or one (optional)
baseURL _{$..datasource.baseURL}	URL representing data source.	Domain: DataSource Range: string	Zero or one (optional)
facets _{$..datasource.facets}	List of facets and corresponding faceted search results.	Domain: DataSource Range: array of Facet as defined in Table 32.	Zero or one (optional)

DataSource encoding example

{
        "displayLabel": "FedEO",
        "description": "Federated Earth Observation",
        "baseURL": "http://fedeo.esa.int/opensearch",
        "facets": []
}

Facet

The following figure shows the Facet schema.

Figure 41. Facet Schema

The complete description of Facet is given in Table 32.

Table 32. Facet object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$..facets[*].type}	Type of the object. This property has the fixed value "Facet".	Range: String Fixed value: "Facet"	Zero or one (optional)
displayLabel _{$..facets[*].displayLabel}	Display label for OpenSearch parameter used as an index for the facet count.	Domain: Facet Range: string	Zero or one (optional)
description _{$..facets[*].description}	Description of the facet.	Domain: Facet Range: string	Zero or one (optional)
index _{$..facets[*].index}	OpenSearch parameter used as an index for the facet count.	Domain: Facet Range: string	Zero or one (optional)
relation _{$..facets[*].relation}	Relation used to group search results.	Domain: Facet Range: string	Zero or one (optional)
terms _{$..datasource.terms}	List of terms for current facet.	Domain: Facet Range: array of Term as defined in Table 33.	One (mandatory)

Facet encoding example

{
        "displayLabel": "Platform",
        "index": "eo:platform",
        "relation": "=",
        "terms": [
                {
                        "actualTerm": "PROBA-V",
                        "query": {
                                "count": "1",
                                "searchTerms": "vegetation",
                                "startIndex": "1",
                                "sru:recordSchema": "server-choice",
                                "eo:platform": "PROBA-V"
                        },
                        "requestUrl": "http://fedeo.esa.int/opensearch/request?query=vegetation&startRecord=1&maximumRecords=1&httpAccept=application/geo%2Bjson&&platform=PROBA-V",
                        "count": 24
                }
        ]
}

Term

The following figure shows the Term schema.

Figure 42. Term Schema

The complete description of Term is given in Table 33.

Table 33. Term object properties
JSON Property	Definition	Data type and values	Multiplicity and use
type _{$..terms[*].type}	Type of the object. This property has the fixed value "Term".	Range: String Fixed value: "Term"	Zero or one (optional)
actualTerm _{$..terms[*].actualTerm}	Actual term.	Domain: Term Range: string	One (mandatory)
query _{$..terms[*].query}	Request parameters to retrieve the search results corresponding to the current term.	Domain: Term Range: Query as defined in OGC 17-047.	Zero or one (optional)
requestURL _{$..terms[*].requestURL}	Request URL to retrieve the search results corresponding to the current term.	Domain: Term Range: string (URI)	Zero or one (optional)
count _{$..terms[*].count}	Number of results corresponding to this term.	Domain: Term Range: integer	One (mandatory)

Term encoding example

{
        "actualTerm": "ENVISAT",
        "query": {
                "count": "1",
                "searchTerms": "vegetation",
                "startIndex": "1",
                "sru:recordSchema": "server-choice",
                "eo:platform": "ENVISAT"
        },
        "requestUrl": "http://fedeo.esa.int/opensearch/request?query=vegetation&startRecord=1&maximumRecords=1&httpAccept=application/geo%2Bjson&&platform=ENVISAT",
        "count": 1
}

8. Software Design

8.1. Software static architecture

The diagram below shows the original allocation of components to the different participants.

Figure 43. Software static architecture

During the Testbed-15 EOPAD thread, the following client and server-side components were deployed and used for integration testing.

Figure 44. Deployment Diagram

8.2. Interfaces context

The diagram below shows the interoperability tests that were performed.

Figure 45. Component Diagram

8.3. Software components design

8.3.1. D117 - Catalog Server (Deimos)

The Deimos software was developed as a plugin for CKAN, an Open Source data portal used in numerous Open Data portals worldwide, including in the Earth Observation domain such as H2020 NextGEOSS or AmeriGEOSS.

The catalogue server provides two interfaces for the users:

Service Interface: This interface allows other catalogue client or another application to discover applications and services through faceted search. This interface has been implemented as an API following the OpenSearch Specification defined in section 6.2 of the Data Model. The python shell of the OpenAPI was generated using the .yaml file and the Swagger Editor Tool. The catalogue also provides a web based user interface (See "D122 - Client (Deimos)") to discover new services in the catalogue.

The user is able to discover services via the OpenSearch API as well. Below are some examples of the OpenSearch Query and respective response. In this example the user is querying by organization, bounding box, free text, unique id, keyword and time interval.

http://servicecatalogue-ogctestbed15.deimos.pt/smi/services?maximumRecords=2&startRecord=1&organisation_name=ESA/ESRIN&bbox=-180,-90,-100,90&query=near&uid=MultiSensorNDVI&subject=NDVI&startDate=2019-06-19T00:00:00&endDate=2019-06-19T20:30:00

{
  "facetedResults": {
    "facets": [ ]
  },
  "features": [...],
  "id": "http://servicecatalogue-ogctestbed15.deimos.pt/smi/services?maximumRecords=2&startRecord=1&organisation_name=ESA%2FESRIN&bbox=-180,-90,-100,90&query=near&uid=MultiSensorNDVI&subject=NDVI&startDate=2019-06-19T00:00:00&endDate=2019-06-19T20:30:00",
  "itemsPerPage": 2,
  "queries": {
    "request": [
      {
        "geo:bbox": "-180,-90,-100,90",
        "count": 2,
        "time:end": "2019-06-19T20:30:00",
        "eo:keyword": "NDVI",
        "eo:organisationName": "ESA/ESRIN",
        "os:searchTerms": "near",
        "time:start": "2019-06-19T00:00:00",
        "startIndex": 1,
        "geo:uid": "MultiSensorNDVI"
      }
    ]
  },
  "startIndex": 1,
  "totalResults": 1,
  "type": "FeatureCollection"
}

This interface is aligned with the specifications mentioned in the Use Case C (Application discovery) :

Bob, a user of applications, uses the Catalogue Service to find an application to perform a specific processing algorithm such as NDVI. He fills a form with the available search criteria or uses a free text form to specify some key words and then the service returns all the applications which matches the specified criteria. The interaction between Bob and the Catalogue Service is mediated by a client of the service which provides a GUI to ease the user experience of Bob.

This use case is also implemented as part of the activity D122 - Client (Deimos)

Service Management Interface: This interface allows catalog clients or other applications to create, update and delete information about applications/services. This interface also provides a web based user interface to perform the same set of operations.

http://servicecatalogue-ogctestbed15.deimos.pt/smi/ returns the Landing Page.

The below section provides examples for each of the applicable use cases which have been implemented.

Use Case A (Application/Service lifecycle management from user/operator)

Use Case description 1 : Alice activates the Catalogue Service management interface to register her application (passing all information required by the data model).

The registration of a new service is possible via the Catalogue Frontend and the OpenAPI interface. Below are the examples:

Catalogue frontend:

Deimos3 AddServiceFrontend

OpenAPI: To submit a service into the catalogue via API, the service owner can make a POST request to an API url where the body is the service GeoJSON metadata as specified in section 7 of the Data Model.

An additional validation step is performed for both the frontend catalogue as well as the API. The validation step verifies if the service is already catalogued, and if so the appplication will inform the service owner of the existing conflict, so the service owner can take the proper approach to resolve the conflict.

In case of a successful registration of the service into the catalogue, both a code 201 and the message Service or application has been successfully inserted are return to the service owner, as seen in the following figure.

Deimos5 AddServiceSuccess

Use Case Description 2: The service checks that Alice is authorized to register the new application and then fulfill her request.

The catalogue frontend requires users to create a profile and register themselves as an authorized user. The users are needed to provide his/her credentials into the Catalogue user interface to register a new service. The below image illustrates the login page of the catalogue:

Deimos4 Login

The CKAN solution supports a structure of Organizations. These are used to create, manage and publish collections of services. Users can have different roles within an Organization, depending on their level of authorization. The following roles are currently available in the catalogue:

Member - The user is able to view the datasets that belong to the organization.
Editor - The user has permissions within the organization to publish, edit and delete services.
Administrator - Besides the editor capabilities, the user is also able to delete the organization.

The role within the organization is given and managed by the system administrator upon the user registration. In the figures below, the user on the left has Editor permissions within the Compusult organization, and thus is able to manage the dataset (edit / delete). While the user on the right only has member permissions, and thus is only able to view the dataset. This is visible by the Manage button on the service page.

Deimos6 EditorRights Deimos7 NoEditorRights

The user authentication specified in the OpenAPI API description is performed via CKAN API Key, which contains the user permissions for each of the Organizations to which the user belongs.

Use Case Description 3 :Alice performs a simple query to be presented with a list of only her applications and checks that the application is registered, asking for its details.
The service returns the record of the application

The Catalogue user interface provides the list of services already registered in the catalogue. To retrieve the list of only the user applications, the user can filter using the Organizations to which they belong.

Deimos8 JustUserServices

An example Query to discover the user services via an OpenAPI desciption could be as follows: http://servicecatalogue-ogctestbed15.deimos.pt/smi/services?organisation_name=ESA/ESRIN

Use Case Description 4: Alice updates the metadata information of her application
The service checks that Alice is authorized to update the information of the application and then modifies it.

The user is able to update the metadata record of the service via the catalogue user interface and the OpenAPI description. The catalogue ensures that the user is authorized to update the service through the process described previously in the service posting.

Use Case Description 5: Alice requests the deletion of the application in the Catalogue Service.The service checks that Alice is authorized to delete the information of the application and then deletes it

The user is able to delete the metadata record of the service via the catalogue user interface and the OpenAPI description. The catalogue ensures that the user is authorized to delete the service through the process described previously in the service posting.

The user can update and/or delete a service through the service management page in the catalogue front-end (Figure below) or via PUT or DELETE request via OpenAPI description (example provided below). In this case, the user needs to mention the service name in the request. http://servicecatalogue-ogctestbed15.deimos.pt/smi/services/multisensorndvi

Deimos9 ServiceManagement

Use Case B (Application creation/deletion via M2M interaction)

The catalogue implementation is aligned with the Use case B where the following set of operations can be performed with the OpenAPI interface provided by the catalogue. All the features have been explained in the previous Use Case A.

Metadata published

Using the CKAN solution there are mandatory metadata fields when publishing a service, such as identifier and title, while the remaining metadata fields are stored as extra fields at the discretion of the catalogue owner. Also using a feature of CKAN the entire GeoJSON is stored as a resource of the service. The figure below illustrates some of the metadata fields catalogued and displayed to the users.

Deimos10 Metadata

Interoperability tests

An interoperability test was carried out between this catalogue server (D117) and the clients (D122 and D123). The goal of this test is to validate the ability of the clients to register a new service to the catalogue and browse, discover update and delete the services using the API exposed by the catalogue. The results of these tests are presented below:

Deimos12 Compusult

Lessons Learned

During the development of the catalogue and respective OpenAPI, it has been found that there are some topics that require further discussion in order to determine the correct path ahead.

Catalogue:

The parsing of the service GeoJSON can quickly became quite complex and extensive due to the fact that there is a high variance and length that can occur within the structure of any given GeoJSON feature. In the solution adopted (CKAN), the complete GeoJSON is stored as a resource, and only a few metadata fields are collected. If this solution is adopted, it is recommended that a metadata field list is compiled, such that it contains the fields that are queryable. As an example, the field that contains the default value of certain input maybe holds no interest querywise, and thus would not be catalogued, but this value would still be within the complete service GeoJSON (resource).

The catalogue can be extended to categorise the services based on the offering types for example - WPS, WMS, Application Package etc.

OpenAPI:

During the development OpenAPI there were two topics that will require further discussion in further iterations.

The first topic regards the OpenSearch Description Document, where the Parameter Extension of OpenSearch is not expressive enough to be able to represent the different components inside a single parameter value. Such parameter is sru:facetLimit, which can assume different values and structures: fixed strings (allowed facets), fixed integers (no facet search), integers set by the user or a mix of fixed strings and dynamic integer.

The second topic regards the authorization / security permission within both the OpenAPI and Catalogue. Since there were no requirements / guidelines regarding the authentication and authorization, the approach adopted was to use the user manager incorporated into our catalogue solution, and propagate it to the OpenAPI via API-KEY header. However, if this topic is not thoroughly discussed, it might lead to multiple implementations by each developer. Leading to the clients to adapt to each API instead of having a uniform way of access.

8.3.2. D121 - Catalog Server (GMU)

Description

The implementation of the catalogue service is implemented and integrated with GeoNetwork – an Open Source catalog application. The basic design is to internally map input or output in GeoJSON to metadata in ISO 19139. This design and development resulted in re-using the browsing capabilities of GeoNetwork without much changes.

Interfaces implemented

The interfaces implemented in GMU Catalog service are shown in Table 34.

Table 34. Interfaces and Specifications Implemented by GMU OGC Catalog Service
Services	URL	Specifications
OpenAPI service	https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a	OpenAPI + GeoJson EO. Refer to Catalogue Service Specification for details. Related document numbers: OGC 17-047r1, OGC 07-045r1, OGC 17-003r0
Browse Page	Catalog Browse	Geonetwork-based view & browse
CAT 3.0	https://cloud.csiss.gmu.edu/ows15/geonet/srv/eng/cat3	Related document numbers: OGC 12-168r6, OGC 12-176r7
CSW 2.0.2	https://cloud.csiss.gmu.edu/ows15/geonet/srv/eng/csw	Related document numbers: OGC 07-06r1, OGC 13-084r2

Metadata published

The GMU Catalog service is provided as a transactional service that allows the insertion/editing/deletion of records that can be injected by either of the following media types:

Requests and responses in GeoJSON EO encoding as specified in [Chapter-6].
Requests and responses in ISO 19139 encoding through CAT 3.0
Requests and responses in ISO 19139 encoding through CSW 2.0.2

For this testbed, the OpenAPI is a new development. The following typical use cases are given and exampled in details.

OpenAPI

The OpenAPI is implemented as specified in [Chapter-6]. The API document is posted in SwaggerHub where code-generation of server-stub and client-stub can be automated. The interface can be viewed in GMU Catalog Service OpenAPI interface.

Figure 46. GMU Catalog Service OpenAPI interface

Use Case 1 - Landing Page

The first use case is to show what is returned by accessing the landing page. One example request is shown in Table 35.

Table 35. Use Case 1 - Landing Page of GMU OGC Catalog Service
Item	Content
Path	https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a
Request	Method	GET
Request	Headers	Accept: application/json
Full request example by Curl	curl --header "Accept: application/json" https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3
Response	Status	HTTP/1.1 200
	Headers	Content-Type: application/json;charset=UTF-8
	Body	{"links":[{"href":"http://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/","rel":"self","type":"application/json","title":"OpenAPI Catalog Landing Page"},{"href":"http://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/api","rel":"service","type":"application/openapi+json;version=3.0","title":"OpenAPI Definition in JSON"},{"href":"http://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/api","rel":"service","type":"text/yaml","title":"OpenAPI Definition in YAML"},{"href":"http://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/api","rel":"service","type":"application/sru+xml","title":"OpenAPI Definition in SRU"},{"href":"http://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/api","rel":"service","type":"application/json;profile=http://explain.z3950.org/dtd/2.0/","title":"OpenAPI Definition in Z3950 JSON"},{"href":"http://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/conformance","rel":"conformance","type":"application/json","title":"OGC conformance class implemented by this Catalog"},{"href":"http://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services","rel":"data","type":"application/json","title":"Services and appliccation metadata"}]}

Use Case 2 - Get OpenAPI specification

The specification of OpenAPI can be retrieved in different formats. One request to retrieve specification in YAML is shown in Table 36.

Table 36. Use Case 2 - Get OpenAPI specification
Item	Content
Path	https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/api
Request	Method	GET
Request	Headers	Accept: text/yaml
Full request example by Curl	curl --header "Accept: text/yaml" https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3/api
Response	Status	HTTP/1.1 200
	Headers	Content-Type: text/yaml;charset=UTF-8
	Body	openapi: "3.0.0" info: description: "Test Service, following ISO/OGC nterface guidelines, to Earth Observation\ \ metadata." title: "Testbed 15 Service Catalogue" contact: name: "CSISS" url: "http://csiss.gmu.edu" email: "gyu@gmu.edu" version: "1.0.0" license: name: "Apache 2.0" url: "http://www.apache.org/licenses/LICENSE-2.0.html" x-logo: url: "http://csiss.gmu.edu/csiss_logo_big.gif" x-providerName: "Copyright 2019, George Mason University." x-serviceName: "OGCTestCatalogue" servers: - url: "https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a" ......

Use Case 3 - Get Service Conformance

The example in Table 37 shows the request to retrieve service conformance declaration.

Table 37. Use Case 3 - Get Service Conformance
Item	Content
Path	https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/conformance
Request	Method	GET
Request	Headers	Accept: application/json
Full request example by Curl	curl --header "Accept: application/json" https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3/conformance
Response	Status	HTTP/1.1 200
	Headers	Content-Type: application/json;charset=UTF-8
	Body	`{"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"]}`

Use Case 4 - Get All Services

The path "/services" provide the base to search and retrieve services by given crtieria. All the services can be retrieved if no parameter is used. Table 38 shows the request and its skeleton response.

Table 38. Use Case 4 - Get All Services
Item	Content
Path	https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services
Request	Method	GET
Request	Headers	Accept: application/json
Full request example by Curl	curl --header "Accept: application/geo+json" curl --header "Accept: application/geo+json" https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services
Response	Status	HTTP/1.1 200
	Headers	Content-Type: application/geo+json
	Body	`{"@context":"https://www.opengis.net/spec/os-geojson/1.0","type":"FeatureCollection","id":"https://cloud.csiss.gmu.edu/ows15/rest3a/ogc/cat3a/services","properties":{},"features":[ ...... ],"totalResults":10,"startIndex":1,"itemsPerPage":10,"queries":{"type":"Queries","request":[{"type":"Query"}]}}`

Use Case 5 - Browse All Services

When services are registered into the catalog, they can be browsed using the browser of GeoNetwork. The portal is given in Table 39. The viewer is exampled in Use Case 5 - Browse GMU Catalog Services.

Table 39. Use Case 5 - Browse All Services
Item	Content
Path	https://cloud.csiss.gmu.edu/geonet/

Figure 47. Use Case 5 - Browse GMU Catalog Services

Use Case 6 - Transaction - insert

An example insert transaction request is shown in Table 40.

Table 40. Use Case 6 - GMU Catalog Service Transaction - Insert
Item	Content
Path	https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services
Request	Method	POST
	Headers	Accept: application/json
	Headers	Content-Type: application/geo+json
Full request example by Curl	curl -u yourusername:yourpassword -d "@data.json" -X POST --header "Accept: application/geo+json" --header "Content-Type: application/geo+json" https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services
Content of data.json	`{"type": "Feature","id": "http://52north.org/testbed15/eopad/SentinelQualityAreaOfInterestTEST",.....}`
Response	Status	HTTP/1.1 200
	Headers	Content-Type: application/geo+json;charset=UTF-8
	Body	`{"description":"Service or application has been successfully inserted"}`

Use Case 7 - Get a Specific Service by id

The service metatadata can be retrieved by using a specific identifier in the path as shown in Table 41.

Table 41. Use Case 7 - GMU Catalog Service Get a Specific Service by ID
Item	Content
Path	https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services/org.52north.dev.testbed.eopad.rest
Request	Method	GET
Request	Headers	Accept: application/geo+json
Full request example by Curl	curl --header "Accept: application/geo+json" -X GET https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services/org.52north.dev.testbed.eopad.rest
Response	Status	HTTP/1.1 200
	Headers	Content-Type: application/geo+json
	Body	`{"id":"https://testbed.dev.52north.org/eopad/rest","type":"Feature","properties":{"identifier":"org.52north.dev.testbed.eopad.rest","kind":"http://inspire.ac.europa.eu/metadata-codelist/ResourceType/service","title":"52°North EOPAD javaPS", ...... }`

Use Case 8 - Transaction - update a Specific Service

Table 42 shows one example to update a speccific service by using identifier.

Table 42. Use Case 8 - GMU Catalog Service Transaction - update a Specific Service
Item	Content
Path	https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services/org.52north.dev.testbed.eopad.rest
Request	Method	PUT
	Headers	Accept: application/json
	Headers	Content-Type: application/geo+json
Full request example by Curl	curl -u yourusername:yourpassword -d "@data2.json" -X PUT --header "Accept: application/json" --header "Content-Type: application/geo+json" https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services/org.52north.dev.testbed.eopad.rest
Content of data.json	`{"id":"https://testbed.dev.52north.org/eopad/rest","type":"Feature","properties":{"identifier":"org.52north.dev.testbed.eopad.rest","kind":"http://inspire.ac.europa.eu/metadata-codelist/ResourceType/service","title":"52°North EOPAD javaPS", ...... }`
Response	Status	HTTP/1.1 200
	Headers	Content-Type: application/json;charset=UTF-8
	Body	`{"description":"Service has been successfully updated."}`

Use Case 9 - Transaction - delete a Specific Service

A specific service can be deleted as shown in Table 43.

Table 43. Use Case 9 - GMU Catalog Service Transaction - delete a Specific Service
Item	Content
Path	https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services/org.52north.dev.testbed.eopad.rest
Request	Method	DELETE
Request	Headers	Accept: application/json
Full request example by Curl	curl -u yourusername:yourpassword -d "@data2.json" -X DELETE --header "Accept: application/json" https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services/org.52north.dev.testbed.eopad.rest
Response	Status	HTTP/1.1 204
	Headers	Content-Type: application/json;charset=UTF-8
	Body	(No content returned)

Interoperability tests

The Catalog service OpenAPI has been tested and verified with examples. These examples include example-catalog-insert-ndvi, example-catalog-insert-sentinel-quality, and example-catalog-insert-wps-service. Service discovery and transaction use cases have been tested.

Lessons learned

The GMU catalog service was implemented following the specification outlined in Catalogue Service Specification. The test cases showed that specifications worked in supporting discovery and transaction of services in a fully-functional catalog with GeoJSON encoding schema. The specifications, including the newly released standard – OGC 17-047r1, are comprehensive in fulfillment of service transaction and discovery using a resource-oriented approach.

8.3.3. D122 - Client (Deimos)

Description

The Catalogue Server D117 also provides a web based user interface to discover new services in the catalogue. This service is accessible at http://servicecatalogue-ogctestbed15.deimos.pt/.

The catalogue provides a web based user interface to discover services by browsing through the catalogue and/or by searching in a free text search box. The figure below shows the search capability of the catalogue using free text, for example ndvi etc.

For this task DEIMOS has also developed a web based client tool to allow users to register, delete and discover services to two catalogues ( D117- DEIMOS and D121- GMU). This client tool also allows the users to deploy applications in mutiple clouds and compose and execute service chain workflows. The sections below will provide an overview of this client tool:

The above image shows the interface where the user can choose the catalogue to register services by providing the GeoJSON file containing the metadata of the service. In this case the user can choose either the Deimos Catalogue (D117) or GMU catalogue (D121) to register the service.

The web client will notify the users once the service has been successfully registered. The above example shows the message when the user registers a service in the DEIMOS Catalogue (D117)

Similarly, the user can delete an already registered service from the Deimos Catalogue (D117) or GMU catalogue (D121). The users are presented with the list of services registered in the catalogue to choose the service to delete. The user access mechanism ensures that the user has the sufficient access priveleges to delete the service.

The users are presented with a message once the service has been removed successfully from the catalogue.

The users can discover services registered in both the Catalog : DEIMOS and GMU from this client. The below image shows the service discovery interface: image::images/Deimos_Clinet_4.png[align="center"]

The results of the service discovery is presented in the client user interface. The below image illustartes that: image::images/Deimos_Clinet_5.png[align="center"]

The users can compose a workflow using this web based tool. The below example shows the workflow composition canvas.

The users can drag and drop the components and configure the components to identify the WPS.

In this case the user is configuring a processing module by selecting the WPS service. The drop-down menu presents the users with the list of WPS services discovered from the catalogue. The tool validates the WPS against the OGC standards before processing further.

Once the processing model is validated, the user needs to configure the input parameter. In the above example the reference to the input data is provided along with the type of data.

Once the processing model is validated , the user needs to configure the output parameter. The user defines the output data identifier.

the above example shows inclusion of the following service in the service chain and configuring the service in the similar way described earlier.