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.