1.1.  Design Approach and Rationale

This section is non-normative.

The response encoding defined in the current document satisfies the following design goals.

• Feature-based GeoJSON model: The model maximises reuse of pre-existing standardized property names. Whereever possible, existing properties from the GeoJSON [NR2] and OWS Context [NR5] Feature objects are used for modeling EO Collection properties instead of proposing new property names. Existing properties are extended where needed (e.g., links).

• Simplicity: This document does not describe the full information models or XML encodings referred to above. The original metadata models should be referred to for these details. This Best Practice intends to provide a simpler, overarching exchange format integrating comments from the Committee on Earth Observation Satellites (CEOS) Working Group on Information Systems and Services (WGISS) community, which supported the submission of this Best Practice to the OGC.

• Convergence: A final design goal is to aim for future convergence of the proposed JSON-LD mapping with GeoDCAT-AP [OR15]. This requires future work.

1.2.  Document Outline

Hereafter a brief outline of the document content allows readers to jump directly to the topic of their interest.

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

• Chapter 4 defines the main terms used in the document.

• The conventions used in this document are explained in Chapter 5;.

• Chapter 6 gives an overview.

• Chapter 7 specifies the proposed GeoJSON encoding.

• Chapter 8 describes how the encoding can be extended with additional properties and describes the extension to JSON-LD which allows for describing multi-dimensional arrays as allowed by GeoJSON.

• Chapter 9 provides information about the expected MIME media types which correspond to the proposed encodings.

• Chapter 10 describes future work.

Finally, the following information was moved to the appendices.

• Annex A defines the Abstract Test Suite for the specification.

• Annex B includes normative JSON-LD @context definitions that allow interpreting the GeoJSON encoding as JSON-LD.

• Annex C.1 presents the mapping of the properties proposed in this specification to the OGC 11-035r1 and UMM-C Conceptual Models.

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

• Annex E includes the JSON schema definitions defining the GeoJSON encoding.

• Annex F explains where the schema file, context file, and examples can be found in the OGC schema repository.

• Annex G provides the revision history of this document.

2.1.  Conformance to base specifications

This section describes the compliance testing required for an implementation of this Best Practice.

2.2.  Conformance classes

The framework, concepts, and methodology for testing, and the criteria to be achieved in order to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site².

Annex A defines a set of tests and conformance classes that will support various applications with a range of different requirements. The following conformance classes are distinguished. Testing is based on data validation. In order to conform to this OGC Best Practice, an implementation shall implement all conformance classes specified in Annex A (normative).

Table 1 — Conformance classes related to data instances

3.1.  Normative References

[1]  The JavaScript Object Notation (JSON) Data Interchange Format, 2014, http://www.ietf.org/rfc/rfc7159.txt

[2]  The GeoJSON Format, 2016, https://tools.ietf.org/html/rfc7946

[3]  OGC OpenSearch-EO GeoJSON(-LD) Response Encoding Standard, 2020, http://docs.opengeospatial.org/is/17-047r1/17-047r1.html.

[4]  OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard, 2020, http://docs.opengeospatial.org/is/17-003r2/17-003r2.html.

[5]  OGC OWS Context GeoJSON Encoding, 2017, http://docs.opengeospatial.org/is/14-055r2/14-055r2.html

[6]  OGC Web Services Common Standard, Version 2.0.0, 2010, http://portal.opengeospatial.org/files/?artifact_id=38867

[7]  Uniform Resource Identifiers (URI): Generic Syntax, 2005, http://www.ietf.org/rfc/rfc3986.txt

[8]  Internationalised Resource Identifiers (IRIs), 2005, https://tools.ietf.org/html/rfc3987

[9]  Hypertext Transfer Protocol – HTTP/1.1, 1999 http://www.ietf.org/rfc/rfc2616.txt

[10]  Web Linking, 2010, http://www.ietf.org/rfc/rfc5988.txt

[11]  ECMAScript Language Specification, Edition 5.1, Standard ECMA-262, 2011, http://www.ecma-international.org/publications/standards/Ecma-262.htm

[12]  The JSON Data Interchange Format, 2017, http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

[13]  A JSON-based Serialisation for Linked Data, W3C Recommendation, 2014, http://www.w3.org/TR/json-ld/

3.2.  Bibliography

[1]  Unified Metadata Model Common Elements, Version 1.10, 18/01/2018, https://wiki.earthdata.nasa.gov/display/CMR/CMR+Documents.

[2]  Unified Metadata Model for Collections (UMM-C), Version 1.10, 18/01/2018, https://wiki.earthdata.nasa.gov/display/CMR/CMR+Documents.

[3]  Dublin Core Metadata Initiative, DCMI Metadata Terms, 14/06/2012, http://dublincore.org/documents/dcmi-terms/.

[4]  JSON-LD 1.0 Processing Algorithms and API, W3C Recommendation 16 January 2014, https://www.w3.org/TR/json-ld-api/

[5]  OGC 12-084r2, OWS Context Atom Encoding Standard, 09/12/2013, http://docs.opengeospatial.org/is/12-084r2/12-084r2.html

[6]  OGC 15-053, Implementing JSON/GeoJSON in an OGC Standard ER, Joan Masó.

[7]  JSON Schema, https://tools.ietf.org/html/draft-zyp-json-schema-04

[8]  RDF 1.1 Primer, W3C Working Group Note 25 February 2014, http://www.w3.org/TR/rdf11-primer/

[9]  RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation 25 February 2014, http://www.w3.org/TR/rdf11-concepts/

[10]  RDF Schema 1.1, W3C Recommendation 25 February 2014, http://www.w3.org/TR/rdf-schema/

[11]  RDF 1.1 XML Syntax, W3C Recommendation 25 February 2014, http://www.w3.org/TR/rdf-syntax-grammar/

[12]  RDF 1.1 Turtle, Terse RDF Triple Language, W3C Recommendation 25 February 2014, http://www.w3.org/TR/turtle/

[13]  Data Catalog Vocabulary (DCAT), W3C Recommendation 16 January 2014, https://www.w3.org/TR/vocab-dcat/.

[14]  RFC 4287, The Atom Syndication Format, December 2005, https://tools.ietf.org/html/rfc4287

[15]  GeoDCAT-AP: A geospatial extension to DCAT application profiles for data portals in Europe, Version 1.0.1, 02/08/2016, https://semiceu.github.io/GeoDCAT-AP/releases/1.0.1/geodcat-ap_1.0.1.pdf

[16]  Google JSON Style Guide, Revision 0.9, https://google.github.io/styleguide/jsoncstyleguide.xml

[17]  W3C vCard Ontology — for describing People and Organizations, W3C Interest Group Note 22 May 2014, http://www.w3.org/TR/vcard-rdf/

[18]  GeoJSON-LD Vocabulary, http://geojson.org/geojson-ld/, http://geojson.org/geojson-ld/vocab.rdf

[19]  OGC 11-035r1, EO Product Collection, Service and Sensor Discovery using the CS-W ebRIM Catalog, Version 1.0, 26/03/2013.

[20]  FOAF Vocabulary Specification 0.99, Namespace Document 14 January 2014 – Paddington Edition, http://xmlns.com/foaf/spec/ .

[21]  JSON-LD 1.1, “A JSON-based Serialisation for Linked Data”, W3C Proposed Recommendation, 07 May 2020, https://www.w3.org/TR/json-ld11/.

[22]  OGC 08-167r2, Semantic Annotations in OGC Standards, Version 2.0, 10/10/2012, https://portal.opengeospatial.org/files/?artifact_id=47857.

[23]  OGC 11-052r4, OGC GeoSPARQL – A Geographic Query Language for RDF Data, Version 1.0, https://portal.opengeospatial.org/files/?artifact_id=47664

[24]  http://goessner.net/articles/JsonPath/index.html

[25]  Data Catalog Vocabulary (DCAT) – Version 2, W3C Recommendation 04 February 2020, https://www.w3.org/TR/vocab-dcat/.

[26]  ISO 19115:2003/Cor 1:2006, Geographic Information – Metadata – Implementation specification, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44361

[27]  ISO 19139, Geographic Information – Metadata XML (ISO 19139:2007), http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32557

[28]  ISO 19139-2:2012, Geographic information — Metadata — XML schema implementation — Part 2: Extensions for imagery and gridded data, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=57104

[29]  Dublin Core Metadata Initiative term declarations represented in RDF schema language, http://dublincore.org/schemas/rdfs/.

[30]  W3C PROV-O: The PROV Ontology, W3C Recommendation 30 April 2013, https://www.w3.org/TR/prov-o/

[31]  SKOS Simple Knowledge Organization System Reference, W3C Recommendation 18 august 2009, http://www.w3.org/TR/skos-reference/.

[32]  European Commission, ISA Programme, “ISA Programme Location Core Vocabulary,” 2015, http://www.w3.org/ns/locn#.

[33]  Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007, Version 2.0.1, 2017-03-02, https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139

5.1.  Abbreviated terms

Some frequently used abbreviated terms:

5.2.  Symbols

5.2.1.  Symbols and abbreviated terms

The schema diagrams³ included in the document show the JSON structure expressed in JSON Schema [OR7] and documented in Annex E.1.

Table 2 — JSON Schema diagram symbols

JSON Schema Entity	Representation	Description
Definition		Definitions are shown as blue rectangles with solid borders.
Mandatory property		Mandatory properties are shown with solid borders.
Optional property		Optional properties are shown with dashed borders.
Property of type “Object” referring to a “Definition” of the Object.		The “Def” attribute inside a rectangle representing a property of type Object refers to the corresponding Object definition.
Pattern property		A pattern property defines the property’s name as a regular expression. There are no minimum or maximum occurrence settings for a pattern property.
Unspecified property		A property can be implicitly specified by adding a suitable pattern property or property wildcard.
“All Of” operator		Contains one or more sub-schemas (definitions), added as children of the operator. An instance is valid if it is valid against all these sub-schemas.
“Any Of” operator		Contains one or more sub-schemas (definitions), added as children of the operator. An instance is valid if it is valid against at least one of these sub-schemas.
“One Of” operator		Contains one or more sub-schemas (definitions), added as children of the operator. An instance is valid if it is valid against exactly one of these sub-schemas.
Subschema (definitions)		The “Def” attribute inside a rectangle representing a (Sub) Schema refers to the corresponding Object definition.

5.3.  Namespace abbreviations

The following namespace abbreviations will be used in this document:

Table 3 — Namespace abbreviations

5.4.  Layout and identifiers

The normative provisions in the current document are denoted by the URI http://www.opengis.net/spec/eoc-geojson/1.0. All requirements and conformance classes that appear in this document are denoted by relative URIs which are relative to this base URI.

5.5.  Style

This document applies the “double quote” guideline defined in [OR16]: “If a property requires quotes, double quotes must be used. All property names must be surrounded by double quotes. Property values of type string must be surrounded by double quotes. Other value types (like boolean or number) should not be surrounded by double quotes.”

5.6.  Data dictionary tables

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

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

6.1.  JavaScript Object Notation

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format that defines a small set of formatting rules for the portable representation of structured data. JSON is derived from the object literals of JavaScript, as defined in the ECMAScript Programming Language Standard [NR11] and can represent four primitive types (strings, numbers, boolean values, and null) and two structured types (objects and arrays). The ordering of the members or properties of any JSON object is considered irrelevant. Even though JSON is based on a subset of the JavaScript Programming Language it is currently well supported by nearly all programming languages, including Java, Python, and C#.

The JSON format is currently described by two competing standards, RFC7159 [NR1] and ECMA-404 [NR12]. Both standards documents are consistent, but the latter defines mainly the grammatical syntax where the former provides some additional semantic and security points.

6.2.  GeoJSON Format Specification

GeoJSON [NR2] is a format for encoding collections of simple geographical features along with their non-spatial attributes using JSON. GeoJSON consists of a single object representing a geometry, feature, or collection of features. The geometries supported are Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, and Geometry Collections.

7.1.  Requirements class: Feature

The Feature object represents the EO Collection (a.k.a. EO Dataset Series). It inherits all properties of the GeoJSON Feature object. In addition, it may contain an optional @context property. The @context properties shall typically be absent in the GeoJSON encoding and implicitly refer to the normative @context defined in Annex B.

Figure 3 — Feature Schema (GeoJSON)

Complete description of Feature is given in Table 4. Most properties are inherited from the Feature object defined in [NR2].

Table 4 — Feature object properties

Example 1: GeoJSON encoding example
{
	"type": "Feature",
	"id": " http://fedeo.esa.int/opensearch/request/?httpAccept=application/geo%2Bjson&parentIdentifier=EOP%3AESA%3AFEDEO&uid=LANDSAT.ETM.GTC",
	"bbox": [
		-180,
		-90,
		180,
		90
	],
	"geometry": {...},
	"properties": {...}
}

Example 2: GeoJSON encoding example (with explicit normative @context property)
{
	"@context": "https://www.opengis.net/eoc-geojson/1.0",
	"type": "Feature",
	"id": " http://fedeo.esa.int/opensearch/request/?httpAccept=application/geo%2Bjson&parentIdentifier=EOP%3AESA%3AFEDEO&uid=LANDSAT.ETM.GTC",
	"bbox": [
		-180,
		-90,
		180,
		90
	],
	"geometry": {...},
	"properties": {...}
}

In the remainder of the document, we will not include the @context property in the GeoJSON encoding in which case it is implied as explained in Annex B.1.1.

7.1.1.  Properties

Requirement Class: Properties
/req/properties
Target Type	Data instance
Dependency	JSON [NR1]
Dependency	/req/acquisition-information
Dependency	/req/product-information
Dependency	/req/metadata-information
Dependency	/req/temporal-extent
Dependency	/req/location
Dependency	/req/data-identification
Dependency	/req/related-url
Dependency	/req/descriptive-keywords
Requirement 2:	/req/properties/properties
Requirement 3:	/req/properties/data-identification
Requirement 4:	/req/properties/descriptive-keywords
Requirement 5:	/req/properties/related-url

Requirement 2:
/req/properties/properties
A “Properties” object shall implement the properties shown in Table 4, with the value matching the type shown, and with the obligation shown.

Requirement 3:
/req/properties/data-identification
A “Properties” object shall implement the properties of a DataIdentification object (Table 7).

Requirement 4:
/req/properties/descriptive-keywords
A “Properties” object shall implement the properties of a DescriptiveKeywords object (Table 21).

Requirement 5:
/req/properties/related-url
A “Properties” object shall implement the properties of a RelatedUrl object (Table 23).

The Properties block contains the EO Collection properties and hypermedia links to related objects. It inherits all DataIdentification, DescriptiveKeywords and RelatedUrl properties.

Figure 4 — Properties Schema

Complete description of Properties is given in Table 5.

Table 5 — Properties object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $.properties.type	Type of the element. This property has the fixed value “Properties”.	Domain: Properties Range: String Fixed value: “Properties”	Zero or one (optional)
isPrimaryTopicOf $.properties.isPrimaryTopicOf	Properties related to the metadata of the EO collection, e.g., metadata dates.	Domain: Properties Range: MetadataInformation (See Table 6)	Zero or one (optional)
acquisitionInformation $.properties.acquisitionInformation	Contains product information as presented in Table 30.	Domain: Properties Range: Array of AcquisitionInformation (See Table 30)	One or more (mandatory)
spatial $.properties.spatial	Alternative encoding of Geometry (intended for JSON-LD) if compliance with GeoDCAT-AP is mandatory (See also section 8.2).	Domain: Properties Range: Location (See Table 34)	Zero or one (optional)
temporal $.properties.temporal	Temporal extent of the collection. Contains same information as $.properties.date (DataIdentification).	Domain: Properties Range: TemporalExtent (See Table 29)	Zero or one (optional)

Example 3: Feature Properties encoding example
{
		"title": "Sentinel-2 Products",
		"identifier": "EOP:ESA:Sentinel-2",
		"kind": "http://purl.org/dc/dcmitype/Collection",
		"rights": "Data are available upon fast registration",
		"abstract": "The Sentinel-2 mission is a land monitoring constellation of two satellites that provide high resolution optical imagery and provide continuity for the current SPOT and Landsat missions. The mission provides a global coverage of the Earth's land surface every 10 days with one satellite and 5 days with 2 satellites, making the data of great use in on-going studies. The satellites are equipped with the state-of-the-art MSI (Multispectral Imager) instrument, that offers high-resolution optical imagery.",
		"date": "2015-06-23T00:00:00Z/",
		"updated": "2018-11-28T15:23:57Z",
		"temporal": {
			"beginningDateTime": "2015-06-23T00:00:00Z"
		},
		"isPrimaryTopicOf": {
			"updated": "2019-07-17T00:00:00Z",
			"published": "2019-07-17T00:00:00Z",
			"lang": "en"
		},
		"categories": [
			...
		],
		"acquisitionInformation": [
			{
				"platform": {
					"id": "https://earth.esa.int/concept/sentinel-2",
					"platformShortName": "Sentinel-2"
				},
				"instrument": {
					"id": "https://earth.esa.int/concept/s2-msi",
					"instrumentShortName": "MSI"
				}
			}
		],
	   "productInformation": {
         ...
      },

		"links": {
			...
		}
	}

7.2.  Requirements class: Metadata Information

The MetadataInformation is encoded as a CatalogRecord as defined by DCAT Version 2 [OR25] with JSON property names consistent with OGC 14-055r2.

Figure 5 — MetadataInformation Schema

Complete description of MetadataInformation is given in Table 6.

Table 6 — MetadataInformation object properties

Example 4: MetadataInformation encoding example
{
         "type": "CatalogRecord",
      	"updated": "2019-07-17T00:00:00Z",
      	"published": "2019-07-17T00:00:00Z",
      	"lang": "en"
}

7.3.  Requirements class: Data Identification

The DataIdentification properties are inherited by the Properties block. The DataIdentification inherits all properties of the Datadates, DataContact and ResourceConstraints object.

Figure 6 — DataIdentification Schema

Complete description of DataIdentification is given in Table 7.

Table 7 — DataIdentification object properties

Example 5: DataIdentification encoding example
{
	"title": "LANDSAT 7 ETM+ (Enhanced Thematic Mapper Plus) Geolocated Terrain Corrected Systematic processing (LANDSAT.ETM.GTC)",
	"identifier": "LANDSAT.ETM.GTC",
	"kind": "http://purl.org/dc/dcmitype/Collection",
	"abstract": "This dataset contains all the Landsat 7 Enhanced Thematic Mapper high-quality ortho-rectified L1T dataset over Kiruna, Maspalomas and Matera visibility masks. The Landsat 7 ETM+ scenes typically covers 185 x 170 km. A standard full scene is nominally centred on the intersection between a Path and Row (the actual image centre can vary by up to 100m). Each band requires 50MB (uncompressed), and Band 8 requires 200MB (panchromatic band with resolution of 15m opposed to 30m).",
	"date": "1999-07-01T00:00:00Z/2003-12-31T00:00:00Z",
	"updated": "1999-07-01T00:00:00Z",
	"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",
			"uri": "http://earth.esa.int",
			"hasTelephone": [ {
				"type": "Voice",
				"hasValue": "tel:+39 06 94180777"
			} ],
			"hasAddress": {
				"country-name": "Italy",
				"postal-code": "00044",
				"locality": "Frascati",
				"street-address": "Via Galileo Galilei CP. 64"
			}
		}
	],
   "provenance": [
		{
         "type":   "ProvenanceStatement",
         "label":  "Forest Map 2006 is derived from the IMAGE2006 (SPOT/LISS scenes) and CORINE2006 landcover dataset. In addition, MODIS composites are used for the Forest type classification."
      }
   ],
   "wasUsedBy": [
       {
          "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-08T00:00:00Z"
                  }
              }
          }
       }
    ]
}

Example 6: DataIdentification encoding example (Citation)
{
	"title": "ESA Sea Surface Temperature Climate Change Initiative (ESA SST CCI): GHRSST Multi-Product ensemble (GMPE)",
	"identifier": "e0659b01259145c8bfb0de6eb12c2690",
	"abstract": "The ESA Sea Surface Temperature Climate Change Initiative (ESA SST CCI) dataset accurately maps the surface temperature of the global oceans over the period 1991 to 2010 using observations from many satellites. The data provides an independently quantified SST to a quality suitable for climate research. The GHRSST Multi-Product Ensemble (GMPE) dataset is an ensemble median of the ESA SST CCI spatially complete analysis with other level 4 SST analysis products. Anomalies of the analyses relative to the median, and the ensemble standard deviation are also provided.All the data in the GMPE files are regridded onto a common 0.25 degree regular latitude longitude grid and there areSST fields for each day. The GMPE for the ESA SST CCI long term product covers the period September 1991 to December 2010. GMPE files are also available for ESA SST CCI demonstration product 1 (which covers June to August 2007).",
	"bibliographicCitation": "Fiedler, E.K.; McLaren, A.; Merchant, C.J.; Donlon, C. (2015): ESA Sea Surface Temperature Climate Change Initiative (ESA SST CCI): GHRSST Multi-Product ensemble (GMPE). NERC Earth Observation Data Centre, 24 February 2015. doi:10.5285/7BAF7407-2F15-406C-8F09-CB9DC10392AA. http://dx.doi.org/10.5285/7BAF7407-2F15-406C-8F09-CB9DC10392AA",
	"doi": "10.5285/7BAF7407-2F15-406C-8F09-CB9DC10392AA",
	"date": "1991-09-01T00:00:00.000Z/2010-12-31T00:00:00.000Z",
	"updated": "2019-09-01T00:00:00.000Z",
   "published": "2014-12-03T12:00:00.000Z",

	"license": [
		{
			"type": "LicenseDocument",
			"label": "Use of these data is covered by the following licence: http://licences.ceda.ac.uk/image/data_access_condition/esacci_sst_terms_and_conditions.pdf . When using these data you must cite them correctly using the citation given on the CEDA Data Catalogue record."
		}
	],
	"accessRights": [
		{
			"type": "RightsStatement",
			"label": "Public data: access to these data is available to both registered and non-registered users."
		}
	],
	"qualifiedAttribution": [
		{
			"type": "Attribution",
			"agent": [
				{
					"type": "Organization",
					"email": "neodc@rl.ac.uk",
					"name": "NERC - Earth Observation Data Centre",
					"hasTelephone": [{
						"type": "Voice",
						"hasValue": "tel:+44(0)1235 446432"
					}],

					"hasAddress": {
						"postal-code": "OX11 0QX",
						"locality": "Harwell Oxford",
						"street-address": "NERC Earth Observation Data Centre (NEODC)"
					}
				}
			],
			"role": "custodian"
		},
		{
			"type": "Attribution",
			"agent": [
				{
					"type": "Organization",
					"email": "support@ceda.ac.uk",
					"name": "Rutherford Appleton Laboratory",
					"hasTelephone": {
						"type": "Voice",
						"hasValue": "tel:01235446432"
					},
					"hasAddress": {
						"postal-code": "OX11 0QX",
						"locality": "Oxon",
						"street-address": "Centre for Environmental Data Analysis (CEDA)"
					}
				}
			],
			"role": "distributor"
		}
	],
	"provenance": [
		{
			"type": "ProvenanceStatement",
			"label": "Data were processed and supplied to the NEODC by the ESA CCI SST project team."
		}
	]
}

7.3.1.  DataDates

Requirement 11:
/req/data-dates
A “DataDates” object shall implement the properties defined in Table 8, with the value matching the type shown, and with the obligation shown.

Figure 7 — DataDates Schema

Complete description of DataDates is given in Table 8.

Table 8 — DataDates object properties

JSON Property	Definition	Data type and values	Multiplicity and use
created $.properties.created	Date of creation of the resource.	Domain: Properties Range: DateTime	Zero or one (optional)
updated $.properties.updated	Date of creation or last update of the resource. DateTime representation, as defined by RFC 3339, section 5.6.	Domain: Properties Range: DateTime	One (mandatory )
published $.properties.published	Date of publication of the resource.	Domain: Properties Range: DateTime	Zero or one (optional)
date $.properties.date	Date or range of dates relevant for the resource (RFC-3339). Formatted in one of the following ways: <datetime> “/” <datetime> <datetime> “/” “/” <datetime> <datetime> “/” For example: “1999-07-01T00:00:00Z/2003-12-31T00:00:00Z”	Domain: Properties Range: String or DateTime	One (mandatory)

Example 7: DataDates encoding example
{
	"date": "1999-07-01T00:00:00Z/2003-12-31T00:00:00Z",
	"created": "1999-07-01T23:59:00Z",
	"published": "1999-07-02T08:00:00Z",
	"updated": "2004-01-01T08:00:00Z"
}

7.3.2.  DataContact

Requirement Class: DataContact
/req/data-contact
Target Type	Data instance
Dependency	JSON [NR1]
Dependency	/req/agent
Dependency	/req/attribution
Requirement 12:	/req/data-contact/properties

Requirement 12:
/req/data-contact/properties
A “DataContact” object shall implement the properties shown in Table 9, with the value matching the type shown, and with the obligation shown.

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

Figure 8 — DataContact Schema

Complete description of DataContact is given in Table 9.

Table 9 — DataContact object properties

JSON Property	Definition	Data type and values	Multiplicity and use
publisher $.properties.publisher	An entity or agent responsible for publishing the metadata (role is “Publisher”).	Optional property in [NR5] Domain: Properties Range: String	Zero or one (optional)
authors $.properties.authors	Entities or persons primarily responsible for making the response document (role is “Author”).	Optional property in [NR5] Domain: Properties Range: Array of Agent (See Table 11)	Zero or one (optional)
contactPoint $.properties.contactPoint	Link an EO collection to relevant organisations (role is “Point of Contact”).	Optional property in [OR13] Domain: Properties Range: Array of Agent (See Table 11)	Zero or one (Optional)
qualifiedAttribution $.properties.qualifiedAttribution	Specifies the relationship between the EO collection and the responsible organisation (role is “Resource Provider”, “Custodian”, “User”, “Distributor”, “Originator”, “Principal Investigator” or “Processor”).	Domain: Properties Array of Attribution (See Table 10)	Zero or one (Optional)

Example 8: DataContact encoding example
{
	"authors": [
		{
			"type": "Organization",
			"email": "eohelp@eo.esa.int",
			"name": "ESA/ESRIN",
			"phone": "tel:+39 06 94180777"
		}
	],
	"contactPoint": [
		{
			"type": "Organization",
			"email": "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": "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"
		}
	]
}

7.3.3.  Attribution

Requirement Class: Attribution
/req/attribution
Target Type	Data instance
Dependency	JSON [NR1]
Dependency	/req/agent
Requirement 13:	/req/attribution/properties

Requirement 13:
/req/attribution/properties
An “Attribution” object shall implement the properties shown in Table 10 with the value matching the type shown, and with the obligation shown.

The Attribution object represents a responsible party and its role and is based on [OR30].

Figure 9 — Attribution Schema

Complete description of Attribution is given in Table 10.

Table 10 — Attribution object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $.properties.qualifiedAttribution[*].type	Type of the element. This property is a string with fixed value “Attribution”.	Range: String Fixed value: “Attribution”	Zero or one (optional)
role $.properties.qualifiedAttribution[*].role	Role of the responsible party corresponding to ISO19115:2003 responsible party role . Values: resourceProvider custodian owner user distributor originator pointOfContact principalInvestigator processor publisher author	Range: String	One (mandatory)
agent $.properties.qualifiedAttribution[*].agent	Organisation or person fulfilling the above “role”. Any properties allowed by vcard:Kind are allowed.	Range: Array of Agent (See Table 11)	One (mandatory)

Example 9: Attribution encoding example
{
	"type": "Attribution",
	"agent": [
      {
		   "type": "Organization",
		   "email": "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"
}

7.3.4.  Agent

Requirement 14:
/req/agent
An “Agent” object shall implement the properties defined in Table 11, with the value matching the type shown, and with the obligation shown.

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

Figure 10 — Agent Schema

Complete description of Agent is given in Table 11.

Table 11 — Agent object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $..type	Type of the element. This property can have one of the following fixed values “Agent” (or “Kind”), “Person” (or “Individual”), “Organization”.	Domain: Agent Range: String	Zero or one (optional)
name $..name	Human readable name of author (or entity) as a single string. Defined in section 7.1.1.7 of [NR5].	Optional property in [NR5] Domain: Agent Range: String.	Zero or one (optional)
email $..email	Email of author (or entity).	Optional property in [NR5] Domain: Agent Range: String.	Zero or one (optional)
uri $..uri	URI associated with the author (or entity).	Optional property in [NR5] Domain: Agent Range: String (URI).	Zero or one (optional)
phone $.properties.authors[*].phone	Single phone number associated with the author (or entity).	Optional property in [OR20] Domain: Agent Range: String.	Zero or one (optional)
hasTelephone $.properties.qualifiedAttribution[].agent[].hasTelephone $.properties.contactPoint[*].hasTelephone	Phone numbers associated with the author (or entity). Can be of type “Voice”, “Fax”, “”. Defined in [OR17].	Optional property in [OR17] Domain: Agent Range: Array of Object.	Zero or more (optional)
hasName $.properties.qualifiedAttribution[].agent[].hasName $.properties.contactPoint[].hasName + $.properties.authors[].hasName	Name associated with the author (or entity) in structured parts as defined in [OR17]: given-name (optional) family-name (optional) additional-name (optional)	Optional property in [OR17] Domain: Agent Range: Object.	Zero or one (optional)
hasAddress $.properties.qualifiedAttribution[].agent[].hasAddress $.properties.contactPoint[*].hasAddress	Address associated with the author (or entity) in structured parts as defined in [OR17]: street-address (optional) locality (optional) region (optional) country-name (optional) postal-code (optional)	Optional property in [OR17] Domain: Agent Range: Object.	Zero or one (optional)

Example 10: Agent encoding example
{
	"type": "Agent",
	"name": "Earth Observation Helpdesk",
	"email": "EOHelp@esa.int",
	"uri": "http://earth.esa.int",
	"phone": "tel:+39 06 94180777",
	"hasTelephone": [
		{
			"type": "Voice",
			"hasValue": "tel:+39 06 94180777"
		},
		{
			"type": "Fax",
			"hasValue": "tel:+39 06 94180292"
		}
	],
	"hasAddress": {
		"country-name": "Italy",
		"postal-code": "00044",
		"locality": "Frascati",
		"street-address": "Via Galileo Galilei CP. 64"
	}
}

Example 11: Agent encoding example (Individual)
{
	"type": "Individual",
	"name": "Christopher J. Merchant",
	"hasName": {
		"given-name": "Christopher",
		"family-name": "Merchant",
		"additional-name": "J."
	},
	"hasAddress": {
		"locality": "Reading"
	}
}

7.3.5.  ProvenanceStatement

Requirement 15:
/req/provenance-statement
A “ProvenanceStatement” object shall implement the properties shown in Table 20 with the value matching the type shown, and with the obligation shown.

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

Figure 11 — ProvenanceStatement Schema

Complete description of ProvenanceStatement is given in Table 12.

Table 12 — ProvenanceStatement object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $.properties.provenance[*].type	Type of the element. This property has the fixed value “ProvenanceStatement”.	Domain: ProvenanceStatement Range: String	Zero or one (optional)
label $.properties.provenance[*].label	Free text content of the corresponding ISO19139-2 metadata property gmd:lineage.	Property [OR15] Domain: ProvenanceStatement Range: String.	One (mandatory)

Example 12: ProvenanceStatement encoding example
{
     "type":   "ProvenanceStatement",
     "label":  "Forest Map 2006 is derived from the IMAGE2006 (SPOT/LISS scenes) and CORINE2006 landcover dataset. In addition, MODIS composites are used for the Forest type classification."
}

7.3.6.  Activity

Requirement Class: Activity
/req/activity
Target Type	Data instance
Dependency	JSON [NR1]
Dependency	/req/association
Dependency	/req/entity
Requirement 16:	/req/activity/properties

Requirement 16:
/req/activity/properties
An “Activity” object shall implement the properties shown in Table 13 with the value matching the type shown, and with the obligation shown.

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

Figure 12 — Activity Schema

Complete description of Activity is given in Table 13.

Table 13 — Activity object properties

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

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

7.3.7.  Entity

Requirement 17:
/req/entity
An “Entity” object shall implement the properties shown in Table 14 with the value matching the type shown, and with the obligation shown.

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

Figure 13 — Entity Schema

Complete description of Entity is given in Table 14.

Table 14 — Entity object properties

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

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

7.3.8.  Association

Requirement Class: Association
/req/association
Target Type	Data instance
Dependency	JSON [NR1]
Dependency	/req/plan
Requirement 18:	/req/association/properties

Requirement 18:
/req/association/properties
An “Association” object shall implement the properties shown in Table 15 with the value matching the type shown, and with the obligation shown.

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

Figure 14 — Association Schema

Complete description of Association is given in Table 15.

Table 15 — Association object properties

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

Example 15: Association encoding example
{
     "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"
         }
     }
}

7.3.9.  Plan

Requirement Class: Plan
/req/plan
Target Type	Data instance
Dependency	JSON [NR1]
Dependency	/req/standard
Requirement 19:	/req/plan/properties

Requirement 19:
/req/plan/properties
A “Plan” object shall implement the properties shown in Table 16 with the value matching the type shown, and with the obligation shown.

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

Figure 15 — Plan Schema

Complete description of Plan is given in Table 16.

Table 16 — Plan object properties

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

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

7.3.10.  Standard

Requirement 20:
/req/standard
A “Standard” object shall implement the properties shown in Table 17 with the value matching the type shown, and with the obligation shown.

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

Figure 16 — Standard Schema

Complete description of Standard is given in Table 17.

Table 17 — Standard object properties

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

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

7.4.  Requirements class: Resource Constraints

The proposed encoding is aligned with DCAT Version 2 [OR25] and GeoDCAT-AP [OR15] §II.15.

Figure 17 — ResourceConstraints Schema

Complete description of ResourceConstraints is given in Table 18.

Table 18 — ResourceConstraints object properties

Example 18: ResourceConstraints encoding example
{
  "rights": "Data are available upon fast registration",
  "license": [
    {
      "type": "LicenseDocument",
      "label": "Fast Registration with immediate access Data is available via EOLI-SA upon registration for the (A)SAR On The Fly Service. 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."
    }
  ],
  "accessRights": [
    {
      "type": "RightsStatement",
      "label": "Utilisation of this data is subject to ESA's Earth Observation Terms and Conditions"
    }
  ]
},

7.4.1.  LicenseDocument

Requirement 22:
/req/license-document
A “LicenseDocument” object shall implement the properties shown in Table 19 with the value matching the type shown, and with the obligation shown.

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

Figure 18 — LicenseDocument Schema

A LicenseDocument is encoded as an object or as a URI identifying such object. The complete description of the LicenseDocument object is given in Table 19.

Table 19 — LicenseDocument object properties

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

Example 19: LicenseDocument encoding example (Object)
{
     "type":   "LicenseDocument",
     "label":  "Fast Registration with immediate access Data is available via EOLI-SA upon registration for the (A)SAR On The Fly Service. 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."
}

Example 20: LicenseDocument encoding example (URI)
"https://creativecommons.org/licenses/by/4.0/"

7.4.2.  RightsStatement

Requirement 23:
/req/rights-statement
A “RightsStatement” object shall implement the properties shown in Table 20 with the value matching the type shown, and with the obligation shown.

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

Figure 19 — RightsStatement Schema

A RightsStatement is encoded as an object or as a URI identifying such object. The complete description of RightsStatement is given in Table 20.

Table 20 — RightsStatement object properties

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

Example 21: RightsStatement encoding example (Object)
{
     "type":   "RightsStatement",
     "label":  "Utilisation of this data is subject to ESA's Earth Observation Terms and Conditions"
}

Example 22: RightsStatement encoding example (URI)
"https://earth.esa.int/web/guest/data-access/how-to-access-eo-data/asar-on-the-fly-faq"

Example 23: Use Constraints encoding example (Object)
{
	"license": [
		{
			"type": "LicenseDocument",
			"label": "Fast Registration with immediate access Data is available via EOLI-SA upon registration for the (A)SAR On The Fly Service. 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."
		}
	]
}

Example 24: Use Constraints encoding example (URI)
{
	"license": [
		"https://creativecommons.org/licenses/by/4.0/"
	]
}

Example 25: Access Constraints encoding example (Object)
{
	"accessRights": [
		{
			"type": "RightsStatement",
			"label": "Utilisation of this data is subject to ESA's Earth Observation Terms and Conditions"
		}
	]
}

Example 26: Access Constraints encoding example (URI)
{
	"accessRights": [
		"https://earth.esa.int/web/guest/data-access/how-to-access-eo-data/asar-on-the-fly-faq"
	]
}

7.5.  Requirements class: Descriptive Keywords

The DescriptiveKeywords properties are inherited by the Properties block. To align with GeoDCAT-AP [OR15] §II.8.1, three kinds of keywords are distinguished.

Figure 20 — DescriptiveKeywords Schema

Complete description of DescriptiveKeywords is given in Table 21.

Table 21 — DescriptiveKeywords object properties

Example 27: DescriptiveKeywords encoding example
{
	"categories": [
		{
			"term": "http://www.eionet.europa.eu/gemet/concept/3650",
			"scheme": "http://www.eionet.europa.eu/gemet/",
         "label":  "Geology"
		},
		{
			"term": "https://gcmdservices.gsfc.nasa.gov/kms/concept/03f0c0a3-04a7-4ef8-8ec0-3c2266510815",
         "scheme": " https://gcmdservices.gsfc.nasa.gov/kms/concepts/concept_scheme/sciencekeyword",
         "label":  "VISIBLE IMAGERY"
		},
     {
			"term": "https://gcmdservices.gsfc.nasa.gov/kms/concept/98dc8278-fe0a-4e36-a638-9d7a5b0ed826",
         "scheme": "https://gcmdservices.gsfc.nasa.gov/kms/concepts/concept_scheme/projects",
         "label":  "FedEO"
		},
     {
			"term": "https://gcmdservices.gsfc.nasa.gov/kms/concept/ad598334-f541-4be4-888c-c2dc7eb54194",
         "scheme": "https://gcmdservices.gsfc.nasa.gov/kms/concepts/concept_scheme/CollectionDataType",
         "label":  "NEAR_REAL_TIME"
		}

	],
	"keyword": [
		"FedEO",
		"ESA LDS"
	],
	"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"
		}
	]
}

7.5.1.  Category

Requirement 27:
/req/category
A “Category” object shall implement the properties defined in OGC 14-055r2 [NR5], with the value matching the type shown, and with the obligation shown.

The Category block contains the properties of a keyword and is defined in [NR5].

Figure 21 — Category Schema

Complete description of Category is given in Table 22.

Table 22 — Category object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $.properties.categories[*].type	Type of the element. This property has the fixed value “Category”.	Domain: Category Range: String Fixed value: “Category”	Zero or one (optional)
scheme $.properties.categories[*].scheme	Identification of the code-list defining the keyword. Defined in section 7.1.1.15 of [NR5].	Optional property in [NR5] Domain: Category Range: String (URI).	Zero or one (optional)
term $.properties.categories[*].term	Identification of the keyword. See also [OR22] for using of URI as string value.	Mandatory property in [NR5] Domain: Category Range: String	One (mandatory)
label $.properties.categories[*].label	Human readable representation of the keyword.	Optional property in [NR5] Domain: Category Range: String	Zero or one (optional)

Example 28: Category encoding example
{
     "type":   "Category",
     "scheme": "http://www.eionet.europa.eu/gemet/",
     "term":   "http://www.eionet.europa.eu/gemet/concept/4612",
     "label":  "Land cover"
}

7.6.  Requirements class: Related URL

Figure 22 — RelatedUrl Schema

Table 23 — RelatedUrl object properties

Example 29: RelatedUrl encoding example
{
     "offerings": [
			{
				"code": "http://www.opengis.net/spec/owc-geojson/1.0/req/wps",
				"operations": [
					{
						"code": "Execute",
						"method": "POST",
						"href": "http://185.52.193.7/wps-proxy/"
					}
				]
			}
		],
		"links": {
			"alternates": [
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/atom%2Bxml&parentIdentifier=EOP%3AESA%3AFEDEO%3ACOLLECTIONS&uid=EOP%3AESA%3ASentinel-2&recordSchema=server-choice",
					"type": "application/atom+xml",
					"title": "Atom format"
				},
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/vnd.iso.19139%2Bxml&parentIdentifier=EOP%3AESA%3AFEDEO%3ACOLLECTIONS&uid=EOP%3AESA%3ASentinel-2&recordSchema=iso",
					"type": "application/vnd.iso.19139+xml",
					"title": "ISO 19139 metadata"
				},
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/vnd.iso.19139-2%2Bxml&parentIdentifier=EOP%3AESA%3AFEDEO%3ACOLLECTIONS&uid=EOP%3AESA%3ASentinel-2&recordSchema=iso19139-2",
					"type": "application/vnd.iso.19139-2+xml",
					"title": "ISO 19139-2 metadata"
				},
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/iso19115%2Bxml&parentIdentifier=EOP%3AESA%3AFEDEO%3ACOLLECTIONS&uid=EOP%3AESA%3ASentinel-2&recordSchema=iso19115",
					"type": "application/iso19115+xml",
					"title": "ISO MENDS metadata"
				},
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/vnd.iso.19115-3%2Bxml&parentIdentifier=EOP%3AESA%3AFEDEO%3ACOLLECTIONS&uid=EOP%3AESA%3ASentinel-2&recordSchema=iso19115-3",
					"type": "application/vnd.iso.19115-3+xml",
					"title": "ISO 19115-3 metadata"
				},
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/dif10%2Bxml&parentIdentifier=EOP%3AESA%3AFEDEO%3ACOLLECTIONS&uid=EOP%3AESA%3ASentinel-2&recordSchema=dif10",
					"type": "application/dif10+xml",
					"title": "DIF-10 metadata"
				},
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/xml&parentIdentifier=EOP%3AESA%3AFEDEO%3ACOLLECTIONS&uid=EOP%3AESA%3ASentinel-2&recordSchema=dc",
					"type": "application/xml",
					"title": "Dublin Core metadata"
				},
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/rdf%2Bxml&parentIdentifier=EOP:ESA:FEDEO:COLLECTIONS&uid=EOP:ESA:Sentinel-2&recordSchema=iso",
					"type": "application/rdf+xml",
					"title": "RDF/XML format"
				},
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/ld%2Bjson&parentIdentifier=EOP:ESA:FEDEO:COLLECTIONS&uid=EOP:ESA:Sentinel-2&recordSchema=iso",
					"type": "application/ld+json",
					"title": "JSON-LD format"
				},
				{
					"href": "http://fedeo.esa.int/opensearch/request/?httpAccept=text/turtle&parentIdentifier=EOP:ESA:FEDEO:COLLECTIONS&uid=EOP:ESA:Sentinel-2&recordSchema=iso",
					"type": "text/turtle",
					"title": "Turtle format"
				}
			],
			"describedby": [
				{
					"href": "https://sentinel.esa.int/web/sentinel/missions/sentinel-2",
					"type": "text/html",
					"title": "ESA Sentinel Online"
				}
			],
			"search": [
				{
					"href": "http://fedeo.esa.int/opensearch/description.xml?parentIdentifier=EOP:ESA:SCIHUB:S2&sensorType=OPTICAL&startDate=2015-06-23T00:00:00Z&endDate=",
					"type": "application/opensearchdescription+xml"
				}
			],
			"previews": [
				{
					"href": "http://fedeo.esa.int/opensearch/images/esa.png",
					"type": "image/png",
					"title": "Quicklook"
				}
			]
		}
}

7.6.1.  Links

Requirement Class: Links
/req/related-url
Target Type	Data instance
Dependency	JSON [NR1]
Dependency	/req/link
Requirement 29:	/req/links/properties

Requirement 29:
/req/links/properties
A “Links” object shall implement the properties shown in Table 24, with the value matching the type shown, and with the obligation shown.

The Links block contains references to related resources as hypermedia links. They include specification references and references to alternative representations of the metadata. For the GeoJSON encoding of the Links object, we use the property names adopted by section 7.1.2 of the GeoJSON encoding for OWS Context OGC 14-055r2 [NR5].

The Links object is a map containing descriptions of potential Links. The key is the “relation” as defined in [NR10] or a relation defined in [NR5].

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.

Figure 23 — Links Schema

Complete description of Links is given in Table 24.

Table 24 — Links object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $.properties.links.type	Type of the element. This property has the fixed value “Links”.	Range: String Fixed value: Links	Zero or one (optional)
profiles $.properties.links.profiles	Specification references identifying which specifications the metadata document complies with. Is defined by [NR5] §7.1.1.1.	Property [NR5]. Range: array of Link as defined in Table 25.	Zero or one (optional)
via $.properties.links.via	Reference to a description of the resource of which the response document is derived (e.g., source of information). Is defined by [NR5] §7.1.1.14.	Range: array of Link as defined in Table 25.	Zero or one (optional)
alternates $.properties.links.alternates	Reference to a description of the resource in an alternative format. Is defined by [NR5] §7.1.2.	Range: array of Link as defined in Table 25.	Zero or one (optional)
related $.properties.links.related	Reference to the location of a related resource. Is also used to return results of correlated search as per OGC 13-068.	Range: array of Link as defined in Table 25.	Zero or one (optional)
previews $.properties.links.previews	Reference to a quick-look or browse image representing the resource. Is defined by [NR5] §7.1.2.10.	Range: array of Link as defined in Table 25.	Zero or one (optional)
search $.properties.links.search	Reference to a formal interface description (e.g., an OpenSearch Description Document, OpenAPI Document or SPARQL Service Description ) of the search interface that can be used to find resources (EO products) belonging to the collection represented by the feature.	Range: array of Link as defined in Table 25.	Zero or one (optional)
describedby $.properties.links.describedby	Reference to a description of the resource or documentation or (human readable) information related to the resource. Such link can also be used to associate the response document with the corresponding JSON Schema file as defined in section 8.2 of [OR7].	Range: array of Link as defined in Table 25.	Zero or one (optional)

Example 30: Search Link encoding example (OpenSearch and OpenAPI)
{
  "search": [
		{
			"href": "http://fedeo.esa.int/opensearch/description.xml?parentIdentifier=LANDSAT.ETM.GTC",
			"type": "application/opensearchdescription+xml"
		},
		{
			"href": "http://fedeo.esa.int/opensearch/description.json?parentIdentifier=LANDSAT.ETM.GTC",
			"type": "application/openapi+json;version=3.0"
		}
	]
}

Example 31: Search Link encoding example (SPARQL)
{
  "search": [
		{
			"href": "https://www.foodie-cloud.org/sparql",
			"type": "application/rdf+xml;profile=\"http://www.w3.org/ns/sparql-service-description#\""
		}
	]
}

The example below refers to a description of the resource on an HTML documentation page and a Jupyter Notebookfootnote::[https://jupyter.org/] .

Example 32: Describedby Link encoding example
{
	"describedby": [
			{
				"href": "https://earth.esa.int/web/guest/data-access/browse-data-products/-/asset_publisher/y8Qb/content/landsat-7-etm-enhanced-thematic-mapper-plus-geolocated-terrain-corrected-systematic-processing-over-kiruna-and-masplomas",
				"type": "text/html"
			},
         {
				"href": "https://earth.esa.int/web/guest/data-access/browse-data-products/-/asset_publisher/y8Qb/content/landsat-7-etm-enhanced-thematic-mapper-plus-geolocated-terrain-corrected-systematic-processing-over-kiruna-and-masplomas.ipynb",
				"type": "application/x-ipynb+json"
	      }
    ]
}

7.6.2.  Link

Requirement 30:
/req/link
A “Link” object shall implement the properties shown in Table 25, with the value matching the type shown, and with the obligation shown.

The Link block contains the properties of a hypermedia link to a resource identified by its URI [NR5].

Figure 24 — Link Schema

For the GeoJSON encoding of each Link object, we use the encoding defined in section 7.1.10 of the GeoJSON encoding for OWS Context OGC 14-055r2 [NR5]. The equivalent JSON-LD encoding is consistent with section 6.1.2.2 of OGC 15-053 [OR6]. Complete description of Link is given in Table 25.

Table 25 — Link object properties

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

7.6.3.  Offering

Requirement Class: Offering
/req/offering
Target Type	Data instance
Dependency	JSON [NR1]
Dependency	OGC 14-055r2 [NR5]
Dependency	/req/operation
Requirement 31:	/req/offering/properties

Requirement 31:
/req/offering/properties
An “Offering” object shall implement the properties defined in OGC 14-055r2 [NR5], with the value matching the type shown, and with the obligation shown.

The Offering block is fully defined in OGC 14-055r2 [NR5]. It describes a service or inline content offering for the EO product and is intended to be consumed by clients that support OGC standards. In the context of the current specification, an Offering can be used to describe:

• View services allowing visualisation via OGC WMS or WMTS service interfaces;

• Reference to download or ordering services according to specific OGC protocols (e.g., WCS); and

• Reference to processing resources including WPS or hosted processing services.

Figure 25 — Offering Schema

Table 26 — Offering object properties

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

A number of examples for typical offerings (e.g., WMS, WPS) are included below.

Example 33: JSON encoding example (WMS)
    {
			"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"
				}
			]
		}

Example 34: JSON encoding example (WCS)
{
	"code": "http://www.opengis.net/spec/owc-geojson/1.0/req/wcs",
	"operations": [
		{
			"code": "GetCapabilities",
			"method": "GET",
			"href": "http://131.176.196.55/wcs?service=WCS&Request=GetCapabilities"
		},
		{
			"code": "DescribeCoverage",
			"method": "GET",
			"type": "application/xml",
			"href": "http://131.176.196.55/wcs?service=WCS&Request=DescribeCoverage&version=2.0.0&CoverageId=LE7_RGB"
		}
	]
}

Example 35: JSON encoding example (WPS)
{
	"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>"
            }
		}
	]
}

7.6.4.  Operation

Requirement 32:
/req/operation
An “Operation” object shall implement the properties of “Operation” defined in OGC 14-055r2 [NR5], with the value matching the type shown, and with the obligation shown.

The Operation block is fully defined in OGC 14-055r2 [NR5]. It describes an operation of a service or inline content offering for the EO collection and is intended to be consumed by OGC-compliant clients. The “code” property identifies the OGC operation name, e.g., GetCapabilities, GetMap etc.

Figure 26 — Operation Schema

Table 27 — Operation object properties

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

For examples, we refer to the examples of Offering given in section 7.6.3.

7.7.  Requirements class: Spatial Information

7.7.1.  Spatial Extent

The spatial information is encoded as a Geometry object as defined by GeoJSON. There are requirements for Position, Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, Geometry Collection described in OGC 17-003r2 [NR4]. Although these geometry objects are relevant for EO Products, for EO Collections, the most common geometry object is a Polygon. For the detailed definition of the geometry objects and corresponding examples, we refer to [NR4].

Requirement Class: Spatial Extent
/req/geometry
Target Type	Data instance
Dependency	GeoJSON [NR2]
Dependency	/req/point
Dependency	/req/multi-point
Dependency	/req/linestring
Dependency	/req/multi-linestring
Dependency	/req/polygon
Dependency	/req/multi-polygon
Requirement 33:	/req/geometry/properties

Requirement 33:
/req/geometry/properties
Objects in a data instance that describe 0-D, 1-D, or 2-D geometries with positions in the WGS-84 system shall be encoded using the GeoJSON geometry encoding [NR2].

7.7.1.1.  Geometry

The Geometry object contains a type property and coordinates property. The object can be any of the specialisations described below. The expected value for the coordinates property depends on the type of the geometry.

Figure 27 — Geometry Schema (GeoJSON)

Complete description of the Geometry properties is given in Table 28. The possible specializations are explained in [NR4].

Table 28 — Geometry object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $.geometry.type	Type of the geometry representing the footprint. Can be one of the geometry types: Point, LineString, Polygon, MultiPoint, MultiLineString or MultiPolygon.	Property [NR2], [OR33] Range: String	One (mandatory)
coordinates $.geometry.coordinates	Array with structure determined by the geometry type to be represented. Note that a position (array of numbers) is indicated by longitude, latitude (in that order).	Property [NR2], [OR33] Range: See section 3.1 of [NR2].	One (mandatory)

Note that consumers that wish to use the standard JSON-LD Processing Algorithms may need to use an alternative representation for the geometry objects as explained in section 8.2 and avoid the use of multi-dimensional arrays.

7.7.1.2.  Polygon

Figure 28 — Polygon Schema

Note that according to [NR2], Polygon rings shall follow the right-hand rule for orientation (counter-clockwise external rings, clockwise internal rings).

Example 36: GeoJSON Polygon encoding example
{
	"type": "Feature",
	"id": "http://fedeo.esa.int/opensearch/request/?httpAccept=application/geo%2Bjson&parentIdentifier=EOP%3AESA%3AFEDEO%3ACOLLECTIONS&uid=EOP%3AESA%3ASentinel-2",
	"geometry": {
		"type": "Polygon",
		"coordinates": [
			[
				[
					-180,
					-90
				],
				[
					180,
					-90
				],
				[
					180,
					90
				],
				[
					-180,
					90
				],
				[
					-180,
					-90
				]
			]
		]
	},

   "properties": { }
}

Example 37: Location Keywords encoding example (GCMD)
{
  "categories": [
    {
      "term": "https://gcmdservices.gsfc.nasa.gov/kms/concept/51e3593f-4b42-4141-972e-96666c479f9c",
      "scheme": " https://gcmdservices.gsfc.nasa.gov/kms/concepts/concept_scheme/locations",
      "label": "GLOBAL"
    }
  ]
}

Example 38: Location Keywords encoding example (INSPIRE)
{
  "categories": [
    {
      "term": "http://publications.europa.eu/resource/authority/country/BEL",
      "scheme": "http://publications.europa.eu/resource/authority/country"
    }
  ]
}

7.8.  Requirements class: Temporal Information

7.8.1.  Temporal Extent

Requirement 35:
/req/temporal-extent
A “TemporalExtent” object shall implement the properties shown in Table 29, with the value matching the type shown, and with the obligation shown.

The TemporalExtent object contains the properties related to the start and end time of the acquisition of the data.

Figure 29 — TemporalExtent Schema

Complete description of the TemporalExtent properties is given in Table 29.

Table 29 — TemporalExtent object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $.properties.temporal.type	Type of the element. This property has the fixed value “PeriodOfTime”.	Domain: PeriodOfTime Range: String Fixed value: “PeriodOfTime”	Zero or one (optional)
beginningDateTime $.properties.temporal.beginningDateTime	Acquisition start date time DateTime representation, as defined by RFC 3339, section 5.6footnote::[rfc3339,A String matching RFC 3339 section 5.6. yyyy-MM-ddThh:mm:ss[.S](Z/(+/-)th:tm) where yyyy = Four digit year, MM = Two digit month (01 = January), dd = Two digit day of month (01 = first day), hh = Hour of day (00 – 23), mm = Minute of hour (00 – 59), ss = Second of minute (00 – 59), S = fraction of seconds with any precision. Times are in UTC (ending with the mandatory Z character) or defined with an offset w.r.t. UTC: th = Time offset hours (00 — 23), tm = Time offset minutes (00 — 59).]	Domain: PeriodOfTime Range: DateTime	Zero or one (optional)
endingDateTime $.properties.temporal.endingDateTime	Acquisition end date time DateTime representation, as defined by RFC 3339, section 5.613footnote::[rfc3339]	Domain: PeriodOfTime Range: DateTime	Zero or one (optional)

Example 39: TemporalExtent encoding example
{
      "beginningDateTime": "2015-06-23T00:00:00Z",
      "endingDateTime": "2018-11-28T15:23:57Z"
}

Example 40: Temporal Keywords encoding example
{
  "categories": [
    {
      "term": "https://gcmdservices.gsfc.nasa.gov/kms/concept/99ef187e-6940-4c10-8d65-00d4426d493b ",
      "scheme": " https://gcmdservices.gsfc.nasa.gov/kms/concepts/concept_scheme/temporalresolutionrange ",
      "label": "Diurnal"
    }
  ]
}

7.9.  Requirements class: Acquisition Information

The acquisition information applicable to EO Collections is a subset of the acquisition information applicable to EO products. The encoding of this subset is identical to the encoding defined in OGC 17-003r2 [NR4] and is repeated here for convenience of the reader.

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

Figure 30 — AcquisitionInformation Schema

The complete description of the AcquisitionInformation properties is given in Table 30. It is a subset of the properties defined in OGC 17-003r2 [NR4].

Table 30 — AcquisitionInformation object properties

Example 41: AcquisitionInformation encoding example
{
  "platform": {
    "id": "https://earth.esa.int/concept/sentinel-2",
    "platformShortName": "Sentinel-2"
  },
  "instrument": {
    "id": "https://earth.esa.int/concept/s2-msi",
    "instrumentShortName": "MSI"
  },
  "acquisitionParameters": {
    "beginningDateTime": "2015-06-23T00:00:00Z"
  }
}

7.9.1.  Platform

The encoding of platform information is identical to the encoding defined in OGC 17-003r2 [NR4] but is repeated here for convenience of the reader.

Requirement 38:
/req/platform
A “Platform” object shall implement the properties shown in Table 31, with the value matching the type shown, and with the obligation shown.

The Platform block contains the properties of the platform that was used to perform the observation.

Figure 31 — Platform Schema

Complete description of the Platform properties is given in Table 31.

Table 31 — Platform object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $..acquisitionInformation[*].platform.type	Type of the object. This property has the fixed value “Platform”.	Range: String Fixed value: “Platform”	Zero or one (optional)
id $..acquisitionInformation[*].platform.id	URI of platform. E.g., http://gcmdservices.gsfc.nasa.gov/kms/concept/a1498dff-002d-4d67-9091-16822c608221 for ENVISAT	Range: String (URI)	Zero or one (Optional)
platformShortName $..acquisitionInformation[*].platform.platformShortName	Platform short name (e.g., “Seasat” or “ENVISAT”)	Domain: Platform Range: String	One (mandatory)
platformSerialIdentifier $..acquisitionInformation[*].platform.platformSerialIdentifier	Platform serial identifier (e.g., for Seasat : 1).	Domain: Platform Range: String	Zero or one (Optional)
orbitType $..acquisitionInformation[*].platform.orbitType	High level characterisation of main mission types taken from a codelist	Domain: Platform Range: String Values: GEO, LEO	Zero or one (Optional)

Example 42: Platform encoding example
{
            "id": "http://gcmdservices.gsfc.nasa.gov/kms/concept/1bffe898-f4a2-458e-92c5-cd7c9c1cd5f0",
            "platformShortName": "Seasat",
            "platformSerialIdentifier": "1",
            "orbitType": "LEO"
}

7.9.2.  Instrument

The encoding of instrument information is identical to the encoding defined in OGC 17-003r2 [NR4] but is repeated here for convenience of the reader.

Requirement 39:
/req/instrument
An “Instrument” object shall implement the properties shown in Table 32, with the value matching the type shown, and with the obligation shown.

The Instrument block contains the properties of the instrument that was used to perform the observation.

Figure 32 — Instrument Schema

A complete description of the Instrument properties is given in Table 32.

Table 32 — Instrument object properties

JSON Property	Definition	Data type and values	Multiplicity and use
type $..acquisitionInformation[*].instrument.type	Type of the object. This property has the fixed value “Instrument”.	String Fixed value: “Instrument”	Zero or one (optional)
id $..acquisitionInformation[*].instrument.id	URI of instrument. E.g., http://gcmdservices.gsfc.nasa.gov/kms/concept/912c3308-23bc-4e12-b7fb-9d82e9fc5fe9 for ENVISAT ASAR	Domain: Instrument Range: String (URI)	Zero or one (optional)
sensorType $..acquisitionInformation[*].instrument.sensorType	Sensor type based on codelist Values: OPTICAL RADAR ALTIMETRIC ATMOSPHERIC LIMB	Domain: Instrument Range: String	Zero or one (optional)
instrumentShortName $..acquisitionInformation[*].instrument.instrumentShortName	Instrument (Sensor) name	Domain: Instrument Range: String	One (mandatory)
description $..acquisitionInformation[*].instrument.description	Instrument description	Domain: Instrument Range: String	Zero or one (optional)

Example 43: Instrument encoding example
{               "id":  "http://gcmdservices.gsfc.nasa.gov/kms/concept/a37282d4-322c-4dd0-8edc-36099b9b586c",
                "sensorType": "RADAR",
                "instrumentShortName": "SAR"
}

7.10.  Requirements class: Product Information

The product information applicable to EO Collections is a subset of the product information applicable to EO products. The encoding of this subset is borrowed from the encoding defined in OGC 17-003r2 [NR4].

The ProductInformation block contains the common properties related to the product belonging to the collection which is the result of the observation and acquisition of the data.

Figure 33 — ProductInformation Schema

The complete description of the AcquisitionInformation properties is given in Table 33. It groups a subset of properties defined in OGC 17-003r2 [NR4].

Table 33 — ProductInformation object properties

Example 44: ProductInformation encoding example
{
    "referenceSystemIdentifier": "http://www.opengis.net/def/crs/EPSG/0/32631",
    "timeliness": "NOMINAL",
    "processingLevel": "3",
    "resolution": [ 10, 20 ],
    "productType": [ "FAPAR" ],
}

8.1.  Additional properties

In the current EO Collection metadata GeoJSON(-LD) Encoding Standard, an “extension” is any property, or object type not defined by the current document. Consuming implementations that encounter unfamiliar extensions shall not stop processing or signal an error and shall continue processing the items as if those properties were not present. Note that support for extensions can vary across implementations and no normative processing model for extensions is defined. Accordingly, implementations that rely too heavily on the use of extensions may experience reduced interoperability with other implementations.

For extensions, JSON-LD [NR13] is used as the primary mechanism for defining and disambiguating extensions. Implementations that wish to fully support extensions should use JSON-LD mechanisms.

It is important to note that the JSON-LD Processing Algorithms [OR4], as currently defined, will silently ignore any property not defined in a JSON-LD @context. Implementations that publish EO OpenSearch Response documents containing extension properties should provide a @context definition for all extensions.

8.2.  JSON-specific constructs

It is important to note that there are valid JSON constructs which cannot be used within a JSON-LD document. For instance, JSON-LD forbids “arrays of arrays” as used by the GeoJSON specification. While implementations are free to use such constructs as extensions within an EO Dataset Metadata document, consumers that use the standard JSON-LD Processing Algorithms will be required to either ignore such extensions or map those to alternative compatible constructs prior to applying the JSON-LD algorithms. Complex geometries can be converted to GeoSPARQL [OR23] “Well-Known Text” representations as illustrated in the non-normative example below.

Example 45: JSON-LD encoding example using GeoSPARQL
{
	"@context": {
		"gj": "https://purl.org/geojson/vocab#",
		"gsp": "http://www.opengis.net/ont/geosparql#"
	},
	"@type": [
		"gj:Feature",
		"gsp:Feature"
	],
	"@id": "http://fedeo.esa.int/opensearch/request/?parentIdentifier=SEA_GEC_1P&uid=SE1_OPER_SEA_GEC_1P_19780927T010430_19780927T010445_001316_0000_2267_9B4F",
	"gsp:hasGeometry": {
		"@type": "gsp:Geometry",
		"gsp:asWKT": "Polygon((-2.682513, 63.261372, -2.695740, 61.997604, 0.005087, 61.965195, 0.135472, 63.227173, -2.682513, 63.261372))"
	},
	...
}

Other implementations may encode geometries as recommended by the GeoDCAT-AP specification [OR15] §II.10.

Figure 34 — Location Schema

Complete description of Location is given in Table 34.

Table 34 — Location object properties

Example 46: JSON encoding example using Location
{
	"@context": {
		…
	},

	"type": "Feature",
	"geometry": null,

	"properties": {

      "spatial": {
				"geometry": [
					{
						"type": "gsp:gmlLiteral",
						"value": "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\"><gml:lowerCorner>-180 -90</gml:lowerCorner><gml:upperCorner>180 90</gml:upperCorner></gml:Envelope>"
					},
					{
						"type": "gsp:wktLiteral",
						"value": "POLYGON ((-180 -90, -180 90, 180 90, 180 -90, -180 -90))"
					},
					{
						"type": "https://www.iana.org/assignments/media-types/application/vnd.geo+json",
						"value": "{\"type\":\"Polygon\",\"crs\":{\"type\":\"name\",\"properties\":{\"name\":\"urn:ogc:def:crs:OGC:1.3:CRS84\"}},\"coordinates\":[[[-180,-90],[-180,90],[180,90],[180,-90],[-180,-90]]]}"
					}
				]
			}
   }
}

Example 47: JSON-LD encoding example using Location
{
	  "@context": {
        	"dcat": "http://www.w3.org/ns/dcat#",
		   "dct": "http://purl.org/dc/terms/",
         "gsp": "http://www.opengis.net/ont/geosparql#",
         "locn": "http://www.w3.org/ns/locn#",
		    …
	  },


     "dct:spatial": {
            "@type": "dct:Location",
				"locn:geometry": [
					{
						"@type": "gsp:gmlLiteral",
						"@value": "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\"><gml:lowerCorner>-180 -90</gml:lowerCorner><gml:upperCorner>180 90</gml:upperCorner></gml:Envelope>"
					},
					{
						"@type": "gsp:wktLiteral",
						"@value": "POLYGON ((-180 -90, -180 90, 180 90, 180 -90, -180 -90))"
					},
					{
						"@type": "https://www.iana.org/assignments/media-types/application/vnd.geo+json",
						"@value": "{\"type\":\"Polygon\",\"crs\":{\"type\":\"name\",\"properties\":{\"name\":\"urn:ogc:def:crs:OGC:1.3:CRS84\"}},\"coordinates\":[[[-180,-90],[-180,90],[180,90],[180,-90],[-180,-90]]]}"
					}
				]
		}

}