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
COPYRIGHT
Copyright © 2019 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
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.
- 1. Subject
- 2. Executive Summary
- 3. References
- 4. Terms and definitions
- 5. Overview
- 6. Catalogue Service Specification
- 7. Data Model
- 7.1. GeoJSON EOPAD Metadata Encoding
- 7.1.1. Design Approach
- 7.1.2. Requirements class: Feature
- 7.1.3. Requirements class: Metadata Information
- 7.1.4. Requirements class: Service Identification
- 7.1.5. Requirements class: Rights Information
- 7.1.6. Requirements class: Descriptive Keywords
- 7.1.7. Requirements class: Related URL
- 7.1.8. Requirements class: Spatial Information
- 7.1.9. Requirements class: Acquisition Information
- 7.2. GeoJSON Search Response Encoding
- 7.1. GeoJSON EOPAD Metadata Encoding
- 8. Software Design
- 8.1. Software static architecture
- 8.2. Interfaces context
- 8.3. Software components design
- 9. Arctic Discovery Catalogue
- Appendix A: Abstract Test Suite
- Appendix B: Interpreting JSON as JSON-LD
- Appendix C: Encoding 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 |
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
-
IETF: RFC 7159, The JavaScript Object Notation (JSON) Data Interchange Format, March 2014
-
DCMI: Dublin Core DCMI Metadata Terms, Dublin Core Metadata Initiative, 14/06/2012
-
W3C: Data Catalog Vocabulary (DCAT), W3C Recommendation 16 January 2014
-
W3C: Linked Data Platform 1.0, W3C Recommendation 26 February 2015
-
W3C: JSON-LD 1.0, A JSON-based Serialization for Linked Data, W3C Recommendation 16 January 2014
-
W3C: JSON-LD 1.0 Processing Algorithms and API, W3C Recommendation 16 January 2014
-
W3C: PROV-O: The PROV Ontology, W3C Recommendation 30 April 2013
-
W3C: Data on the Web Best Practices: Data Quality Vocabulary, W3C Working Group Note 15 December 2016
-
W3C: RDF 1.1 XML Syntax, W3C Recommendation 25 February 2014
-
W3C: RDF 1.1 Turtle, Terse RDF Triple Language, W3C Recommendation 25 February 2014
-
OASIS: OASIS - searchRetrieve: Part 3. APD Binding for SRU 2.0 Version 1.0, OASIS Standard, 30 January 2013
-
OASIS: OASIS - searchRetrieve: Part 4. APD Binding for OpenSearch Version 1.0, OASIS Standard, 30 January 2013
-
OASIS: OASIS - searchRetrieve: Part 7. Explain Version 1.0, OASIS Standard, 30 January 2013
-
OGC: OGC 11-052r4, OGC® GeoSPARQL - A Geographic Query Language for RDF Data
-
OGC: OGC 11-035r1, EO Product Collection, Service and Sensor Discovery using the CS-W ebRIM Catalog
-
OGC: OGC 13-026r9, OGC® OpenSearch Extension for Earth Observation (OpenSearch-EO)
-
OGC: OGC 13-068, OGC® OpenSearch Extension for Correlated Search
-
OGC: OGC 14-055r2, OGC® OWS Context GeoJSON Encoding Standard
-
OGC: OGC 17-047, OGC® OpenSearch-EO GeoJSON(-LD) Response Encoding Standard (To be published soon)
-
OGC: OGC 17-084, EO Collection GeoJSON(-LD) Encoding Standard
-
OGC: OGC 18-049r1, OGC Testbed-14: Application Package Engineering Report
-
OGC: OGC 18-050r1, OGC Testbed-14: ADES & EMS Results and Best Practices Engineering Report
-
OGC: OGC 19-062, OGC API Hackathon 2019 Engineering Report (To be published soon)
-
OAI: OpenAPI Specification, Version 3.0.2, OpenAPI Initiative
-
OpenSearch community: OpenSearch Parameter Extension, Version 1.0 Draft 2
-
OpenSearch community: OpenSearch SRU Extension, Version 1.0 Draft 1
-
OpenSearch community: OpenSearch Semantic Extension, Version 1.0 Draft 1
-
ESDIS: Unified Metadata Model Services (UMM-S), Revision 1.2, Earth Science Data and Information Systems (ESDIS) Project
3.2. Other references
-
W3C: JSON-LD 1.1, A JSON-based Serialization for Linked Data, W3C Working Draft 10 May 2019
-
W3C: Data Catalog Vocabulary (DCAT) - Version 2, W3C Candidate Recommendation 03 October 2019
-
W3C: Data Catalog Vocabulary (DCAT) - Version 2 - W3C Working Draft 28 May 2019
-
Negotiating Profiles in HTTP, draft-svensson-accept-profile-00
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
<?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?}&query={searchTerms?}&startRecord={startIndex?}&startPage={startPage?}&maximumRecords={count?}&startDate={time:start?}&endDate={time:end?}&title={eo:title?}&publisher={dc:publisher?}&bbox={geo:box?}&uid={geo:uid?}&organisationName={eo:organisationName?}&productType={eo:productType?}&platform={eo:platform?}&instrument={eo:instrument?}&classifiedAs={semantic:classifiedAs?}&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:
-
[OGC10-032r8] (Geo and time)
-
[OGC13-026r9] (Earth Observation)
-
[OGC13-068] (Correlated search)
-
SRU Extension of OpenSearch (Faceted search)
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.
Search Parameter | Description | Metadata mapping | Examples |
---|---|---|---|
os:searchTerms |
Free text search. |
$.properties.abstract |
query=vegetation |
eo:keyword |
Search for matching keyword. |
$.properties.keyword |
keyword=vegetation |
eo:title |
Search for matching title. |
$.properties.title |
|
geo:uid |
Retrieve metadata for service or application via its identifier. |
$.properties.identifier |
|
sru:facetLimit |
Number of counts that should be reported per facet field. |
Not applicable |
|
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:
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.
-
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.
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.
6.3.1. Landing Page
The /
(Landing Page) path is required to comply with the OGC API-Common draft specification.
The following request returns the Landing Page.
GET https://fedeo.esa.int/ Accept: application/json
{
"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
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.
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.
6.3.3. Conformance statements
The /conformance
(Conformance statements) path is required to comply with the in development OGC API - Common draft specification.
The following request returns the Conformance statements.
GET https://fedeo.esa.int/conformance Accept: application/json
{
"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.
The following request returns the Collections metadata.
GET https://fedeo.esa.int/collections Accept: application/json
{
"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.
The following diagram shows the interaction with the above resources to search, create, update or delete metadata items in the catalogue.
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]
-
OGC API Features [OGC17-069r2]
-
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.
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.
Resource | $.type | JSON-LD @type | $.properties.kind or JSON-LD dct:type |
---|---|---|---|
EO Service/Application |
Feature |
dcat:DataService |
|
EO Collection |
Feature |
dcat:Dataset |
|
EO Product |
Feature |
gj:Feature |
The complete description of Feature is given in Table 4. Most properties are inherited from the Feature object defined in [OGC14-055r2].
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
@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 of the element. This property is a string with fixed value "Feature". |
Property |
One (mandatory) |
id |
Unique identifier for the application or service (URI). |
Property |
One (mandatory) |
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 |
Zero or one (optional) |
geometry |
Contains the description of the geometry of the feature. The value shall be either a Geometry object or a JSON null value. |
Property |
One (mandatory) |
properties |
Groups all other properties of the feature not covered by the properties higher in this table as imposed by [GeoJSON]. |
Property |
One (mandatory) |
{
"type": "Feature",
"id": "http://fedeo.esa.int/services/MultiSensorNDVI",
"bbox": [
-180,
-90,
180,
90
],
"geometry": {...},
"properties": {...}
}
{
"@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.
The complete description of Properties is given in Table 5.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
acquisitionInformation |
Related acquisition information (related platform and instruments). |
Property |
Zero or one (optional) |
spatial |
Alternative geometry information compliant with typical [GeoDCAT-AP] encoding. |
Property |
Zero or one (optional) |
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.
The complete description of MetadataInformation is given in Table 6.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
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 |
Date of first availability of the metadata record. |
Range: DateTime |
Zero or one (optional) |
lang |
Metadata language, not empty with an RFC-3066 code as defined in [OGC14-055r2]. |
Range: String |
Zero or one (optional) |
{
"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.
The complete description of ServiceIdentification is given in Table 7.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
title |
Human readable title given to the service or processing application. Defined in [OGC14-055r2]. |
Range: String |
One (mandatory) |
identifier |
Identifier given to the service or processing application. Defined in [OGC14-055r2]. |
Range: String |
One (mandatory) |
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 |
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 |
Description of the service or processing application content or purpose as defined in [OGC14-055r2]. |
Range: String |
Zero or one (optional) |
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 |
A bibliographic reference for the resource. Equivalent to mandatory ServiceCitation in [UMM-S] §2.2.1.16. |
Range: String |
Zero or one (optional) |
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 |
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 |
Encoding of provenance information. |
Range: Array of ProvenanceStatement (Table 11) |
Zero or more (optional) |
wasUsedBy |
Description of the conformity of the metadata (DQ_ConformanceResult). |
Range: Array of Activity (Table 12) |
Zero or more (optional) |
{
"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."
}
{
"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,
The complete description of ServiceContact is given in Table 8.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
publisher |
An entity or agent responsible for publishing the resource (role is "Publisher"). Defined in [OGC14-055r2]. |
Property |
Zero or one (optional) |
authors |
Entities or persons primarily responsible as authors of the resource (role is "Author"). Defined in [OGC14-055r2]. |
Property |
Zero or one (optional) |
contactPoint |
Entities or persons acting as primary contact point (role is "Point of Contact"). Defined in [DCAT]. |
Property |
Zero or one (optional) |
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 |
Zero or one (optional) |
{
"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].
The complete description of Attribution is given in Table 9.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property is a string with fixed value "Attribution". |
Property |
Zero or one (optional) |
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. |
Property |
One (mandatory) |
agent |
Organization or person fulfilling the above "role". Any properties allowed by vcard:Kind are allowed. |
Property |
One (mandatory) |
{
"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].
The complete description of Agent is given in Table 10.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property can have one of the following fixed values "Agent" (or "Kind"), "Person" (or "Individual"), "Organization". |
Domain: Agent |
Zero or one (optional) |
name |
Human readable name of author (or entity). Defined in section 7.1.1.7 of [OGC14-055r2]. |
Domain: Agent |
Zero or one (optional) |
email |
Email address of author (or entity). Defined in [OGC14-055r2]. |
Domain: Agent |
Zero or one (optional) |
uri |
URI of author (or entity). Defined in [OGC14-055r2]. |
Domain: Agent |
Zero or one (optional) |
{
"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].
The complete description of ProvenanceStatement is given in Table 11.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "ProvenanceStatement". |
Property |
Zero or one (optional) |
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 |
One (mandatory) |
{
"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].
The complete description of Activity is given in Table 12.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "Activity". |
Property |
Zero or one (optional) |
generated |
Refers to the conformity result which is encoded as an Entity. |
Property |
One (mandatory) |
qualifiedAssociation |
Refers to the specification against which conformity is expressed, encoded as an Association. |
Property |
One (mandatory) |
{
"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].
The complete description of Entity is given in Table 13.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "Entity". |
Property |
Zero or one (optional) |
degree |
URI defining the degree of conformity. The INSPIRE Registry maintains a URI set at http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity. |
Property |
One (mandatory) |
description |
Description of the result. |
Property |
Zero or one (optional) |
{
"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].
The complete description of Association is given in Table 14.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "Association". |
Domain: Association |
Zero or one (optional) |
hadPlan |
Set of actions or steps intended by one or more agents to achieve some goals. |
Domain: Association |
One (mandatory) |
Plan
The proposed encoding is aligned with [GeoDCAT-AP] §II.14 and [PROV-O].
The complete description of Plan is given in Table 15.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "Plan". |
Domain: Plan |
Zero or one (optional) |
wasDerivedFrom |
Refers to the specification against which conformity is expressed, encoded as a Standard. |
Domain: Plan |
One (mandatory) |
{
"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].
The complete description of Standard is given in Table 16.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "Standard". |
Domain: Standard |
Zero or one (optional) |
title |
/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result |
Domain: Standard |
One (mandatory) |
issued |
/gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gmd:result |
Domain: Standard |
Zero or one (optional) |
{
"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.
The main properties of CompoundPriceSpecification are listed in Table 17. For additional properties, please refer to [schema.org].
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "CompoundPriceSpecification". |
Domain: CompoundPriceSpecification |
Zero or one (optional) |
description |
Textual description. |
Domain: CompoundPriceSpecification |
Zero or one (optional) |
priceComponent |
Price components according to multiple dimensions that apply in combination to determine the total price. |
Domain: CompoundPriceSpecification |
Zero or one (optional) |
{
"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].
The complete description of RightsInformation is given in Table 18.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
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 |
Zero or one (optional) |
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 |
Zero or one (optional) |
rights |
Information about rights held in and over the application or service. See [OGC14-055r2] §7.1.2.7. |
Property |
Zero or one (optional) |
LicenseDocument
The proposed encoding is aligned with [GeoDCAT-AP] §II.15.
The complete description of LicenseDocument is given in Table 19.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "LicenseDocument". |
Property |
Zero or one (optional) |
label |
Free text content of the corresponding ISO19139-2 metadata property gmd:useLimitation. |
Property |
One (mandatory) |
RightsStatement
The proposed encoding is aligned with [GeoDCAT-AP] §II.15 and [DCMI].
The complete description of RightsStatement is given in Table 20.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "RightsStatement". |
Property |
Zero or one (optional) |
label |
Free text content of the corresponding ISO19139-2 metadata properties gmd:accessConstraints and gmd:otherConstraints. |
Property |
One (mandatory) |
Use Constraints
Use Constraints shall be implemented through the LicenseDocument (Table 19) object.
{
"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.
{
"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.
The complete description of DescriptiveKeywords is given in Table 21.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
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 |
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 |
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 |
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) |
{
"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"
}
]
}
Category
The complete description of Category is given in Table 22.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "Category". |
Domain: Category |
Zero or one (optional) |
scheme |
Identification of the code-list defining the keyword. Defined in section 7.1.1.15 of [OGC14-055r2]. |
Domain: Category |
Zero or one (optional) |
term |
Identification of the keyword. See also OGC 08-167r2 for using of URI as string value. |
Domain: Category |
One (mandatory) |
label |
Human readable representation of the keyword. |
Domain: Category |
Zero or one (optional) |
{
"type": "Category",
"term": "http://www.eionet.europa.eu/gemet/concept/3650",
"scheme": "http://www.eionet.europa.eu/gemet/",
"label": "Geology"
}
7.1.7. Requirements class: Related URL
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.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
links |
Refers to related, actionable resources including alternative metadata. Property defined in [OGC14-055r2]. |
Range: Links (Table 24) |
Zero or one (optional) |
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 |
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 |
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) |
{
"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].
{
"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.
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.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "Links". |
Range: String |
Zero or one (optional) |
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 |
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 |
Reference to the download location for the resource. |
Range: array of Link (Table 25) |
Zero or one (optional) |
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 |
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 |
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 |
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 |
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) |
{
"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].
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.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
href |
URI describing the related resource. Property defined in [OGC14-055r2] §7.1.10. |
Domain: Link |
One (mandatory) |
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 |
Zero or one (optional) |
title |
Human readable information about the link. Property defined in [OGC14-055r2] §7.1.10. |
Domain: Link |
Zero or one (optional) |
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 |
Zero or one (optional) |
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 |
Zero or one (optional) |
An alternative representation is required when the Data Model is used in combination with an OGC API Features service binding.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
href |
URI describing the related resource. Property defined in [OGC17-069r2]. |
Domain: Link |
One (mandatory) |
rel |
Link relation type as defined in RFC8288. Property defined in [OGC17-069r2]. |
Domain: Link |
Zero or one (optional) |
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 |
Zero or one (optional) |
title |
Human readable information about the link. Property defined in <OGC17-069r2>>. |
Domain: Link |
Zero or one (optional) |
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 |
Zero or one (optional) |
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 |
Zero or one (optional) |
A possible JSON-LD encoding for the above alternative Link encoding could be:
"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.
"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.
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.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the element. This property has the fixed value "Offering". |
Domain: Offering |
Zero or one (optional) |
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 |
One (mandatory) |
operations |
Array of operations used to invoke the service. Is defined by [OGC14-055r2] §7.1.3.2. |
Domain: Offering |
Zero or more (optional) |
contents |
Array of contents (inline or by reference). Is defined by [OGC14-055r2] §7.1.3.3 and §7.1.5. |
Domain: Offering |
Zero or more (optional) |
styles |
Array of style sets. Is defined by [OGC14-055r2] §7.1.3.4 and §7.1.6. |
Domain: Offering |
Zero or more (optional) |
{
"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"
}
]
}
{
"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/
{
"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>.
{
"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].
{
"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"
}
}
}
}
}
]
}
{
"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.
{
"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. |
{
"type": "Feature",
"id": "http://fedeo.esa.int/services/NdviCalculation",
"bbox": [...],
"geometry": {...},
"properties": {
...
"endpointDescription": [ "http://52north.org/eopad/wps/processes/NdviCalculation" ]
}
}
{
"@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.
The complete description of Operation is given in Table 28.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
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 |
One (mandatory) |
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 |
One (mandatory) |
type |
MIME type of the expected results. Is defined by [OGC14-055r2] §7.1.4.3. |
Domain: Operation |
Zero or one (optional) |
href |
Service request URL. Is defined by [OGC14-055r2] §7.1.4.4. |
Domain: Operation |
One (mandatory) |
request |
Optional request body content. Is defined by [OGC14-055r2] §7.1.4.5. |
Domain: Operation |
Zero or one (optional) |
result |
Optional result payload of the operation. Is defined by [OGC14-055r2] §7.1.4.6. |
Domain: Operation |
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.
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.
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.
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.
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].
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
facetedResults |
Representation of the faceted results. |
Property |
Zero or one (optional) |
{
"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.
The complete description of FacetedResults is given in Table 30.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the object. This property has the fixed value "FacetedResults". |
String Fixed value: "FacetedResults" |
Zero or one (optional) |
datasource |
List of distributed data sources providing faceted search results and corresponding faceted search results. |
Domain: FacetedResults |
Zero or one (optional) |
facets |
List of facets and corresponding faceted search results. |
Domain: FacetedResults |
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.
{
"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.
The complete description of DataSource is given in Table 31.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the object. This property has the fixed value "DataSource". |
Range: String |
Zero or one (optional) |
displayLabel |
Display label for data source. |
Domain: DataSource |
Zero or one (optional) |
description |
Description of data source. |
Domain: DataSource |
Zero or one (optional) |
baseURL |
URL representing data source. |
Domain: DataSource |
Zero or one (optional) |
facets |
List of facets and corresponding faceted search results. |
Domain: DataSource |
Zero or one (optional) |
{
"displayLabel": "FedEO",
"description": "Federated Earth Observation",
"baseURL": "http://fedeo.esa.int/opensearch",
"facets": []
}
Facet
The following figure shows the Facet schema.
The complete description of Facet is given in Table 32.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the object. This property has the fixed value "Facet". |
Range: String |
Zero or one (optional) |
displayLabel |
Display label for OpenSearch parameter used as an index for the facet count. |
Domain: Facet |
Zero or one (optional) |
description |
Description of the facet. |
Domain: Facet |
Zero or one (optional) |
index |
OpenSearch parameter used as an index for the facet count. |
Domain: Facet |
Zero or one (optional) |
relation |
Relation used to group search results. |
Domain: Facet |
Zero or one (optional) |
terms |
List of terms for current facet. |
Domain: Facet |
One (mandatory) |
{
"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.
The complete description of Term is given in Table 33.
JSON Property | Definition | Data type and values | Multiplicity and use |
---|---|---|---|
type |
Type of the object. This property has the fixed value "Term". |
Range: String |
Zero or one (optional) |
actualTerm |
Actual term. |
Domain: Term |
One (mandatory) |
query |
Request parameters to retrieve the search results corresponding to the current term. |
Domain: Term |
Zero or one (optional) |
requestURL |
Request URL to retrieve the search results corresponding to the current term. |
Domain: Term |
Zero or one (optional) |
count |
Number of results corresponding to this term. |
Domain: Term |
One (mandatory) |
{
"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.
During the Testbed-15 EOPAD thread, the following client and server-side components were deployed and used for integration testing.
8.2. Interfaces context
The diagram below shows the interoperability tests that were performed.
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.
{
"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:
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.
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:
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.
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.
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
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.
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:
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.
Services | URL | Specifications |
---|---|---|
OpenAPI service |
OpenAPI + GeoJson EO. Refer to Catalogue Service Specification for details. Related document numbers: OGC 17-047r1, OGC 07-045r1, OGC 17-003r0 |
|
Browse Page |
Geonetwork-based view & browse |
|
CAT 3.0 |
Related document numbers: OGC 12-168r6, OGC 12-176r7 |
|
CSW 2.0.2 |
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.
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.
Item | Content | |
---|---|---|
Path |
||
Request |
Method |
GET |
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 |
|
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.
Item | Content | |
---|---|---|
Path |
https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/api |
|
Request |
Method |
GET |
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 |
|
Use Case 3 - Get Service Conformance
The example in Table 37 shows the request to retrieve service conformance declaration.
Item | Content | |
---|---|---|
Path |
https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/conformance |
|
Request |
Method |
GET |
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 |
|
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.
Item | Content | |
---|---|---|
Path |
https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services |
|
Request |
Method |
GET |
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 |
|
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.
Item | Content | |
---|---|---|
Path |
Use Case 6 - Transaction - insert
An example insert transaction request is shown in Table 40.
Item | Content | |
---|---|---|
Path |
https://cloud.csiss.gmu.edu/ows15/geonet/rest3a/ogc/cat3a/services |
|
Request |
Method |
POST |
Headers |
Accept: application/json |
|
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 |
|
|
Response |
Status |
HTTP/1.1 200 |
Headers |
Content-Type: application/geo+json;charset=UTF-8 |
|
Body |
|
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.
Item | Content | |
---|---|---|
Path |
||
Request |
Method |
GET |
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 |
|
Use Case 8 - Transaction - update a Specific Service
Table 42 shows one example to update a speccific service by using identifier.
Item | Content | |
---|---|---|
Path |
||
Request |
Method |
PUT |
Headers |
Accept: application/json |
|
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 |
|
|
Response |
Status |
HTTP/1.1 200 |
Headers |
Content-Type: application/json;charset=UTF-8 |
|
Body |
|
Use Case 9 - Transaction - delete a Specific Service
A specific service can be deleted as shown in Table 43.
Item | Content | |
---|---|---|
Path |
||
Request |
Method |
DELETE |
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.