I. Executive summary
This Report summarizes the OGC Testbed-21 Data Quality for Integrity, Provenance, and Trust (DQ4IPT) activity, which evaluated and implemented ISO 19157-1:2023 as the primary framework for standardized data quality (DQ) reporting in Earth Observation (EO) systems. As EO data increasingly supports automated analytics and AI-driven decision-making, structured quality assessment, traceable provenance, and verifiable integrity are essential to establishing trust. Indeed, integrity, provenance, and trust (IPT) considerations are increasingly becoming a necessity in data ecosystems.
The report analyzes interoperability between ISO 19157, ISO 19115/19115-4, W3C PROV, NASA Unified Metadata Model (UMM), OGC Training Data Markup Language for AI (TrainingDML-AI) standard, and the SpatioTemporal Asset Catalog (STAC) community standard. Two DQ-enabled IPT server prototypes demonstrate delivery of satellite products metadata with embedded ISO 19157 quality reports and PROV-based lineage. The server prototypes are based on the OGC API — Processes and OGC API — Records standards respectively. A supporting software library enables metadata conversion, provenance transformation, and validation.
Results show that ISO 19157-1:2023 provides a stronger foundation for trust-enabled EO infrastructures than ISO 19115 alone, particularly through standardized measures, meta-quality, and Geospatial Data Interpretability Index (GDII) assessment, while maintaining backwards compatibility and cross-standard interoperability.
I.A. Key Achievements
Implementation of ISO 19157-1:2023 data quality metadata in IPT frameworks
Successful integration with NASA UMM and OGC TrainingDML-AI metadata standards
Development of metadata conversion library supporting multiple quality standards
Integration of ISO 19115 and ISO 19157 standards in a proposed STAC extension for liability and claims
Integration of W3C PROV in the above mentioned STAC extension
STAC extension liability and claims submitted as OGC Building Block to manage Data Quality, Identity, Provenance and Trust as a service
DQ_ prefix used as an alias to non prefixed concepts.
I.B. Document and Components Delivered
D001: DQ-enabled IPT Server Architecture and Requirements (this document)
D101: IPT Server that implements the OGC API – Processes standard
D102: IPT Server that implements the OGC API – Records standard and supports ISO 19115-4 conformant metadata
D103: Metadata Conversion Software Library
I.C. Value Proposition
This work enables:
Data Producers: Comprehensive quality reporting following international standards
Data Consumers: Machine-readable quality metadata for fitness-for-purpose assessment
ML Developers: Quality-aware training data selection via TrainingDML-AI integration
Achieves: Interoperable quality metadata across NASA, ESA, and CEOS systems
II. Keywords
The following are keywords to be used by search engines and document catalogues.
Data quality, Identity Provenance Trust, ISO 19157, ISO 19115-4, NASA UMM, Training ML, QA4EO CEOS
III. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- 4113 Engineering (L. Colaiacomo)
- Geoknoesis LLC (S. Fellah)
- KurrawongAI (J. Feiss)
- Secure Dimensions GmbH (A. Matheus)
- Spacebel s.a. (Y. Coene)
1. Introduction
The incorporation and prioritization of the principles of Integrity, Provenance, and Trust (IPT) are critical for maintaining the availability, reliability, and credibility of data across various endpoints and operators. As defined in OGC Testbed-20, these principles are mutually reinforcing: Integrity ensures data remains unaltered and fit for purpose; Provenance provides the chain of custody to verify that integrity; and Trust is the confidence established by these assurances.
However, a prerequisite for achieving trust is the effective documentation and communication of Data Quality. As noted by Bugbee et al., “Incorrect or missing information may impede a user from determining the dataset’s fitness for a particular engineering research question or new application.”[34] This Report documents the results of the DQ4IPT task, which explored how standardized data quality reporting can be integrated into IPT frameworks to provide this essential assurance for Earth Observation (EO) data.
The integration of data quality metadata into Integrity, Provenance, and Trust (IPT) frameworks for Earth observation data requires careful selection and implementation of appropriate international standards. This Report documents the development and evaluation of data quality-enabled IPT servers based on comprehensive analysis of available data quality standards, including ISO 19157-1:2023, ISO 19115/19115-4, W3C PROV, and their interoperability with NASA UMM and OGC TrainingDML-AI.
1.1. Background
1.1.1. The Transition to Analysis Ready Data
Over the last three decades, the Earth Observation (EO) industry has undergone a fundamental paradigm shift, moving from a scarcity-driven scientific discipline to a massive-scale data utility. This evolution has been driven by the convergence of open data policies, commercial “New Space” agility, and the explosion of Artificial Intelligence. These forces collectively necessitated the creation of Analysis Ready Data (ARD), a concept for a standard that transforms satellite imagery from simple “pictures” into reliable, machine-readable measurements.
This transformation occurred in distinct phases:
The Data Deluge: The opening of government archives (Landsat, Sentinel) and the rise of high-cadence commercial monitoring (e.g., Planet) created data volumes that manual processing could no longer handle; and
The AI Convergence: The rise of Geospatial Foundation Models means data is now consumed primarily by algorithms rather than human analysts. These models require “tensor-ready” consistency, necessitating strict ARD standards to ensure pixels are physically accurate and comparable over time.
1.1.2. The Challenge of Trust in Automated Systems
As EO data becomes the input for automated decision-making from algorithmic trading to defense systems, it becomes a high-value vector for “Data Poisoning” attacks. Unlike traditional vandalism, these attacks aim to weaponize the credibility of the data. For example, an adversary might subtly alter spectral signatures in ARD to hide environmental non-compliance or introduce mathematical noise to blind computer vision models (Adversarial AI).
In this context, Integrity is not just about error checking; it is a security control against adversarial modification. Provenance is the defense against “Deepfake Geography,” ensuring that the chain of custody can be audited back to a trusted sensor. Consequently, Earth observation data users require confidence in the quality, provenance, and trustworthiness of satellite imagery and derived products
1.1.3. Implementation Gaps
Despite these emerging threats, current implementations lack standardized mechanisms for comprehensive data quality reporting that integrate with modern provenance tracking frameworks. While ARD standards address the scientific Geospatial Data Interpretability Index (GDII) of the data, The GDII is an ordinal quality index defined over a scale of 1 to 9 (or 1 to 5 for lower-resolution applications), where each level is associated with: A normative level description specifying the analytical tasks the data objectively supports at that level (analogous to NIIRS criterion text) A minimum threshold for each contributing ISO 19157 quality element they do not inherently solve the trust and security requirements of distributed systems.
Organizations implementing Integrity, Provenance, and Trust (IPT) capabilities currently face multiple specific challenges.
Quality Standard Selection: Multiple overlapping standards exist (ISO 19115, ISO 19157, ISO 19115-4) with varying levels of comprehensiveness and adoption.
Metadata Interoperability: There is a critical need to support NASA UMM, TrainingDML-AI, and other domain-specific metadata models alongside international standards.
Provenance Integration: Systems face conflicting requirements for both geospatial (ISO) and semantic web (W3C PROV) provenance representations.
Measure Standardization: There is a lack of consistent quality measure definitions across organizations, leading to ambiguity in automated reporting.
Trust Assessment: There is a growing need for “metaquality” (quality of the quality report itself) and Geospatial Data Interpretability Index (GDII) evaluations to determine if data is fit for purpose.
This Testbed addressed these challenges by implementing and evaluating ISO 19157-1:2023 as the primary data quality framework, with full interoperability support for existing standards.
1.1.4. Foundations from OGC Testbed-20
The OGC Testbed-20 IPT activity established the initial architectural building blocks for resilient data services, demonstrating how to maintain data reliability in distributed systems where access points fluctuate. Two primary IPT server implementations were developed to secure the data lifecycle: a Federated Agile Collaborative Trusted System (FACTS) by Secure Dimensions, which utilized Smart Certificates to manage data reliability through trusted processes like “Trusted Teapot” and “Trusted Watermarking”; and a server by Spacebel that leveraged Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) to verify the authenticity of Earth Observation (EO) data sources. These architectures were validated through nine Technology Integration Experiments (TIEs) and applied to critical scenarios, including an EO Data Supply Chain use case for verifying data origin, an EO Traceability Service for tracking product lineage, and a Situation Report use case that merged vector and raster data into validated outputs. Collectively, these efforts demonstrated how IPT principles can support cross-organizational trust without altering legacy data formats, providing the technical baseline upon which this testbed expands.
1.2. Aims
The aim of the DQ4IPT task was to develop and demonstrate a comprehensive data quality framework for IPT that:
Standardizes Quality Reporting: Implements ISO 19157-1:2023 for comprehensive, interoperable quality metadata;
Enables Provenance Integration: Maintains full compatibility with W3C PROV for semantic web applications;
Supports Metadata Interoperability: Demonstrates conversion between ISO 19157, ISO 19115, NASA UMM, and TrainingDML-AI;
Provides Trust Assessment: Implements metaquality and Geospatial Data Interpretability Index (GDII) evaluation frameworks; and
Delivers Practical Implementation: Creates reusable server components and software libraries.
1.3. Objectives
OGC Testbed-21 is a collaborative effort to rapidly prototype, design, develop, and test solutions to location-related challenges. OGC Testbed-21 is exploring the following tasks:
Data Quality for Integrity, Provenance, and Trust (DQ4IPT);
GEOINT Imagery Media for Intelligence, Surveillance, and Reconnaissance for OGC Testbed-21 (GIMI-T21); and
Conformance Testing Tool Development (CTTG).
While working on the aforementioned tasks, participants collaborated to create mechanisms that improve the representation of Data Quality in Integrity, Provenance, and Trust (IPT) frameworks; facilitate the development of the GEOINT Imagery Media for Intelligence, Surveillance, and Reconnaissance (GIMI) specification; and advance the development of conformance testing tools for GIMI. The aim of the DQ4IPT task was to explore the integration of data quality considerations into IPT frameworks in such a way that users of Earth Observation data can have confidence in the data they use for analysis. The objectives of the task were therefore to:
develop a reference architecture that integrates data quality considerations into IPT frameworks,
demonstrate how the reference architecture can improve confidence in Earth Observation data, and
identify the challenges likely to be encountered when adapting existing platforms to the approach proposed by the reference architecture.
The deliverables of the task include the following.
D101 DQ-enabled IPT Server 1: An OGC API – Processes implementation, along with supporting software components, that together implement IPT capabilities. At least one of the processes offered by the API must offer outputs that include a processed image (originally collected by a satellite) and JSON-encoded ISO 19115 metadata that includes data quality reports that reference definitions of quality measures from OGC RAINBOW.1
Key features of the DQ-enabled IPT Server 1 include the following.
D102 DQ-enabled IPT Server 2: An OGC API – Records implementation, along with supporting software components, that together implement IPT capabilities. The metadata served by the OGC API – Records implementation must include links to JSON-encoded ISO 19115 metadata that includes data quality reports that reference definitions of quality measures from OGC RAINBOW.
D103 DQ-enabled software library: A software library capable of accessing metadata and data quality reports from the servers implemented by Components D101 and D102, and then retrieving data from the servers. The software library must be able to convert metadata from ISO 19115-3 conformant XML documents to ISO 19115-4 (draft) conformant JSON documents. The software library must also support conversion of metadata from NASA UMM conformant JSON documents to ISO 19115-4 (draft) conformant JSON documents. Furthermore, the software library must demonstrate conversion of metadata from TrainingDML-AI JSON documents to ISO 19115-4 (draft) conformant JSON documents.
D001 Data Quality for Integrity, Provenance and Trust Report: A report that captures all results and lessons learned.
1.3.1. Primary Objectives
The objectives of the DQ4IPT task were as follows.
Implement ISO 19157-1:2023 Framework: Develop server components using ISO 19157-1:2023 as the primary data quality standard, including:
All quality categories (completeness, logical consistency, positional accuracy, temporal quality, thematic quality, metaquality, Geospatial Data Interpretability Index (GDII))
Standardized quality measures from ISO 19157 register (https://iso19157.quality.fgi.fi/)
Structured evaluation methods (directInternal, directExternal, indirect)
Multiple result types (quantitative, conformance, descriptive, coverage)
Ensure Standards Interoperability: Demonstrate conversion and compatibility between:
ISO 19157-1:2023 ↔ ISO 19115/19115-4 (backward compatibility)
ISO 19157 ↔ NASA UMM (5/5 compatibility via ISO 19115 alignment)
ISO 19157 ↔ OGC TrainingDML-AI (4/5 compatibility for ML training data)
ISO 19157 ↔ W3C PROV (full provenance integration)
Integrate Provenance and Trust: Maintain identity and provenance compatibility across all quality frameworks:
W3C PROV for semantic web provenance graphs
ISO 19115/19157 lineage for geospatial workflows
Metaquality assessment for trust evaluation
Validate with OGC RAINBOW: Reference ISO 19157 registered quality measures from OGC RAINBOW catalog
Develop Practical Implementations: Create reusable server components and libraries
1.3.1.1. Deliverables
The deliverables of the task include the following.
D101 DQ-enabled IPT Server 1: An OGC API – Processes implementation, along with supporting software components, that together implement IPT capabilities. At least one of the processes offered by the API must offer outputs that include a processed image (originally collected by a satellite) and JSON-encoded ISO 19115 metadata that includes data quality reports that reference definitions of quality measures from OGC RAINBOW. Key features include:
Processed satellite imagery outputs
JSON-encoded ISO 19157-1:2023 data quality reports (RECOMMENDED)
Backward compatible ISO 19115/19115-4 quality reports
Quality measures referencing ISO 19157 register and OGC RAINBOW definitions
W3C PROV provenance graphs with full identity preservation
D102 DQ-enabled IPT Server 2: An OGC API – Records implementation, along with supporting software components, that together implement IPT capabilities. The metadata served by the OGC API – Records implementation must include links to JSON-encoded ISO 19115 metadata that includes data quality reports that reference definitions of quality measures from OGC RAINBOW. Key features include:
Metadata records with JSON-encoded ISO 19115 quality reports
Metadata including data quality reports
Data quality reports that reference definitions of quality measures from OGC RAINBOW.
D103 DQ-enabled software library: A software library capable of accessing metadata and data quality reports from the servers implemented by Components D101 and D102, and then retrieving data from the servers. The software library must be able to convert metadata from ISO 19115-3 conformant XML documents to ISO 19115-4 (draft) conformant JSON documents. The software library must also support conversion of metadata from NASA UMM conformant JSON documents to ISO 19115-4 (draft) conformant JSON documents. Furthermore, the software library must demonstrate conversion of metadata from TrainingDML-AI JSON documents to ISO 19115-4 (draft) conformant JSON documents. Capabilities include:
Accessing ISO 19157-1:2023 and ISO 19115/19115-4 quality reports
Converting between ISO 19115-3 XML ↔ ISO 19157 JSON
Converting NASA UMM JSON → ISO 19157/ISO 19115-4 JSON
Converting TrainingDML-AI JSON → ISO 19157/ISO 19115-4 JSON
Maintaining provenance across all conversions using W3C PROV
Validating quality reports using JSON Schema and SHACL
D001 Data Quality for Integrity, Provenance and Trust Report: A report that captures all results and lessons learned, documenting:
ISO 19157-1:2023 implementation approach and results
Standards comparison and interoperability analysis
Best practices for quality-enabled IPT frameworks
Lessons learned and recommendations for future work
2. Topics
2.1. Review of Implemented Standards: Significance and Challenges
This section provides a critical evaluation of the key standards selected for the DQ4IPT architecture. It analyzes their strategic significance for Integrity, Provenance, and Trust (IPT) and documents specific implementation challenges encountered during the Testbed.
2.1.1. ISO 19157 (Geographic Information — Data Quality)
The standardization of geospatial data quality has evolved from fragmented regional efforts in the 1980s to a consolidated international framework. Initially, ISO managed data quality through three separate and interdependent specifications (ISO 19113, 19114, and 19138), but this complexity led to the 2013 unification of principles, evaluation procedures, and measures into a single document, ISO 19157:2013. This consolidation provided a unified conceptual model but remained a static document, which proved difficult to update at the pace required by modern technologies like Big Data and Artificial Intelligence.
To address these challenges, the standard was recently restructured into the modular ISO 19157-n series (where n is a part number), dividing the framework into specialized parts to enhance flexibility and machine readability.
Part 1 (General Requirements) defines the core conceptual model and evaluation procedures, notably replacing the legacy “Geospatial Data Interpretability Index (GDII)” element with a robust extensibility mechanism.
Part 2 (XML Schema Implementation) provides the technical encoding rules for machine-readable reporting.
Part 3 (Data Quality Measures Register) establishes the governance for a dynamic online register, allowing new quality measures to be added and maintained without requiring a revision of the entire standard.
Usage in Testbed: Utilized as the primary framework for structuring data quality reports, defining measures, and encoding results within the IPT Servers.
Significance for IPT: Unlike ISO 19115, which treats quality as a metadata field, ISO 19157-1 elevates quality to a standalone model. Its introduction of Metaquality (the quality of the quality report itself) and completeness (measures the presence and absence of features, their attributes, and relationships in a dataset compared to what should be present according to specifications) is critical for establishing Trust, as it allows users to quantitatively assess the reliability of the quality claims.
Limitations & Challenges
Lack of JSON Schema: The standard officially supports XML. Developing a robust, non-normative JSON schema for modern REST APIs was a primary engineering hurdle for this Testbed.
ML Gap: The standard lacks native measure codes for Machine Learning concepts (e.g., Class Imbalance, Label Noise), requiring custom extensions.
Complexity: The nested structure of evaluations (Direct/Indirect) and result types creates a high barrier to entry for developers compared to simpler models.
2.2. ISO 19115 Series (Geographic Information — Metadata)
The standardization of geospatial metadata began with the ISO 19115 series, which established the core conceptual models for describing geographic information. While the conceptual fundamentals were refined in ISO 19115-1:2014, the industry historically relied on the ISO/TS 19139 Technical Specification to provide the concrete XML encoding needed for actual data exchange. This “ISO XML” format became the backbone of global interoperability, eventually evolving into ISO 19115-3 to support newer data models, yet legacy 19139 implementations remain dominant in many operational archives.
Today, the industry is transitioning from these monolithic XML encodings toward lighter, web-friendly formats to align with modern architectural patterns. The emerging ISO 19115-4 standard addresses this shift by defining a standardized JSON encoding for the ISO 19115-1 conceptual model, bridging the gap between rigorous geospatial semantics and modern REST APIs. This evolution is critical for ensuring that high-fidelity metadata can be seamlessly consumed by cloud-native systems and OGC API implementations without the overhead of traditional XML parsing.
The series currently consists of the following key parts relevant to Data Quality integration.
ISO 19115-1:2014: Geographic information — Metadata — Part 1: Fundamentals (Conceptual Model)
ISO 19115-2:2019: Geographic information — Metadata — Part 2: Extensions for acquisition and processing (Critical for EO imagery lineage)
ISO 19115-3:2016: Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts
ISO 19115-4 (Draft): Geographic information — Metadata — Part 4: JSON schema implementation of metadata fundamentals
Usage in Testbed: Utilized as the primary “host” structure for embedding data quality reports. The Testbed demonstrated backward compatibility by mapping modern ISO 19157-1 quality elements into legacy ISO 19115-1 metadata records, ensuring older catalogs can still serve trust-enabled data.
Significance for IPT: ISO 19115 provides the Provenance Context (Lineage). While ISO 19157 defines quality, ISO 19115’s LI_Lineage class defines the processing history (steps and sources) that led to that quality state. Without this lineage, a user cannot verify why a dataset has a specific quality level, making it essential for the “Provenance” pillar of IPT.
Limitations & Challenges:
Complexity vs. Agility: The full ISO 19115 model is massive and deeply nested, often leading to “profile fatigue” where different organizations implement incompatible subsets.
Encoding Lag: The industry is shifting rapidly to JSON, but the normative XML encoding (ISO 19115-3) remains dominant in legacy systems. The Testbed highlighted the urgent need for a stable ISO 19115-4 JSON schema to bridge this gap for modern REST APIs.
2.2.1. OGC SpatioTemporal Asset Catalog (STAC)
The SpatioTemporal Asset Catalog (STAC) specification originated in October 2017 at a collaborative code sprint in Boulder, Colorado, convened by the Radiant Earth Foundation to address the fragmentation of geospatial data discovery. Bringing together developers from 14 major organizations—including Planet, Development Seed, Google, and Element84, the initiative aimed to replace the bespoke API structures used by different satellite providers with a unified standard. This collaborative effort was driven by the need to make geospatial assets easily indexable and searchable across different platforms without requiring developers to write custom code for every dataset.
Central to the standard’s design was a “static first” and “cloud-native” philosophy, which allowed catalogs to exist as simple, crawlable linked JSON files on cloud storage. Crucially, the dynamic STAC API was architected as a compliant implementation of OGC API — Features, ensuring that every STAC Item is accessible as a standard OGC Feature . This alignment allows standard geospatial clients (like QGIS) to consume STAC catalogs out of the box. Following a series of iterative development sprints, STAC Version 1.0.0 was released in May 2021, and the standard is now formally transitioning its intellectual property to the Open Geospatial Consortium (OGC) to ensure long-term stability and deep integration with the OGC API ecosystem.
Usage in Testbed: Implemented as the primary delivery mechanism for the IPT Servers. The Testbed utilized the STAC Liability and Claims Extension to embed ISO 19157-1 quality reports and W3C PROV lineage directly into STAC Items, making trust data immediately accessible to cloud-native clients.
Significance for IPT: STAC enables accessibility for trust data. By placing quality and provenance metadata directly in the JSON file alongside the data links (assets), STAC ensures that a user or algorithm cannot access the data without also seeing its “Trust Scorecard.” This tight coupling prevents the “detached metadata” problem common in older XML-based systems.
Alignment with CEOS-ARD (Incomplete): A critical emerging area is the alignment with CEOS Analysis Ready Data (ARD) standards. While STAC provides the structure for discovery, CEOS-ARD defines the rigorous processing and quality thresholds required for scientific analysis. Work is currently underway to develop a dedicated STAC CEOS-ARD Extension that maps these quality parameters (such as geometric accuracy and radiometric calibration) directly into STAC Items. This extension remains a work in progress, representing a significant gap in the current ecosystem: until it is finalized, identifying truly “Analysis Ready” data via standard STAC queries relies on ad-hoc metadata fields rather than a certified, interoperable standard
Limitations & Challenges:
Extension Maturity: While the core STAC specification is stable, complex IPT features rely on extensions (like the Liability and Claims Extension) that are still evolving, requiring careful version management.
Granularity Management: Applying rigorous cryptographic signatures (Integrity) to highly dynamic STAC catalogs can introduce latency, requiring a balance between real-time indexing and static verification.
2.2.2. OGC Immutable SpatioTemporal Asset Catalog (STAC)
The Immutable SpatioTemporal Asset Catalog (STAC) is a compliant implementation where the metadata records (STAC Items) are stored on a public permissioned blockchain (Hyperledger Fabric). The Testbed-21 implementation supports the regular STAC API and data format which ensures interoperability with existing implementations. To create a STAC Item onto the blockchain, aka into the Immutable Catalog, a RESTful API was implemented. The API interacts with the immutable catalog Hyperledger Fabric chaincode which ensures immutability by only allowing a get (HTTP GET), create (HTTP PUT/POST) , and delete (HTTP DELETE) of STAC Items. The API supports the creation of a single STAC Item via HTTP PUT and a bulk creation by POSTing an array of STAC Items. The API is asynchronous to ensure optimal performance when interacting with the blockchain. This asynchronous behavior introduces a latency between the actual create request and the availability on the Immutable Catalog.
By introducing a metadata storage on the blockchain, there is no need to store Verifiable Credentials, as the blockchain entries are immutable by definition and can always be verified to be trustworthy. However, to achieve a local storage of an immutable STAC Item, one export mechanism could be based on using W3C Verifiable Credentials.
Usage in Testbed: The Immutable SpatioTemporal Asset Catalog is used by the IPT-Server 1 for storing the data quality and provenance enriched metadata. A STAC Browser is deployed to visualize the STAC API in a common way.
Performance: In order to understand the performance implications of a blockchain-anchored catalog, approximately. 4.8 Million records from the ESA Sentinel-2 catalog were cloned. The Immutable Catalog with ESA Sentinel-2 records can also be searched via spatio-temporal queries.
The following results were measured on a Virtual Server environment with 8 vCPU, 16GB RAM and SSD:
fetch 1000 items with 10 parallel queries: 150ms
fetch 1000 items with BBOX filter and 10 parallel queries: 150ms
fetch 1000 items with TEMPORAL filter and 10 parallel queries: 2000ms
fetch 1000 items with BBOX and TEMPORAL filter and 10 parallel queries: 1700ms
2.2.3. W3C Verifiable Credentials (VC)
The Verifiable Credentials (VC) standard is a core component of the W3C’s decentralized identity stack, designed to express credentials on the web in a way that is cryptographically secure, privacy-respecting, and machine-verifiable. Analogous to a digital version of a physical passport or university degree, a VC allows an Issuer to assert claims about a Subject, which a Holder can then present to a Verifier. This model decouples the verification process from the issuer’s direct involvement, enabling scalable, offline-capable trust architectures.
Usage in Testbed: Used as the cryptographic “wrapper” to package ISO 19157 quality reports and EO products, ensuring tamper-evidence during transport.
Significance for IPT: VCs provide the Integrity layer that scientific formats (like GeoTIFF or JSON) lack. They allow data to be digitally signed by an Issuer (e.g., ESA, USGS) so that any modification by an intermediary invalidates the credential, preventing “Man-in-the-Middle” or “Data Poisoning” attacks.
Limitations & Challenges
Payload Overhead: Wrapping granular granule-level metadata in VCs significantly increases file sizes and processing latency.
Resolver Maturity: The ecosystem of DID Resolvers is fragmented. Universal Resolvers often failed to handle specific DID methods (e.g., did:web vs did:indy) consistently during interoperability experiments.
2.2.4. W3C PROV-O / PROV-JSON
The W3C PROV family of specifications provides a generic, cross-domain foundation for provenance interchange on the Web. Developed to enable the interoperable exchange of provenance information in heterogeneous environments, PROV defines a core data model built around Entities (physical, digital, or conceptual things), Activities (dynamic processes that generate or use entities), and Agents (parties responsible for activities). This model allows systems to capture the “who, what, where, when, and how” of data generation in a way that transcends specific application domains.
Usage in Testbed: Implemented to map ISO 19115 LI_Lineage steps into a semantic graph format that tracks the processing history of data.
Significance for IPT: PROV provides Provenance interoperability beyond the geospatial domain. By using PROV, the lineage of a satellite image becomes queryable by general-purpose semantic web tools (via SPARQL), allowing non-geospatial systems to audit the “chain of custody”.
Limitations & Challenges
Granularity Mismatch: Mapping the rigid, step-by-step structure of ISO LI_ProcessStep to the flexible graph structure of PROV Activity requires careful semantic alignment to avoid losing detail.
Verbosity: PROV-JSON representations can become extremely verbose for complex processing chains, impacting API performance.
2.2.5. OGC TrainingDML-AI
As Artificial Intelligence (AI) becomes central to Earth Observation, the quality of the training data itself—not just the imagery—has become a critical concern. The OGC Training Data Markup Language for Artificial Intelligence TrainingDML-AI is an OGC Standard designed to address this gap by defining a conceptual model and encoding for documenting high-quality training datasets. It standardizes how to describe the provenance, quality, and characteristics of training samples, ensuring that Machine Learning models are trained on reliable, well-understood data.
Usage in Testbed: Used to describe the quality of training datasets for Machine Learning models, specifically for the AI/ML use cases.
Significance for IPT: As automated systems increasingly rely on AI, the quality of training data becomes a security issue. TrainingDML-AI provides the specific metrics (IoU, F1 Score) needed to trust an AI model’s output.
Limitations & Challenges
ISO Interoperability: There is a “semantic friction” between TrainingDML-AI and ISO 19157. While 4/5 of concepts map cleanly, AI-specific statistical metrics do not have direct equivalents in the ISO measure registry, necessitating the use of generic DescriptiveResult fields which reduces machine-interpretability.
2.2.6. W3C Decentralized Identifiers (DID)
Decentralized Identifiers (DIDs) are a new type of globally unique identifier standardized by the W3C. Unlike traditional identifiers (like URLs or email addresses) that are controlled by a central registry, DIDs are designed to be decoupled from centralized authorities, allowing the owner to prove control over the identifier using cryptographic proofs. A DID resolves to a DID Document, which contains the public keys and service endpoints necessary to initiate trusted interactions, forming the foundational identity layer for Self-Sovereign Identity (SSI) architectures.
Usage in Testbed: Employed to assign persistent, cryptographically verifiable identifiers to two distinct classes of entities: Organizations (e.g., Data Providers, Catalogs) and Resources (e.g., EO Collections and individual Granules). The testbed primarily utilized the did:web method for ease of deployment, while also experimenting with ledger-based methods like did:indy.
Significance for IPT: DIDs are the foundational Trust Anchor of the architecture. By decoupling identity from physical location (server URL), DIDs allow users to verify the origin of a dataset regardless of where it is currently stored. This enables a “Self-Sovereign Identity” (SSI) model where data providers control their own verification keys, preventing “vendor lock-in” for trust services.
Limitations & Challenges
Method Fragmentation: The lack of a truly universal resolver was a significant hurdle. Interoperability experiments (TIEs) revealed friction between different DID methods (e.g., did:web vs. did:indy) and key formats. For instance, the FACTS ecosystem could process keys in publicKeyBase58 format but failed with publicKeyJwk, limiting cross-component verification.
Resolver Maturity: To be highlighted that “none of the available DID resolvers offer the level of universality… expected from a production-grade solution,” creating a fragility in the verification chain.
Granularity vs. Scale: Assigning a unique DID to every single satellite image granule (product) creates a massive management overhead for DID Documents, raising questions about the scalability of this approach for petabyte-scale archives.
2.3. Data Quality Standards for Integrity, Provenance, and Trust
Implementing trustworthy IPT frameworks for Earth observation data requires selecting and properly integrating international data quality standards. This section analyzes the available standards and recommends an implementation approach based on comprehensive testing and interoperability analysis.
2.3.1. ISO 19157-1:2023 vs ISO 19115/19115-4: Standards Comparison
Two primary ISO standards address data quality for geographic information.
ISO 19115-1:2014 / ISO 19115-4 (draft): Metadata standards that include basic quality elements as part of general metadata structures. ISO 19115-4 provides a JSON encoding for the ISO 19115-1 metadata model, thus offering a JSON alternative to the ISO 19115-3 and ISO 19157-1 XML schemas.
ISO 19157-1:2023: Dedicated data quality standard providing comprehensive framework specifically designed for quality assessment and reporting.
The following table compares the two standards based on implementation testing in STAC liability claims extension:
| Feature | ISO 19115/19115-4 | ISO 19157-1:2023 |
|---|---|---|
| Quality Categories | 5 basic categories (completeness, consistency, positional accuracy, temporal accuracy, thematic accuracy) | 7 comprehensive categories including metaquality (confidence, representativity, homogeneity) and completeness |
| Quality Measures | Generic measure descriptions, no standardization | Standardized measures with persistent codes (e.g., Measure 28 = “Mean value of positional uncertainties”) |
| Evaluation Methods | Limited method specification | Explicit method types: directInternal, directExternal, indirect |
| Result Types | Basic conformance/quantitative | 4 comprehensive result types: quantitative, conformance, descriptive, coverage |
| Lineage | Basic processStep elements | Enhanced lineage with LE_ProcessStep, LE_Source, LE_ProcessSteps with LE_Processing, LE_ProcessStepReport and LE_ProcessParameter and LE_Source from ISO 19115-2:2019 |
| Trust Assessment | None | Metaquality for quality-of-quality assessment, confidence levels |
| Measure Registry | No registry | ISO 19157 registry at https://schemas.isotc211.org/19157/-/dqm/1.2.0/ |
| completeness | Not addressed | ISO 19157-1:2023 now defines a proper extensibility mechanism in compliance with ISO 19115-1:2014, which ensures addition of new quality elements. |
| Backward Compatibility | N/A | 100% compatible — all ISO 19115 quality can map to ISO 19157 |
Recommendation: Implement ISO 19157-1:2023 as primary standard while maintaining ISO 19115/19115-4 backward compatibility through conversion libraries. ISO 19157 provides superior capabilities for IPT frameworks requiring trust assessment through metaquality and persistent measure codes for consistent cross-organization reporting.
2.3.2. W3C PROV Provenance Integration
Both ISO standards require integration with W3C PROV for semantic web provenance tracking. Testing demonstrates full compatibility between ISO 19157/19115 lineage and W3C PROV:
| ISO Concept | W3C PROV Concept | Alignment |
|---|---|---|
| LI_Lineage | prov:Activity graph | Lineage encompasses provenance activities |
| LI_ProcessStep | prov:Activity | Direct 1:1 mapping |
| LI_Source | prov:Entity | Source data = input entities |
| processor (CI_Responsibility) | prov:Agent | Processor = responsible agent |
| processStep.description | prov:Activity label/comment | Process description alignment |
| processStep.rationale | prov:Activity annotation | Purpose/rationale alignment |
Identity Preservation: W3C PROV entities can reference ISO quality reports via prov:hadQualityInformation relationship, maintaining full semantic identity across both frameworks.
2.3.3. NASA UMM Compatibility Analysis
NASA’s Unified Metadata Model (UMM) provides JSON-encoded metadata for Earth observation data. Compatibility testing with ISO 19157 reveals:
Compatibility Score: 5/5 — Excellent interoperability
| UMM Element | ISO 19157 Mapping | Status |
|---|---|---|
| DataQuality | DataQuality | ✓ Direct mapping |
| DataQuality.QualityFlags | ConformanceResult | ✓ Maps to conformance results |
| DataQuality.QualityInformation | DescriptiveResult | ✓ Maps to descriptive results |
| CollectionProgress | Completeness | ✓ Completeness category |
| TemporalExtent | TemporalQuality scope | ✓ Temporal quality scope |
Conversion Strategy: UMM → ISO 19157 conversion achievable through direct field mapping with minimal transformation. UMM’s reliance on ISO 19115 foundation ensures smooth integration with ISO 19157.
2.3.4. TrainingDML-AI Compatibility Analysis
OGC TrainingDML-AI provides metadata for machine learning training datasets. Compatibility with ISO 19157:
Compatibility Score: 4/5 — Good interoperability with limitations
| TrainingDML-AI Element | ISO 19157 Mapping | Status |
|---|---|---|
| trainingDataQuality | DataQuality | ✓ Direct mapping |
| labelQuality | ThematicQuality | ✓ Thematic accuracy |
| datasetCompleteness | Completeness | ✓ Completeness category |
| labelingProcedure | LE_ProcessStep | ✓ Lineage process |
| qualityAssessment | Completeness | ✓ Fitness for ML training |
| ML-specific metrics (precision, recall, F1) | No direct equivalent | ⚠ Requires custom extension |
Limitation: ISO 19157 lacks machine learning-specific quality concepts (e.g., class imbalance, label noise). These require custom measures in the ISO 19157-3 register.
Conversion Strategy: TrainingDML-AI → ISO 19157 conversion successful for general quality elements. ML-specific metrics require mapping to custom measures or DescriptiveResult for non-standardized metrics.
2.3.5. OGC RAINBOW Quality Measures Integration
OGC RAINBOW provides a catalog of data quality measure definitions defined in ISO 19157-3. Integration with ISO 19157:
Approach: Reference ISO 19157 standardized measures from RAINBOW catalog:
ISO 19157-3 Measure Code → RAINBOW Measure
Example: ISO 19157-3 Measure 28 → RAINBOW “Positional Uncertainty”
Ensures consistent definitions across organizations
Implementation: Quality reports reference both:
Listing 1
{
"measureIdentification": {
"code": "28",
"authority": "ISO 19157-3"
},
"externalReference": {
"url": "https://def.isotc211.org/dataqualitymeasures/",
"authority": "OGC RAINBOW"
}
}
2.4. Overview
The STAC Liability and Claims Extension participates in the OGC Testbed-21 Data Quality for Integrity, Provenance, and Trust (DQ4IPT) task as a cross-cutting building block that provides the legal, security, and claims dimension of the broader IPT framework. It is designed to operate alongside and within the two DQ4IPT server deliverables (D101, D102) and the D103 software library.
Building block identifier: ogc.contrib.stac.extensions.liability-claims DQ4IPT alignment version: v1.6.0 Compatibility score: 4.5 / 5
2.5. Role within the DQ4IPT Architecture
Figure 1
The extension is consumed by D102 (OGC API – Records / STAC API) as the carrier of legal and trust metadata embedded in STAC Items and Collections, and by D103 as the read/write interface for combined quality, provenance, and integrity records.
2.7. D101 — OGC API – Processes (ISO 19157 quality output)
D101 produces STAC Items whose properties embed ISO 19157 data quality reports via the liability:quality field. The process execution endpoint that triggers quality-enriched output is:
Listing 2
POST /processes/{processId}/executeResponse items carry:
| Field | Content |
|---|---|
| liability:quality | ISO 19157-1:2023 DQ reports (completeness, positional accuracy, thematic accuracy) |
| liability:prov | W3C PROV-JSON provenance graph of the processing chain |
| liability:security_classification | Asset-level security level (TLP, NATO, national markings) |
2.8. D102 — OGC API – Records / STAC API (liability-claims carrier)
D102 serves STAC records enriched with the full liability: field set. Key endpoints:
Listing 3
GET /collections/{collectionId}/items/{itemId}
GET /collections/{collectionId}/items?liability:claim_status=pending
POST /collections/{collectionId}/items (ingest with claims metadata)STAC Items served by D102 include:
| Field | Content |
|---|---|
| liability:claim_id | Unique claim or incident identifier |
| liability:claim_status | Lifecycle status: pending, accepted, settled, closed |
| liability:claim_type | environmental, property_damage, operational, etc. |
| liability:responsible_party | Named responsible entity |
| liability:legal_jurisdiction | Applicable legal framework / territory |
| liability:damages_estimated | Monetary estimate with ISO 4217 currency |
| liability:prov | W3C PROV-JSON for full chain-of-custody traceability |
| liability:vc | W3C Verifiable Credential (did:web) — TIE-02 conformance |
2.9. D103 — DQ-enabled Software Library (r/w interface)
The D103 library reads and writes liability: fields as part of its combined quality–provenance–integrity payload. It exposes the following programmatic operations:
| Operation | Description |
|---|---|
| read_liability_claims(stac_item) | Parse all liability: fields from a STAC Item into a structured object |
| write_liability_claims(stac_item, claims) | Serialise a claims object back into STAC Item properties |
| validate_liability_claims(stac_item) | Run AJV schema validation against v1.6.0/schema.json (TIE-01) |
| lift_to_rdf(stac_item) | Apply context.jsonld + semantic-uplift.jsonld to produce PROV-O / DQV RDF |
| issue_vc(stac_item, did_key) | Package quality + claims metadata as a W3C VC signed with did:web (TIE-02) |
2.10. Schema Validation (TIE-01)
Conformance class TIE-01 requires that every STAC Item served by D102 is valid against the liability-claims JSON Schema. The D103 library uses AJV (draft-07 strict mode) for validation:
Listing 4
{
"stac_extensions": [
"https://luciocola.github.io/stac-extension-liability-claims/v1.6.0/schema.json"
],
"properties": {
"liability:claim_status": "pending",
"liability:quality": { ... },
"liability:prov": { "entity": {}, "activity": {}, "agent": {} }
}
}
2.11. Verifiable Credentials Integration (TIE-02)
Conformance class TIE-02 requires that quality and claims assertions can be packaged as W3C Verifiable Credentials anchored to a did:web DID Document registered in the D102 Credential Registry. The liability:vc field in a STAC Item holds the signed VC JSON-LD envelope.
2.12. Complementary Extension Co-deployment
When deployed alongside the T21-DQ4IPT data quality extension (dq: prefix), the two extensions are non-conflicting and complementary:
| Concern | Extension | Field prefix |
|---|---|---|
| ISO 19157 technical quality measures | T21-DQ4IPT (dq:) | dq:quality |
| Legal / claims / insurance | Liability-Claims | liability:claim_* |
| W3C PROV provenance | Liability-Claims | liability:prov |
| Security classification | Liability-Claims | liability:security_classification |
| Verifiable Credentials | Liability-Claims | liability:vc |
2.13. References
OGC Testbed-21 DQ4IPT Engineering Report (D001) — Data Quality for Integrity, Provenance and Trust
ISO 19157-1:2023 — Geographic information — Data quality — Part 1: General requirements
ISO 19115-4:2023 — Geographic information — Metadata — Part 4: JSON encoding
W3C PROV-DM — https://www.w3.org/TR/prov-dm/
W3C Verifiable Credentials Data Model 2.0 — https://www.w3.org/TR/vc-data-model-2.0/
2.13.1. Quality Assurance for Earth Observation (QA4EO)
The Quality Assurance Framework for Earth Observation (QA4EO) https://www.qa4eo.org/documents/ provides complementary guidelines that align with ISO 19157-1:2023 implementation. The framework promotes international collaboration to harmonize product quality and provides guidelines for satellite Earth observation product delivery.
The QA4EO framework outlines 7 key principles:
Principle 1 – Data and metadata should satisfy user requirements
Principle 2 – Data and metadata should be quality controlled by following established procedures
Principle 3 – Metadata should be physically and operationally linked to data
Principle 4 – Implementations should be traceable to community accepted standards
Principle 5 – Pre- and post-launch instrument calibration and validation must be independent
Principle 6 – An initial review of validation activities should be documented with all datasets
Principle 7 – Uncertainty characterization should be regularly reviewed and updated
Alignment with ISO 19157: QA4EO principles map directly to ISO 19157 capabilities:
Principle 4 (traceable standards) → ISO 19157 standardized measures
Principle 6 (validation documentation) → Metaquality confidence assessment
Principle 7 (uncertainty characterization) → QuantitativeResult with uncertainty
Implementing ISO 19157-1:2023 with W3C PROV provenance tracking provides the technical foundation for achieving QA4EO compliance while enabling IPT mechanisms through transparent, standardized quality metadata.
2.13.2. STAC Extension Integration for IPT
The STAC Liability and Claims Extension provides a proven implementation pattern for integrating ISO 19157-1:2023 data quality with W3C PROV provenance in modern geospatial data catalogs. This extension demonstrates practical application of the quality standards framework within SpatioTemporal Asset Catalogs (STAC), enabling cloud-native access to quality-assured Earth observation data.
2.13.2.1. Extension Overview
The STAC Liability and Claims Extension v1.1.0 implements:
Primary Standard: ISO 19157-1:2023 with full support for all quality categories
Backward Compatibility: ISO 19115/19115-4 quality reports
Provenance Integration: W3C PROV-JSON for semantic web interoperability
Verifiable Credentials: W3C VC 2.0 for cryptographic verification (v1.2.0)
NASA UMM Compatibility: 5/5 rating through ISO 19115 alignment
TrainingDML-AI Compatibility: 4/5 rating for ML training data quality
2.13.2.2. Key Technical Features
| Capability | Implementation | IPT Benefit |
|---|---|---|
| Quality Reporting | liability:quality field with ISO 19157-1:2023 JSON schema | Standardized, machine-readable quality metadata |
| Provenance Tracking | liability:prov field with W3C PROV-JSON | Semantic web integration, SPARQL query support |
| Metaquality | ISO 19157 confidence, representativity, homogeneity | Trust assessment through quality-of-quality metrics |
| Geospatial Data Interpretability Index (GDII) Assessment | ISO 19157 fitness-for-purpose evaluation | Document dataset suitability for specific applications |
| Standardized Measures | ISO 19157 registered measure codes (e.g., Measure 28) | Consistent quality reporting across organizations |
| Verifiable Claims | W3C Verifiable Credentials 2.0 integration | Cryptographic proof of quality assessments |
| Access Control | Security classification metadata with API-level auth | Secure data sharing with role-based access |
2.13.2.3. Integration with IPT Servers
The STAC extension pattern can be applied to both OGC API implementations required for DQ4IPT.
D101 (OGC API — Processes):
Process outputs include STAC Items with liability:quality containing ISO 19157 reports
Each processing step tracked in liability:prov as PROV activities
Quality measures reference ISO 19157 register and OGC RAINBOW definitions
Verifiable credentials provide cryptographic proof of processing provenance
D102 (OGC API — Records):
Metadata records structured as STAC Collections/Items
liability:quality provides comprehensive quality assessments
liability:prov enables semantic web discovery via SPARQL
Collection-level quality summaries aggregate item-level metrics
2.13.2.4. JSON Schema Validation
The extension provides standalone JSON schemas for quality validation:
json-schema/iso19157-quality.json — ISO 19157-1:2023 (RECOMMENDED)
json-schema/iso19115-quality.json — ISO 19115/19115-4 (backward compatibility)
json-schema/prov.json — W3C PROV-JSON validation
json-schema/verifiable-credential.json — W3C VC 2.0 validation
These schemas enable:
Runtime validation of quality reports
IDE autocomplete for metadata authoring
Conformance testing for IPT implementations
Documentation generation from schemas
2.13.2.5. Example: Satellite Imagery Quality Report
The following demonstrates ISO 19157-1:2023 quality reporting in STAC:
Listing 5
{
"stac_version": "1.0.0",
"stac_extensions": [
"https://stac-extensions.github.io/liability-claims/v1.1.0/schema.json"
],
"type": "Feature",
"id": "sentinel2-quality-demo",
"properties": {
"datetime": "2025-06-15T10:30:00Z",
"liability:quality": {
"scope": {"level": "dataset"},
"report": [
{
"category": "positionalAccuracy",
"subcategory": "absoluteExternalPositionalAccuracy",
"measure": {
"measureIdentification": {
"code": "28",
"codeSpace": "ISO 19157",
"version": "2023"
},
"nameOfMeasure": ["Mean value of positional uncertainties"]
},
"evaluationMethod": {
"evaluationMethodType": "directExternal",
"evaluationMethodDescription": "RMSE with ground control points",
"dateTime": "2025-06-16T14:00:00Z"
},
"result": [{
"resultType": "quantitative",
"value": [12.3],
"valueUnit": "meter",
"errorStatistic": "RMSE"
}]
},
{
"category": "metaquality",
"subcategory": "confidence",
"measure": {
"measureIdentification": {
"code": "129",
"codeSpace": "ISO 19157"
},
"nameOfMeasure": ["Confidence level"]
},
"result": [{
"resultType": "quantitative",
"value": [0.95],
"valueUnit": "probability"
}]
}
]
},
"liability:prov": {
"entity": {
"quality-report": {
"prov:type": "QualityReport",
"prov:wasGeneratedBy": "quality-assessment"
}
},
"activity": {
"quality-assessment": {
"prov:type": "QualityAssessment",
"prov:wasAssociatedWith": "quality-team"
}
}
}
}
}
2.13.2.6. Benefits for DQ4IPT Implementation
Standards Compliance: Demonstrates ISO 19157-1:2023 implementation in production-ready format
Interoperability: Proven compatibility with NASA UMM and TrainingDML-AI
Cloud-Native: STAC’s widespread adoption enables integration with existing infrastructure
Validation Framework: JSON schemas provide immediate conformance testing
Provenance Identity: W3C PROV integration maintains semantic consistency
Trust Mechanisms: Verifiable credentials enable cryptographic verification
The STAC extension serves as a reference implementation for IPT servers, demonstrating how ISO 19157 quality metadata can be integrated with modern geospatial APIs while maintaining full semantic web compatibility through W3C PROV.
2.13.3. TIEs
The Technology Integration Experiment (TIE) matrix documents the verified interfaces between all components of the DQ4IPT task. Each cell records:
The interface standard or protocol used
The message/data format exchanged
The direction of interaction (→ = caller to provider)
The DQ4IPT task comprises three deliverable components that may interact with external quality registers, provenance frameworks, and metadata source systems.
NOTE: The component descriptions below reflect the CFP requirements (OGC Testbed-21 CFP §2.1.5) and the implementation outcomes documented in the DQ4IPT Engineering Report (D001). The primary quality framework is ISO 19157-1:2023, embedded within ISO 19115 / ISO 19115-4 metadata structures. The STAC Liability Claims Extension (v1.3.0 / v1.4.0) is the operative delivery mechanism for embedding quality reports and PROV-JSON provenance into STAC Items. ISO 19115-4 (draft JSON encoding) is the target conversion format for D103 metadata conversions.
| ID | Name | Role |
|---|---|---|
| D101 | DQ-enabled IPT Server 1 | OGC API – Processes implementation: processes satellite imagery; outputs include processed image + JSON-encoded ISO 19115-4 compliant metadata containing ISO 19157 data quality reports referencing OGC RAINBOW measure definitions. W3C PROV-JSON provenance embedded in STAC Items via Liability Claims Extension. |
| D102 | DQ-enabled IPT Server 2 | OGC API – Records / STAC API catalogue: serves ISO 19115-4 and ISO 19157-3 compliant metadata with embedded ISO 19115-4 data quality reports referencing OGC RAINBOW. Implements ISO 19115-5 lineage/provenance for Biomass datasets. Implements GeoDCAT-AP metadata responses refering to OGC Rainbow quality measure definitions. Supports Verifiable Credentials (VC 1.0/2.0) with Decentralized Identifiers (DIDs) for content integrity. Includes a Credential Registry interface and implements W3C DID Extensions. |
| D103 | DQ-enabled Software Library | Client library (dq_ipt_library): accesses quality reports and metadata from D101 and D102; converts ISO 19115-3 XML → ISO 19115-4 JSON, NASA UMM JSON → ISO 19115-4 JSON, TrainingDML-AI JSON → ISO 19115-4 JSON (all with bidirectional fidelity tracking); generates W3C PROV graphs from ISO lineage; executes SPARQL queries on PROV graphs; validates against JSON Schema, SHACL, and PROV-CONSTRAINTS; reads/writes STAC Items with Liability Claims Extension. |
2.14. Primary Interoperability Matrix
NOTE: Symbol key used in cells:
✅ Verified — interaction confirmed by deliverable implementation or documented TIE
🔵 Required — mandated by CFP but implementation detail not fully documented
— No direct interaction required
| D101 +Server 1 | D102 +Server 2 | D103 +Library | |
|---|---|---|---|
| D101 +Server 1 | — | 🔵 D101 fetches STAC Item and Verifiable Credential from D102 | ✅ D103 retrieves ISO 19115-3 XML metadata URL from D101 and returns JSON encoded data quality back to D101 |
| D102 +Server 2 | — | — | ✅ D103 queries D102 catalogue; retrieves ISO 19115-4 JSON metadata with ISO 19157 DQ reports; validates response against ISO-TC211 JSON schemas OGC API – Records / STAC API ISO 19115-4 JSON, validated with ajv (TIE-01) |
| D103 +Library | ✅ D103 retrieves ISO 19115-3 XML metadata URL from D101 | ✅ D103 queries D102 catalogue; retrieves and parses ISO 19115-4 JSON records; validates them against ISO 19115-4 JSON Schema OGC API – Records / STAC API | — |
2.15. Documented Technology Integration Experiments (TIEs)
The following TIEs were executed during the DQ4IPT task:
| TIE ID | Components | Description | Result |
|---|---|---|---|
| TIE-01 | D103 ↔ D102 | Validated ISO 19115-4 JSON responses generated by D102 (NOAA_AVHRR_L1B_LAC.json) against ISO-TC211 GitHub JSON schemas (19115-4.json, mdj.json, dqc.json) using ajv (JSON Schema draft 2020-12). Command: ajv validate -d NOAA_AVHRR_L1B_LAC.json -s "19115-4.json" --spec=draft2020 --validateFormats=true --strict=false -c ajv-formats -r "mdj.json" -r "dqc.json" -r "Feature.json" | ✅ Passed — ISO 19115-4 records validate correctly |
| TIE-02 | D102 ↔ W3C VCs / DIDs | VC 1.0 Universal Verifier test — STAC Items signed as Verifiable Credentials verified using W3C Universal Verifier against did:web and did:indy DID methods. VC 2.0 proof algorithm implemented and verified against verifier.io. | ✅ Passed for VC 1.0; documented issues with VC 2.0 and context conflicts |
| TIE-03 | D103 ↔ D101 | D103 api_clients module retrieved processing results from D101 OGC API – Processes endpoint, parsed ISO 19115 + ISO 19157 DQ report JSON, and validated measure codes against RAINBOW / ISO 19157-3 register. | ✅ Passed — measure codes resolved; PROV-JSON generated from LI_Lineage |
2.16. Interface Specification Detail
2.16.1. INT-01: D101 (OGC API – Processes)
| Property | Value |
|---|---|
| Protocol | HTTPS / HTTP 1.1 |
| Standard | OGC API – Processes 1.0 |
| Endpoint pattern | POST /processes/{processId}/execute |
| Request format | input_url (string), meta_url (string) |
| Response format (JSON) | application/json — STAC Item |
| Response format (metadata) | application/json — STAC Liability Claims Extension compliant JSON-encoded ISO 19115 metadata structure containing embedded ISO 19157-1:2023 data quality report elements and W3C PROV-JSON provenance |
| Key quality JSON fields (Liability Claims) | liability:quality → ISO 19115-4 JSON encoded data quality as received from D103 |
| PROV-JSON fields (Liability Claims) | liability:prov → W3C PROV-JSON graph with prov:Entity (product DID), prov:Activity (satellite process), prov:Agent (operator) |
2.16.2. INT-02: D103 → D102 (OGC API – Records / STAC API Catalogue Query)
| Property | Value |
|---|---|
| Protocol | HTTPS / HTTP 1.1 |
| Standard | OGC API – Records 1.0 / STAC API 1.0 |
| Endpoint patterns | GET /collections/{collectionId}/items GET /search?bbox=...&datetime=... (STAC API) |
| Filter language | CQL2 Text / CQL2 JSON (STAC API Filter extension) Standard STAC bbox, datetime, ids parameters |
| Response format | application/geo+json — GeoJSON FeatureCollection of STAC Items application/json — ISO 19115-4 JSON (linked via STAC assets) Liability Claims Extension fields: liability:quality (ISO 19157 DQ report), liability:prov (PROV-JSON), liability:integrity (cryptographic hash / VC) |
| TIE validation | ISO 19115-4 JSON responses validated by D103 using ajv against ISO-TC211 schemas (TIE-01): 19115-4.json, mdj.json, dqc.json, Feature.json |
2.16.3. INT-03: D102 / D103 → RAINBOW / ISO 19157-3 Measure Lookup
| Property | Value |
|---|---|
| Protocol | HTTPS (read-only dereference) |
| Standard | Linked Data / OGC RAINBOW catalog — ISO 19157-3 Data Quality Measures Register |
| URI patterns | https://defs-dev.opengis.net/vocprez-hosted/object?uri=https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure (RAINBOW) https://def.isotc211.org/dataqualitymeasures/{measureCode} (ISO 19157-3 register) |
| Response format | application/ld+json or text/html |
| Example measures used | Measure 28 — “Mean value of positional uncertainties” Measure 65 — “Number of excess items” (CommissionOmission) Measure 129 — “Rate of missing items” (CompletenessOmission) Measure 136 — “Attribution correctness” (ThematicAccuracy) |
| Usage | All three components resolve measure codes at runtime to populate measure.nameOfMeasure, measure.measureDescription, and measure.sourceCitation in ISO 19157 quality reports |
2.16.4. INT-04: D103 — Metadata Source Conversions (ISO 19115-4 Target)
| Property | Value |
|---|---|
| Sources | NASA CMR UMM-G JSON (umm_to_iso19157.py), OGC TrainingDML-AI catalog JSON (trainingdml_to_iso19157.py), ISO 19115-3 XML repositories (iso19115_to_iso19157.py) |
| Retrieval | HTTP GET to CMR API or local file path |
| Conversion target format | ISO 19115-4 (draft) JSON — integrated JSON encoding of ISO 19115-1 / ISO 19115-2 / ISO 19157-1 schemas (mdj.json, dqc.json) Bidirectional with fidelity tracking (fidelity_tracker.py) |
| W3C PROV output | ISO LI_Lineage → W3C PROV-JSON graph (iso_to_prov.py) LI_ProcessStep → prov:Activity, LI_Source → prov:Entity, CI_Responsibility → prov:Agent |
| Compatibility verified | UMM → ISO 19115-4: 5/5 fields mapped (via ISO 19115 intermediary) TrainingDML-AI → ISO 19115-4: 4/5 fields (AI metrics use DescriptiveResult) ISO 19115-3 XML → ISO 19115-4 JSON: bidirectional, full namespace support |
2.16.5. INT-05: D103 — W3C PROV Graph Generation and SPARQL Queries
| Property | Value |
|---|---|
| Modules | prov_generator.py, prov_validator.py, iso_to_prov.py, sparql_client.py |
| PROV serializations | PROV-JSON (primary), RDF/Turtle (for SPARQL) |
| Validation | PROV-CONSTRAINTS (prov_validator.py); JSON Schema; SHACL |
| SPARQL client | In-process SPARQL queries on generated PROV graphs (no external triple store required for D103; external SPARQL endpoint optional) |
| RDF vocabularies | prov: (W3C PROV-O), dqgeo: (DQ4IPT geospatial extension namespace) |
| Example SPARQL query | PREFIX prov: <http://www.w3.org/ns/prov#> |
2.16.6. INT-06: D102 — Verifiable Credentials / DIDs (Content Integrity)
| Property | Value |
|---|---|
| Standard | W3C Verifiable Credentials Data Model 1.0 / 2.0 W3C Decentralized Identifiers (DIDs) — did:web, did:indy |
| Credential Registry | W3C DID Extensions Credential Registry (https://www.w3.org/TR/did-extensions-properties/#credentialregistry) |
| Signing | VC 1.0: hashlink integrity protection (OGC 17-003r2 JSON syntax) VC 2.0: implemented custom proof algorithm (crv key family, matched verifier.io) |
| Verification | Universal Verifier (VC 1.0 verified ✅) verifier.io cross-check (VC 2.0 verified ✅ with documented constraints) |
| Content of VC claims | Product geometry (corner points), acquisition time, sensor DID, data quality report hash, processing lineage hash |
2.17. Standards Interoperability Summary
| Standard Pair | D101 | D102 | D103 | Compatibility Result |
|---|---|---|---|---|
| ISO 19157-1:2023 ↔ ISO 19115/19115-4 | — | ✅ | ✅ | 100% backward compatible; all ISO 19115 quality elements map to ISO 19157 categories. ISO 19157 identified as primary quality framework; ISO 19115-4 JSON encoding adopted as target delivery format. |
| ISO 19157 ↔ NASA UMM-G | — | ✅ (ingestion) | ✅ (conversion) | 5/5 field alignment via ISO 19115 intermediary. UMM quality fields map to ThematicAccuracy, PositionalAccuracy, CompletenessOmission, metaquality confidence, and Geospatial Data Interpretability Index (GDII) (IOP-01). |
| ISO 19157 ↔ OGC TrainingDML-AI | — | ✅ (ingestion) | ✅ (conversion) | 4/5 field compatibility. Training data completeness and label accuracy (IoU, F1) map via DescriptiveResult; AI-specific metrics have no direct ISO 19157 measure, requiring generic fields (IOP-02). |
| ISO 19157 / ISO 19115 ↔ W3C PROV-O | ✅ (received from D103) | ✅ | ✅ | Full 1:1 mapping: LI_ProcessStep → prov:Activity, LI_Source → prov:Entity, CI_Responsibility → prov:Agent. Implemented in D103 iso_to_prov.py; PROV-JSON embedded in STAC Items via Liability Claims Extension. |
| ISO 19115-3 XML ↔ ISO 19115-4 JSON | n/a (received from D103) | ✅ | ✅ | Bidirectional conversion implemented with full namespace support (D103 iso19115_to_iso19157.py). TIE-01 validated D102-generated ISO 19115-4 JSON against ISO-TC211 official JSON schemas using ajv. |
| STAC Items ↔ Liability Claims Extension (v1.3.0/v1.4.0) | ✅ | ✅ | ✅ | Central delivery mechanism for embedded ISO 19157 quality reports and W3C PROV-JSON provenance in STAC Items. Compliance analysis included in ER Annex B. Version 1.3.0 operationally tested; v1.4.0 aligns with canonical eovoc schemas. |
| ISO 19157 ↔ OGC RAINBOW / ISO 19157-3 Register | n/a (received from D103) | ✅ | ✅ | All measure codes resolve to authoritative definitions at runtime via URI dereference. D103 measures.py module provides registry access API. |
| W3C Verifiable Credentials ↔ STAC / ISO 19115-4 | ✅ (validate) | ✅ | ✅ (read) | D102 signs STAC Items as VC 1.0/2.0; content integrity protected via hashlink. Documented issues with floating-point JSON-LD normalization and VC 2.0 context conflicts (IOP-04, IOP-05). |
2.18. Interoperability Issues and Resolutions
| Issue ID | Description | Resolution | Status |
|---|---|---|---|
| IOP-01 | NASA UMM-G has no native metaquality confidence field | Mapped UMM.DataQualityFlag → ISO 19157 Metaquality.confidence with default confidence = 0.7 when UMM flag is present but unquantified. Implemented in D103 umm_to_iso19157.py. | ✅ Resolved |
| IOP-02 | TrainingDML-AI AI-specific statistical measures (IoU, F1 Score) have no direct equivalent in the ISO 19157 measures register | AI metrics converted via generic DescriptiveResult fields. Gap formally documented; ISO 19157-3 extension measure profile recommended. OGC TrainingDML-AI SWG notified for future alignment. | 🔵 Gap documented; pending ISO 19157-3 extension |
| IOP-03 | DID method fragmentation — did:web and did:indy resolvers returned inconsistent results; Universal Resolvers failed to process publicKeyBase58 and publicKeyJwk interchangeably | D102 implementation constrained to a consistent key family (crv). Cross-method verification identified as a future standardization gap. Reported against DID resolver ecosystem. | 🔵 Partially mitigated; systemic gap remains |
| IOP-04 | Floating-point JSON-LD normalization caused VC proof verification failures — coordinate values (e.g., 65.440002) serialize inconsistently across JSON-LD libraries (DIDKit outputs “6.5440002E1”), invalidating cryptographic proof | Adjusted the VC JSON-LD context to avoid problematic coordinate representations. Issue reported to pyld developers (https://github.com/digitalbazaar/pyld/issues/230). | ✅ Workaround applied; upstream fix pending |
| IOP-05 | ISO 19115-4 mdj.json JSON schema missing LI_Lineage subclasses — LE_Source and LE_ProcessStep objects not defined, preventing validation of provenance information | Workaround: provenance expressed using available ISO schema constructs; recommendation submitted to ISO/TC 211 to add LE_Source and LE_ProcessStep to the official mdj.json schema file. | 🔵 Documented; recommendation to ISO/TC 211 submitted |
| IOP-06 | VC 2.0 context conflict — OGC context (OGC 17-003r2) redefines description and mediaType fields, incompatible with W3C credentials/v2 context | D102 uses VC 1.0 for STAC asset signing; VC 2.0 full integration deferred. Issue reported at https://github.com/w3c/json-ld-syntax/issues/443. | 🔵 Deferred; VC 1.0 operationally adopted |
2.19. TIE Diagram
[[Figure 2]] .System Architecture Overview image::Architecture-Overview.png[]
2.20. References
OGC Testbed-21 Call for Participation (CFP), §2.1.5 DQ4IPT Work Items and Deliverables: https://portal.ogc.org/files/111567
OGC Testbed-21 CFP landing page: https://www.ogc.org/requests/towards-greater-interoperability-ogc-testbed-21-call-for-participation/
ISO 19157-1:2023 — Geographic information — Data quality — Part 1: General framework
ISO 19115-4 (Draft) — Geographic information — Metadata — Part 4: JSON schema implementation of metadata fundamentals. ISO-TC211 schemas: https://github.com/ISO-TC211/GOM
OGC API – Processes 1.0: https://ogcapi.ogc.org/processes/
OGC API – Records 1.0: https://ogcapi.ogc.org/records/
STAC API Specification 1.0.0: https://github.com/radiantearth/stac-api-spec
STAC Extension Liability Claims: referenced in ER Annex B
W3C PROV-O: https://www.w3.org/TR/prov-o/
W3C Verifiable Credentials Data Model 1.0: https://www.w3.org/TR/vc-data-model/
W3C Verifiable Credentials Data Model 2.0: https://www.w3.org/TR/vc-data-model-2.0/
W3C Decentralized Identifiers (DIDs) 1.0: https://www.w3.org/TR/did-core/
W3C DID Extensions Properties (Credential Registry): https://www.w3.org/TR/did-extensions-properties/#credentialregistry
OGC RAINBOW / ISO 19157-3 Quality Measures Register: https://defs-dev.opengis.net/vocprez-hosted/object?uri=https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure
ISO 19157 Quality Measure Register: https://def.isotc211.org/dataqualitymeasures/
NASA CMR UMM-G: https://cmr.earthdata.nasa.gov/
OGC TrainingDML-AI: https://www.ogc.org/standard/trainingdml-ai/
pyld JSON-LD library issue (floating-point normalization): https://github.com/digitalbazaar/pyld/issues/230
Testbed-20 IPT Report (OGC 24-033): https://docs.ogc.org/per/24-033.html
3. Outlook
The development and testing of ISO 19157-1:2023-based IPT frameworks for Earth observation data has revealed significant opportunities for advancement in geospatial data quality management. This section outlines future directions, challenges, and recommendations for continued development.
3.1. Achieved Outcomes
The DQ4IPT thread of Testbed has successfully demonstrated:
Standards Integration: ISO 19157-1:2023 provides a comprehensive framework superior to ISO 19115/19115-4 for IPT applications, particularly through metaquality and Geospatial Data Interpretability Index (GDII) assessment capabilities;
Provenance Interoperability: Full compatibility between ISO 19157 DataQuality.lineage and W3C PROV enables both geospatial (ISO) and semantic web (PROV) communities to leverage the same provenance information;
Metadata Conversion: High-fidelity conversion between ISO 19157-3, NASA UMM (5/5 compatibility), and TrainingDML-AI (4/5 compatibility) demonstrates practical interoperability;
Cloud-Native Implementation: STAC Liability and Claims Extension provides production-ready pattern for integrating quality metadata in cloud-optimized catalogs; and
Trust Mechanisms: Metaquality (confidence, representativity, homogeneity) enables quantitative trust assessment of quality reports themselves.
3.2. Future Work
NOTE: Priority Future Work — The following three areas are identified as the highest-priority directions for the DQ4IPT task beyond the current testbed cycle.
Blockchain-Based Provenance Anchoring — tamper-evident, immutable anchoring of W3C PROV graphs and ISO 19157 quality records on a distributed ledger.
OGC DQ4IPT Building Block — operationalization of the submitted OGC Building Block to expose DQ4IPT capabilities as a composable, cross-API service.
QGIS and Platform Client Support — native integration of DQ4IPT functionality into QGIS and other geospatial platforms so that field operators and analysts can consume quality-annotated, provenance-tracked IPT outputs directly.
3.2.1. Semantic uplift in future testbeds
Testbed-21 explains how semantic uplift (JSON-LD context annotation, optional transforms, and RDF-oriented validation) relates to IPT, STAC quality metadata, and OGC RAINBOW, but it does not run a dedicated interoperability or performance campaign for uplift itself. End-to-end semantic uplift should be exercised further—across implementations, APIs, and catalogue workflows—in future OGC testbeds, alongside continued IPT and data-quality work. See Annex C.
3.2.2. OWS Context as a Semantic Knowledge Graph (RDF/Turtle)
Traditional OGC Web Services Context (OWS Context) documents — delivered as static XML (OGC 12-084r2) or GeoJSON (OGC 14-055r2) snapshots — describe a set of geospatial resources and their rendering context at a point in time. A high-priority future direction is to transition OWS Context into a living, queryable semantic Knowledge Graph serialized in RDF/Turtle, replacing static documents with a graph structure that supports inference, dynamic integration of AI-generated insights, and strict machine-readable provenance.
Motivation: Static OWS Context documents cannot reason about their own contents. Once serialized, they cannot be updated to reflect changes in service availability, data quality, or processing lineage without regenerating the entire document. In contrast, an RDF Knowledge Graph encoding the same context is:
Queryable via SPARQL — clients can ask “which layers in this operating picture have positional accuracy CE90 < 10 m?” without parsing a flat list;
Inferable via OWL reasoning — ontological rules can deduce new relationships (e.g., that a layer derived from a restricted source inherits its access control constraints);
Composable — multiple OWS Context graphs from different organizations can be merged via owl:sameAs alignments and federation queries; and
Provenance-aware — each resource entry carries W3C PROV triples (prov:wasGeneratedBy, prov:wasDerivedFrom) traceable to ISO 19157 quality reports and DQ4IPT processing chains.
Implementation Path:
Ontology Design: Define an owsc: ontology namespace (extending OGC OWS Context Core semantics) that maps OWS Context concepts — ows:Context, ows:Resource, ows:Offering, ows:Operation — to RDF classes and properties. Align with prov:Entity, dcat:Dataset, and iso19157:DataQuality where applicable.
RDF/Turtle Serialization: Represent each OWS Context resource as an RDF named individual with typed literals for service endpoints, CRS, bounding box (using GeoSPARQL geo:hasGeometry), and styling rules. Example fragment:
Listing 7
@prefix owsc: <http://www.opengis.net/owc/1.0/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix dq: <http://def.isotc211.org/iso19157/-1/2023/DataQuality#> .
@prefix geo: <http://www.opengis.net/ont/geosparql#> .
<urn:owsc:context:dq4ipt-cop-001>
a owsc:Context ;
owsc:title "DQ4IPT Common Operating Picture — OWS Context KG" ;
owsc:author "DQ4IPT Processing Chain" ;
prov:generatedAtTime "2026-03-11T00:00:00Z"^^xsd:dateTime ;
owsc:resource <urn:owsc:resource:s2-classified-layer> .
<urn:owsc:resource:s2-classified-layer>
a owsc:Resource ;
owsc:title "Sentinel-2 Classified Imagery — DQ4IPT Validated" ;
owsc:offering <urn:owsc:offering:wms-s2> ;
prov:wasDerivedFrom <urn:stac:item:s2-l2a-20260311> ;
dq:hasDataQualityReport <urn:dq:report:positional-ce90-s2> .
<urn:dq:report:positional-ce90-s2>
a dq:PositionalAccuracy ;
dq:measureCode "28" ;
dq:resultValue "8.3"^^xsd:decimal ;
dq:resultUnit <https://qudt.org/vocab/unit/M> .AI-Generated Insight Integration: Connect AI inference results (land cover change detection, anomaly alerts) as new RDF nodes derived via prov:wasGeneratedBy from the AI activity node. The Knowledge Graph can absorb these dynamically without schema changes, making the OWS Context self-updating as new analytical products are registered.
DQ4IPT Building Block Bridge: Wire the OGC DQ4IPT Building Block API output (quality + provenance STAC Items) as the authoritative source for the dq:hasDataQualityReport and prov: triples populating the Knowledge Graph, ensuring every layer’s quality status in the context document is traceable to a validated DQ4IPT result.
SPARQL Endpoint Exposure: Serve the Knowledge Graph via a standards-compliant SPARQL 1.1 endpoint and an interface that is compatible with the OGC API — Features standard and supports GeoSPARQL, enabling both semantic and spatial queries over the same graph.
Benefits:
OWS Context becomes a “living document” that reflects real-time service status, current quality assessments, and updated provenance without manual regeneration;
Supports federated Common Operating Picture (COP) scenarios: multiple organizations contribute sub-graphs that are merged at query time via a SPARQL federation layer;
Enables ontology-driven access control: classification and releasability constraints (from the COP STAC Extension) modeled as RDF properties enforced by the SPARQL endpoint; and
Provides a natural integration surface for future ISO 19157-3 semantic measure register alignment and W3C PROV-O geospatial profiles.
3.2.3. Enhanced Machine Learning Integration
TrainingDML-AI compatibility at 4/5 rating reveals opportunities for improvement:
Challenge: ISO 19157 lacks native support for ML-specific quality concepts (class imbalance, label noise, dataset bias)
Solution Path:
Extend ISO 19157 register with ML-specific quality measures;
Develop standardized mappings from ML metrics (precision, recall, F1) to ISO 19157 data quality measures; and
Create specialized Geospatial Data Interpretability Index (GDII) assessment framework for ML training data fitness.
Impact: Enable consistent quality reporting for AI/ML training datasets used in Earth observation applications
3.2.4. Verifiable Credentials Integration
W3C Verifiable Credentials 2.0 support (introduced in STAC extension v1.2.0) enables cryptographic verification:
Current State: Proof-of-concept implementations exist for signing quality reports
Future Work:
Develop standardized credential schemas for ISO 19157 quality elements;
Implement selective disclosure protocols for sensitive quality information;
Create credential revocation registries for outdated quality assessments; and
Establish trust frameworks for credential issuers in Earth observation community.
Impact: Enable legally binding, cryptographically verifiable quality statements with non-repudiation
3.2.5. Automated Quality Measure Computation
Challenge: Manual quality assessment is time-consuming and inconsistent
Solution Path:
Develop automated computation libraries for ISO 19157 registered measures;
Integrate with cloud processing platforms (AWS, GCP, Azure) for at-scale quality assessment;
Create reference implementations for common EO data types (SAR, optical, LiDAR); and
Standardize quality assessment pipelines for processing chains (e.g., L1→L2→L3).
Impact: Reduce quality assessment cost while improving consistency and coverage
3.2.6. Real-Time Quality Monitoring
Opportunity: Extend IPT frameworks to near-real-time data streams
Technical Requirements:
Streaming quality assessment for satellite data downlinks;
Incremental provenance graph updates;
Quality alerts based on ISO 19157 quality evaluation result; and
Dashboard visualization of quality metrics over time.
Use Cases:
Emergency response requiring rapid data quality verification;
Continuous monitoring of satellite sensor performance; and
Automated anomaly detection in processing pipelines.
3.2.7. Blockchain-Based Provenance Anchoring ⭐ Priority
Concept: Anchor W3C PROV graphs and ISO 19157 quality records to a distributed ledger to provide tamper-evident, long-term provenance integrity for satellite imagery processing chains. This directly extends the Liability Claims STAC Extension with cryptographic immutability guarantees, making quality attestations legally defensible and verifiable by any third party without trusting the originating server.
Implementation:
Compute a deterministic hash of the serialized PROV-JSON graph (including all prov:Entity, prov:Activity, and prov:Agent nodes) and record it on-chain as a transaction receipt;
Embed the on-chain transaction reference (block hash, transaction ID, timestamp) into the STAC Item via the liability:integrity field of the Liability Claims Extension;
Enable third-party verification of provenance integrity by resolving the on-chain receipt and comparing against the STAC Item’s embedded hash;
Create an immutable audit trail for ISO 19157 quality assessments, supporting re-inspection after data product updates or reprocessing events; and
Evaluate permissioned distributed ledgers (e.g., Hyperledger Fabric, IOTA) alongside public chains for compliance with government data sovereignty requirements.
Benefits:
Enhanced trust for liability-sensitive applications (defense, emergency response, environmental regulation) — Compliance with regulatory requirements (EU AI Act, EU NIS2 Directive, Defense procurement audit trails) — Long-term preservation of quality metadata independent of the originating service’s availability — Non-repudiation: processing agents cannot disown quality attestations once anchored;
Compliance with regulatory requirements (EU AI Act, NIS2, Defence procurement audit trails);
Long-term preservation of quality metadata independent of the originating service’s availability; and
Non-repudiation: processing agents cannot disown quality attestations once anchored.
3.2.8. OGC DQ4IPT Building Block and OGC API Implementation ⭐ Priority
Concept: Operationalize the DQ4IPT outcomes as a reusable OGC Building Block — as per the Building Block submitted during this testbed — to expose DQ4IPT capabilities as a composable, cross-API service accessible to any OGC API-conformant system.
Implementation:
Package the DQ4IPT quality assessment and provenance pipeline as a formally described OGC Building Block with a machine-readable API definition, executable schema, and conformance class;
Enable satellite sensor outputs, vector datasets, and Common Operating Picture (COP) layers to be submitted to the building block for DQ4IPT compliance validation, returning a structured response (JSON, RDF/Turtle, or STAC Item) with verified conformance status;
Expose the building block as an OGC API – Processes endpoint (POST /processes/dq4ipt-validate/jobs) accepting input data references and returning quality + provenance annotations conformant with the Liability Claims STAC Extension;
Require that validated outputs be referenced in an immutable catalogue (STAC, OGC API – Records) to preserve the chain of quality evidence; and
Publish the Building Block to the OGC Building Blocks Register to enable discovery and reuse across testbed participants and production deployments.
Benefits:
Simplifies DQ4IPT adoption across organizations by providing a single, well-documented integration surface rather than requiring per-system integration of multiple standards;
Creates a transversal quality service applicable to all OGC API families (Processes, Records, Features, Maps);
Enables automated DQ4IPT validity checks for any incoming digital information before storage or dissemination; and
Supports federated quality governance: organizations can run their own building block instances while cross-validating against a shared OGC registry.
3.2.9. QGIS and Platform Client Support for IPT Functionality ⭐ Priority
Concept: Develop native client-side support for DQ4IPT functionality within QGIS and other mainstream geospatial platforms (ArcGIS Pro, OpenLayers, GDAL/OGR toolchain), enabling field operators, analysts, and data managers to consume quality-annotated, provenance-tracked IPT outputs without requiring specialist technical knowledge of the underlying standards.
Implementation:
Develop a QGIS plugin that connects to DQ4IPT-compliant services (OGC API – Records / Processes, STAC API with Liability Claims Extension) and renders quality and provenance metadata directly in the layer properties panel and map canvas;
Expose ISO 19157 quality report elements (completeness, positional accuracy, thematic accuracy) as queryable layer attributes, filterable in QGIS expressions and symbology rules;
Visualize W3C PROV graphs as an interactive lineage diagram within QGIS, navigable per feature or per raster tile;
Provide a one-click “Verify Provenance” action that resolves the blockchain anchor (where present) and displays the tamper-evidence status alongside the layer metadata;
Implement equivalent read/display support in web clients (OpenLayers / Leaflet plugin) and the GDAL metadata domain for command-line and scripting workflows; and
Integrate with the OGC DQ4IPT Building Block API so that QGIS can submit layers for remote DQ4IPT validation and receive annotated STAC Items in return.
Benefits:
Lowers the barrier to adoption by making quality and provenance information accessible within the tools already used by end-users (emergency responders, defense analysts, environmental agencies);
Enables spatially-aware quality filtering: users can select only features or tiles meeting a defined quality threshold before analysis or dissemination;
Bridges the gap between backend standards compliance (ISO 19157, W3C PROV, Liability Claims Extension) and frontline operational decision-making; and
Supports the Common Operating Picture (COP) use case by surfacing classification, releasability, and provenance trust indicators directly in the map view.
3.3. Standardization Activities
3.3.1. OGC Standards Development
Recommendations for OGC
Formalize STAC Quality Extension: Submit Liability and Claims Extension to OGC for standardization as community standard;
Develop OGC API — Quality: Create dedicated API for querying and managing ISO 19157 quality metadata;
Enhance RAINBOW Catalog: Expand OGC RAINBOW quality measure catalog with:
ML/AI quality measures;
Real-time/streaming data quality measures;
Crowdsourced data quality measures; and
Create Best Practices Guide: Document recommended ISO 19157 implementation patterns for EO data.
3.3.2. ISO Standards Evolution
Recommendations for ISO/TC 211
ISO 19157: Develop domain-specific extensions for:
Machine learning training data;
Real-time/streaming data;
Crowdsourced data or Volunteered Geographic Information (VGI);
Synthetic/simulated data;
Automated Quality Assessment: Develop standard procedures for automated measure computation; and
Metaquality Framework: Expand metaquality concepts with operational guidelines.
3.3.3. W3C Coordination
Recommendations for W3C Integration
PROV-GEO: Create geospatial profile of PROV specifically for EO data processing;
PROV-Quality: Develop formal ontology linking PROV provenance to ISO 19157 quality; and
Credential Schemas: Standardize Verifiable Credential templates for quality assertions.
3.4. Community Adoption Challenges
3.4.1. Training and Education
Challenge: ISO 19157-1:2023 complexity creates adoption barrier
Mitigation Strategies: - Develop comprehensive training materials and workshops; - Create simplified “starter” profiles for common use cases; - Provide reference implementations and code examples; and - Establish certification programs for quality assessment practitioners.
3.4.2. Tool Ecosystem Development
Current Gap: Limited commercial tool support for ISO 19157-1:2023
Required Developments: - Desktop GIS integration (QGIS, ArcGIS Pro); - Web-based quality authoring tools; - Validation services (SaaS offerings); and - Migration tools for legacy ISO 19115 metadata.
3.4.3. Performance Optimization
Challenge: Comprehensive quality metadata increases payload sizes
Solutions: - Develop compression strategies for quality reports; - Implement lazy loading for quality metadata in APIs; - Create summary/aggregation patterns for collection-level quality; and - Optimize JSON-LD contexts for compact representation.
3.5. Research Directions
3.5.1. Quality Propagation Modeling
Research Question: How does quality propagate through processing chains?
Approach: - Develop mathematical models for quality uncertainty propagation; - Implement error propagation frameworks for multi-stage processing; and - Create simulation tools for quality prediction.
Application: Enable users to predict output quality before processing
3.5.2. User-Driven Quality Assessment
Research Question: How to integrate domain expert knowledge into quality frameworks?
Approach: - Develop crowd-sourced quality validation platforms; - Create reputation systems for quality assessors; and - Design user interfaces for Geospatial Data Interpretability Index (GDII) assessment capture.
Application: Supplement automated quality measures with expert judgment
3.5.3. AI-Assisted Quality Evaluation
Research Question: Can machine learning improve quality assessment efficiency?
Approach: - Training ML models to predict quality metrics from data characteristics; - Develop anomaly detection for quality outliers; and - Create recommender systems for fitness-for-purpose evaluation.
Application: Reduce manual quality assessment workload
3.6. Implementation Recommendations
For organizations implementing ISO 19157-based IPT frameworks:
Start with Core Categories: Begin with positional accuracy, completeness, and logical consistency before expanding to metaquality and Geospatial Data Interpretability Index (GDII);
Leverage Existing Standards: Build on ISO 19115 lineage and NASA UMM compatibility for smooth migration;
Adopt STAC Extensions: Use proven STAC Liability and Claims Extension pattern for cloud-native implementations;
Validate Early and Often: Implement JSON Schema validation in development pipelines;
Document Measures: Reference ISO 19157 register and OGC RAINBOW definitions for all measures;
Maintain Provenance: Generate W3C PROV graphs alongside ISO lineage for maximum interoperability; and
Plan for Evolution: Design systems to accommodate future enhancements (Verifiable Credentials, blockchain anchoring).
3.7. Conclusion
The harmonization of ISO 19115/19115 and ISO 19157 for Earth observation data quality represents a significant advancement in capabilities, particularly for IPT applications requiring trust assessment and fitness-for-purpose evaluation. The demonstrated interoperability with NASA UMM, TrainingDML-AI, and W3C PROV, combined with the practical implementation pattern provided by the STAC Liability and Claims Extension, creates a solid foundation for widespread adoption.
Key success factors for continued development include:
Standardization coordination across OGC, ISO, and W3C;
Tool ecosystem development to lower adoption barriers;
Community training to build expertise in ISO 19157 implementation; and
Research investment in quality propagation, ML integration, and automated assessment.
Organizations implementing IPT frameworks should adopt ISO 19157-1:2023 as their primary quality standard while maintaining backward compatibility with ISO 19115/19115-4 through the proven conversion patterns demonstrated in this testbed. The combination of standardized quality measures, metaquality assessment, and W3C PROV provenance provides the technical foundation for establishing trust in Earth observation data products.
4. Security, Privacy and Ethical Considerations
Integrity, Provenance, and Trust (IPT) can be implemented in different ways. During previous OGC Testbeds, options under the Data Centric Security (DCS) were introduced. During this OGC Testbed the options to implement IPT as a separate ecosystem were introduced. Which is the best fitting approach depends on the use cases. Because DCS ties the security requirements with the data itself, the use cases must be clearly defined before a security scheme is designed and added to the data. Considering the High Efficiency Imagery Format (HEIF) as an example, one potential implementation of DCS for HEIF files is the C2PA Content Credentials Specification. When implementing IPT based on a separate ecosystem, the support for different use cases is more agile as demonstrated by the Testbed-21 IPT ecosystems (FACTS) that supports the IPT-Server 1.
Security in the context of IPT must not only consider the typical requirements like data integrity, confidentiality, and accessibility but also authenticity of processing actors (users or processes) that process data. With DCS, the implementation of these security requirements can easily be implemented for any newly generated data. But it is extremely difficult if not impossible to apply DCS to existing data. All existing data would have to exist in at least two different formats: the old unprotected format and the new DCS format. One could easily imagine that perhaps more than one DCS format will evolve over time. Therefore, the implementation of DCS for EO and other data that is used in international collaboration is not recommended.
The approach in the OGC Testbed-21 is based on establishing an IPT supporting ecosystem that allows for the keeping of data as is! The FACTS ecosystem that supports the IPT-Server 1 component introduces an immutable SpatioTemporal Asset Catalog (iSTAC) that stores metadata records for data assets on a blockchain. This ensures tamper resistance for the metadata records themselves. The metadata record (a STAC feature) is linked to the actual data asset via the data’s hash. This allows to link data assets with trusted metadata records stored on an immutable catalog.
With this approach, any data asset can be associated to a metadata record for verifying genuineness. It does not matter where the data is stored, i.e. in the cloud, on the edge, on local drives, on USB stick, etc. as long as it is possible to calculate the data hash. With the data hash, a genuine check can be performed via the iSTAC API or via the Smart Contract on the blockchain itself. A genuine check verifies the data integrity and authenticity to establish trust into the data asset.
Figure 2 — Testbed-21 Secure Dimensions Immutable Catalog Components
Privacy in the context of IPT is concerned with the user and not with the data. In other words, privacy is about the user’s information required to implement IPT. In simplified terms, the EU GDPR describes the conditions for the collection, storage and processing of user personal and personal identifiable information. For example, an email address must be considered user personal information and a geo location from GPS must be considered personal identifiable information. Regarding the implementation of IPT, it is important that collected user data by organization “A” cannot simply be pushed to other organizations unless the user has authorized that personal information forwarding. The rule of thumb to be considered when implementing IPT is that the user must be the acting entity that has full sovereignty over their personal data. For OGC Testbed-21 the FACTS ecosystem introduces the use of SSI (Self Sovereign Identifiers) combined with blockchain based certificates that guarantee that users stay on top of their personal data and can decide for which transaction a particular personal attribute shall be used. In a system of trusted processes, the use of certificates stored in user wallets paired with ZKP (Zero Knowledge Proof) ensures GDPR compliance.
Ethics in the context of IPT address the freedom of an acting user to be able to decline that personal information is being collected or processed without an harm. In other words, it is not ethical to push (force) the user into actions that they do not want. So, for example, the automated collection and processing of personal data without the user’s approval must be considered non ethical. Therefore, when designing IPT the ethical considerations should be incorporated into the design. The Testbed-21 FACTS ecosystem can be considered ethical as it introduces SSI (Self Sovereign Identifiers) for users and ZKP (Zero Knowledge Proof) which allows the user to withhold non required personal information in a proof process. Furthermore, ZKP allows the user to proof being in possession of a particular personal attribute without releasing the attribute value.
5. DQ enabled IPT Server 1: OGC API — Processes Implementation
This component implements an OGC API — Processes server that provides satellite imagery processing with comprehensive ISO 19115-4 JSON encoded data quality reporting and W3C PROV provenance tracking. The server demonstrates integration of quality metadata into Integrity, Provenance, and Trust frameworks through standardized API outputs.
5.1. Architecture Overview
The DQ-enabled IPT Server 1 implements the following architecture:
| Component | Description |
|---|---|
| OGC API — Processes | RESTful API following OGC API — Processes 1.0 specification |
| Processing Engine | Satellite imagery processing pipeline |
| Quality Assessment Module | ISO 19115-4 quality metadata |
| Provenance Tracker | W3C PROV-JSON provenance graph generation for all processing steps |
| Metadata Generator | STAC-compliant metadata with liability:quality and liability:prov fields |
| Quality Data Integration | Quality measures from DQ4IPT Enabled Software Library |
| Output | STAC-compliant metadata uploaded to immutable STAC and processed imagery uploaded to IPFS |
5.2. Aims
The aims of the DQ-enabled IPT Server 1 were to:
Demonstrate ISO 19115-4 Integration: Provide prototype implementation of comprehensive data quality reporting;
Enable Provenance Tracking: Generate W3C PROV graphs documenting complete processing lineage;
Standardize Quality Measures: Reference ISO 19157 registered measures as received from DQ4IPT Enabled Software Library; and
Support Immutable STAC: Upload STAC Items with quality metadata to Immutable Catalog via REST API.
5.3. Objectives
5.3.1. Primary Objectives
The primary objectives of the server were to:
Implement OGC API — Processes: Deploy conformant API offering satellite imagery processing;
Quality Reports: Import ISO 19115-4 JSON encoded quality assessments for all outputs from DQ4IPT Enabled Software Library;
Track Provenance: Document processing workflows using W3C PROV;
Deliver STAC Outputs: Format results as STAC Items with embedded quality metadata; and
Store Processed Results: Use IPFS to upload processed imagery and store content identifier (CID) in STAC metadata.
5.3.2. Technical Implementation
5.3.2.1. Process Definition
The server implements a satellite imagery processing workflow:
Process ID: gs:trusted-watermarking
Inputs:
image_url: Satellite imagery thumbnail
meta_url: STAC Item metadata for image_url
Outputs:
STAC Item with quality and provenance metadata
Indirect Outputs:
Processed image uploaded to IPFS
STAC Item uploaded to Immutable STAC (FACTS blockchain)
5.3.2.2. Quality Assessment Implementation
The quality assessment module uses the ISO 19115-3 XML URL from the STAC Item referenced by the meta_url to call the DQ4IPT Enabled Software Library. The dataQualityInfo element from the response is integrated into the STAC Item.
5.3.2.3. Provenance Graph Structure
The W3C PROV provenance graph documents:
Entities:
Source imagery (input imagery);
Source metadata (input metadata);
Intermediate product VC for input image;
Intermediate product watermarked image;
Intermediate product STAC Item based on liability and claims STAC extension;
Activities:
Watermarking;
Integrating quality assessment;
Integrating provenance assessment;
Agents:
Processing software (GeoServer 3.0.0 SNAPSHOT — Trusted Watermarking Process); and
Responsible organization.
Listing 8 — Example PROV structure
{
"liability:prov": {
"prefix": {
"prov": "http://www.w3.org/ns/prov#",
"ex": "http://ogc.org/testbed-21/dq4ipt#"
},
"entity": {
"ex:source-imagery": {
"prov:type": "prov:Entity",
"prov:label": "Input Imagery (Sentinel-2 L1C)",
"ex:role": "InputImagery"
},
"ex:source-metadata": {
"prov:type": "prov:Entity",
"prov:label": "Input Metadata (ISO 19115 / ISO 19157)",
"ex:role": "InputMetadata"
},
"ex:vc-input-image": {
"prov:type": "prov:Entity",
"prov:label": "Verifiable Credential for Input Image",
"ex:role": "IntermediateProductVC",
"prov:wasDerivedFrom": "ex:source-imagery",
"prov:wasGeneratedBy": "ex:watermarking"
},
"ex:watermarked-image": {
"prov:type": "prov:Entity",
"prov:label": "Watermarked Image (Trusted Watermark Applied)",
"ex:role": "IntermediateProductWatermarkedImage",
"prov:wasDerivedFrom": "ex:source-imagery",
"prov:wasGeneratedBy": "ex:watermarking"
},
"ex:stac-item-liability": {
"prov:type": "prov:Entity",
"prov:label": "STAC Item (Liability Claims Extension)",
"ex:role": "IntermediateProductSTACItem",
"prov:wasDerivedFrom": ["ex:watermarked-image", "ex:source-metadata"],
"prov:wasGeneratedBy": "ex:integrating-provenance-assessment"
}
},
"activity": {
"ex:watermarking": {
"prov:type": "ex:Watermarking",
"prov:label": "Trusted Watermarking Process",
"prov:used": ["ex:source-imagery", "ex:source-metadata"],
"prov:startTime": "2025-06-15T10:00:00Z",
"prov:endTime": "2025-06-15T10:05:00Z",
"prov:wasAssociatedWith": "ex:geoserver-software"
},
"ex:integrating-quality-assessment": {
"prov:type": "ex:QualityAssessmentIntegration",
"prov:label": "Integrating Quality Assessment (ISO 19157 DQ Report)",
"prov:used": ["ex:watermarked-image", "ex:source-metadata"],
"prov:wasInformedBy": "ex:watermarking",
"prov:wasAssociatedWith": ["ex:geoserver-software", "ex:responsible-organization"]
},
"ex:integrating-provenance-assessment": {
"prov:type": "ex:ProvenanceAssessmentIntegration",
"prov:label": "Integrating Provenance Assessment (W3C PROV-JSON into STAC Item)",
"prov:used": ["ex:watermarked-image", "ex:vc-input-image", "ex:source-metadata"],
"prov:wasInformedBy": "ex:integrating-quality-assessment",
"prov:wasAssociatedWith": ["ex:geoserver-software", "ex:responsible-organization"]
}
},
"agent": {
"ex:geoserver-software": {
"prov:type": "prov:SoftwareAgent",
"prov:label": "GeoServer 3.0.0-SNAPSHOT — Trusted Watermarking Process"
},
"ex:responsible-organization": {
"prov:type": "prov:Organization",
"prov:label": "Responsible Organization",
"prov:actedOnBehalfOf": "ex:geoserver-software"
}
}
}
}
5.3.2.4. STAC Output
All processing outputs are delivered as STAC Items with embedded quality and provenance metadata:
Listing 9 — STAC Item Example
{
"stac_version": "1.0.0",
"assets": {
"PRODUCT": {
"file:checksum": "1e2095c5b784a1ed6d616a009b43e088a7a3f73649a530bafb8ebc76b1956ff84695",
"alternate": {
"FACTS_Browser_Cookie": {
"description": "In order to download the asset via a Web Browser, you first need to establish a connection with your wallet via https://assets.ogc.secd.eu/link so that the Asset Controller can request proof for FACTS Certificates via that secure and private connection when you try to fetch the Asset. Once you have a connection established, you can use the Download link above to fetch the GeoPackage.",
"href": "https://assets.ogc.secd.eu/files/6b5614108583449cf0e1ea3fb2c405139cf31be2fd2033f5bf79818ea42f83f1",
"title": "Download Asset via Web Browser session cookie",
"type": "image/jpeg"
},
"FACTS_API_Key": {
"auth": {
"refs": [
"apiKey"
],
"roles": [
"download"
],
"schemes": {
"flows": {
"authorizationCode": {
"authorizationApi": "https://wallet.ogc.secd.eu/user/x-facts-key",
"method": "get",
"responseField": "x-facts-key",
"parameters": {
"expires_in": {
"schema": {
"examples": "300",
"type": "string"
},
"in": "query",
"description": "the validity of the token in seconds",
"required": "true"
}
}
}
},
"in": "header",
"name": "X-FACTS-Key",
"description": "X-FACTS-Key represents the connection between your Wallet and the Asset Controller to request proof of required FACTS Certificates.",
"type": "apiKey",
"required": "true"
}
},
"description": "In order to download the asset via the API, you first need to fetch an API-Key token (X-FACTS-Key) via https://wallet.ogc.secd.eu/connections/select which must be submitted as HTTP Header `X-FACTS-Key` with the asset URL from `Copy URL`. ",
"href": "https://assets.ogc.secd.eu/files/6b5614108583449cf0e1ea3fb2c405139cf31be2fd2033f5bf79818ea42f83f1",
"title": "Download Asset via X-FACTS-Key",
"type": "image/jpeg"
}
},
"href": "https://ipfs.ogc.secd.eu/files/6b5614108583449cf0e1ea3fb2c405139cf31be2fd2033f5bf79818ea42f83f1",
"title": "Product",
"type": "image/jpeg"
}
},
"bbox": [
95.91153308,
25.92713265,
96.09259599,
26.08689352
],
"geometry": {
"coordinates": [
[
[
95.91153308,
26.08689352
],
[
95.91153308,
25.92713265
],
[
96.09259599,
25.92713265
],
[
96.09259599,
26.08689352
],
[
95.91153308,
26.08689352
]
]
],
"type": "Polygon"
},
"links": [
{
"rel": "derived_from",
"href": "https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application%2Fgeo%2Bjson%3Bprofile%3Dhttps%3A%2F%2Fstacspec.org",
"type": "application/geo+json",
"title": "Source metadata"
},
{
"rel": "self",
"href": "https://ic.ogc.secd.eu/stac/collections/test_dq4ipt/items/asset_1773241644929",
"type": "application/geo+json",
"title": "asset_1773241644929"
},
{
"rel": "collection",
"href": "https://ic.ogc.secd.eu/stac/collections/test_dq4ipt",
"type": "application/json",
"title": "test_dq4ipt"
}
],
"collection": "test_dq4ipt",
"id": "asset_1773241644929",
"type": "Feature",
"stac_extensions": [
"https://stac-extensions.github.io/file/v2.1.0/schema.json",
"https://stac-extensions.github.io/alternate-assets/v1.1.0/schema.json",
"https://stac-extensions.github.io/processing/v1.2.0/schema.json",
"https://luciocola.github.io/stac-extension-liability-claims/json-schema/schema.json"
],
"properties": {
"output": {
"image_height": 92,
"file:checksum": "1e2095c5b784a1ed6d616a009b43e088a7a3f73649a530bafb8ebc76b1956ff84695",
"metadata_url": "https://ic.ogc.secd.eu/stac/collections/test_dq4ipt/items/asset_1773241644929",
"image_url": "https://assets.ogc.secd.eu/files/6b5614108583449cf0e1ea3fb2c405139cf31be2fd2033f5bf79818ea42f83f1",
"image_width": 100,
"image_type": "image/jpeg"
},
"liability:prov": {
"agent": {
"ex:responsible-organization": {
"prov:type": "prov:Organization",
"prov:label": "Responsible Organization",
"prov:actedOnBehalfOf": "ex:geoserver-software"
},
"ex:geoserver-software": {
"prov:type": "prov:SoftwareAgent",
"prov:label": "GeoServer 3.0.0-SNAPSHOT u2014 Trusted Watermarking Process"
}
},
"activity": {
"ex:watermarking": {
"prov:used": [
"ex:source-imagery",
"ex:source-metadata"
],
"prov:startTime": "2026-03-11T15:07:24Z",
"prov:wasAssociatedWith": "ex:geoserver-software",
"prov:type": "ex:Watermarking",
"prov:label": "Trusted Watermarking Process",
"prov:endTime": "2026-03-11T15:07:24Z"
},
"ex:integrating-provenance-assessment": {
"prov:used": [
"ex:watermarked-image",
"ex:vc-input-image",
"ex:source-metadata"
],
"prov:wasAssociatedWith": [
"ex:geoserver-software",
"ex:responsible-organization"
],
"prov:type": "ex:ProvenanceAssessmentIntegration",
"prov:label": "Integrating Provenance Assessment (W3C PROV-JSON into STAC Item)",
"prov:wasInformedBy": "ex:integrating-quality-assessment"
},
"ex:integrating-quality-assessment": {
"prov:used": [
"ex:watermarked-image",
"ex:source-metadata"
],
"prov:wasAssociatedWith": [
"ex:geoserver-software",
"ex:responsible-organization"
],
"prov:type": "ex:QualityAssessmentIntegration",
"prov:label": "Integrating Quality Assessment (ISO 19157 DQ Report)",
"prov:wasInformedBy": "ex:watermarking"
}
},
"prefix": {
"ex": "http://ogc.org/testbed-21/dq4ipt#",
"prov": "http://www.w3.org/ns/prov#"
},
"entity": {
"ex:source-imagery": {
"prov:type": "prov:Entity",
"prov:label": "Input Imagery (Sentinel-2 L1C)",
"ex:role": "InputImagery"
},
"ex:watermarked-image": {
"prov:wasDerivedFrom": "ex:source-imagery",
"prov:wasGeneratedBy": "ex:watermarking",
"prov:type": "prov:Entity",
"prov:label": "Watermarked Image (Trusted Watermark Applied)",
"ex:role": "IntermediateProductWatermarkedImage"
},
"ex:vc-input-image": {
"prov:wasDerivedFrom": "ex:source-imagery",
"prov:wasGeneratedBy": "ex:watermarking",
"prov:type": "prov:Entity",
"prov:label": "Verifiable Credential for Input Image",
"ex:role": "IntermediateProductVC"
},
"ex:stac-item-liability": {
"prov:wasDerivedFrom": [
"ex:watermarked-image",
"ex:source-metadata"
],
"prov:wasGeneratedBy": "ex:integrating-provenance-assessment",
"prov:type": "prov:Entity",
"prov:label": "STAC Item (Liability Claims Extension)",
"ex:role": "IntermediateProductSTACItem"
},
"ex:source-metadata": {
"prov:type": "prov:Entity",
"prov:label": "Input Metadata (ISO 19115 / ISO 19157)",
"ex:role": "InputMetadata"
}
}
},
"processing:level": "L1",
"input": {
"image": {
"image_height": 92,
"file:checksum": "1220e76930f8123c4fc42abd0f6c9d22cd5daa24785b6fcbf43891f6e76263be43dd",
"image_url": "https://tpm-ds.eo.esa.int/oads/meta/Tropforest/thumbnail/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_TIMG.jpg",
"image_width": 100,
"image_type": "image/jpeg;charset=UTF-8"
},
"metadata": {
"metadata_url": "https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application%2Fgeo%2Bjson%3Bprofile%3Dhttps%3A%2F%2Fstacspec.org",
"vc_url": "https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/vc%2Bld%2Bjson",
"VC_verification": true,
"VC": {
"relatedResource": [
{
"digestMultibase": "zQmYRMC8UMw4ipWvivUKvzvTWrjbKk1oywH1QpoY6w3tCQX",
"id": "https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld"
},
{
"digestMultibase": "zQmXqCSMRKhzJm6JnhLAVL7seE13dZG7uJscvTXANw4jmJr",
"id": "http://tpm-ds.eo.esa.int/oads/meta/Tropforest/browse/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_BID.JPG"
},
{
"digestMultibase": "zQmduyvHCpCQTv51KqbuQih8vs4cRcS9DdKnUYeuNnzfosr",
"id": "http://tpm-ds.eo.esa.int/oads/meta/Tropforest/thumbnail/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_TIMG.jpg"
}
],
"credentialSubject": {
"date": "2009-11-21T03:27:23Z/2009-11-21T03:27:23Z",
"bbox": [
95.91153308,
25.92713265,
96.09259599,
26.08689352
],
"geometry": {
"coordinates": [
[
[
95.91153308,
26.08689352
],
[
95.91153308,
25.92713265
],
[
96.09259599,
25.92713265
],
[
96.09259599,
26.08689352
],
[
95.91153308,
26.08689352
]
]
],
"type": "Polygon"
},
"links": {
"data": [
{
"href": "https://tpm-ds.eo.esa.int/oads/data/Tropforest/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP",
"title": "Download",
"type": "application/x-binary"
}
],
"previews": [
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/Tropforest/browse/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_BID.JPG",
"title": "QUICKLOOK",
"type": "image/jpeg"
},
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/Tropforest/thumbnail/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_TIMG.jpg",
"title": "THUMBNAIL",
"type": "image/jpeg"
}
]
},
"id": "did:web:emc.spacebel.be:collections:TropForest:items:KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026",
"title": "KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026",
"updated": "2024-04-30T11:32:32Z"
},
"issuanceDate": "2026-03-11T15:07:22Z",
"id": "did:web:emc.spacebel.be:collections:TropForest:items:KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026",
"proof": {
"created": "2026-03-11T15:07:22.696Z",
"jws": "eyJhbGciOiJFUzI1NksiLCJraWQiOiJiQnpXOHlHeEt1RUNMal9JeFNyTkN1eVJKOUppZ2ptTU9DeDJGZHpDcnFBIiwiY3JpdCI6WyJiNjQiXSwiYjY0IjpmYWxzZX0..opXmcXQlUvxz9q6Bbyn7BPLmHm3U1x4pxJsOmqB197RM77L2oRz38cCYOKzAxVHzIIrYBZIj3Ygfap36e3OqDQ",
"proofPurpose": "assertionMethod",
"type": "EcdsaSecp256k1Signature2019",
"verificationMethod": "did:web:emc.spacebel.be:organisations:esa_esrin#owner"
},
"type": [
"VerifiableCredential",
"Feature"
],
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld",
{
"digestMultibase": {
"@type": "https://w3id.org/security#multibase",
"@id": "https://w3id.org/security#digestMultibase"
},
"relatedResource": {
"@type": "@id",
"@id": "https://www.w3.org/2018/credentials#relatedResource"
}
}
],
"issuer": "did:web:emc.spacebel.be:organisations:esa_esrin"
}
},
"image_hash_verified": true
},
"datetime": "2026-03-11T15:07:24Z",
"start_datetime": "2009-11-21T03:27:23Z",
"end_datetime": "2009-11-21T03:27:23Z",
"processing:facility": "Secure Dimensions Processes",
"processing:lineage": "Watermarking Process",
"processing:datetime": "2026-03-11T15:07:24Z",
"liability:quality": {
"scope": {
"level": "dataset"
},
"report": [
{
"result": [
{
"valueRecordType": "decimal",
"type": "QuantitativeResult",
"value": [
4.0
]
}
],
"measure": {
"measureIdentification": {
"code": "7",
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Cloud cover",
"nameOfMeasure": [
"Percentage of image obscured by cloud"
]
},
"evaluationMethod": [
{
"evaluationMethodType": "directInternal",
"type": "FullInspection"
}
],
"type": "CompletenessOmission"
}
]
},
"processing:software": {
"name": "Geoserver",
"version": "3.0-SNAPSHOT"
}
}
}
5.3.3. Validation and Testing
5.3.3.1. Conformance Testing
The server undergoes conformance testing for:
OGC API — Processes: Compliance with OGC API — Processes 1.0 specification; and
STAC Specification: Conformance with STAC 1.0.0 and liability-claims extension.
5.3.3.2. Quality Measure Validation
Quality measures are validated against:
STAC Liability and Claims extension: https://luciocola.github.io/stac-extension-liability-claims/json-schema/schema.json
5.3.4. Deployment Considerations
5.3.4.1. Infrastructure Requirements
Runtime: GeoServer 3.0 SNAPSHOT (Java + Tomcat)
Dependencies: Java libraries see below
Storage: IPFS
Database: PostgreSQL with PostGIS for metadata storage
Blockchain Hyperledger Fabric
Listing 10 — Java library dependencies
import com.danubetech.dataintegrity.verifier.LdVerifier;
import com.danubetech.dataintegrity.verifier.LdVerifierRegistry;
import com.danubetech.keyformats.crypto.ByteVerifier;
import com.danubetech.keyformats.crypto.PublicKeyVerifier;
import com.danubetech.keyformats.crypto.PublicKeyVerifierFactory;
import com.danubetech.keyformats.jose.JWK;
import com.danubetech.keyformats.jose.KeyTypeName;
import com.danubetech.verifiablecredentials.VerifiableCredential;
import com.google.gson.Gson;
import foundation.identity.jsonld.ConfigurableDocumentLoader;
import foundation.identity.jsonld.JsonLDException;
import io.grpc.ChannelCredentials;
import io.grpc.Grpc;
import io.grpc.ManagedChannel;
import io.grpc.TlsChannelCredentials;
import io.ipfs.multibase.Multibase;
import io.ipfs.multihash.Multihash;
import org.apache.commons.io.IOUtils;
import org.geoserver.wps.gs.GeoServerProcess;
import org.geotools.process.factory.DescribeParameter;
import org.geotools.process.factory.DescribeProcess;
import org.geotools.process.factory.DescribeResult;
import org.hyperledger.fabric.client.*;
import org.hyperledger.fabric.client.identity.*;
import org.hyperledger.fabric.client.identity.Identity;
import org.hyperledger.fabric.client.identity.Signer;
import org.json.simple.JSONArray;
import org.json.simple.JSONObject;
import org.json.simple.parser.JSONParser;
import org.json.simple.parser.ParseException;
import javax.imageio.ImageIO;
import javax.net.ssl.HttpsURLConnection;
import java.awt.*;
import java.awt.image.BufferedImage;
import java.io.*;
import java.lang.reflect.InvocationTargetException;
import java.net.*;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.security.*;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.time.Instant;
import java.util.*;
import java.util.List;
import java.util.concurrent.TimeUnit;
5.3.4.2. API Endpoints
Key endpoints following OGC API — Processes (https://geoserver.ogc.secd.eu/geoserver/ogc/processes/v1/processes):
GET /processes — List available processes;
GET /processes/gs:TrustedWatermarking — Process description; and
POST /processes/gs:TrustedWatermarking/execution — Execute process.
No job endpoints are required as the execution is synchronous.
5.3.5. Integration with IPT Framework
The server demonstrates IPT principles through:
Integrity: Cryptographic hashing of outputs (IPFS CID);; and
Trust: Verifiable quality assessments via STAC metadata on blockchain.
All outputs reference standardized quality measures ensuring consistent interpretation across organizations implementing IPT frameworks.
6. DQ enabled IPT Server 2: OGC API — Records Implementation
This component implements an OGC API-Records and STAC-API compliant catalogue server that provides access to satellite imagery metadata with embedded ISO 19115-4 data quality reports and ISO19115-4 compliant provenance information when available. The server demonstrates discovery and retrieval of quality-assured Earth observation data through standardized catalog interfaces it is integrated with an IPT-enabled framework based on W3C DID and Verifiable Credentials.
6.1. Architecture Overview
The DQ-enabled IPT Server 2 implements the following architecture:
| Component | Description |
|---|---|
| OGC API-Records Catalogue Server | Multi-organization catalogue with RESTful API following OGC API-Records 1.0 and STAC API specifications. Supports content-negotiation to return ISO19115-4 or other metadata flavours (e.g. STAC, OGC 17-003r2, etc.). |
| Verifiable Data Registry | Registry providing access to W3C DID documents for resources and W3C Verifiable Credentials for EO products. The Registry implements an API as defined in DID Document Property Extensions. |
| STAC API-Extensions | Implements STAC API extensions: Filter, Fields, Sort, Collection Search, CQL2-JSON, CQL2-Text, etc. |
| DIF Universal Resolver | Online resolver at https://dev.uniresolver.io/ that can be used to resolve public DID. |
| Universal Verifier | Online verifier at https://univerifier.io/ that can be used to verify W3C Verifiable Credentials and Presentations. |
| STACBrowser | Open-source STAC Catalogue client that can access the OGC API-Records Catalogue Server https://radiantearth.github.io/stac-browser/#/external/emc.spacebel.be/?.language=en. |
| Jupyter Notebook | Notebook acting as Catalogue Client demonstrating the various interfaces and metadata responses implemented by the DQ-enabled IPT Server. |
Figure 3 — Component Diagram
6.2. Objectives
The objectives of the DQ-enabled IPT Server 2 are to:
Enable Discovery: Provide search and filtering capabilities;
Standardized Metadata Encoding: Support STAC metadata encoding and implement ISO19115-4 JSON metadata encoding for collections and granules (products);
Quality Reports : Provide examples of Quality Reports in the EO domain encoded with ISO19115-4 referencing ISO19157 quality measures available in RAINBOW;
Provenance Metadata : Provide examples of Provenance metadata in the EO domain encoded with ISO19115-4 complementing the provenance information inherent to the use of DID and related crypographical proof verification;
Standardized Catalog Access: Implement OGC API-Records and STAC API specifications; and
Support Trust and Integrity Assessment: Publish resolvable W3C DID for EO resources and organizations and W3C Verifiable Credentials for EO products allowing cryptographical proof verification of origin of the metadata and integrity of metadata claims, including integrity of referenced external resources.
6.3. Technical Implementation
6.3.1. Catalog Organization
The catalogue is based on the CEOS FedEO and ESA MAAP Catalogue server implementations. The server organizes metadata as STAC Collections and Items. Collections may be “local” or obtained from federated catalogues. Items from external catalogues are accessed via distributed search and the server performs metadata format conversions as needed.
Collections (top-level groupings):
Collections from multiple agencies (ISO19139-2, ISO19115-3, ISO19115-4, OGC 17-084r1, STAC, etc.);
Each collection represented as STAC Collection;
ISO 19157 metadata with quality reports/measures (if available) accessible as STAC asset;
DID representing the collection included in the metadata (ISO19115-4, STAC Collection);
Organization (e.g., agency) identified with a DID identifier/document; and
ISO19115-4 encoding of CEOS ARD quality information used as examples of quality reports.
Items (individual products):
Each product represented as STAC Item;
DID representing the product included in the metadata (ISO19115-4, STAC Item);
Product components including quicklooks represented as STAC assets;
ISO 19157, ISO 19115-3 and ISO 19157-2 metadata with quality reports/measures accessible as STAC asset;
Quality measure identifiers referring (i.e. identical to) to measure identifiers registered on OGC RAINBOW;
W3C Verifiable Credential for the product represented as STAC asset;
Provenance information (if available) via STAC Processing Extension, ISO19115-4 lineage complemented with issuer/holder DID (Document) information; and
ISO19115-4 encoding of OGC17-003r2 quality information used as examples for quality reports (e.g., Biomass).
W3C DID (Decentralized Identifiers):
Data Provider organizations represented by DID identifier (issuer/holder/verifier). Organizations are assumed to self-identify by having created a DID; In these cases, the DID subject is also the DID controller;
Data Provider DID resolves to DID Document with public key information for integrity checks;
EO Collection represented by DID identifier;
EO Product represented by DID identifier;
DID resolve to DID documents; and
DID documents reference service to obtain Verifiable Credentials (Data Model v1.0 or 2.0) .
6.3.2. OGC API-Records Catalogue Server
The catalogue interfaces include but are not limited to OGC API-Records and STAC API. The diagram below shows the resources corresponding to the RESTful interface covering these two interfaces.
Figure 4 — Resource Diagram
6.3.3. Verifiable Data Registry
The DIF (Decentralized Identity Foundation) Linked Verifiable Presentation specification defines how to share, discover and retrieve Verifiable Credentials publicly via a service entry in a “DID Document”. The W3C DID Property Extensions furthermore defines how to refer to the Credential Registry where the Verifiable Credentials for a subject can be retrieved. Both extensions are used in the prototype implementation and the above example.
The following shows how the vp service can be used through a Universal Resolver:
An example of a call to the Credential Registry (VC 1.0):
Example calls to the Credential Registry for subjects with multiple VCs (VC 1.0 and VC 2.0):
Example calls to the Credential Registry to get DID documents:
The interface to the Credential Registry was implemented using a part of the interface proposed in https://www.w3.org/TR/did-extensions-properties/#credentialregistry and partly represented below.
Figure 5 — Resource Diagram
The DIDs can also be resolved using the Universal Resolver endpoint https://dev.uniresolver.io/1.0/identifiers/<did> using content negotiation (application/json).
The various DID are recorded in the Verifiable Data Registry which supports returning data necessary to produce the corresponding DID documents. Although the DID use the Web method for simplicity, other DID methods might be applied as well.
6.3.4. Metadata
6.3.4.1. STAC Item
The digital identifiers of the resources described in the catalogue are included in the metadata (e.g. ISO19115-4 or STAC) in the catalogue as shown below. In the below collection example, a DOI and DID are both available.
Listing 11
{
"date": {
"creation": "2019-05-23"
},
"identifier": [
{
"code": "10.5270/esa-qoe849q",
"codeSpace": "https://doi.org"
},
{
"code": "did:web:emc.spacebel.be:collections:TropForest",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "TropForest"
}
In STAC Items and Collections, the DID identifier is encoded with the STAC Additional Identifiers Extension.
Listing 12
{
"stac_version": "1.0.0",
"type": "Feature",
"stac_extensions": [
"https://stac-extensions.github.io/external-ids/v1.0.0/schema.json"
],
"properties": {
"externalIds": [{
"scheme": "https://www.w3.org/ns/did/v1",
"value": "did:web:emc.spacebel.be:collections:TropForest:items:KO2_OTPF_KO2_MSC_2F_20090813T143026_20090813T143026_016247_W060_S022"
}]
}
}
6.3.4.2. ISO19115-4
The catalogue served through the OGC API-Records instance provides access to metadata records of EO collections and EO products.
The following quality-related metadata is provided in the ISO19115-4 format:
Furthermore, the Quality Information available in the OGC 17-003r2 metadata is transformed into ISO19115-4 conformant metadata according to the following mapping and a default quality information is provided if this information is missing in the source format. An extract of the returned ISO19115-4 encoding is included in Example 2.1 in the Notebook (Annex E).
The product metadata in the ESA Catalogue is encoded as OGC 17-003r2 metadata. Quality information may be available in the QualityInformation and the qualityStatus flag. This flag can be DEGRADED or NOMINAL and thus be encoded using the ISO19157-3 measure at https://defs-hosted.opengis.net/prez-hosted/catalogs/hosted:iso-19157-3/collections/ns10:qualityMeasure/items/qualitymeasure:101
Listing 13
"productInformation": {
"qualityInformation": {
"qualityDegradationQuotationMode": "MANUAL",
"qualityStatus": "DEGRADED",
"qualityDegradationTag": "RADIOMETRY",
"qualityDegradation": 10.0
}
}
Listing 14
"productInformation": {
"cloudCover": 4,
"qualityInformation": {
"qualityDegradationQuotationMode": "AUTOMATIC",
"qualityStatus": "NOMINAL",
"qualityDegradation": 0.0
}
}
| OGC 17-003r2 | ISO19157/ISO19115-4 | OGC RAINBOW |
|---|---|---|
| qualityDegradationQuotationMode | evaluationMethod | |
| qualityStatus | measure “data product specification passed” (ConceptualConsistency) | https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/101 |
| qualityDegradation | measure “rate of imperfect coverage” (Omission) | https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/211 |
| cloudCover | measure “rate of missing items” (Omission) | https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/7 |
| snowCover | measure “rate of missing items” (Omission) | https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/7 |
The table below shows the mapping that was implemented to encode the provenance information available for products from OGC 17-003r2 format to STAC and ISO19115-4. The processing:lineage property in the STAC Processing Extension is limited to a single string. The same STAC Extension recommends using the derived_from relation in a STAC link to refer to the STAC metadata of the item(s) that are used for producing the STAC Item.
| OGC17-003r2 | ISO19115-3/4 | STAC | Example |
|---|---|---|---|
| processingCenter | processStep[].processor[].party (organisation) | processing:facility | “Biomass CPF” |
| processingLevel | identificationInfo.processingLevel.code | processing:level | “1A” |
| processorName | processStep[].processingInformation[]. softwareReference.title | processing:software | “Biomass L1 Processor” |
| processorVersion | processStep[].processingInformation[]. softwareReference.edition | processing:software | “3.3.3” |
| processingDate | processStep[].stepDateTime | processing:datetime | “2025-07-03T03:45:31Z” |
A sample of the BiomassLevel1aIOC collection from ESA MAAP is available at https://radiantearth.github.io/stac-browser/#/external/emc.spacebel.be/collections/BiomassLevel1aIOC The STAC Items of this collection have assets with ISO19115-4 metadata. This metadata includes quality information and provenance information produced from the source OGC 17-003r2 metadata as explained above.
The Provenance (lineage) Information available in the OGC 17-003r2 metadata is transformed by the catalogue into ISO19115-4 as shown in Example 2.6. Unfortunately, the available ISO19115-4 JSON schemas in the ISO Guthub repository contain an incomplete definition of LI_Lineage without processStep. The original mdj.json JSON schema was extended based on the ISO19115-3 Metadata for Resource Lineage (MRL) with the following types to be able to express the detailed provenance information:
LE_Source
LE_ProcessStep
LE_ProcessStepReport
LE_Algorithm
LE_Processing
LE_NominalResolution
The Example 2.6 in the Notebook (Annex E) can actually be produced from the corresponding BiomassLevel1aIOC OGC 17-003r2 metadata in ESA MAAP.
6.3.4.3. DIDs and DID Documents
The Testbed participants propose to identify products with a W3C DID identifier, these products may be single-file products or directory products. The directory products may correspond to unpacked EO-SIP (EO Submission Information Package) packages from a long-term archive. The original product corresponds to the assets in the red dashed line in the diagram above. As these product files (assets) may be in public S3 bucket for dissemination purposes, a way to be able to verify the provenance and authenticity of the product is of interest.
While many organizations now make available their EO Products in on-line object storage (S3), the product metadata format accompanying the data may vary.
The simulated environment consists of various organizations that self-identify by having created a DID. In these cases, the DID subject is also the DID controller (See B.9.1 of https://www.w3.org/TR/did-1.0/#data-model).
Also the different EO collections and EO products/granules are identified by DID. In this case, the DID controller differs from the DID subject.
| DID Subject Type | DID Subject Example | DID Controller |
|---|---|---|
| Organisation | did:web:emc.spacebel.be:organisations:esa_esrin | did:web:emc.spacebel.be:organisations:esa_esrin |
| EO Collection | did:web:emc.spacebel.be:collections: PROBA.HRC.1A | did:web:emc.spacebel.be:organisations:esa_esrin |
| EO Product | did:web:emc.spacebel.be:collections: PROBA.HRC.1A:items: PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001 | did:web:emc.spacebel.be:organisations:esa_esrin |
The DID resolve to DID documents.
Figure 6 — Object Diagram
6.3.4.4. Verifiable Credential
Metadata for EO products contains information (claims or statements) about the actual EO product. By using a single format based on W3C Verifiable Credentials (VC), the Testbed participants aimed to make these claims verifiable and in addition offer a homogeneous solution. The VC can be considered the identity card of the product. Typical claims relate to where the actual product was acquired (i.e. the geometry), also the time it has been acquired. The Testbed participants aimed to avoid that incorrect geometry information and/or incorrect date of observation or other metadata properties may lead to wrong decisions.
The claim representation in the Verifiable Credentials is based on the following design drivers:
Adoption of the W3C Verifiable Credential (VC) representation
Avoid definition of yet another EO metadata format for expressing claims/verifiable statements about an EO product.
This can be achieved by adopting JSON-LD EO metadata representations such as the following.
OGC 17-003r2 which allows interpretation as JSON-LD and for which the JSON encoding is widely adopted for ESA Earth Explorer, Heritage and Third Party missions.
GeoDCAT-AP based on W3C DCAT and work at OGC Incubator.
Schema.org as proposed in the eo-on-schema.org guidelines which are the outcome of an ESA project.
The IPT Engineering Report https://docs.ogc.org/per/24-033.html in addition mentions current work on a JSON-LD compatible representation for the popular STAC metadata format.
For any external resource referenced by a link from inside the VC, appropriate Content Integrity Protection is to be applied as explained in The OGC Testbed-20 IPT Engineering Report sections D.8, D.8.1. based on VC Data Model 1.1 and D.8.2. based on VC Data Model 2.0.
E.g., the VC 1.1 Data Model proposes a multibase multihash value e.g. provided as value of a hl query parameter using https://datatracker.ietf.org/doc/html/draft-sporny-hashlink-07. See https://w3c-ccg.github.io/ hashlink/#hl-url-params. The advantage of this is that the original (OGC 17-003r2 JSON) syntax of the claims can remain unchanged (as the href remain href properties, with an hl query parameter appended carrying the multihash value) and the original JSON schema is still respected.
The VC is accessible from the STAC Item in the API-Records/STAC Catalogue via a link. The EBSI media type for a VC and VP in the link allows to identify the VC. For VC 2.0, version=2.0 is appended to the media type to distinguish both versions.
The prototype supports: - VC 1.0 for all collections (The open-source software DIDKit is used to sign these VCs); and - VC 2.0 for a subset of the collections (due to an implementation limitation related to the key type (crv or cryptographic curve) associated with the key of the organization in its DID document), i.e. DLR and JAXA organizations.
| Key type (crv) | Collections/Organisation | Supported VC versions in prototype |
|---|---|---|
| Ed25519 | DLR, JAXA, CEOS | VC 1.0, VC 2.0 |
| secp256k1 | others, e.g. ESA, INPE | VC 1.0 |
Note that the above choice of key types was done in an arbitrary way in Testbed-20 to test multiple variations and remained unchanged for Testbed-21.
The current prototype uses the relatedResource property from the VC 2.0 Data Model applied to Version 1.0 Verifiable Credentials for content integrity protection. The missing VC 2.0 properties were included in the @context (in case of a VC 1.0) as shown below. The resulting VC can be validated using the Universal Verifier.
The VC is accessible from the STAC Item in the API-Records/STAC Catalogue via a link. The EBSI media type for a VC and VP in the link allows to identify the VC.
6.3.4.5. References to OGC RAINBOW
In the ISO19115-4 encoding, measurements are identified using their ISO19157-3 URI which are described in OGC RAINBOW. The Catalogue is also able to return GeoDCAT-AP responses containing the same quality information using the W3C PROV specification as depicted below.
Figure 7 — Class Diagram
Example 2.2.4 in the Notebook (Annex E) shows the GeoDCAT-AP response.
Also, conformance results w.r.t. to a Specification can be expressed in GeoDCAT-AP using the PROV-O vocabulary as depicted below.
Figure 8 — Class Diagram
6.3.5. Validation and Conformance
The rows in the table below refer to a component invoking/using another component in the corresponding column. The Examples in the table refer to the corresponding part in the Jupyter Notebook available as Annex E in this Report.
| From/To | DID Repository (D102.2) | Catalogue (D102.1) | Watermarking Process (D101.1) | Immutable Catalogue (D101.2) |
|---|---|---|---|---|
| Notebook | Notebook §3 | Notebook §1-§2 | Notebook §4.1-§4.3 | Notebook §4.4 |
| DIF Universal DID Resolver | Example | - | - | - |
| STACBrowser | - | Notebook Examples 1.6, 2.5 | - | Notebook §4.5 |
| Watermarking Process | Notebook §4.1-§4.3 | Notebook §4.1-§4.3 | - | Notebook §4.1-§4.3 |
| VC Universal Verifier | See VC 1.0 and VC 2.0 examples below | - | - | |
| ISO19115-4 Validator | - | See ajv example below | - | - |
In addition, a TIE test has been performed to confirm that the ISO19115-4 response generated by the Catalogue (D102.1) — published as STAC assets — can be validated with the JSON schemas available in the ISO-TC211 GitHub repository.
Example of ISO19115-4 validation:
Listing 15
ajv validate -d NOAA_AVHRR_L1B_LAC.json -s "19115-4.json" --spec=draft2020 --validateFormats=true --strict=false -c ajv-formats -r "mdj.json" -r "dqc.json" -r "Feature.json"
Example of a VC 1.0 verification with Universal Verifier:
Figure 9 — Universal Verifier Example (VC)
6.3.5.1. Issues encountered
No existing library for VC 2.0 signing and verification was identified. Therefore, the Testbed participants implemented the VC 2.0 proof algorithm. The implementation matches the verifier.io implementation for a specific key family (crv).
The Testbed participants experienced different results after normalization of numerical values (coordinates) by different implementations which caused proof verification to fail. This is due to some of the coordinates in the metadata, e.g. 65.440002 . Such numbers cannot be represented accurately bitwise, and when serialized to exponential notation (as mandated by the RDF canonization algorithm), the result was 6.544000200000001E1 . Here is a simple reproduction of the problem : https://json-ld.org/playground/#startTab=tab-canonized&json-ld=%7B%22%40context%22%3A%5B%7B%22bbox%22%3A%22ogc%3Abbox%22%7D%5D%2C%22bbox%22%3A%5B65.440002%5D%7D With DIDKit, we got “6.5440002E1” for the same input.
the Testbed participants identified an issue with JSON-LD context expansion by a JSON-LD library our implementation is using. The issue was reported to the developers and is at https://github.com/digitalbazaar/pyld/issues/230. As work-around, we adjusted the context used in the VC.
While we could include the external OGC context document for OGC 17-003r2 encoding in VC 1.0 and obtain valid VC, the same is not possible in VC 2.0. it is due to a conflict with the credentials/v2 context. More specifically, the OGC context redefines the “description” and “mediaType” fields, which are defined as protected in the VC context. It could be solved by putting the OGC context first in the list (letting the VC context override it), but the VC spec mandates that the VC context is first. See also https://github.com/w3c/json-ld-syntax/issues/443 and https://github.com/w3c/json-ld-syntax/issues/424.
The mdj.json JSON schema in the ISO 19115-4 repository contains an LI_Lineage object definition without the LE_Source and LE_ProcessStep which are needed to express the provenance information. We recommend to add these objects in the official ISO mdj.json JSON schema file.
7. DQ-enabled Software Library
This component provides a comprehensive software library for accessing, converting, and validating data quality metadata across multiple international standards. The library enables developers to integrate ISO 19157-1:2023 quality reporting and W3C PROV provenance tracking into their applications.
7.1. Library Overview
The DQ-enabled software library implements the following capabilities:
| Module | Functionality |
|---|---|
| Quality Metadata Access | Read and parse ISO 19157-1:2023 and ISO 19115/19115-4 quality reports |
| Metadata Conversion | Bidirectional conversion between ISO 19157, ISO 19115, NASA UMM, and TrainingDML-AI |
| Provenance Processing | W3C PROV graph generation, validation, and SPARQL queries |
| Schema Validation | JSON Schema and SHACL validation for quality reports |
| STAC Integration | Read/write STAC Items with liability-claims extension |
| API Clients | Client libraries for OGC API — Processes and OGC API — Records |
| Quality Assessment Tools | Compute ISO 19157 registered measures from geospatial datasets |
| Measure Registry | Access ISO 19157 and OGC RAINBOW measure definitions |
7.2. Aims
The aims of the DQ-enabled software library are to:
Simplify Quality Metadata Access: Provide high-level APIs for reading and writing ISO 19157 quality reports;
Enable Standards Interoperability: Demonstrate conversion between ISO 19157, NASA UMM, and TrainingDML-AI;
Support Provenance Tracking: Generate and validate W3C PROV graphs from processing workflows;
Facilitate Integration: Provide client libraries for accessing IPT servers; and
Validate Compliance: Implement comprehensive validation for quality metadata.
7.3. Objectives
7.3.1. Primary Objectives
Implement Metadata Parsers: Support ISO 19157, ISO 19115, NASA UMM, TrainingDML-AI;
Provide Conversion Functions: Bidirectional format transformation with fidelity tracking;
Enable PROV Generation: Create W3C PROV graphs from ISO 19115 lineage;
Support Validation: JSON Schema, SHACL, and PROV-CONSTRAINTS validation; and
Deliver API Clients: Python clients for OGC API — Processes and OGC API — Records.
7.3.2. Library Architecture
7.3.2.1. Module Structure
The library is organized into the following modules:
Listing 16
dq_ipt_library/
├── quality/
│ ├── iso19157.py # ISO 19157-1:2023 parser and generator
│ ├── iso19115.py # ISO 19115/19115-4 support
│ ├── nasa_umm.py # NASA UMM metadata
│ ├── trainingdml.py # TrainingDML-AI metadata
│ └── measures.py # ISO 19157 measure registry access
├── provenance/
│ ├── prov_generator.py # W3C PROV graph generation
│ ├── prov_validator.py # PROV-CONSTRAINTS validation
│ ├── iso_to_prov.py # ISO lineage → PROV conversion
│ └── sparql_client.py # SPARQL query interface
├── conversion/
│ ├── converters.py # Master conversion framework
│ ├── iso19157_to_iso19115.py
│ ├── iso19115_to_iso19157.py
│ ├── umm_to_iso19157.py
│ ├── iso19157_to_umm.py
│ ├── trainingdml_to_iso19157.py
│ └── fidelity_tracker.py # Conversion quality assessment
├── validation/
│ ├── json_schema.py # JSON Schema validation
│ ├── shacl_validator.py # SHACL validation for RDF
│ └── conformance.py # OGC conformance testing
├── stac/
│ ├── item_reader.py # Read STAC Items with quality
│ ├── item_writer.py # Write STAC Items with quality
│ └── collection_manager.py
├── api_clients/
│ ├── processes_client.py # OGC API - Processes client
│ ├── records_client.py # OGC API - Records client
│ └── stac_client.py # STAC API client
└── utils/
├── measure_registry.py # Access ISO 19157 + RAINBOW
└── quality_metrics.py # Compute quality measures
7.3.2.2. Core API Examples
Reading ISO 19157 Quality Reports:
Listing 17
from dq_ipt_library.quality import ISO19157QualityReport
# Parse from JSON
with open('quality_report.json') as f:
report = ISO19157QualityReport.from_json(f.read())
# Access quality elements
for element in report.quality_elements:
print(f"Category: {element.category}")
print(f"Measure: {element.measure.name}")
print(f"Value: {element.result.value}")
print(f"Confidence: {element.metaquality.confidence}")
# Filter by category
positional = report.get_elements_by_category('positionalAccuracy')
for elem in positional:
if elem.result.value[0] <= 15.0:
print(f"High accuracy: {elem.result.value[0]}m")
Converting Between Standards:
Listing 18
from dq_ipt_library.conversion import MetadataConverter
# Initialize converter
converter = MetadataConverter()
# Convert NASA UMM → ISO 19157
umm_metadata = load_umm_metadata('umm_dataset.json')
iso19157, fidelity = converter.convert(
source_format='nasa_umm',
target_format='iso19157',
metadata=umm_metadata
)
print(f"Conversion fidelity: {fidelity.score}/100")
print(f"Unmapped fields: {fidelity.unmapped_fields}")
# Convert ISO 19157 → TrainingDML-AI
trainingdml, fidelity = converter.convert(
source_format='iso19157',
target_format='trainingdml_ai',
metadata=iso19157
)
# Save converted metadata
with open('trainingdml_output.json', 'w') as f:
f.write(trainingdml.to_json())
Generating W3C PROV from ISO Lineage:
Listing 19
from dq_ipt_library.provenance import ISOToPROVConverter
# Read ISO 19115 lineage
iso_lineage = quality_report.lineage
# Convert to W3C PROV
converter = ISOToPROVConverter()
prov_document = converter.convert_lineage(iso_lineage)
# Serialize as PROV-JSON
prov_json = prov_document.serialize(format='json')
# Export as RDF for SPARQL
prov_rdf = prov_document.serialize(format='turtle')
with open('provenance.ttl', 'w') as f:
f.write(prov_rdf)
# Query with SPARQL
from dq_ipt_library.provenance import SPARQLClient
client = SPARQLClient('http://localhost:3030/provenance')
results = client.query("""
PREFIX prov: <http://www.w3.org/ns/prov#>
SELECT ?activity ?agent
WHERE {
?activity a prov:Activity ;
prov:wasAssociatedWith ?agent .
}
""")
Validating Quality Metadata:
Listing 20
from dq_ipt_library.validation import QualityValidator
validator = QualityValidator()
# Validate against JSON Schema
is_valid, errors = validator.validate_json_schema(
quality_report,
schema_type='iso19157'
)
if not is_valid:
for error in errors:
print(f"Validation error: {error.message} at {error.path}")
# Validate W3C PROV using SHACL
prov_valid, violations = validator.validate_shacl(
prov_document,
shapes_file='shacl/liability-claims-shapes.ttl'
)
# Validate measure codes against registry
from dq_ipt_library.utils import MeasureRegistry
registry = MeasureRegistry()
for element in quality_report.quality_elements:
measure_code = element.measure.identification.code
if not registry.is_valid_measure(measure_code):
print(f"Invalid measure code: {measure_code}")
else:
definition = registry.get_measure(measure_code)
print(f"Measure: {definition.name}")
print(f"Definition: {definition.description}")
Accessing IPT Servers:
Listing 21
from dq_ipt_library.api_clients import ProcessesClient, RecordsClient
# Access DQ-enabled IPT Server 1 (OGC API - Processes)
processes = ProcessesClient('https://processes.example.org')
# Execute satellite processing with quality assessment
job = processes.execute(
process_id='satellite-imagery-quality-processor',
inputs={
'source_imagery': 'https://data.example.org/l1c.tif',
'processing_level': 'L2A',
'quality_assessment': True
}
)
# Wait for completion
result = job.wait_for_completion()
# Access STAC Item with quality metadata
stac_item = result.get_stac_item()
quality_report = stac_item.properties['liability:quality']
# Access DQ-enabled IPT Server 2 (OGC API - Records)
records = RecordsClient('https://catalog.example.org')
# Search with quality filtering
items = records.search(
bbox=[-122.5, 37.5, -122.0, 38.0],
datetime='2025-06-01/2025-06-30',
filter={
'quality_threshold': {'positionalAccuracy': 15.0},
'confidence_level': 0.90
}
)
for item in items:
print(f"Item: {item.id}")
quality = item.properties['liability:quality']
print(f"Positional accuracy: {quality.get_metric('positionalAccuracy')}m")
print(f"Confidence: {quality.get_metaquality('confidence')}")
Computing Quality Measures:
Listing 22
from dq_ipt_library.utils import QualityMetrics
from osgeo import gdal
# Load geospatial dataset
dataset = gdal.Open('satellite_image.tif')
# Compute ISO 19157 measures
metrics = QualityMetrics()
# Measure 28: Mean positional uncertainty (requires GCPs)
ground_control_points = load_gcps('gcps.json')
positional_accuracy = metrics.compute_positional_uncertainty(
dataset,
ground_control_points,
method='rmse'
)
# Measure 7: Number of missing items (completeness)
missing_pixels = metrics.compute_completeness(
dataset,
nodata_value=-9999
)
# Create ISO 19157 quality element
quality_element = ISO19157QualityElement(
category='positionalAccuracy',
subcategory='absoluteExternalPositionalAccuracy',
measure=ISO19157Measure(
identification={'code': '28', 'codeSpace': 'ISO 19157'},
name='Mean value of positional uncertainties'
),
evaluation_method=EvaluationMethod(
method_type='directExternal',
description='RMSE with ground control points',
datetime=datetime.now(timezone.utc)
),
result=QuantitativeResult(
value=[positional_accuracy],
unit='meter',
error_statistic='RMSE'
)
)
7.3.3. Conversion Fidelity Framework
The library tracks conversion quality between metadata standards:
| Metric | Description | Range |
|---|---|---|
| Field Coverage | Percentage of source fields mapped to target | 0-100% |
| Semantic Preservation | Degree to which meaning is preserved | 0-100% |
| Reversibility | Ability to round-trip without loss | 0-100% |
| Overall Fidelity | Weighted average of above metrics | 0-100% |
Example fidelity report:
Listing 23
fidelity_report = converter.get_fidelity_report()
print(f"""
Conversion: NASA UMM → ISO 19157-1:2023
---
Field Coverage: {fidelity_report.field_coverage}%
Semantic Preservation: {fidelity_report.semantic_preservation}%
Reversibility: {fidelity_report.reversibility}%
Overall Fidelity: {fidelity_report.overall_score}%
Unmapped Source Fields:
{', '.join(fidelity_report.unmapped_source_fields)}
Unmapped Target Fields:
{', '.join(fidelity_report.unmapped_target_fields)}
Notes:
{fidelity_report.notes}
""")
7.3.4. Installation and Dependencies
Installation:
Listing 24
pip install dq-ipt-library
# Optional: Install SPARQL support
pip install dq-ipt-library[sparql]
# Optional: Install full validation suite
pip install dq-ipt-library[validation]
Dependencies:
Python 3.11+
jsonschema — JSON Schema validation
prov — W3C PROV library
rdflib — RDF processing
pyshacl — SHACL validation
requests — HTTP client for API access
pystac — STAC library
osgeo/gdal — Geospatial data processing (optional)
7.3.5. Testing and Validation
The library includes comprehensive test suites:
Unit Tests:
Listing 25
pytest tests/unit/
# Test quality report parsing
pytest tests/unit/test_iso19157.py
# Test conversions
pytest tests/unit/test_conversion.py
# Test PROV generation
pytest tests/unit/test_provenance.py
Integration Tests (require running servers):
Listing 26
# Set server URLs
export IPT_SERVER1_URL=https://processes.example.org
export IPT_SERVER2_URL=https://catalog.example.org
pytest tests/integration/
# Test full workflow: process → catalog → retrieve
pytest tests/integration/test_workflow.py
Conversion Fidelity Tests:
Listing 27
# Test round-trip conversions
pytest tests/fidelity/test_roundtrip.py
# Measure conversion quality
pytest tests/fidelity/test_conversion_scores.py --verbose
7.3.6. Documentation and Examples
The library provides comprehensive documentation:
API Reference: Auto-generated from docstrings (Sphinx);
User Guide: Tutorial-style documentation;
Example Gallery: Jupyter notebooks demonstrating common workflows; and
Conversion Cookbook: Recipes for specific metadata transformations.
Example notebooks included:
01_reading_quality_metadata.ipynb — Parse ISO 19157 and ISO 19115 reports;
02_nasa_umm_conversion.ipynb — Convert UMM ↔ ISO 19157;
03_prov_generation.ipynb — Generate W3C PROV from lineage;
04_stac_integration.ipynb — Work with STAC Items;
05_api_clients.ipynb — Access IPT servers; and
06_quality_computation.ipynb — Compute ISO 19157 measures from data.
7.3.7. Integration with IPT Framework
The library enables developers to:
Build IPT-aware Applications: Integrate quality and provenance into custom tools;
Validate Metadata: Ensure conformance with ISO 19157 and W3C PROV;
Convert Legacy Metadata: Migrate from ISO 19115 to ISO 19157-1:2023;
Query Provenance: Execute SPARQL queries on W3C PROV graphs; and
Access IPT Servers: Programmatic access to quality-assured data catalogs.
All library components maintain full compatibility with the STAC Liability and Claims Extension, ensuring consistent implementation across server and client applications.
Bibliography
[7] Paul Churchyard, Open Geospatial Consortium: OGC 24-033, Testbed-20: Integrity, Provenance, and Trust (IPT) Report. Open Geospatial Consortium (2025). http://www.opengis.net/doc/PER/t20-D001.
[8] Ben Domenico, Open Geospatial Consortium: OGC 10-092r3, NetCDF Binary Encoding Extension Standard: NetCDF Classic and 64-bit Offset Format. Open Geospatial Consortium (2011). https://docs.ogc.org/is/10-092r3/10-092r3/pdf.
[9] Panagiotis (Peter) A. Vretanos, Tom Kralidis, Angelos Tzotsos, Charles Heazel, Open Geospatial Consortium: OGC 20-004r1, OGC API — Records — Part 1: Core. Open Geospatial Consortium (2025). http://www.opengis.net/doc/IS/ogcapi-records-1/1.0.
[10] Y. Coene, U. Voges, O. Barois, Open Geospatial Consortium: OGC 17-003r2, OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard. Open Geospatial Consortium (2020). http://www.opengis.net/doc/IS/eo-geojson/1.0.0.
[11] Akinori Asahara, Ryosuke Shibasaki, Nobuhiro Ishimaru, David Burggraf, Open Geospatial Consortium: OGC 14-084r2, OGC® Moving Features Encoding Extension: Simple Comma Separated Values (CSV). Open Geospatial Consortium (2015). http://www.opengis.net/doc/IS/movingfeatures/csv-extension/1.0.0.
[12] Akinori Asahara, Ryosuke Shibasaki, Nobuhiro Ishimaru, David Burggraf, Open Geospatial Consortium: OGC 14-083r2, OGC® Moving Features Encoding Part I: XML Core. Open Geospatial Consortium (2015). http://www.opengis.net/doc/IS/movingfeatures/xmlcore/1.0.0.
[13] International Organization for Standardization (committee): ISO 19113:2002, Geographic information — Quality principles. International Organization for Standardization, Geneva (2002). https://www.iso.org/standard/26018.html.
[14] International Organization for Standardization (committee): ISO 19114:2003, Geographic information — Quality evaluation procedures. International Organization for Standardization, Geneva (2003). https://www.iso.org/standard/26019.html.
[15] International Organization for Standardization (committee): ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/53798.html.
[16] International Organization for Standardization (committee): ISO 19115-2:2019, Geographic information — Metadata — Part 2: Extensions for acquisition and processing. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/67039.html.
[17] ISO: ISO 19115-3:2016, ISO: ISO 19115-3:2016, Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts. ISO (2016).
[18] ISO: ISO 19115-4, ISO: ISO 19115-4, Geographic information — Metadata — Part 4: JSON schema implementation of metadata fundamentals (Under development). ISO.
[19] International Organization for Standardization (committee): ISO/TS 19138:2006, Geographic information — Data quality measures. International Organization for Standardization, Geneva (2006). https://www.iso.org/standard/32556.html.
[20] International Organization for Standardization (committee): ISO 19157:2013, Geographic information — Data quality. International Organization for Standardization, Geneva (2013). https://www.iso.org/standard/32575.html.
[21] International Organization for Standardization (committee): ISO 19157-1:2023, Geographic information — Data quality — Part 1: General requirements. International Organization for Standardization, Geneva (2023). https://www.iso.org/standard/78900.html.
[22] International Organization for Standardization (committee): ISO/TS 19157-2:2016, Geographic information — Data quality — Part 2: XML schema implementation. International Organization for Standardization, Geneva (2016). https://www.iso.org/standard/66197.html.
[23] ISO: ISO 19157-3, ISO: ISO 19157-3, Geographic information — Data quality — Part 3: Data quality measures register (Under development). ISO.
[24] Open Geospatial Consortium. OGC Naming Authority tools. https://opengeospatial.github.io/ogc-na-tools/
[25] OGC: OGC 17-069r3: OGC API — Features — Part 1: Core, http://docs.opengeospatial.org/is/17-069r3/17-069r3.html
[26] OGC: OGC 19-079r1: OGC API — Features — Part 3: Filtering, http://docs.opengeospatial.org/is/19-079r1/19-079r1.html
[27] OGC: OGC 11-165r2: CF-netCDF3 Data Model Extension standard, 2012
[28] OGC Building Blocks (Rainbow). Creating Building Blocks — Semantic uplift. https://ogcincubator.github.io/bblocks-docs/create/semantic-uplift
[29] Radiant Earth: STAC API Specification v1.0.0, https://github.com/radiantearth/stac-api-spec
[30] STAC Extensions: CEOS Analysis Ready Data (ARD) Extension, https://github.com/stac-extensions/ceos-ard
[31] Radiant Earth: SpatioTemporal Asset Catalog (STAC) Specification v1.0.0, https://github.com/radiantearth/stac-spec
[32] Standardized Big Data Processing in Hybrid Clouds. In: Proceedings of the 4th International Conference on Geographical Information Systems Theory, Applications and Management — Volume 1: GISTAM, pp. 205–210. SciTePress (2018).
[33] Open Geospatial Consortium. Tutorials for the OGC Naming Authority tools. https://opengeospatial.github.io/ogc-na-tools/tutorials/
[34] Bugbee, K., Roux, J. le, Sisco, A., Kaulfus, A., Staton, P., Woods, C., Dixon, V., Lynnes, C., Ramachandran, R.: Improving discovery and use of NASA’s earth observation data through metadata quality assessments. Data Science Journal. 20, 17-17 (2021).
[35] ISO : ISO TR 19115-4, Geographic information – Metadata — Part 4: JSON schema implementation of metadata fundamentals (Under development)
[36] ISO : ISO19115-4 JSON Encoding, https://github.com/ISO-TC211/XML/tree/master/schemas.isotc211.org/json/19115/-4 (incomplete)
[37] Lawrence Livermore National Laboratory: NetCDF CF Metadata Conventions – http://cfconventions.org/
[38] ESIP: Attribute Convention for Data Discovery (ACDD) – http://wiki.esipfed.org/index.php/
[39] W3C : W3C Decentralized Identifiers (DIDs) v1.0 , W3C Recommendation 19 July 2022 — https://www.w3.org/TR/did-core/
[40] W3C : W3C did:web Method Specification — https://w3c-ccg.github.io/did-method-web
[41] W3C : W3C Verifiable Credentials Data Model v1.0, W3C Recommendation 19 November 2019 — https://www.w3.org/TR/2019/REC-vc-data-model-20191119/
[42] W3C : W3C Verifiable Credentials Data Model v2.0, W3C Recommendation 15 May 2025 — https://www.w3.org/TR/vc-data-model-2.0/
[43] W3C : DID Document Property Extensions, W3C Group Note 11 December 2025, https://www.w3.org/TR/did-extensions-properties/
[44] DIF: Linked Verifiable Presentation v1.0.0, https://identity.foundation/linked-vp/spec/v1.0.0/
[45] CEOS Analysis Ready Data, https://ceos.org/ard/
[46] OGC: July 2024 Open Standards Code Sprint Summary Engineering Report, https://opengeospatial.github.io/ogcna-auto-review/24-034.html#results_iso19157_3
[47] OGC: OGC RAINBOW — Registry of Terms and Definitions, https://defs.opengis.net/prez/
[48] OGC: OGC Training Data Markup Language for Artificial Intelligence (TrainingDML-AI) Part 2: JSON Encoding Standard, https://docs.ogc.org/is/24-006r1/24-006r1.html.
Annex A
(normative)
Abbreviations/Acronyms
API
Application Programming Interface
ARA
Agile Reference Architecture
ARD
Analysis Ready Data
BB
Building Block
CEOS
Committee on Earth Observation Satellites
CO
Collaborative Object
DCS
Data Centric Security
DID
Decentralized Identifier
DIF
Decentralized Identity Foundation
EBSI
European Blockchain Service Infrastructure
EO
Earth Observation
ESA
European Space Agency
FACTS
Federated Agile Collaborating Trusted Systems
FAIR
Findable Accessible Interoperable and Reusable
GDAL
Geospatial Data Abstraction Library
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
INPE
National Institute for Space Research (Instituto Nacional de Pesquisas Espaciais)
IPFS
InterPlanetary File System
IPT
Integrity Provenance Trust
IRI
Internationalized Resource Identifier
ISO
International Organization for Standardization
JSON
JavaScript Object Notation
JWK
JSON Web Key
JWS
JSON Web Signature
JWT
JSON Web Token
OGC
Open Geospatial Consortium
RDF
Resource Description Framework
REST
Representational State Transfer
SaaS
Software as a Service
SatCen
European Union Satellite Centre
SC
Smart Certificate
SSI
Self-Sovereign Identity
STAC
SpatioTemporal Asset Catalog
TIE
Technology Integration Experiment
UMM
Unified Metadata Model
URL
Uniform Resource Locator
VA
Verifiable Attestation
VC
Verifiable Credentials
VP
Verifiable Presentations
W3C
World Wide Web Consortium
XML
eXtensible Markup Language
ZKP
Zero Knowledge Proof
Annex B
(informative)
STAC Extension Liability Claims v1.3.0 — Compliance Analysis
B.1. Abstract of Annex
This document analyzes the compliance of STAC Extension Liability Claims v1.3.0 with canonical EOVOC schemas for ISO 19157 and ISO 19115 standards. It identifies structural differences, provides compliance assessment, and recommends implementation strategies for full interoperability.
B.2. Summary
The v1.3.0 directory contains dqc.json and mdj.json files that are structurally similar to the canonical eovoc schemas but NOT fully compliant due to:
Different $id URIs — Your schemas use luciocola.github.io instead of eovoc.github.io
Cross-references point to local domain — Internal $ref links use your URLs
Anchor usage — 1.2.0 schemas use $anchor while eovoc uses $comment
Reference format differences — Some internal refs use different patterns
B.3. Detailed Compliance Issues
B.3.1. old schemas use
Listing B.1
"definitions": {
"AbsolutePositionalAccuracy": {
"$anchor": "AbsolutePositionalAccuracy",
"type": "object",
...
}
}
B.3.2. eovoc schemas use
Listing B.2
"definitions": {
"AbsolutePositionalAccuracy": {
"$comment": "AbsolutePositionalAccuracy",
"type": "object",
...
}
}
B.4. Internal Reference Patterns
Listing B.3
"$ref": "#MD_Constraints"
B.4.1. vs eovoc
Listing B.4
"$ref": "#/definitions/MD_Constraints"
B.5. Compliance
B.5.1. Full Canonical Compliance, suggested approach
Use the official eovoc schemas directly by referencing them as external schemas.
B.5.1.1. Advantages
Guaranteed compatibility with ISO 19115/19157 tools
Automatic updates when eovoc updates their schemas
Interoperability with other STAC extensions using eovoc
Smaller extension package size (no duplicate schemas)
Clear separation of concerns
Follows STAC extension best practices
B.5.1.2. Implementation
In schema.json, replace local schema definitions with:
Listing B.5
{
"liability:iso19157_quality": {
"description": "ISO 19157-1:2023 data quality information",
"$ref": "https://eovoc.github.io/eof-eos-stac-extension/v0.0.1/dqc.json#/definitions/DataQuality"
},
"liability:iso19115_metadata": {
"description": "ISO 19115-1:2014 metadata information",
"$ref": "https://eovoc.github.io/eof-eos-stac-extension/v0.0.1/mdj.json#/definitions/MD_Metadata"
}
}
B.6. Recommended Action Plan for v1.3.0
B.6.1. Update schema.json to Reference Canonical Schemas
Update the quality-related field definitions to reference eovoc:
Listing B.6
"liability:iso19157_quality": {
"title": "ISO 19157 Data Quality",
"description": "Data quality information compliant with ISO 19157-1:2023",
"$ref": "https://eovoc.github.io/eof-eos-stac-extension/v0.0.1/dqc.json#/definitions/DataQuality"
},
"liability:iso19115_metadata": {
"title": "ISO 19115 Metadata",
"description": "Metadata information compliant with ISO 19115-1:2014",
"$ref": "https://eovoc.github.io/eof-eos-stac-extension/v0.0.1/mdj.json#/definitions/MD_Metadata"
}
B.6.2. Update iso19157-quality.json (Wrapper)
Replace internal definitions with canonical reference:
Listing B.7
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://luciocola.github.io/stac-extension-liability-claims/v1.3.0/iso19157-quality.json#",
"title": "ISO 19157-1:2023 Data Quality (Canonical Integration)",
"description": "Integration wrapper for eovoc canonical ISO 19157 schemas",
"$ref": "https://eovoc.github.io/eof-eos-stac-extension/v0.0.1/dqc.json#/definitions/DataQuality"
}
B.6.3. Update iso19115-quality.json (Wrapper)
Listing B.8
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://luciocola.github.io/stac-extension-liability-claims/v1.3.0/iso19115-quality.json#",
"title": "ISO 19115 Metadata (Canonical Integration)",
"description": "Integration wrapper for eovoc canonical ISO 19115 schemas",
"$ref": "https://eovoc.github.io/eof-eos-stac-extension/v0.0.1/mdj.json#/definitions/MD_Metadata"
}
B.7. Dependencies
This extension uses canonical ISO 19115/19157 schemas from the eovoc project:
Data Quality (ISO 19157): https://eovoc.github.io/eof-eos-stac-extension/v0.0.1/dqc.json
Metadata (ISO 19115): https://eovoc.github.io/eof-eos-stac-extension/v0.0.1/mdj.json
These schemas are maintained by the Earth Observation Vocabulary project and ensure compatibility with ISO standards.
B.8. Structural Differences Summary
B.8.1. dqc.json Comparison
| Aspect | Your v1.3.0 | eovoc Canonical | Compliant? |
|---|---|---|---|
| $id domain | luciocola.github.io | eovoc.github.io | ❌ No |
| $id trailing # | Yes (dqc.json#) | No (dqc.json) | ❌ No |
| Uses $anchor | Yes | No (uses $comment) | ⚠️ Minor |
| Cross-refs to mdj.json | Point to luciocola | Point to eovoc | ❌ No |
| Definition structure | Same | Same | ✅ Yes |
| Property schemas | Same | Same | ✅ Yes |
B.8.2. mdj.json Comparison
| Aspect | Your v1.3.0 | eovoc Canonical | Compliant? |
|---|---|---|---|
| $id domain | luciocola.github.io | eovoc.github.io | ❌ No |
| $id trailing # | Yes (mdj.json#) | No (mdj.json) | ❌ No |
| Uses $anchor | Yes | No (uses $comment) | ⚠️ Minor |
| Internal $ref format | #Name | #/definitions/Name | ❌ No |
| Cross-refs to dqc.json | Point to luciocola | Point to eovoc | ❌ No |
| Definition structure | Same | Same | ✅ Yes |
| Property schemas | Same | Same | ✅ Yes |
B.9. Content Verification
| ✅ | Definitions are structurally identical — Both define the same ISO 19157/19115 classes |
| ✅ | Property schemas match — Field types and requirements are the same |
| ✅ | Required fields match — Mandatory properties are identical |
| ⚠️ | Reference mechanisms differ — Format and targets of $ref links vary |
| ❌ | Schema identifiers differ — URLs don’t match canonical sources |
B.10. STAC extension liability claims v1.3.0
The v1.3.0 schemas are content-compatible but reference-incompatible with the canonical eovoc schemas, this has been achieved with STAC extension liability claims v1.4.0
B.11. ISO standard lineage (DQ_ evolution)
This document covers:
Structural differences in DataQuality class across three standard versions
Quality category evolution from flat to hierarchical organization
Lineage location changes and separation from quality reporting
Metaquality formalization and fitness-for-purpose assessment mechanisms
Migration strategies for implementers transitioning between versions
B.11.1. Referenced documents
The following documents are referred to in this document:
ISO 19157:2013, Geographic information — Data quality (Withdrawn)
ISO 19157-1:2023, Geographic information — Data quality — Part 1: Framework
ISO 19157-2:2023, Geographic information — Data quality — Part 2: Data quality measures
ISO 19157-3:2026, Geographic information — Data quality — Part 3: Geospatial Data Interpretability Index (GDII) elements (PROPOSED — Not yet published)
ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals
ISO 19115-2:2019, Geographic information — Metadata — Part 2: Extensions for acquisition and processing
ISO 19157:2013: Original monolithic standard
ISO 19157-1:2023: Part 1 — Framework (fundamental restructuring)
ISO 19157-3:2026: Part 3 — Geospatial Data Interpretability Index (GDII) elements (proposed reintroduction)
B.11.2. Key findings
| Aspect | 2013 | 2023 | 2026 (Part 3) |
|---|---|---|---|
| Geospatial Data Interpretability Index (GDII) support | ✅ Included (15th element) | ❌ Removed | ✅ Reintroduced (separate part) |
| Quality Categories | 15 flat elements | 6 hierarchical categories | 6 + Geospatial Data Interpretability Index (GDII) (optional) |
| Lineage Location | Inside DataQuality | ISO 19115-1:2014 | ISO 19115-1:2014 |
| Metaquality | Poorly defined | ✅ Formalized (3 subcategories) | Enhanced |
| Measure Register | Informal (Annex D) | ✅ URI-based register | Extended register |
| Part Structure | Single document | Multi-part (1-4) | Part 3 adds Geospatial Data Interpretability Index (GDII) |
B.12. DataQuality class structure
B.12.1. ISO 19157:2013 — Original structure
Listing B.9
DataQuality
├── scope: Scope [1..1]
│ ├── level: MD_ScopeCode (dataset, series, feature, etc.)
│ └── extent: EX_Extent [0..*]
│
├── report: Element [0..*] ← Concrete class, 15 specific subtypes
│ ├── CompletenessCommission
│ ├── CompletenessOmission
│ ├── ConceptualConsistency
│ ├── DomainConsistency
│ ├── FormatConsistency
│ ├── TopologicalConsistency
│ ├── AbsoluteExternalPositionalAccuracy
│ ├── RelativeInternalPositionalAccuracy
│ ├── GriddedDataPositionalAccuracy
│ ├── TemporalConsistency
│ ├── TemporalValidity
│ ├── AccuracyOfATimeMeasurement
│ ├── ThematicClassificationCorrectness
│ ├── NonQuantitativeAttributeCorrectness
│ ├── QuantitativeAttributeAccuracy
│ └── Geospatial Data Interpretability Index (GDII)Element ← Removed in 2023, reintroduced in 2026
│
└── lineage: LI_Lineage [0..*] ← Moved to ISO 19115-1:2014 in 2023
├── statement: CharacterString [0..1]
├── processStep: LI_ProcessStep [0..*]
└── source: LI_Source [0..*]
B.12.2. Characteristics
Flat hierarchy: 15 quality elements at same level
Lineage embedded: LI_Lineage part of DataQuality
No abstraction: Element is concrete class
Geospatial Data Interpretability Index (GDII) included: As 15th element (later found to be incorrect interpretation)
B.12.3. ISO 19157-1:2023 — Framework restructuring
Listing B.10
DataQuality
├── scope: Scope [1..1]
│ ├── level: MD_ScopeCode (enhanced list)
│ └── extent: EX_Extent [0..*]
│
├── report: AbstractDQ_Element [0..*] ← Abstract class, hierarchical
│ │
│ ├── Completeness (Category)
│ │ ├── commission (Subcategory)
│ │ └── omission (Subcategory)
│ │
│ ├── LogicalConsistency (Category)
│ │ ├── conceptualConsistency
│ │ ├── domainConsistency
│ │ ├── formatConsistency
│ │ └── topologicalConsistency
│ │
│ ├── PositionalAccuracy (Category)
│ │ ├── absoluteExternalPositionalAccuracy
│ │ ├── relativeInternalPositionalAccuracy
│ │ └── griddedDataPositionalAccuracy
│ │
│ ├── TemporalQuality (Category)
│ │ ├── accuracyOfATimeMeasurement
│ │ ├── temporalConsistency
│ │ └── temporalValidity
│ │
│ ├── ThematicQuality (Category)
│ │ ├── thematicClassificationCorrectness
│ │ ├── nonQuantitativeAttributeCorrectness
│ │ └── quantitativeAttributeAccuracy
│ │
│ └── Metaquality (Category - ENHANCED)
│ ├── confidence (NEW distinct subcategory)
│ ├── homogeneity (NEW distinct subcategory)
│ └── representativity (NEW distinct subcategory)
│
└── standaloneQualityReportDetails: CharacterString [0..1] ← NEW
(URL to external quality report document)
B.12.4. Lineage removed from DataQuality
Lineage is now defined in ISO 19115-1:2014:
Listing B.11
MD_Metadata
└── dataQualityInfo: MD_DataQuality [0..*]
└── lineage: LI_Lineage [0..1]
├── statement: CharacterString [0..1]
├── scope: MD_Scope [0..1]
├── processStep: LI_ProcessStep [0..*]
├── source: LI_Source [0..*]
└── additionalDocumentation: CI_Citation [0..*]
B.12.5. Characteristics
Hierarchical structure: 6 categories → subcategories → measures
Abstract base class: AbstractDQ_Element allows extension
Geospatial Data Interpretability Index (GDII) REMOVED: Confirmed by ISO experts as incorrect
Lineage separated: Moved to metadata standard (ISO 19115-1:2014)
Metaquality formalized: 3 distinct subcategories with clear semantics
External reports: standaloneQualityReportDetails for linked documentation
B.12.6. Critical changes
❌ Geospatial Data Interpretability Index (GDII)Element deleted — “did not belong in quality standard”
✅ Metaquality now handles fitness-for-purpose via confidence subcategory
✅ Conformance results are primary fitness-for-purpose mechanism
B.12.8. Standard structure
Listing B.12
ISO 19157 Multi-part Standard (2023-2026)
├── ISO 19157-1:2023 - Part 1: Framework (published)
├── ISO 19157-2:2023 - Part 2: Data quality measures (published)
├── ISO 19157-3:2026 - Part 3: Geospatial Data Interpretability Index (GDII) elements (PROPOSED) ← NEW
└── ISO 19157-4:TBD - Part 4: Domain-specific quality measures (future)
B.12.9. DataQuality extension
Listing B.13
DataQuality (from ISO 19157-1:2023)
├── scope: Scope [1..1]
├── report: AbstractDQ_Element [0..*]
│ ├── [All ISO 19157-1:2023 categories: completeness, logicalConsistency,
│ │ positionalAccuracy, temporalQuality, thematicQuality, metaquality]
│ │
│ └── Geospatial Data Interpretability Index (GDII) (Category - REINTRODUCED in Part 3) ← NEW/RESTORED
│ ├── fitnessForPurpose (Subcategory)
│ ├── accessibilityAndUsageConstraints (Subcategory)
│ ├── userExperienceAndInterfaceQuality (Subcategory - NEW)
│ └── fitnessForIntendedUse (Subcategory)
│
└── standaloneQualityReportDetails: CharacterString [0..1]
B.12.11. Geospatial Data Interpretability Index (GDII) reintroduced as optional extension
Not mandatory for ISO 19157-1:2023 compliance
Separate conformance class: “Geospatial Data Interpretability Index (GDII) Quality Extension”
Explicitly domain-specific (not universal quality requirement)
B.12.12. Clear separation from metaquality
| Metaquality (ISO 19157-1:2023) | Geospatial Data Interpretability Index (GDII) (ISO 19157-3:2026) |
|---|---|
| confidence (trust in quality data) | fitnessForPurpose (meets user needs) |
| homogeneity (consistency) | accessibility (can user access?) |
| representativity (sample coverage) | userExperience (how easy to use?) |
B.12.13. Fitness-for-purpose refinement
ISO 19157-1:2023: Use metaquality confidence + conformance results
ISO 19157-3:2026: Use Geospatial Data Interpretability Index (GDII).fitnessForPurpose when application-specific
Guidance: Prefer conformance to specifications (CEOS-ARD, INSPIRE, etc.) over subjective fitness
B.12.14. New Geospatial Data Interpretability Index (GDII) measures (Part 3 register additions)
Measure 501: Application domain suitability score
Measure 502: User requirements compliance percentage
Measure 503: API Geospatial Data Interpretability Index (GDII) rating (Nielsen heuristics)
Measure 504: Visualization quality assessment
Measure 505: Accessibility compliance (WCAG, Section 508)
B.12.15. Conformance classes
Listing B.14
ISO 19157-3:2026 Conformance Classes
├── Core Geospatial Data Interpretability Index (GDII): Geospatial Data Interpretability Index (GDII).fitnessForPurpose (mandatory if using Part 3)
├── Accessibility: Geospatial Data Interpretability Index (GDII).accessibilityAndUsageConstraints (optional)
├── User Experience: Geospatial Data Interpretability Index (GDII).userExperienceAndInterfaceQuality (optional)
└── Application Fitness: Geospatial Data Interpretability Index (GDII).fitnessForIntendedUse (optional)
B.12.16. Implementation guidance
Example 1 — Example: When to use Geospatial Data Interpretability Index (GDII) (Part 3) vs Metaquality (Part 1)
Scenario 1: Cloud coverage limits confidence in classification
Correct approach: ISO 19157-1:2023 metaquality confidence
{
"category": "metaquality",
"subcategory": "confidence",
"result": [{
"resultType": "quantitative",
"value": 0.845,
"valueUnit": "percentage clear pixels"
}]
}
Example 2
Scenario 2: Product meets CEOS-ARD Surface Reflectance specification
Correct approach: ISO 19157-1:2023 conformance result
{
"category": "completeness",
"result": [{
"resultType": "conformance",
"pass": true,
"specification": {
"title": "CEOS-ARD Surface Reflectance v5.0.1",
"date": "2021-06-15"
}
}]
}
Example 3
Scenario 3: Dataset specifically designed for precision agriculture
Correct approach: ISO 19157-3:2026 Geospatial Data Interpretability Index (GDII) fitnessForPurpose
{
"category": "Geospatial Data Interpretability Index (GDII)",
"subcategory": "fitnessForPurpose",
"measure": {
"nameOfMeasure": ["Suitability for precision agriculture"],
"measureIdentifier": "https://def.isotc211.org/dataqualitymeasures/501"
},
"result": [{
"resultType": "conformance",
"pass": true,
"specification": {
"title": "Precision Agriculture Data Requirements v2.1",
"date": "2025-03-01"
},
"explanation": "10m spatial resolution, 5-day revisit, NDVI accuracy ±0.02 meets precision agriculture requirements"
}]
}
B.13. Comparative analysis
B.13.1. Quality categories evolution
| Category | ISO 19157:2013 | ISO 19157-1:2023 | ISO 19157-3:2026 |
|---|---|---|---|
| Completeness | 2 elements (commission, omission) | ✅ Category with 2 subcategories | Same as 2023 |
| Logical Consistency | 4 elements | ✅ Category with 4 subcategories | Same as 2023 |
| Positional Accuracy | 3 elements | ✅ Category with 3 subcategories | Same as 2023 |
| Temporal Quality | 3 elements | ✅ Category with 3 subcategories | Same as 2023 |
| Thematic Quality | 3 elements | ✅ Category with 3 subcategories | Same as 2023 |
| Metaquality | 1 element (poorly defined) | ✅ Category with 3 formalized subcategories | Same as 2023 |
| Geospatial Data Interpretability Index (GDII) | 1 element (15th element) | ❌ Removed (“did not belong”) | ✅ Reintroduced as optional Part 3 |
| Total | 15 flat elements | 6 hierarchical categories | 7 categories (6 core + 1 optional) |
B.13.2. Fitness-for-purpose assessment
| Version | Mechanism | Example |
|---|---|---|
| ISO 19157:2013 | Geospatial Data Interpretability Index (GDII)Element with descriptive result | “Suitable for 1:50,000 mapping” (unstructured) |
| ISO 19157-1:2023 | Metaquality.confidence + ConformanceResult | Conformance to CEOS-ARD spec (structured) |
| ISO 19157-3:2026 | Geospatial Data Interpretability Index (GDII).fitnessForPurpose + conformance | Conformance to application-specific requirements |
NOTE: Evolution: From unstructured Geospatial Data Interpretability Index (GDII) statements → structured conformance → domain-specific fitness | ||
B.13.3. Lineage location
| Version | Lineage Location | Rationale |
|---|---|---|
| ISO 19157:2013 | Inside DataQuality.lineage | Lineage seen as quality aspect |
| ISO 19157-1:2023 | Moved to MD_Metadata (ISO 19115-1:2014) | Lineage is metadata, not quality measure |
| ISO 19157-3:2026 | Remains in ISO 19115-1:2014 | No change — separation maintained |
IMPORTANT
Lineage and quality are now cleanly separated. STAC Extension correctly implements this as separate dq:lineage and dq:quality fields.
B.13.4. Result types evolution
| Result Type | 2013 | 2023 | 2026 |
|---|---|---|---|
| ConformanceResult | ✅ Basic (pass/fail) | ✅ Enhanced (specification citation) | ✅ Same + domain specs |
| QuantitativeResult | ✅ Value + unit | ✅ Value + UOM + record type | ✅ Same |
| DescriptiveResult | ✅ Text statement | ✅ Structured statement | ✅ Same |
| CoverageResult | ❌ Not available | ✅ New (raster quality masks) | ✅ Same |
B.13.5. Measure registration system
| Version | Measure Identifier | Registry Type | Example |
|---|---|---|---|
| ISO 19157:2013 | Informal reference | Annex D (static list) | “Measure 28” (no URI) |
| ISO 19157-1:2023 | URI-based | Dynamic register | https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/28 |
| ISO 19157-3:2026 | URI-based (extended) | Dynamic + Part 3 measures | https://def.isotc211.org/dataqualitymeasures/501 (permanent URI) |
B.13.6. Permanent URI (effective April 2026)
Core measures (1-XXX): https://def.isotc211.org/dataqualitymeasures/{id}
Geospatial Data Interpretability Index (GDII) measures (501-5XX): https://def.isotc211.org/Geospatial Data Interpretability Index (GDII)Measures/{id}
B.15. ISO 19157:2013 → ISO 19157-1:2023
B.15.1. Breaking changes
❌ Remove Geospatial Data Interpretability Index (GDII)Element usage
✅ Migrate to Metaquality.confidence or conformance results
✅ Move lineage to separate field (outside DataQuality)
✅ Update measure identifiers to URIs
B.15.2. Example migration
Listing B.15 — ISO 19157:2013 (DEPRECATED)
{
"dataQuality": {
"scope": { "level": "dataset" },
"report": [
{
"element": "Geospatial Data Interpretability Index (GDII)",
"nameOfMeasure": ["Fitness for urban planning"],
"result": {
"type": "descriptive",
"statement": "Suitable for 1:10,000 urban planning applications"
}
}
],
"lineage": {
"statement": "Derived from Sentinel-2 Level-2A"
}
}
}
Listing B.16 — ISO 19157-1:2023 (CURRENT)
{
"dq:quality": [
{
"scope": { "level": "dataset" },
"report": [
{
"category": "completeness",
"measure": {
"nameOfMeasure": ["Fitness for urban planning"],
"measureIdentifier": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/7"
},
"result": {
"resultType": "conformance",
"pass": true,
"specification": {
"title": "Urban Planning Data Specification v3.2",
"date": "2024-01-15"
},
"explanation": "Positional accuracy ≤5m, completeness ≥95% meets urban planning requirements for 1:10,000 scale"
}
}
]
}
],
"dq:lineage": [
{
"type": "lineage",
"statement": "Derived from Sentinel-2 Level-2A",
"processStep": []
}
]
}
B.16. ISO 19157-1:2023 → ISO 19157-3:2026 (optional upgrade)
B.16.1. When to adopt ISO 19157-3:2026
✅ Your data serves specific application domains (agriculture, urban planning, emergency response)
✅ You need to document API Geospatial Data Interpretability Index (GDII) or user experience metrics
✅ You want to report accessibility compliance (WCAG, Section 508)
❌ General-purpose datasets (use ISO 19157-1:2023 conformance instead)
B.16.2. Example: Adding Geospatial Data Interpretability Index (GDII) (Part 3)
Listing B.17
{
"dq:quality": [
{
"scope": { "level": "dataset" },
"report": [
{
"$comment": "ISO 19157-1:2023 - Core quality (always include)",
"category": "positionalAccuracy",
"subcategory": "absoluteExternalPositionalAccuracy",
"measure": {
"nameOfMeasure": ["Mean positional uncertainty"],
"measureIdentifier": "https://def.isotc211.org/dataqualitymeasures/28"
},
"result": {
"resultType": "quantitative",
"value": 2.3,
"valueUnit": "meters",
"valueRecordType": "Real"
}
},
{
"$comment": "ISO 19157-3:2026 - Geospatial Data Interpretability Index (GDII) extension (optional)",
"category": "Geospatial Data Interpretability Index (GDII)",
"subcategory": "fitnessForPurpose",
"stac_extensions": [
"https://def.isotc211.org/iso19157-3/v1.0.0/schema.json"
],
"measure": {
"nameOfMeasure": ["Suitability for precision agriculture"],
"measureIdentifier": "https://def.isotc211.org/Geospatial Data Interpretability Index (GDII)Measures/501"
},
"result": {
"resultType": "conformance",
"pass": true,
"specification": {
"title": "Precision Agriculture Data Requirements - ASABE S612.1",
"date": "2024-11-01",
"url": "https://elibrary.asabe.org/abstract.asp?aid=53684"
}
}
}
]
}
]
}
B.17. Impact on STAC Extension Liability Claims
B.17.1. Current implementation (ISO 19157-1:2023)
Status: ✅ COMPLIANT
The STAC Extension Liability Claims correctly implements ISO 19157-1:2023:
✅ Geospatial Data Interpretability Index (GDII) removed from v1.3.0, v1.4.0, v1.5.0
✅ Lineage separated via dq:lineage field (ISO 19115-1:2014)
✅ Extended lineage via dq:extendedLineage field (ISO 19115-2:2019)
✅ Metaquality confidence recommended for fitness assessments
✅ Conformance results for specification compliance
B.18. ISO 19157-3:2026 adoption considerations
B.18.1. Arguments for adoption
✅ Remote sensing imagery has specific application fitness requirements
✅ NIIRS ratings (already in v1.5.0) align with Geospatial Data Interpretability Index (GDII) assessment
✅ Users need to document fitness for emergency response, agriculture, urban planning
✅ Optional conformance class maintains backward compatibility
B.18.2. Arguments against adoption
❌ ISO 19157-3:2026 is not yet published (still in draft/proposal stage)
❌ ISO 19157-1:2023 conformance + metaquality already sufficient
❌ Adds complexity — users may misuse Geospatial Data Interpretability Index (GDII) instead of conformance
❌ Migration guide just removed Geospatial Data Interpretability Index (GDII); reintroducing may confuse users
B.18.3. Recommendations
WAIT until ISO 19157-3:2026 is officially published, then:
Monitor adoption by OGC, CEOS, ESA, NASA
Add as optional extension (new conformance class)
Provide clear guidance on when to use Geospatial Data Interpretability Index (GDII) vs metaquality
Version as v1.6.0 or v2.0.0 with ISO 19157-3:2026 support
B.18.4. For current users (ISO 19157-1:2023)
✅ Continue using metaquality confidence for fitness limitations (cloud coverage, sensor quality)
✅ Continue using conformance results for specification compliance (CEOS-ARD, INSPIRE)
✅ Keep lineage separated in dq:lineage field
✅ Use extended lineage (dq:extendedLineage) for detailed algorithm documentation
❌ Do NOT reintroduce Geospatial Data Interpretability Index (GDII) until ISO 19157-3:2026 is published
B.18.5. For future planning (ISO 19157-3:2026)
📅 Monitor ISO TC211 publication schedule for ISO 19157-3:2026 release
📋 Evaluate community adoption by OGC, CEOS, Copernicus before implementation
🔍 Assess user demand for domain-specific fitness assessments
⚠️ Provide clear migration guidance to avoid confusion with removed Geospatial Data Interpretability Index (GDII) from v1.3.0-v1.5.0
🧪 Create testbed examples demonstrating correct Geospatial Data Interpretability Index (GDII) vs metaquality usage
B.19. ISO 19115 Family vs ISO 19157 vs STAC Liability & Claims Extension — Comprehensive Comparison
B.19.1. 1. Standards Overview
| Standard | Series | Full Title | Primary Role | Current Status |
|---|---|---|---|---|
| ISO 19115-1 | ISO 19115 | Geographic information — Metadata — Part 1: Fundamentals | Core metadata model for geographic resources | Published (2014, Amd.1:2018) |
| ISO 19115-2 | ISO 19115 | Geographic information — Metadata — Part 2: Extensions for acquisition and processing | Metadata extensions for imagery and gridded data acquisition | Published (2019) |
| ISO 19115-3 | ISO 19115 | Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts | XML encoding of ISO 19115-1/2 | Published (2016) |
| ISO 19115-4 | ISO 19115 | Geographic information — Metadata — Part 4: Imagery and gridded data | Imagery-specific metadata quality elements | Published |
| ISO 19157-1 | ISO 19157 | Geographic information — Data quality — Part 1: General requirements | Data quality framework and principles | Published (2023 revision) |
| ISO 19157-3 | ISO 19157 | Geographic information — Data quality — Part 3: Data quality measures register | Standardized quality measures catalog with unique numeric codes | Expected April 2026 |
| STAC Liability & Claims | STAC Extensions | STAC Extension for Liability Claims, Data Quality, Provenance, and Data Space fields | JSON-based STAC encoding of claims, quality, provenance, and ISO 20151 data sovereignty | v1.6.0 (April 2026) |
B.19.2. 2. Conceptual Scope Comparison
| Concept Domain | ISO 19115 Family | ISO 19157 | STAC Liability & Claims |
|---|---|---|---|
| Metadata model | ✅ Core focus (ISO 19115-1) | ❌ Out of scope | ⚠️ Subset via liability:* fields |
| Data quality reporting | ⚠️ Via dataQualityInfo element (references ISO 19157) | ✅ Core focus | ✅ Via liability:quality → ISO 19157 DataQuality |
| Quality measures registry | ❌ No standardized codes | ✅ Core focus in ISO 19157-3 (numeric codes) | ✅ References ISO 19157-3 measure codes |
| Imagery acquisition metadata | ✅ ISO 19115-2 / ISO 19115-4 | ❌ Out of scope | ⚠️ NIIRS via liability:niirs |
| Lineage & provenance | ✅ LI_Lineage in ISO 19115-1 | ✅ DataQuality.lineage | ✅ W3C PROV-JSON via liability:prov + ISO 19115 LI_Source |
| Legal/liability claims | ❌ Not addressed | ❌ Not addressed | ✅ Core focus (liability:claim_*, liability:responsible_party) |
| Insurance & financial damages | ❌ Not addressed | ❌ Not addressed | ✅ liability:damages_estimated, liability:insurance_provider |
| Data sovereignty / data spaces | ❌ Not addressed | ❌ Not addressed | ✅ ISO 20151 fields (usage policy, data contracts) |
| XML encoding | ✅ ISO 19115-3 (XML/XSD) | ✅ XML (mdq: namespace) | ✅ JSON-LD / JSON Schema (STAC-native) |
| JSON Schema | ⚠️ ISO TC211 provides JSON schemas | ⚠️ via eovoc/dqc.json | ✅ Native JSON Schema Draft-07 |
| Semantic uplift / RDF | ❌ Limited | ❌ Limited | ✅ context.jsonld with CEOS-ARD and ISO 19157-3 ontology namespaces |
| NIIRS interpretability | ❌ Not addressed | ❌ Not addressed | ✅ liability:niirs (NIIRS 0–9 per sensor type) |
| Fitness for purpose | ⚠️ Informal in ISO 19115 | ❌ Geospatial Data Interpretability Index (GDII) category removed in ISO 19157-1:2023 | ✅ dq:quality descriptive results |
| Metaquality | ❌ Not addressed | ✅ ISO 19157-1:2023 (confidence, representativity, homogeneity) | ✅ Supported in liability:quality |
B.19.3. 3. Structural Architecture
B.19.3.1. ISO 19115 Family — Metadata-Centric Architecture
Listing B.18
MD_Metadata (ISO 19115-1)
├── identificationInfo → Resource description, keywords, spatial extent
├── contentInfo → ISO 19115-2/4: Sensor, bands, acquisition parameters
├── dataQualityInfo → Integration point: contains DataQuality (ISO 19157)
├── resourceLineage → LI_Lineage (source data, process steps)
├── metadataScope → Scope level (dataset, series, tile, feature)
└── contact / dateInfo / ... → Administrative metadata
B.19.3.2. ISO 19157 — Quality-Centric Architecture
Listing B.19
DataQuality (ISO 19157-1)
├── scope → MD_Scope (level: dataset, series, feature, attribute...)
├── report[] → Array of Element subclasses:
│ ├── CompletenessOmission / CompletenessCommission
│ ├── AbsoluteExternalPositionalAccuracy
│ ├── ThematicClassificationCorrectness
│ ├── QuantitativeAttributeAccuracy
│ ├── ConceptualConsistency / DomainConsistency / ...
│ └── Metaquality (confidence, representativity, homogeneity)
│ ├── measureIdentification → ISO 19157-3 numeric code (e.g., Measure 28, 47, 129)
│ ├── evaluationMethod → directInternal | directExternal | indirect
│ └── result[] → QuantitativeResult | ConformanceResult | DescriptiveResult
└── lineage → LI_Lineage reference
B.19.3.3. STAC Liability & Claims — STAC-Native JSON Architecture
Listing B.20
STAC Item / Collection
└── properties
├── liability:responsible_party → Responsible party identifier
├── liability:claim_id → Unique claim identifier
├── liability:claim_status → pending | accepted | settled | closed | ...
├── liability:claim_type → environmental | property_damage | financial | ...
├── liability:claim_date → RFC 3339 datetime
├── liability:incident_date → RFC 3339 datetime
├── liability:resolution_date → RFC 3339 datetime
├── liability:resolution_status → in_favor | against | partial_settlement | ...
├── liability:coverage_area → GeoJSON geometry
├── liability:affected_parties[] → name, role, contact
├── liability:damages_estimated → Numeric (minimum: 0)
├── liability:damages_currency → ISO 4217 code (USD, EUR, ...)
├── liability:legal_jurisdiction → Legal jurisdiction string
├── liability:insurance_provider → Insurance entity name
├── liability:policy_number → Policy identifier
├── liability:evidence_refs[] → URI list (supporting materials)
├── liability:origin → Source organization
├── liability:notes → Free text
├── liability:quality → ISO 19157 DataQuality (via eovoc dqc.json)
│ OR ISO 19115 quality report (backward compat.)
├── liability:prov → W3C PROV-JSON (entities, activities, agents)
├── liability:niirs → NIIRS (overall + per-sensor variants)
├── dq:quality → Standalone DataQuality (ISO 19157-1)
├── dq:lineage → Standalone LI_Lineage (ISO 19115)
├── dq:extendedLineage → Extended LE_ProcessStep lineage
└── ard:* → Flattened ARD queryable fields (CQL2-compatible)
├── ard:geometric_accuracy → Copies AbsoluteExternalPositionalAccuracy value
├── ard:radiometric_accuracy → Copies QuantitativeAttributeAccuracy value
├── ard:cloud_coverage → Cloud coverage % (optical)
├── ard:data_mask_coverage → Data mask % (radar)
└── ard:specification_compliance → CEOS-ARD PFS compliance status
B.19.4. 4. Quality Category Mapping
| ISO 19115-1 Element | ISO 19115-4 Element | ISO 19157-1 Category | ISO 19157-3 Measure Codes | STAC Liability Field | Notes |
|---|---|---|---|---|---|
| completeness | completeness | completeness.omission / completeness.commission | 3 (rate of missing items), 4 (rate of excess items), 6 (# missing items) | liability:quality.report[].category: "completeness" | Direct mapping; ISO 19157 adds subcategories |
| logicalConsistency | logicalConsistency | logicalConsistency.conceptual / .domain / .format / .topological | 7–15 (various consistency measures) | liability:quality.report[].category: "logicalConsistency" | ISO 19157 splits into 4 subcategories |
| positionalAccuracy | positionalAccuracy | positionalAccuracy.absoluteExternal / .relativeInternal / .gridded | 28 (mean positional uncertainty), 47 (RMSE), 48 (CEP), 50 (LEP) | liability:quality.report[].category: "positionalAccuracy" + ard:geometric_accuracy | RMSE preferred; ISO 19157-3 adds gridded accuracy |
| thematicAccuracy | thematicAccuracy | thematicQuality.classification / .quantitative / .nonquantitative | 60–67 (attribute accuracy), 117 (value domain conformance) | liability:quality.report[].category: "thematicQuality" + ard:radiometric_accuracy | Renamed in ISO 19157 |
| temporalAccuracy | temporalAccuracy | temporalQuality.accuracy / .consistency / .validity | 68–72 (temporal accuracy measures) | liability:quality.report[].category: "temporalQuality" | ISO 19157 adds temporal consistency and validity |
| attributeAccuracy | — | Merged into thematicQuality | 60–67 | liability:quality.report[].category: "thematicQuality" | Subcategory of thematic quality |
| topologicalConsistency | — | logicalConsistency.topological | 13–15 | liability:quality.report[].category: "logicalConsistency" | Subcategory of logical consistency |
| lineage | lineage | lineage (LI_Lineage reference) | — | liability:prov + dq:lineage | PROV-JSON enriches ISO lineage |
| — | radiometricAccuracy (19115-4) | thematicQuality.quantitativeAttributeAccuracy | 60, 63 | ard:radiometric_accuracy | No direct ISO 19157 category; maps to thematic quality |
| — | sensorQuality (19115-4) | metaquality.confidence | 129 (confidence in DQ result) | liability:quality.report[].category: "metaquality" | Maps calibration status to metaquality confidence |
| — | cloudCoverage (19115-4) | metaquality.confidence (descriptive) | — | ard:cloud_coverage | No standardized ISO 19157-3 measure; use descriptive result |
| — | snowCoverage (19115-4) | metaquality.confidence (descriptive) | — | No direct field — descriptive result | No standardized ISO 19157-3 measure |
| — | processingLevel (19115-4) | lineage.processStep | — | dq:extendedLineage.processStep[] | Document as LE_ProcessStep in lineage |
| — | Geospatial Data Interpretability Index (GDII)Assessment (19115-4) | ❌ Removed in ISO 19157-1:2023 | — | liability:quality.result[].resultType: "descriptive" | Use descriptive result for fitness-for-purpose |
| — | — | metaquality (NEW in ISO 19157-1:2023) | 128–132 | liability:quality.report[].category: "metaquality" | No ISO 19115 equivalent; high value for geospatial claims |
| — | — | — | — | liability:niirs | NIIRS interpretability — no ISO standard equivalent |
B.19.5. 5. Lineage and Provenance Comparison
| Aspect | ISO 19115-1 LI_Lineage | ISO 19157-1 Lineage | STAC Liability liability:prov | STAC dq:lineage |
|---|---|---|---|---|
| Model | ISO 19115-1 metadata model | References ISO 19115 LI_Lineage | W3C PROV-DM (entities, activities, agents) | ISO 19115-1 LI_Lineage (JSON encoding) |
| Process steps | LI_ProcessStep | LI_ProcessStep reference | prov:Activity with time intervals | LE_ProcessStep (ISO 19115-2) |
| Source data | LI_Source | LI_Source reference | prov:Entity with derivation relations | LI_Source (ISO 19115-2 via mdj.json) |
| Agents/actors | CI_ResponsibleParty | CI_ResponsibleParty | prov:Agent with prov:actedOnBehalfOf | CI_ResponsibleParty via CI_Citation |
| Granularity | Medium (process steps, sources) | Medium (references 19115) | High (entity-activity-agent graph) | High (LE_ProcessStep with CI_Date) |
| Interoperability | XML/XSD only | XML + JSON (TC211) | W3C PROV-JSON (universal) | JSON-LD via STAC |
| Traceability | Dataset-level to source | Dataset-level | Item-level, fine-grained graph | Item-level, hierarchical |
| Legal admissibility | ❌ Not designed for legal use | ❌ Not designed for legal use | ⚠️ Partial (agent/activity trails) | ❌ Not designed for legal use |
| Claim evidence support | ❌ | ❌ | ✅ prov:wasDerivedFrom, prov:wasGeneratedBy | ❌ |
| Blockchain / distributed | ❌ | ❌ | ✅ Compatible with anchoring | ❌ |
B.19.6. 6. Evaluation Method Comparison
| Method Type | ISO 19115-1 | ISO 19157-1 | STAC Liability Encoding |
|---|---|---|---|
| Direct internal | Generic description | evaluationMethodType: "directInternal" | evaluationMethod.evaluationMethodType: "directInternal" in Element |
| Direct external | Generic description | evaluationMethodType: "directExternal" | evaluationMethod.evaluationMethodType: "directExternal" |
| Indirect | Generic description | evaluationMethodType: "indirect" | evaluationMethod.evaluationMethodType: "indirect" |
| Evaluation procedure citation | LI_ProcessStep.description | evaluationProcedure: CI_Citation | Full CI_Citation with responsible parties, identifiers, URLs |
| Evaluation date | LI_ProcessStep.dateTime | evaluationMethod.dateTime | evaluationMethod.dateTime (RFC 3339) |
| Measure identification | ❌ No standardized codes | ✅ ISO 19157-3 numeric codes (e.g., “28”) | measureIdentification.code + codeSpace: "ISO 19157" |
B.19.7. 7. Result Types Comparison
| Result Type | ISO 19115-1 | ISO 19157-1 | STAC Liability Encoding |
|---|---|---|---|
| Quantitative value | Simple number + unit | QuantitativeResult with value[], valueUnit | resultType: "quantitative" + value: [number] (array since v1.3.0) |
| Multi-value (per band) | ❌ Single value only | ✅ Array of values | value: [v1, v2, v3] (v1.3.0+ breaking change from scalar) |
| Conformance (pass/fail) | Pass/fail description | ConformanceResult with pass, specification | resultType: "conformance" + pass: true/false + specification: CI_Citation |
| Descriptive statement | Free text description | DescriptiveResult with statement | resultType: "descriptive" + statement: "..." |
| Coverage result | ❌ Not supported | CoverageResult | ⚠️ Partial support |
| Error statistic | ❌ Not formalized | errorStatistic field | errorStatistic: "RMSE" / "CEP" / etc. |
B.19.8. 8. Legal and Claims Domains
NOTE: This is the unique differentiator of the STAC Liability & Claims Extension — ISO standards do not address these concepts at all.
| Concept | ISO 19115 | ISO 19157 | STAC Liability & Claims |
|---|---|---|---|
| Responsible party for claim | CI_ResponsibleParty (metadata contact only) | ❌ | liability:responsible_party |
| Claim status lifecycle | ❌ | ❌ | liability:claim_status: pending → settled → closed |
| Claim type classification | ❌ | ❌ | liability:claim_type: environmental, property_damage, personal_injury, financial, operational |
| Affected parties | ❌ | ❌ | liability:affected_parties[] (name, role, contact) |
| Financial damages | ❌ | ❌ | liability:damages_estimated + liability:damages_currency (ISO 4217) |
| Insurance coverage | ❌ | ❌ | liability:insurance_provider + liability:policy_number |
| Legal jurisdiction | ❌ | ❌ | liability:legal_jurisdiction |
| Incident vs. claim date | ❌ | ❌ | liability:incident_date vs liability:claim_date |
| Resolution outcome | ❌ | ❌ | liability:resolution_status: in_favor, against, partial_settlement, dismissed, withdrawn |
| Evidence references | ❌ | ❌ | liability:evidence_refs[] (URI list to documents, images, STAC assets) |
| Geographic claim area | ❌ | ❌ | liability:coverage_area (GeoJSON geometry) |
| Data sovereignty | ❌ | ❌ | ISO 20151 fields (usage policy, data contracts, sovereignty constraints) |
B.19.9. 9. Data Space and Sovereignty (ISO 20151)
NOTE: The STAC Liability & Claims Extension v1.5.0+ incorporates ISO 20151 data space interoperability fields. Neither ISO 19115 nor ISO 19157 address this domain.
| Concept | ISO 19115 | ISO 19157 | STAC Liability & Claims |
|---|---|---|---|
| Usage policy | ⚠️ Partial (MD_Constraints) | ❌ | ✅ ISO 20151 usage policy fields |
| Data contracts | ❌ | ❌ | ✅ Data contract references |
| Sovereignty constraints | ❌ | ❌ | ✅ Data sovereignty encoding |
| Access control | ⚠️ MD_SecurityConstraints | ❌ | ✅ Integrated with claims status |
B.19.10. 10. Encoding and Interoperability
| Characteristic | ISO 19115-3 (XML) | ISO 19157 (XML/JSON) | STAC Liability & Claims (JSON) |
|---|---|---|---|
| Primary encoding | XML Schema (XSD) | XML + JSON (ISO TC211) | JSON Schema Draft-07 |
| Namespace | mdb:, mdq:, mrl: | mdq:, mdq:DQ_* | liability:, dq:, ard: |
| Schema location | ISO TC211 XSD repository | TC211 + eovoc canonical | luciocola.github.io/stac-extension-liability-claims/vX.Y.Z/schema.json |
| JSON-LD context | ❌ Limited | ❌ Limited | ✅ context.jsonld with CEOS-ARD + ISO 19157-3 ontologies |
| Semantic web (RDF) | ❌ | ❌ | ✅ ard:* mapped to ISO 19157-3 and CEOS-ARD ontology concepts |
| OGC API compliance | ⚠️ Via OGC Metadata API | ⚠️ Via OGC Features API | ✅ STAC API + CQL2 queryable ard:* fields |
| STAC Item/Collection | ❌ | ❌ | ✅ Native |
| W3C PROV | ❌ | ❌ | ✅ liability:prov (PROV-JSON model) |
| Backward compatibility | ✅ ISO 19115-1 → 19115-3 | ✅ ISO 19157-1:2013 → 2023 | ✅ v1.1.0 items valid in v1.6.0 |
| Validation tooling | XML validators (Saxon, Schematron) | XML/JSON validators | Python (validate.py), JSON Schema validators |
B.19.11. 11. Quality Framework Integration in STAC
The STAC Liability & Claims Extension integrates ISO 19157 quality into STAC through three complementary paths.
B.19.11.1. Path A — Full ISO 19157 Quality (Recommended, v1.3.0+)
Listing B.21
{
"liability:quality": {
"scope": { "level": "dataset" },
"report": [{
"type": "AbsolutePositionalAccuracy",
"category": "positionalAccuracy",
"measure": {
"measureIdentification": { "code": "47", "codeSpace": "ISO 19157", "version": "2023" },
"nameOfMeasure": ["Root mean square error"]
},
"evaluationMethod": {
"evaluationMethodType": "directExternal",
"dateTime": "2026-03-15T12:00:00Z"
},
"result": [{ "resultType": "quantitative", "value": [8.5], "valueUnit": "meter", "errorStatistic": "RMSE" }]
}]
}
}
References canonical eovoc dqc.json (ISO 19157).
B.19.11.2. Path B — ISO 19115 Quality (Backward Compatibility)
Listing B.22
{
"liability:quality": {
"type": "iso19115_quality_report",
"qualityElements": [...]
}
}
References local iso19115-quality.json (deprecated from v2.0.0).
B.19.11.3. Path C — ARD Flattened Fields (CQL2 Queryable)
Listing B.23
{
"ard:geometric_accuracy": 8.5,
"ard:geometric_accuracy_unit": "meter",
"ard:geometric_accuracy_type": "RMSE",
"ard:cloud_coverage": 12.3,
"ard:specification_compliance": "CEOS-ARD NRB v1.2"
}
Enables CQL2 queries such as: ard:geometric_accuracy <= 10 AND ard:cloud_coverage < 20
B.19.12. 12. Standards Evolution Timeline
Listing B.24
ISO 19115-1:2014 ──────────────────────────────────────────────── Core metadata model
ISO 19115-2:2019 ──────────────────────────────────────────────── Imagery acquisition
ISO 19115-3:2016 ──────────────────────────────────────────────── XML implementation
ISO 19115-4 ──────────────────────────────────────────────── Imagery quality metadata
ISO 19157-1:2013 ──► ISO 19157-1:2023 (revised) ──────────────── DQ framework
ISO 19157-3:2026 (expected April 2026) ────────────────────────── Measures register
STAC Liability & Claims Extension:
v1.1.0 (2025) ─ Core claims + ISO 19157 quality + W3C PROV
v1.2.0 (Feb 2026) ─ ISO TC211 alignment + ARD queryable fields + semantic uplift
v1.3.0 (Feb 2026) ─ Canonical eovoc schemas + MD_Scope objects + CI_Citation
v1.4.0 (Feb 2026) ─ EOVOC v0.0.2 alignment + CI_Date in LE_ProcessStep
v1.5.0 (2026) ─ ISO 20151 data space interoperability
v1.6.0 (Apr 2026) ─ Current (NIIRS + full schema consolidation)
B.19.13. 13. Decision Guide — Which Standard to Use When
| Requirement | Recommended Standard |
|---|---|
| Archive geospatial metadata for cataloguing | ISO 19115-1 + ISO 19115-3 (XML) |
| Document imagery acquisition parameters (sensor, bands, orbit) | ISO 19115-2 / ISO 19115-4 |
| Report standardized data quality with numeric measure codes | ISO 19157-1 + ISO 19157-3 measures |
| Publish geospatial data on the web with quality filters | STAC Liability & Claims (ard:* + liability:quality) |
| Track legal/insurance claims related to geospatial events | STAC Liability & Claims (liability:claim_*) |
| Document data provenance for legal/audit purposes | STAC liability:prov (W3C PROV-JSON) |
| Query imagery by positional accuracy or cloud coverage | STAC ard:geometric_accuracy, ard:cloud_coverage |
| Assess imagery interpretability (NIIRS) | STAC liability:niirs |
| Encode data contracts and sovereignty constraints | STAC liability:* (ISO 20151 fields) |
| Cross-validate against official ISO TC211 tooling | liability:quality → eovoc canonical dqc.json |
B.19.14. 14. Key Gaps and Bridging Strategies
| Gap | Upstream Standards | STAC Liability & Claims Solution |
|---|---|---|
| ISO 19115 imagery elements (cloudCoverage, snowCoverage) have no ISO 19157-3 measure codes | ISO 19115-4 ↔ ISO 19157-3 | Use metaquality.confidence with descriptive result + ard:cloud_coverage queryable field |
| ISO 19157-1:2023 removed Geospatial Data Interpretability Index (GDII) category | ISO 19115 Geospatial Data Interpretability Index (GDII)Assessment | Use descriptive result with fitness-for-purpose statement |
| No legal/claims domain in either ISO 19115 or ISO 19157 | Both ISO families | Full liability:claim_* fields + liability:evidence_refs + liability:coverage_area |
| No standardized NIIRS encoding in any ISO standard | Both ISO families | liability:niirs with per-sensor type variants (visible, radar, infrared, MSI, SAR) |
| XML-first ISO standards poorly suited for REST APIs | ISO 19115-3, ISO 19157 | STAC JSON + CQL2-queryable ard:* fields |
| No W3C PROV link from ISO quality reports | ISO 19115 lineage | liability:prov PROV-JSON complementing dq:lineage |
| Data space/sovereignty not covered by ISO TC211 | Both ISO families | ISO 20151 fields in v1.5.0+ |
B.19.14.1. Bibliography
[1] International Organization for Standardization (committee): ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/53798.html.
[2] International Organization for Standardization (committee): ISO 19115-2:2019, Geographic information — Metadata — Part 2: Extensions for acquisition and processing. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/67039.html.
[3] International Organization for Standardization (committee): ISO 19157:2013, Geographic information — Data quality. International Organization for Standardization, Geneva (2013). https://www.iso.org/standard/32575.html.
[4] International Organization for Standardization (committee): ISO 19157-1:2023, Geographic information — Data quality — Part 1: General requirements. International Organization for Standardization, Geneva (2023). https://www.iso.org/standard/78900.html.
[5] ISO: ISO 19157-2:2023, Geographic information — Data quality — Part 2: Data quality measures. ISO (2023).
[6] ISO: ISO 19157-3:2026, Geographic information — Data quality — Part 3: Geospatial Data Interpretability Index (GDII) elements (PROPOSED — Not yet published). ISO (2026).
B.19.14.2. Measure registers
Current: https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/
Permanent (April 2026): https://def.isotc211.org/dataqualitymeasures/
Geospatial Data Interpretability Index (GDII) measures (proposed): https://def.isotc211.org/Geospatial Data Interpretability Index (GDII)Measures/
Annex C
(informative)
Semantic lifting
C.1. Overview
This annex summarizes semantic lifting: transforming data from syntactic or application-specific formats into semantically annotated, machine-interpretable representations aligned with global vocabularies and knowledge models such as RDF and Linked Data. For the Data Quality for Integrity, Provenance, and Trust (DQ4IPT) work documented in this Report, that capability matters because quality metadata, provenance, and trust assertions increasingly travel as JSON alongside STAC and OGC API payloads—yet trust and interoperability require those payloads to mean the same thing to catalogues, validators, and policy engines across organizations. Semantic lifting is the bridge from application-specific JSON to shared IRIs, registered definitions (including ISO 19157 quality measures registered in OGC RAINBOW), and graph-friendly representations compatible with W3C PROV and semantic validation. The annex describes JSON-LD context annotation, optional pre- and post-processing, deterministic RDF generation, and the role of the OGC Naming Authority tooling that supports published vocabularies and registers.
Semantic lifting is the process of transforming data from syntactic or application-specific formats into semantically annotated, machine-interpretable representations aligned with global vocabularies and knowledge models such as RDF and Linked Data.
Within the OGC ecosystem, semantic lifting enables geospatial and related datasets, commonly expressed in JSON, XML, or other structured formats, to transition into semantically grounded graph representations that support interoperability, validation, reasoning, and cross-domain integration.
C.2. Relevance to DQ4IPT
The DQ4IPT activity in Testbed-21 ties data quality to integrity, provenance, and trust in Earth Observation (EO) services. That problem is not only syntactic—whether a document is valid JSON—but semantic: different systems must agree on what a quality result, measure reference, or lineage link denotes, and must be able to combine those facts with PROV, catalogues, and machine-learning pipelines without hand-coded one-off mappings.
Semantic lifting supports this Report’s goals in several concrete ways:
Registered quality semantics — Deliverables reference ISO 19157 quality reporting and definitions associated with OGC RAINBOW. Lifting connects instance data to stable IRIs and registers, so “the same” measure or scope is not reinvented per API or per project.
JSON-first EO metadata — ISO 19115-4-oriented JSON, STAC Items, and API responses are the exchange surface for D101/D102 and the conversion library (D103). Semantic lifting explains how those encodings can be annotated so they remain aligned with ISO and W3C models when taken beyond a single vendor’s parser.
STAC and API metadata — DQ4IPT implementations surface quality and IPT-related fields in STAC Items and OGC API JSON. When those payloads are annotated with JSON-LD semantics, the same quality report can be validated, linked to PROV, and checked against registers without ad hoc field interpretation.
Provenance and trust tooling — W3C PROV and semantic policies (for example SHACL) expect graphs with explicit identities and relationships. Lifting is what makes JSON-embedded quality and lineage participate in that ecosystem instead of staying trapped in siloed structures.
Conversion and meta-quality — The report stresses interoperability among ISO 19157, ISO 19115, NASA UMM, and TrainingDML-AI. Lifting does not replace those conversions, but it clarifies how target models can be published with machine-readable semantics so conversions and “metaquality” checks are auditable and repeatable.
In short, semantic lifting is part of the infrastructure story for trustworthy, machine-actionable data quality metadata in IPT—not an optional academic step, but a practical way to keep JSON-centric APIs and graph-centric trust machinery aligned.
For DQ4IPT-style pipelines, semantic lifting is achieved primarily through:
Semantic annotation of schemas using JSON-LD contexts (so ISO 19115-4 / ISO 19157 quality structures and identifiers have stable IRIs)
Optional transformation steps before and after lifting (for example normalizing STAC or API JSON before uplift, or reshaping RDF afterward for catalogues)
Deterministic generation of RDF graphs from JSON instances (so IPT and quality assertions can be audited and reasoned over consistently)
This approach ensures that semantics are declared explicitly, transparently, and reusably, rather than embedded implicitly in application logic.
C.3. Semantic lifting in OGC
Semantic lifting in OGC focuses on schema-driven semantics, not ad hoc data conversion. The core principle is:
If the schema is semantically annotated, any conforming instance can be lifted consistently and repeatably.
Key characteristics of semantic lifting in OGC:
Semantics are expressed using JSON-LD contexts mapping terms to IRIs
Identifiers, classes, and relationships are made explicit
Output graphs are compatible with RDF, SPARQL, SHACL, and GeoSPARQL
Lifting workflows are tool-independent and inspectable
Semantic lifting enables:
Explicit semantics for entities, properties, and relationships
Integration with Linked Data ecosystems and domain ontologies
Validation and reasoning using SHACL and rule engines
Reuse of geospatial information across heterogeneous systems
Semantic lifting is therefore foundational to semantic interoperability across OGC APIs, datasets, catalogs, and digital infrastructures.
C.4. Role of the OGC Naming Authority
The OGC Naming Authority (NA) provides tooling and workflows for registering and publishing semantic assets such as vocabularies, schemas, and mappings used across OGC and partner communities OGC Naming Authority tools.
For DQ4IPT, those assets matter because data quality reports need globally meaningful identifiers for measures and scopes—exactly what registers such as OGC RAINBOW are intended to support [47]. Semantic lifting connects JSON instance fields (for example quality measure references inside ISO 19115-4-oriented metadata) to those IRIs so that validators, catalogues, and PROV-aware tools interpret them uniformly.
Semantic lifting is realized through annotation and processing pipelines (schema plus context, optional transforms, RDF output), not a single monolithic tool. Typical steps include:
Annotating schemas with JSON-LD contexts
Applying optional transformation steps before or after context application
Producing JSON-LD and RDF in a reproducible manner for testing, publication, or downstream integration
C.5. Core mechanism: JSON-LD context annotation
C.5.1. Semantic annotation of JSON schemas
The primary mechanism for schema-driven semantic lifting is the annotation of JSON Schemas with JSON-LD contexts.
This can be achieved by:
Shipping a context.jsonld file alongside the schema in a repository or component package; or
Referencing a context via an x-jsonld-context property on the schema (URL or relative path to a JSON-LD context document)
This Report’s STAC examples attach ISO 19157–oriented data quality metadata under properties.liability:quality (with scope and report), and reference the STAC Liability and Claims extension JSON Schema used in the IPT server sections—for example https://luciocola.github.io/stac-extension-liability-claims/json-schema/schema.json as listed in the stac_extensions arrays in Annex D and in the clause on DQ-enabled IPT Server 1. Semantic lifting does not introduce a different instance JSON shape: it associates a JSON-LD context with the schema that validates that JSON (for example via a root-level x-jsonld-context property on the JSON Schema document, or a context.jsonld file published alongside it), so that conforming STAC Items lift to RDF with stable IRIs for quality measures and scopes (including URIs aligned with OGC RAINBOW and ISO 19157-3 registers where applicable).
The fragment below reproduces the properties object from the STAC Item template already shown in this report (same structure as in Annex D); it is instance JSON, not a schema definition.
Listing C.1
{
"properties": {
"datetime": "",
"start_datetime": "",
"end_datetime": "",
"liability:quality": {
"scope": {
"level": "series"
},
"report": []
}
}
}
These contexts define:
Mappings from JSON property names to IRIs
RDF classes (@type) associated with schema objects
Base IRIs for identifier minting
Linkages to external vocabularies and ontologies
Once annotated, the schema itself becomes a semantic contract that governs how instance data is interpreted as RDF.
C.5.2. Context modularity and composition
In complex specifications, schemas frequently reuse sub-schemas or nested components. Semantic lifting must therefore support modular and composable contexts.
Composable context design enables:
Context fragments associated with individual schema components (for example separate fragments for STAC core, extensions, and quality blocks)
Composition when sub-schemas are reused across services
Avoidance of large, monolithic context documents
This supports scalable semantic annotation for large API or metadata stacks such as STAC plus multiple extensions.
C.6. Semantic uplift manifests and additional steps
C.6.1. Semantic uplift manifest (semantic-uplift.yaml)
For cases where direct JSON-LD annotation is insufficient, some toolchains support additional uplift steps defined in a semantic-uplift.yaml file (name and placement depend on the toolchain in use).
This manifest allows declarative specification of:
Pre-processing steps (before JSON-LD context application)
Post-processing steps (after RDF generation)
C.6.2. Pre-processing steps
Pre-processing steps typically reshape or normalize source JSON to make it suitable for semantic interpretation.
Examples include:
JQ transformations
ID normalization or minting
Structural flattening or restructuring
These steps operate on JSON before semantic annotation is applied.
C.6.3. Post-processing steps
Post-processing steps operate on the RDF graph produced from JSON-LD.
Supported patterns include:
SPARQL CONSTRUCT for graph reshaping
SPARQL UPDATE for enrichment
SHACL or SHACL-AF rules for inference and validation
These steps enable semantic patterns that cannot be expressed using JSON-LD context alone.
C.7. End-to-end semantic lifting workflow
A recommended semantic lifting workflow for DQ4IPT-style metadata is:
Annotate schema
Define JSON-LD contexts for schema terms
Associate classes, properties, and IRIs
(Optional) Pre-processing
Apply JSON transforms (for example, jq)
Normalize identifiers and structure
Generate JSON-LD
Apply context mappings to instance data
Produce semantically annotated JSON
Convert to RDF
Parse JSON-LD into RDF serializations (Turtle, N-Quads)
(Optional) Post-processing
Apply SPARQL or SHACL rules
Enrich or reshape the RDF graph
Validate and reason
Validate using SHACL shapes
Apply entailment or inference rules
Publish
Expose RDF via APIs or catalogs
Register datasets using DCAT or similar vocabularies
C.8. Runtime versus publication-time lifting
Semantic lifting for specification and catalogue assets is often performed:
At build time, when generating examples, validation artifacts, or static RDF views
At publication time, when datasets or metadata collections are prepared for dissemination
Runtime semantic lifting in live IPT or catalogue services is possible but depends on:
Availability of reusable, documented uplift definitions
Stability of transformation logic
Performance and operational constraints
Support for reusable runtime uplift varies by implementation; DQ4IPT server and library components may perform conversion and validation without full RDF uplift unless that is an explicit requirement.
C.9. Semantic uplift in future testbeds
Testbed-21 DQ4IPT documents how semantic lifting relates to IPT, STAC-oriented quality metadata, and OGC RAINBOW, but it does not constitute a full interoperability exercise or conformance campaign for semantic uplift itself. End-to-end uplift (JSON-LD contexts, optional transforms, RDF generation, SHACL or SPARQL-based checks) should be tested further—under realistic loads, with multiple implementations, and across catalogue and API workflows—in future OGC testbeds, so that uplift definitions, tooling, and operational guidance can mature alongside IPT and data-quality deliverables.
Figure C.1 — Semantic lifting end-to-end flow (conceptual sequence)
Annex D
(informative)
IPT Server 1
The IPT-Server-1 for the Testbed-21 and the supporting infrastructure, the FACTS ecosystem, is contributed by Secure Dimensions.
D.1. FACTS Ecosystem Introduction
The FACTS ecosystem consists of two main components: (i) Smart Certificates and (ii) Immutable Catalog. The first component Smart Certification is outlined in the OGC Testbed-20 Engineering Report Testbed-20: Integrity, Provenance, and Trust (IPT) Report — Annex B. The second component Immutable Catalog is introduced in the following sub-sections.
The iSTAC component of the FACTS ecosystem is a SpatioTemporal Asset Catalog (STAC) where the STAC features (the metadata records) are stored on a provenance blockchain. For Testbed-21, a Hyperledger Fabric blockchain is used. To support Testbed-21, the deployment of a test instance was favored over using an existing provenance blockchain simply because an existing blockchain charges per transaction. For Testbed-21, one blockchain with different iSTAC was deployed. On iSTAC for performance testing of a blockchain-based STAC was loaded with approx. 4 million records from the ESA EO Sentinel-2 catalog. Would an existing blockchain have been used, the creation of 4M records would have a cost transaction fee. Also, we do not have the authority to establish an iSTAC on an existing blockchain that contains metadata records from ESA.
Any STAC feature, uploaded to the iSTAC must include the hash value for the actual data asset that is associated to the metadata record. This ensures that any data asset can easily be associated with its metadata record stored on the blockchain. For an immutable catalog, as deployed for Testbed-21, the responsible chaincode does allow the creation of new STAC feature for authorized users and allows bulk read via the STAC API.
Figure D.1 — Testbed-21 Secure Dimensions Immutable Catalog Components
The component diagram illustrates the two main usages: (i) anonymous access to blockchain assets via the STAC API and (ii) authorized processes or users from basically any client component. Any STAC asset uploaded must follow a minimal structure:
Listing D.1
{
"assets": {
"PRODUCT": {
"href": "",
"title": "Product",
"type": "",
"file:checksum": ""
}
},
"bbox": [],
"collection": "",
"geometry": {},
"id": "",
"properties": {
"datetime": "",
"start_datetime": "",
"end_datetime": "",
"liability:quality": {
"scope": {
"level": "series"
},
"report": []
}
},
"stac_extensions": [
"https://stac-extensions.github.io/file/v2.1.0/schema.json",
"https://stac-extensions.github.io/alternate-assets/v1.1.0/schema.json",
"https://stac-extensions.github.io/processing/v1.2.0/schema.json",
"https://luciocola.github.io/stac-extension-liability-claims/json-schema/schema.json"
],
"stac_version": "1.0.0",
"type": "Feature",
"links": [
{
"rel": "derived_from",
"href": "",
"type": "application/geo+json",
"title": "Source metadata"
},
{
"rel": "self",
"href": "",
"type": "application/geo+json"
},
{
"rel": "collection",
"href": "",
"type": "application/json",
"title": ""
}
]
}
The file:checksum is the most important element in the JSON template. This links the data asset with the STAC feature. Values are according to the https://stac-extensions.github.io/file/v2.1.0/schema.json described as multihash values. So for example the Blake3 hash with value 67f6f2beaa4fe9bb0082980dc2d1bbb14ffb7335914025e1dc5070be29748486 is encoded as 1e2067f6f2beaa4fe9bb0082980dc2d1bbb14ffb7335914025e1dc5070be29748486.
The following image illustrates an iSTAC feature that documents the first computer bug:
Figure D.2 — Testbed-21 Secure Dimensions Immutable Catalog STAC Feature linked to the documentation of the first computer bug
The data asset links to the actual image showing the reporting of the first computer bug (the image itself is stored on IPFS):
Figure D.3 — Testbed-21 Secure Dimensions IPFS documentation of the first computer bug
This data asset’s Blake3 hash can easily be computed on the command line b3sum FirstBug.jpg with results in the value 67f6f2beaa4fe9bb0082980dc2d1bbb14ffb7335914025e1dc5070be29748486. This documents that the image is genuine and the above metadata belongs to the image.
The genuine check can also be done via the iSTAC Browser as search via data asset hash is implemented as an additional search.
Figure D.4 — Testbed-21 Secure Dimensions Immutable Catalog STAC Browser Genuine Check
D.2. IPT-Server-1
D.2.1. Introduction
The IPT-Server-1 is implemented in Java as a Geoserver plugin for OGC API Processes named TrustedWatermarking. The plugin source code is available from the Github repository Geoserver Trusted Watermarking Plugin. The implementation creates a watermark to the input image and verifies the integrity of the input image based on a STAC record from a STAC catalog. For each execution, the process generates IPT relevant metadata as defined in this Report that is uploaded to the FACTS iSTAC (immutable SpatialTemporal Asset Catalog). This STAC feature can be visualized via a regular STAC API. For demonstration purposes, the Testbed-21 ISTAC Browser can be used. The Immutable Catalog with DQ4IPT Records catalog contains the metadata records for the TrustedWatermarking process.
D.2.2. API
The IPT-Server-1 offers a regular OGC API Processes interface. The input and output parameters are defined here.
Figure D.5 — Testbed-21 Secure Dimensions Trusted Watermarking Process
The OGC API Records conformant execution of the process can be triggered via the Processes OpenAPI document with the following example input:
Listing D.2
{ "inputs": {
"image_url": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG" ,
"meta_url": "https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/geo%2Bjson;profile=https://stacspec.org"
}
}
Figure D.6 — Testbed-21 Secure Dimensions IPT-Server-1 Execution
The response is the STAC Feature which is uploaded to the iSTAC (the blockchain). For the execution example above, the following STAC Feature (metadata record) was created:
Listing D.3
{
"stac_version": "1.0.0",
"assets": {
"PRODUCT": {
"file:checksum": "1e20df9923d5d018df07f07ab9de843f46618329c2c3acace6005b994795e51f8937",
"alternate": {
"FACTS_Browser_Cookie": {
"description": "In order to download the asset via a Web Browser, you first need to establish a connection with your wallet via https://assets.ogc.secd.eu/link so that the Asset Controller can request proof for FACTS Certificates via that secure and private connection when you try to fetch the Asset. Once you have a connection established, you can use the Download link above to fetch the GeoPackage.",
"href": "https://assets.ogc.secd.eu/files/fa6271befa5650990856528bf34e647dcbaa9e133d03447199ecc50df71dd4a0",
"title": "Download Asset via Web Browser session cookie",
"type": "image/jpeg"
},
"FACTS_API_Key": {
"auth": {
"refs": [
"apiKey"
],
"roles": [
"download"
],
"schemes": {
"flows": {
"authorizationCode": {
"authorizationApi": "https://wallet.ogc.secd.eu/user/x-facts-key",
"method": "get",
"responseField": "x-facts-key",
"parameters": {
"expires_in": {
"schema": {
"examples": "300",
"type": "string"
},
"in": "query",
"description": "the validity of the token in seconds",
"required": "true"
}
}
}
},
"in": "header",
"name": "X-FACTS-Key",
"description": "X-FACTS-Key represents the connection between your Wallet and the Asset Controller to request proof of required FACTS Certificates.",
"type": "apiKey",
"required": "true"
}
},
"description": "In order to download the asset via the API, you first need to fetch an API-Key token (X-FACTS-Key) via https://wallet.ogc.secd.eu/connections/select which must be submitted as HTTP Header `X-FACTS-Key` with the asset URL from `Copy URL`. ",
"href": "https://assets.ogc.secd.eu/files/fa6271befa5650990856528bf34e647dcbaa9e133d03447199ecc50df71dd4a0",
"title": "Download Asset via X-FACTS-Key",
"type": "image/jpeg"
}
},
"href": "https://ipfs.ogc.secd.eu/files/fa6271befa5650990856528bf34e647dcbaa9e133d03447199ecc50df71dd4a0",
"title": "Product",
"type": "image/jpeg"
}
},
"bbox": [
133.87,
-23.68,
133.9,
-23.64
],
"geometry": {
"coordinates": [
[
[
133.9,
-23.68
],
[
133.9,
-23.64
],
[
133.87,
-23.64
],
[
133.87,
-23.68
],
[
133.9,
-23.68
]
]
],
"type": "Polygon"
},
"links": [
{
"rel": "derived_from",
"href": "https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/geo%2Bjson;profile=https://stacspec.org",
"type": "application/geo+json",
"title": "Source metadata"
},
{
"rel": "self",
"href": "https://ic.ogc.secd.eu/stac/collections/test_dq4ipt/items/asset_1770644376054",
"type": "application/geo+json",
"title": "asset_1770644376054"
},
{
"rel": "collection",
"href": "https://ic.ogc.secd.eu/stac/collections/test_dq4ipt",
"type": "application/json",
"title": "test_dq4ipt"
}
],
"collection": "test_dq4ipt",
"id": "asset_1770644376054",
"type": "Feature",
"stac_extensions": [
"https://stac-extensions.github.io/file/v2.1.0/schema.json",
"https://stac-extensions.github.io/alternate-assets/v1.1.0/schema.json",
"https://stac-extensions.github.io/processing/v1.2.0/schema.json",
"https://luciocola.github.io/stac-extension-liability-claims/json-schema/schema.json"
],
"properties": {
"processing:level": "L1",
"datetime": "2026-02-09T13:39:35Z",
"start_datetime": "2016-02-04T07:28:52Z",
"end_datetime": "2016-02-04T07:28:52Z",
"processing:facility": "Secure Dimensions Processes",
"processing:lineage": "Watermarking Process",
"processing:datetime": "2026-02-09T13:39:35Z",
"liability:quality": {
"scope": {
"level": "series"
},
"report": [
{
"result": [
{
"pass": true,
"specification": {
"date": "2021-10-14T00:00:00Z",
"identifier": "https://ceos.org/spec/ard/conf",
"title": "CEOS ARD Normalised Radar Backscatter (CARD4L-NRB)"
},
"type": "ConformanceResult",
"resultType": "conformance"
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "The measure will take the value true if all the requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"Data product specification passed"
]
},
"completeness": {
"category": "completeness"
},
"type": "ConceptualConsistency",
"category": "completeness"
}
]
},
"processing:software": {
"name": "Geoserver",
"version": "3.0-SNAPSHOT"
},
"ipt": {
"output": {
"image_height": 1026,
"file:checksum": "1e20df9923d5d018df07f07ab9de843f46618329c2c3acace6005b994795e51f8937",
"metadata_url": "https://ic.ogc.secd.eu/stac/collections/test_dq4ipt/items/asset_1770644376054",
"image_url": "https://assets.ogc.secd.eu/files/fa6271befa5650990856528bf34e647dcbaa9e133d03447199ecc50df71dd4a0",
"image_width": 1026,
"image_type": "image/jpeg"
},
"input": {
"image": {
"image_height": 1026,
"file:checksum": "1220ecff1a367594707fe3603f73fdd6091b039b8e0b98c48d92643f84bc229cc471",
"image_url": "https://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG",
"image_width": 1026,
"image_type": "image/png;charset=UTF-8"
},
"metadata": {
"metadata_url": "https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/geo%2Bjson;profile=https://stacspec.org",
"vc_url": "https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/vc%2Bld%2Bjson",
"VC_verification": true,
"VC": {
"relatedResource": [
{
"digestMultibase": "zQmYRMC8UMw4ipWvivUKvzvTWrjbKk1oywH1QpoY6w3tCQX",
"id": "https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld"
},
{
"digestMultibase": "zQmeHnYH1jaUefpeAbARzC46rJSzSte8uWn52GGcQWXMcmn",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG"
},
{
"digestMultibase": "zQmPFZfx6KoEAgPpFosgJEKQ17K7sJpsSZWtyNo7vwBHXyr",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_TIMG.jpg"
}
],
"credentialSubject": {
"date": "2016-02-04T07:28:52Z/2016-02-04T07:28:52Z",
"bbox": [
133.87,
-23.68,
133.9,
-23.64
],
"links": {
"data": [
{
"href": "https://tpm-ds.eo.esa.int/oads/data/PROBA1-HRC/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP",
"title": "Download",
"type": "application/x-binary"
}
],
"previews": [
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG",
"title": "QUICKLOOK",
"type": "image/png"
},
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_TIMG.jpg",
"title": "THUMBNAIL",
"type": "image/jpeg"
}
]
},
"geometry": {
"coordinates": [
[
[
133.9,
-23.68
],
[
133.9,
-23.64
],
[
133.87,
-23.64
],
[
133.87,
-23.68
],
[
133.9,
-23.68
]
]
],
"type": "Polygon"
},
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001",
"title": "PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001",
"updated": "2024-04-30T11:28:07Z"
},
"issuanceDate": "2026-02-09T13:39:33Z",
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001",
"proof": {
"created": "2026-02-09T13:39:33.336Z",
"jws": "eyJhbGciOiJFUzI1NksiLCJraWQiOiJiQnpXOHlHeEt1RUNMal9JeFNyTkN1eVJKOUppZ2ptTU9DeDJGZHpDcnFBIiwiY3JpdCI6WyJiNjQiXSwiYjY0IjpmYWxzZX0..ww0HqgGaA8-WQV2-yO0GbK5JnisW9dXkkXD_DwUIzsg9TdG_yo2nC-mS1-fcoCl0BTxHfwUX60MaXBOib39nCQ",
"proofPurpose": "assertionMethod",
"type": "EcdsaSecp256k1Signature2019",
"verificationMethod": "did:web:emc.spacebel.be:organisations:esa_esrin#owner"
},
"type": [
"VerifiableCredential",
"Feature"
],
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld",
{
"digestMultibase": {
"@type": "https://w3id.org/security#multibase",
"@id": "https://w3id.org/security#digestMultibase"
},
"relatedResource": {
"@type": "@id",
"@id": "https://www.w3.org/2018/credentials#relatedResource"
}
}
],
"issuer": "did:web:emc.spacebel.be:organisations:esa_esrin"
}
},
"image_hash_verified": true
}
}
}
}
NOTE: The above response is incomplete as the provenance recording is not included. More details about the STAC Feature are presented in another annex.
D.2.3. Processing Step Details
The following sequence diagram illustrates the different processing step of the TrustedWatermarking process.
Figure D.7 — TrustedWatermarking Process Execution and Interaction Diagram
The following introduces the processing steps in more detail. The steps are simplified as the outcome of boolean tests is not captured for clarity. Also, the input verification (the tests whether the image_url and meta_url input parameters are present in the API call) are not shown.
Example
creates a STAC Asset from the template that will capture all IPT related metadata. To capture the IPT and Data Quality metadata, the STAC Asset uses the [IPT Liability and Claims extension]() which was developed during Testbed-21.
fetches the input metadata as a STAC Feature from any STAC catalog. The Spacebel STAC Catalog has been used throughout Testbed-21 as their STAC features include the relevant link for establishing trusted processing: VC including asset hash and ISO metadata URL.
fetches the VC following the link with type application/vc+ld+json
verifies the VC using the Java Library com.danubetech.dataintegrity.verifier.LdVerifier. The result of the verification (true / false) is captured in the STAC Asset.
fetches the input image and calculates the input hash using the hash algorithm from the VC. The image hash is calculated only if the VC contains a hash for the image_url.
if the VC contains the image_url, the hash from the image_url and the hash from the VC are compared. The result is captured in the STAC Asset.
creates the output image with the watermark SECD <date time now in ISO8601 format> on the input image in the right bottom corner.
Calculates the Blake3 hash for the watermarked (output) image
uploads the watermarked image to the IPFS service
from the meta_url STAC feature get the ISO 19115-3 XML encoded metadata URL for asset of type application/vnd.iso.19115-3+xml. With that URL fetch the ISO 19115-4 JSON encoded quality metadata from D103
The response from D103 is the JSON encoded quality metadata that the Trusted Watermarking process can directly include into the DataQualityInfo element of the STAC Asset
adds all processing results to the STAC Asset
uploads the final STAC Asset to the iSTAC. As the iSTAC is read-only, the process uses a direct connection to the blockchain using the java library org.hyperledger.fabric.client.
Annex E
(informative)
D102 Notebook
E.1. Overview
The notebook shows how to obtain quality and provenance (lineage) information from the Spacebel D102 OGC API-Records / STAC Catalogue for:
collections
granules (products)
Examples of the following collection-level quality information (§1):
CEOS-ARD compliant collection
INSPIRE implementing rules compliant collection
Collection with CEOS Data Management and Stewardship Maturity Matrix (DSMM) (NOAA_AVHRR_L1B_LAC)
Examples of granule-level information (§2):
Quality measures incl. cloud cover, snow cover, ..
Quality metadata in ISO19115-4, ISO19115-3 and ISO19157-2 encodings as STAC items.
Lineage information (processing)
Resolution of W3C DID identifiers of resources (§3)
Invocation of the Processing service for watermarking (§4)
Listing E.1
import json, requests, xml
from IPython.display import Markdown as md
from IPython.display import Image
from xml.dom import minidom
from xml.etree import ElementTree
# OGC API - Records endpoint
URL_LANDING_PAGE = 'https://emc.spacebel.be/'
# Immutable Catalogue STAC endpoint
URL_IMMUTABLE_CAT_LANDING_PAGE = 'https://ic.ogc.secd.eu/stac/'
STAC_BROWSER_URL = 'https://radiantearth.github.io/stac-browser/#/external/'
# First resolver is publicly accessible but cannot handle query parameters.
DID_RESOLVER_1 = "https://dev.uniresolver.io/1.0/identifiers/"
# The second DID resolver requires an access token and has access constraints (calls per hour).
DID_RESOLVER_2 = "https://api.godiddy.com/0.1.0/universal-resolver/identifiers/"
DID_RESOLVER = DID_RESOLVER_1
The Catalogue client can be accessed at https://radiantearth.github.io/stac-browser/#/external/emc.spacebel.be/?.language=en
E.2. Collections
E.2.2. GET /collections/{collection-id}
Example: 1.1
> Access a collection with CEOS-ARD Quality Information (GeoJSON). ISO19115-4 record is an asset of this collection. > More about CEOS-ARD at https://ceos.org/ard/. > See also recommendations DATA#1 to DATA#4 at https://github.com/ceos-org/interoperability-handbook/blob/main/Architecture.md.
Listing E.2
response = requests.get(URL_LANDING_PAGE + 'collections/novasar_l2ard_hh_hv')
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.3
{
"extent": {
"spatial": {
"bbox": [
[
-62.87262834116111,
-55.94470669421993,
173.246741777445,
38.42053289934906
]
]
},
"temporal": {
"interval": [
[
"2019-11-02T00:00:00.000Z",
"2025-10-08T23:59:59.999Z"
]
]
}
},
"stac_version": "1.0.0",
"keywords": [
"Normalised Radar Backscatter"
],
"created": "2025-10-20T00:00:00.00Z",
"externalIds": [
{
"scheme": "https://www.w3.org/ns/did/v1",
"value": "did:web:emc.spacebel.be:collections:novasar_l2ard_hh_hv"
}
],
"description": "NovaSAR-1 CEOS-ARD (level 2) HH,HV polarizations",
"type": "Collection",
"title": "novasar_l2ard_hh_hv",
"license": "various",
"assets": {
"metadata_ogc_17_069r3": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv",
"type": "application/geo+json;profile=\"http://www.opengis.net/spec/ogcapi-features-1/1.0\"",
"title": "OGC 17-069r3 metadata"
},
"metadata_iso_19115_4": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/vnd.iso.19115-4%2Bjson",
"title": "ISO19115-4",
"type": "application/vnd.iso.19115-4+json"
},
"metadata_iso_19139": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/vnd.iso.19139%2Bxml",
"title": "ISO 19139 metadata",
"type": "application/vnd.iso.19139+xml"
},
"metadata_iso_19139_2": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/vnd.iso.19139-2%2Bxml",
"title": "ISO 19139-2 metadata",
"type": "application/vnd.iso.19139-2+xml"
},
"metadata_dif_10": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/dif10%2Bxml",
"title": "DIF-10 metadata",
"type": "application/dif10+xml"
},
"metadata_iso_19115_3": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/vnd.iso.19115-3%2Bxml",
"title": "ISO 19115-3 metadata",
"type": "application/vnd.iso.19115-3+xml"
},
"metadata_ogc_17_084r1": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?mode=owc",
"title": "OGC 17-084r1 metadata",
"type": "application/geo+json;profile=\"http://www.opengis.net/spec/eoc-geojson/1.0\""
},
"metadata_html": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=text/html",
"title": "HTML",
"type": "text/html"
},
"quicklook": {
"roles": [
"overview"
],
"href": "https://eo-data.csiro.au/projects/easi-thumbnails/novasar_l2ard_hh_hv/2019/11/CEOS-ARD_NRB_v5_5_NovaSAR_01_7940_scd_29_191102_023255_HH_HV_A_R-ql.png",
"type": "image/png",
"title": "graphic overview"
}
},
"links": [
{
"rel": "canonical",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv",
"type": "application/json",
"title": "novasar_l2ard_hh_hv"
},
{
"rel": "self",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv",
"type": "application/json"
},
{
"rel": "root",
"href": "https://emc.spacebel.be",
"type": "application/json",
"title": "FedEO Clearinghouse"
},
{
"rel": "parent",
"href": "https://emc.spacebel.be",
"title": "collections",
"type": "application/json"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/atom%2Bxml",
"type": "application/atom+xml",
"title": "Atom format"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/xml",
"type": "application/xml",
"title": "Dublin Core metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/json",
"type": "application/json",
"title": "STAC metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/ld%2Bjson;profile=https://schema.org",
"type": "application/ld+json;profile=\"https://schema.org\"",
"title": "JSON-LD (schema.org) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/ld%2Bjson;profile=http://data.europa.eu/930/",
"type": "application/ld+json;profile=\"http://data.europa.eu/930/\"",
"title": "JSON-LD (GeoDCAT-AP) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/rdf%2Bxml",
"type": "application/rdf+xml",
"title": "RDF/XML metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/rdf%2Bxml;profile=https://schema.org",
"type": "application/rdf+xml;profile=\"https://schema.org\"",
"title": "RDF/XML (schema.org) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/rdf%2Bxml;profile=http://data.europa.eu/930/",
"type": "application/rdf+xml;profile=\"http://data.europa.eu/930/\"",
"title": "RDF/XML (GeoDCAT-AP) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=text/turtle;profile=https://schema.org",
"type": "text/turtle;profile=\"https://schema.org\"",
"title": "Turtle (schema.org) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=text/turtle;profile=http://data.europa.eu/930/",
"type": "text/turtle;profile=\"http://data.europa.eu/930/\"",
"title": "Turtle (GeoDCAT-AP) metadata"
},
{
"rel": "related",
"href": "https://emc.spacebel.be/series/eo:organisationName/CSIRO",
"title": "More collections for CSIRO"
}
],
"id": "novasar_l2ard_hh_hv",
"stac_extensions": [
"https://stac-extensions.github.io/external-ids/v1.0.0/schema.json",
"https://stac-extensions.github.io/processing/v1.2.0/schema.json"
],
"updated": "2025-10-20T00:00:00.00Z",
"providers": [
{
"roles": [
"producer"
],
"name": "CSIRO",
"url": "www.csiro.au"
},
{
"roles": [
"host"
],
"name": "FedEO Clearinghouse",
"url": "https://emc.spacebel.be/readme.html"
}
],
"summaries": {
"processing:lineage": [
"No info available."
]
}
}
The collection metadata is available in alternative metadata encodings which are included as STAC assets. One of the assets provides an ISO19115-4 metadata encoding. advertizes identifiers which may include a DOI and/or A DID.
Listing E.4
jstr = json.dumps(data['assets']['metadata_iso_19115_4'], indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.5
{
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/vnd.iso.19115-4%2Bjson",
"title": "ISO19115-4",
"type": "application/vnd.iso.19115-4+json"
}
Listing E.6
data['assets']['metadata_iso_19115_4']['href']
Figure E.1
'https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/vnd.iso.19115-4%2Bjson'
Listing E.7
response = requests.get(data['assets']['metadata_iso_19115_4']['href'])
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.8
{
"bbox": [
-62.87262834116111,
-55.94470669421993,
173.246741777445,
38.42053289934906
],
"geometry": {
"coordinates": [
[
[
-62.87262834116111,
-55.94470669421993
],
[
173.246741777445,
-55.94470669421993
],
[
173.246741777445,
38.42053289934906
],
[
-62.87262834116111,
38.42053289934906
],
[
-62.87262834116111,
-55.94470669421993
]
]
],
"type": "Polygon"
},
"id": "novasar_l2ard_hh_hv",
"conformsTo": [
"https://standards.iso.org/iso/19115/-4/0.1/core",
"https://standards.iso.org/iso/19115/-4/0.1/data-quality-core",
"https://standards.iso.org/iso/19115/-4/0.1/no-ref"
],
"type": "Feature",
"properties": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"identificationInfo": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"extent": [
{
"geographicElement": [
{
"northBoundLatitude": 38.42053289934906,
"southBoundLatitude": -55.94470669421993,
"type": "EX_GeographicBoundingBox",
"westBoundLongitude": -62.87262834116111,
"eastBoundLongitude": 173.246741777445
}
]
}
],
"descriptiveKeywords": [
{
"thesaurusName": {
"title": "CEOS-ARD Product Family Specification"
},
"keyword": [
"Normalised Radar Backscatter"
]
}
],
"citation": {
"date": {
"creation": "2025-10-20"
},
"identifier": [
{
"code": "did:web:emc.spacebel.be:collections:novasar_l2ard_hh_hv",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "novasar_l2ard_hh_hv"
},
"abstract": "NovaSAR-1 CEOS-ARD (level 2) HH,HV polarizations"
},
"metadataStandard": [
{
"title": "ISO 19115-1:2014"
},
{
"title": "ISO 19115-4"
}
],
"contact": [
{
"role": "pointOfContact",
"party": [
{
"contactInfo": [
{
"address": [
{
"deliveryPoint": [
"Building 101, Clunies Ross Street"
],
"country": "Australia",
"city": "Black Mountain",
"postalCode": "ACT 2601"
}
],
"phone": {
"voice": "tel:+61395452176"
}
}
],
"name": "CSIRO",
"type": "CI_Organisation"
}
]
}
],
"dataQualityInfo": [
{
"scope": {
"level": "series"
},
"report": [
{
"result": [
{
"pass": true,
"specification": {
"date": {
"publication": "2021-10-14"
},
"identifier": [
{
"code": "https://ceos.org/ard/files/PFS/NRB/v5.5",
"codeSpace": "https://ceos.org/ard"
}
],
"edition": "5.5",
"title": "CEOS-ARD Product Family Specification: Normalised Radar Backscatter"
},
"type": "ConformanceResult",
"explanation": "See the referenced specification"
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Indication that all requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"Data product specification passed"
]
},
"evaluationMethod": [
{
"referenceDoc": [],
"evaluationProcedure": {
"editionDate": "2021-10-14",
"edition": "5.5",
"onlineResource": [
{
"linkage": "https://ceos.org/ard/files/PFS/NRB/v5.5/CARD4L-PFS_NRB_v5.5.pdf"
},
{
"linkage": "https://ceos.org/ard/files/Self%20Assessments/NRB/v5.5/Opera%20RTC%20Sentinel-1%20self-assessment.zip"
},
{
"linkage": "https://ceos.org/ard/files/Peer%20Reviews/NRB/v5.5/NovaSAR_WGCVEval.zip"
}
],
"title": "CEOS-ARD Product Family Specification: Normalised Radar Backscatter"
},
"type": "FullInspection",
"evaluationMethodDescription": "This collection is conformant with the CEOS-ARD NRB Specification"
}
],
"type": "DomainConsistency"
}
]
}
],
"dateInfo": {
"revision": "2025-10-20"
},
"metadataScope": [
{
"resourceScope": "series",
"name": "series"
}
]
}
}
The ISO metadata includes Identification Information with a Citation. In this section, its identifiers such as an optional DOI and/or DID may be included. The DID resolves to a DID document.
Listing E.9
jstr = json.dumps(data['properties']['identificationInfo']['citation'], indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.10
{
"date": {
"creation": "2025-10-20"
},
"identifier": [
{
"code": "did:web:emc.spacebel.be:collections:novasar_l2ard_hh_hv",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "novasar_l2ard_hh_hv"
}
Listing E.11
did = data['properties']['identificationInfo']['citation']['identifier'][0]['code']
did
Figure E.2
'did:web:emc.spacebel.be:collections:novasar_l2ard_hh_hv'
Listing E.12
# resolve DID
print(did)
response = requests.get( DID_RESOLVER + did,
headers={ 'Accept': 'application/json' })
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Figure E.3
did:web:emc.spacebel.be:collections:novasar_l2ard_hh_hv
Listing E.13
{
"controller": "did:web:emc.spacebel.be:organisations:csiro",
"id": "did:web:emc.spacebel.be:collections:novasar_l2ard_hh_hv",
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1"
],
"alsoKnownAs": [
"https://emc.spacebel.be/collections/novasar_l2ard_hh_hv",
"https://emc.spacebel.be/collections/novasar_l2ard_hh_hv?httpAccept=application/vnd.iso.19115-4%2Bjson"
]
}
Example: 1.2
> Access a collection with CEOS-ARD Quality Information (ISO19115-4) using content negotiation.
Listing E.14
response = requests.get(URL_LANDING_PAGE + 'collections/novasar_l2ard_hh_hv',
headers={'Accept': 'application/vnd.iso.19115-4+json'})
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.15
{
"bbox": [
-62.87262834116111,
-55.94470669421993,
173.246741777445,
38.42053289934906
],
"geometry": {
"coordinates": [
[
[
-62.87262834116111,
-55.94470669421993
],
[
173.246741777445,
-55.94470669421993
],
[
173.246741777445,
38.42053289934906
],
[
-62.87262834116111,
38.42053289934906
],
[
-62.87262834116111,
-55.94470669421993
]
]
],
"type": "Polygon"
},
"id": "novasar_l2ard_hh_hv",
"conformsTo": [
"https://standards.iso.org/iso/19115/-4/0.1/core",
"https://standards.iso.org/iso/19115/-4/0.1/data-quality-core",
"https://standards.iso.org/iso/19115/-4/0.1/no-ref"
],
"type": "Feature",
"properties": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"identificationInfo": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"extent": [
{
"geographicElement": [
{
"northBoundLatitude": 38.42053289934906,
"southBoundLatitude": -55.94470669421993,
"type": "EX_GeographicBoundingBox",
"westBoundLongitude": -62.87262834116111,
"eastBoundLongitude": 173.246741777445
}
]
}
],
"descriptiveKeywords": [
{
"thesaurusName": {
"title": "CEOS-ARD Product Family Specification"
},
"keyword": [
"Normalised Radar Backscatter"
]
}
],
"citation": {
"date": {
"creation": "2025-10-20"
},
"identifier": [
{
"code": "did:web:emc.spacebel.be:collections:novasar_l2ard_hh_hv",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "novasar_l2ard_hh_hv"
},
"abstract": "NovaSAR-1 CEOS-ARD (level 2) HH,HV polarizations"
},
"metadataStandard": [
{
"title": "ISO 19115-1:2014"
},
{
"title": "ISO 19115-4"
}
],
"contact": [
{
"role": "pointOfContact",
"party": [
{
"contactInfo": [
{
"address": [
{
"deliveryPoint": [
"Building 101, Clunies Ross Street"
],
"country": "Australia",
"city": "Black Mountain",
"postalCode": "ACT 2601"
}
],
"phone": {
"voice": "tel:+61395452176"
}
}
],
"name": "CSIRO",
"type": "CI_Organisation"
}
]
}
],
"dataQualityInfo": [
{
"scope": {
"level": "series"
},
"report": [
{
"result": [
{
"pass": true,
"specification": {
"date": {
"publication": "2021-10-14"
},
"identifier": [
{
"code": "https://ceos.org/ard/files/PFS/NRB/v5.5",
"codeSpace": "https://ceos.org/ard"
}
],
"edition": "5.5",
"title": "CEOS-ARD Product Family Specification: Normalised Radar Backscatter"
},
"type": "ConformanceResult",
"explanation": "See the referenced specification"
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Indication that all requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"Data product specification passed"
]
},
"evaluationMethod": [
{
"referenceDoc": [],
"evaluationProcedure": {
"editionDate": "2021-10-14",
"edition": "5.5",
"onlineResource": [
{
"linkage": "https://ceos.org/ard/files/PFS/NRB/v5.5/CARD4L-PFS_NRB_v5.5.pdf"
},
{
"linkage": "https://ceos.org/ard/files/Self%20Assessments/NRB/v5.5/Opera%20RTC%20Sentinel-1%20self-assessment.zip"
},
{
"linkage": "https://ceos.org/ard/files/Peer%20Reviews/NRB/v5.5/NovaSAR_WGCVEval.zip"
}
],
"title": "CEOS-ARD Product Family Specification: Normalised Radar Backscatter"
},
"type": "FullInspection",
"evaluationMethodDescription": "This collection is conformant with the CEOS-ARD NRB Specification"
}
],
"type": "DomainConsistency"
}
]
}
],
"dateInfo": {
"revision": "2025-10-20"
},
"metadataScope": [
{
"resourceScope": "series",
"name": "series"
}
]
}
}
Example: 1.3
> Extract the CEOS-ARD quality information.
Listing E.16
jstr = json.dumps(data['properties']['dataQualityInfo'], indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.17
[
{
"scope": {
"level": "series"
},
"report": [
{
"result": [
{
"pass": true,
"specification": {
"date": {
"publication": "2021-10-14"
},
"identifier": [
{
"code": "https://ceos.org/ard/files/PFS/NRB/v5.5",
"codeSpace": "https://ceos.org/ard"
}
],
"edition": "5.5",
"title": "CEOS-ARD Product Family Specification: Normalised Radar Backscatter"
},
"type": "ConformanceResult",
"explanation": "See the referenced specification"
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Indication that all requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"Data product specification passed"
]
},
"evaluationMethod": [
{
"referenceDoc": [],
"evaluationProcedure": {
"editionDate": "2021-10-14",
"edition": "5.5",
"onlineResource": [
{
"linkage": "https://ceos.org/ard/files/PFS/NRB/v5.5/CARD4L-PFS_NRB_v5.5.pdf"
},
{
"linkage": "https://ceos.org/ard/files/Self%20Assessments/NRB/v5.5/Opera%20RTC%20Sentinel-1%20self-assessment.zip"
},
{
"linkage": "https://ceos.org/ard/files/Peer%20Reviews/NRB/v5.5/NovaSAR_WGCVEval.zip"
}
],
"title": "CEOS-ARD Product Family Specification: Normalised Radar Backscatter"
},
"type": "FullInspection",
"evaluationMethodDescription": "This collection is conformant with the CEOS-ARD NRB Specification"
}
],
"type": "DomainConsistency"
}
]
}
]
E.2.3. Quality information / INSPIRE
See https://radiantearth.github.io/stac-browser/#/external/emc.spacebel.be/collections/PROBA.HRC.1A
Example: 1.4
> Access a collection with INSPIRE Quality Information (ISO19115-4) using content negotiation.
Listing E.18
response = requests.get(URL_LANDING_PAGE + 'collections/PROBA.HRC.1A',
headers={'Accept': 'application/vnd.iso.19115-4+json'})
data = json.loads(response.text)
jstr = json.dumps(data['properties']['dataQualityInfo'], indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.19
[
{
"scope": {
"level": "series"
},
"report": [
{
"result": [
{
"pass": false,
"specification": {
"date": {
"publication": "2010-12-08"
},
"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"
},
"type": "ConformanceResult",
"explanation": "This data set is conformant with the INSPIRE Implementing Rules for the interoperability of spatial data sets and services"
}
],
"type": "DomainConsistency"
}
]
}
]
E.2.4. Quality information / CEOS DSMM
Example: 1.5
> Access a collection with CEOS Management and Stewardship Maturity Matrix (DSMM).
Listing E.20
collection_url = URL_LANDING_PAGE + 'collections/NOAA_AVHRR_L1B_LAC'
Listing E.21
response = requests.get(collection_url,
headers={'Accept': 'application/vnd.iso.19115-4+json'})
data = json.loads(response.text)
jstr = json.dumps(data['properties']['dataQualityInfo'], indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.22
[
{
"scope": {
"level": "series"
},
"report": [
{
"result": [
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_1_MetadataForDiscovery"
},
"type": "QuantitativeResult",
"value": [
"PartiallyManaged"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_2_OnlineAccess"
},
"type": "QuantitativeResult",
"value": [
"FullyManaged"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_3_DataEncoding"
},
"type": "QuantitativeResult",
"value": [
"Managed"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_4_DataDocumentation"
},
"type": "QuantitativeResult",
"value": [
"Managed"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_5_DataTraceability"
},
"type": "QuantitativeResult",
"value": [
"Managed"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_6_DataValidation"
},
"type": "QuantitativeResult",
"value": [
"FullyManaged"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_7_DataUncertainty"
},
"type": "QuantitativeResult",
"value": [
"PartiallyManaged"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_8_DataQualityControl"
},
"type": "QuantitativeResult",
"value": [
"FullyManaged"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_9_DataPreservation"
},
"type": "QuantitativeResult",
"value": [
"FullyManaged"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_10_DataMetadataVerification"
},
"type": "QuantitativeResult",
"value": [
"FullyManaged"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_11_DataProcessingReprocessing"
},
"type": "QuantitativeResult",
"value": [
"Managed"
]
},
{
"resultScope": {
"level": "https://ceos.org/resources/Codelist/DSMM_Codelists.xml#MMP_12_PersistentResolvableIdentifiers"
},
"type": "QuantitativeResult",
"value": [
"FullyManaged"
]
}
],
"measure": {
"measureIdentification": {
"code": "CEOS.WGISS.DSIG.DSMM",
"authority": {
"edition": "1.3",
"alternateTitle": [
"CEOS"
],
"title": "Committee on Earth Observation Satellites"
}
},
"measureDescription": "The Data Management and Stewardship Maturity Matrix (DSMM) is a unified framework that defines criteria for each of nine components based on measurable practices, which can be used to apply a progressive, 4-level rating to an individual dataset, representing stewardship maturity stages rated as Not Assessed or Not Managed (Level 0), Partially Managed (Level 1), Managed (Level 2), Fully Managed (Level 3).",
"nameOfMeasure": [
"Data Management and Stewardship Maturity Assessment"
]
},
"evaluationMethod": [
{
"referenceDoc": [],
"evaluationProcedure": {
"editionDate": "2024-10",
"edition": "1.1",
"onlineResource": [
{
"linkage": "https://ceos.org/document_management/Working_Groups/WGISS/Interest_Groups/Data_Stewardship/White_Papers/WGISS%20Data%20Management%20and%20Stewardship%20Maturity%20Matrix.pdf"
}
],
"title": "WGISS Data Management and Stewardship Maturity Matrix"
},
"type": "FullInspection",
"evaluationMethodDescription": "Data Stewardship Maturity Assessment was evaluated by the metadata content editor using the Scientific Data Stewardship Maturity Assessment Model v1.3."
}
],
"type": "ConceptualConsistency"
},
{
"result": [
{
"pass": false,
"specification": {
"date": {
"publication": "2010-12-08"
},
"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"
},
"type": "ConformanceResult",
"explanation": "This data set is conformant with the INSPIRE Implementing Rules for the interoperability of spatial data sets and services"
}
],
"type": "DomainConsistency"
}
]
}
]
Example: 1.6
> Access a collection with CEOS Management and Stewardship Maturity Matrix (DSMM) from STACBrowser. ISO19115-4 metadata is available as an asset.
Listing E.23
# remove https:// in item_url
browser_url = STAC_BROWSER_URL + collection_url.replace("https://","")
browser_url
Figure E.4
'https://radiantearth.github.io/stac-browser/#/external/emc.spacebel.be/collections/NOAA_AVHRR_L1B_LAC'
E.3. Products
E.3.1. 2.1 Quality information
The product metadata in the ESA Catalogue is encoded as OGC 17-003r2 metadata. Quality information may be available in the qualityInformation and the qualityStatus flag. This flag can be DEGRADED'' or NOMINAL’’ and thus be encoded using the ISO19157-3 measure at https://defs-hosted.opengis.net/prez-hosted/catalogs/hosted:iso-19157-3/collections/ns10:qualityMeasure/items/qualitymeasure:101 Also the cloudCover and snowCover properties can be considered quaity measures as they indicate the percentage of pixels that cannot be used.
Listing E.24
"productInformation": {
"qualityInformation": {
"qualityDegradationQuotationMode": "MANUAL",
"qualityStatus": "DEGRADED",
"qualityDegradationTag": "RADIOMETRY"
}
Listing E.25
"qualityInformation": {
"qualityDegradationQuotationMode": "AUTOMATIC",
"qualityStatus": "NOMINAL",
"qualityDegradation": 0.0
}
| OGC 17-003r2 | ISO19157/ISO19115-4 | OGC RAINBOW |
|---|---|---|
| qualityDegradationQuotationMode | evaluationMethod | |
| qualityStatus | measure | https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/ MD101 |
| qualityDegradation | measure | https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/ MD211 |
| snowCover | measure | https://standards.isotc211.org/19157/-3/1/dqc/content/ MD7 |
| cloudCover | measure | https://standards.isotc211.org/19157/-3/1/dqc/content/ MD7 |
Example: 2.1
> Get ISO19115-4 metadata for a product (with quality information) using content negotiation
Listing E.26
# https://emc.spacebel.be/collections/novasar_l2ard_hh_hv/items/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001
# https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001
# item_url = URL_LANDING_PAGE + 'collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001'
item_url = URL_LANDING_PAGE + 'collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026'
response = requests.get( item_url,
headers={'Accept': 'application/vnd.iso.19115-4+json'})
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.27
{
"bbox": [
95.91153308,
25.92713265,
96.09259599,
26.08689352
],
"geometry": {
"coordinates": [
[
[
95.91153308,
26.08689352
],
[
95.91153308,
25.92713265
],
[
96.09259599,
25.92713265
],
[
96.09259599,
26.08689352
],
[
95.91153308,
26.08689352
]
]
],
"type": "Polygon"
},
"conformsTo": [
"https://standards.iso.org/iso/19115/-4/0.1/core",
"https://standards.iso.org/iso/19115/-4/0.1/data-quality-core",
"https://standards.iso.org/iso/19115/-4/0.1/no-ref"
],
"id": "KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026",
"type": "Feature",
"properties": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"identificationInfo": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"extent": [
{
"geographicElement": [
{
"northBoundLatitude": 26.08689352,
"southBoundLatitude": 25.92713265,
"type": "EX_GeographicBoundingBox",
"westBoundLongitude": 95.91153308,
"eastBoundLongitude": 96.09259599
}
]
}
],
"parentMetadata": {
"identifier": [
{
"code": "TropForest"
},
{
"code": "did:web:emc.spacebel.be:collections:TropForest",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "TropForest"
},
"citation": {
"identifier": [
{
"code": "KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026"
},
{
"code": "did:web:emc.spacebel.be:collections:TropForest:items:KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026"
},
"abstract": "KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026"
},
"metadataStandard": [
{
"title": "ISO 19115-1:2014"
},
{
"title": "ISO 19115-4"
}
],
"contact": [
{
"role": "pointOfContact",
"party": [
{
"contactInfo": [
{
"address": [
{
"deliveryPoint": [
"Largo Galileo Galilei 1"
],
"country": "Italy",
"city": "Frascati (Roma)",
"postalCode": "00044",
"electronicMailAddress": [
"eohelp@esa.int"
]
}
],
"phone": {
"voice": "tel:+3906941801"
}
}
],
"name": "ESA/ESRIN",
"type": "CI_Organisation"
}
]
}
],
"dataQualityInfo": [
{
"scope": {
"level": "dataset"
},
"report": [
{
"result": [
{
"type": "QuantitativeResult",
"value": [
"true"
]
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "The measure will take the value true if all the requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"MD101"
]
},
"type": "ConceptualConsistency"
},
{
"result": [
{
"valueUnit": "%",
"type": "QuantitativeResult",
"value": [
0
]
}
],
"measure": {
"measureIdentification": {
"code": "211",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Quality degradation - rate of imperfect coverage.",
"nameOfMeasure": [
"MD211"
]
},
"evaluationMethod": [
{
"type": "FullInspection",
"evaluationMethodDescription": "Automatic quality degradation check."
}
],
"type": "Omission"
},
{
"measure": {
"measureIdentification": {
"code": "7",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Cloud cover",
"nameOfMeasure": [
"Percentage of image obscured by cloud"
]
},
"evaluationMethod": [
{
"evaluationMethodType": "directInternal",
"type": "FullInspection",
"evaluationMethodDescription": "N/A."
}
],
"type": "Omission",
"results": [
{
"valueUnit": "%",
"type": "QuantitativeResult",
"value": [
4
]
}
]
}
]
}
],
"resourceLineage": [
{
"processStep": [
{
"output": [
{
"source": [
{
"sourceCitation": {
"code": "did:web:emc.spacebel.be:collections:TropForest:items:KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026",
"title": "KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026"
}
}
]
}
],
"processingInformation": {},
"stepDateTime": {
"created": "2012-01-04T00:00:00Z"
},
"processor": [
{
"role": "processor",
"party": [
{
"name": "Astrium Services",
"type": "CI_Organisation"
}
]
}
]
}
]
}
],
"dateInfo": {
"revision": "2024-04-30T11:32:32Z"
},
"distributionInfo": [
{
"distributor": [],
"transferOptions": [
{
"onLine": [
{
"function": "download",
"name": "data",
"description": "Download",
"linkage": "https://tpm-ds.eo.esa.int/oads/data/Tropforest/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP"
},
{
"function": "browseGraphic",
"name": "previews",
"description": "QUICKLOOK",
"linkage": "http://tpm-ds.eo.esa.int/oads/meta/Tropforest/browse/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_BID.JPG"
},
{
"function": "browseGraphic",
"name": "previews",
"description": "THUMBNAIL",
"linkage": "http://tpm-ds.eo.esa.int/oads/meta/Tropforest/thumbnail/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_TIMG.jpg"
}
]
}
]
}
],
"metadataScope": [
{
"resourceScope": "dataset",
"name": "dataset"
}
]
}
}
Example: 2.2.1
> Extract ISO19115-4 quality information for the product.
Listing E.28
# response = requests.get(URL_LANDING_PAGE + 'collections/PROBA.HRC.1A',
# headers={'Accept': 'application/vnd.iso.19115-4+json'})
# data = json.loads(response.text)
jstr = json.dumps(data['properties']['dataQualityInfo'], indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.29
[
{
"scope": {
"level": "dataset"
},
"report": [
{
"result": [
{
"type": "QuantitativeResult",
"value": [
"true"
]
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "The measure will take the value true if all the requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"MD101"
]
},
"type": "ConceptualConsistency"
},
{
"result": [
{
"valueUnit": "%",
"type": "QuantitativeResult",
"value": [
0
]
}
],
"measure": {
"measureIdentification": {
"code": "211",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Quality degradation - rate of imperfect coverage.",
"nameOfMeasure": [
"MD211"
]
},
"evaluationMethod": [
{
"type": "FullInspection",
"evaluationMethodDescription": "Automatic quality degradation check."
}
],
"type": "Omission"
},
{
"measure": {
"measureIdentification": {
"code": "7",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Cloud cover",
"nameOfMeasure": [
"Percentage of image obscured by cloud"
]
},
"evaluationMethod": [
{
"evaluationMethodType": "directInternal",
"type": "FullInspection",
"evaluationMethodDescription": "N/A."
}
],
"type": "Omission",
"results": [
{
"valueUnit": "%",
"type": "QuantitativeResult",
"value": [
4
]
}
]
}
]
}
]
Example: 2.2.2
> Extract ISO19157-2 quality information for the product.
Listing E.30
response = requests.get( item_url,
headers={'Accept': 'application/vnd.iso.19157-2+xml'})
xmlstr = minidom.parseString(response.text).toprettyxml(indent=' ',newl='')
md("```xml\n" + xmlstr + "\n```\n")
Listing E.31
<?xml version="1.0" ?><mdq:DQ_DataQuality xmlns:mdq="http://standards.iso.org/iso/19157/-2/mdq/1.0" xmlns:gco="http://standards.iso.org/iso/19115/-3/gco/1.0" xmlns:mcc="http://standards.iso.org/iso/19115/-3/mcc/1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/2001/XMLSchema#">
<mdq:scope>
<mcc:MD_Scope>
<mcc:level>
<mcc:MD_ScopeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset"/>
</mcc:level>
</mcc:MD_Scope>
</mdq:scope>
<mdq:report>
<mdq:DQ_CompletenessOmission>
<mdq:measure>
<mdq:DQ_MeasureReference>
<mdq:measureIdentification>
<mcc:MD_Identifier>
<mcc:authority xlink:href="https://www.iso.org/"/>
<mcc:code>
<gco:CharacterString>7</gco:CharacterString>
</mcc:code>
<mcc:codeSpace>
<gco:CharacterString>https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/</gco:CharacterString>
</mcc:codeSpace>
</mcc:MD_Identifier>
</mdq:measureIdentification>
<mdq:nameOfMeasure>
<gco:CharacterString>Percentage of image obscured by cloud</gco:CharacterString>
</mdq:nameOfMeasure>
<mdq:measureDescription>
<gco:CharacterString>Cloud cover</gco:CharacterString>
</mdq:measureDescription>
</mdq:DQ_MeasureReference>
</mdq:measure>
<mdq:evaluationMethod>
<mdq:DQ_FullInspection>
<mdq:evaluationMethodType>
<mdq:DQ_EvaluationMethodTypeCode codeList="http://standards.iso.org/iso/19157/-2/mdq/1.0/codelists.xml#DQ_EvaluationMethodTypeCode" codeListValue="directInternal"/>
</mdq:evaluationMethodType>
</mdq:DQ_FullInspection>
</mdq:evaluationMethod>
<mdq:result>
<mdq:DQ_QuantitativeResult>
<mdq:value>
<gco:Record>
<xsd:decimal>4.0</xsd:decimal>
</gco:Record>
</mdq:value>
<mdq:valueUnit xlink:href="urn:ogc:def:uom:OGC:1.0:percent"/>
<mdq:valueRecordType>
<gco:RecordType>decimal</gco:RecordType>
</mdq:valueRecordType>
</mdq:DQ_QuantitativeResult>
</mdq:result>
</mdq:DQ_CompletenessOmission>
</mdq:report>
</mdq:DQ_DataQuality>
Example: 2.2.3
> Extract ISO19115-3 quality information for the product.
Listing E.32
response = requests.get( item_url,
headers={'Accept': 'application/vnd.iso.19115-3+xml'})
# xmlstr = minidom.parseString(response.text).toprettyxml(indent=' ',newl='')
# md("```xml\n" + xmlstr + "\n```\n")
Listing E.33
root = ElementTree.fromstring(response.text)
ns = {'mdb': 'http://standards.iso.org/iso/19115/-3/mdb/1.0'}
el = root.find('mdb:dataQualityInfo', ns)
xmltxt = ElementTree.tostring(el, encoding='unicode', method='xml')
# md("```xml\n" + xmltxt + "\n```\n")
xmlstr = minidom.parseString(xmltxt).toprettyxml(indent=' ',newl='')
md("```xml\n" + xmlstr + "\n```\n")
Listing E.34
<?xml version="1.0" ?><ns0:dataQualityInfo xmlns:ns0="http://standards.iso.org/iso/19115/-3/mdb/1.0" xmlns:ns1="http://standards.iso.org/iso/19157/-2/mdq/1.0" xmlns:ns2="http://standards.iso.org/iso/19115/-3/mcc/1.0" xmlns:ns3="http://www.w3.org/1999/xlink" xmlns:ns4="http://standards.iso.org/iso/19115/-3/gco/1.0" xmlns:ns5="http://www.w3.org/2001/XMLSchema#">
<ns1:DQ_DataQuality>
<ns1:scope>
<ns2:MD_Scope>
<ns2:level>
<ns2:MD_ScopeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset"/>
</ns2:level>
</ns2:MD_Scope>
</ns1:scope>
<ns1:report>
<ns1:DQ_CompletenessOmission>
<ns1:measure>
<ns1:DQ_MeasureReference>
<ns1:measureIdentification>
<ns2:MD_Identifier>
<ns2:authority ns3:href="https://www.iso.org/"/>
<ns2:code>
<ns4:CharacterString>7</ns4:CharacterString>
</ns2:code>
<ns2:codeSpace>
<ns4:CharacterString>https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/</ns4:CharacterString>
</ns2:codeSpace>
</ns2:MD_Identifier>
</ns1:measureIdentification>
<ns1:nameOfMeasure>
<ns4:CharacterString>Percentage of image obscured by cloud</ns4:CharacterString>
</ns1:nameOfMeasure>
<ns1:measureDescription>
<ns4:CharacterString>Cloud cover</ns4:CharacterString>
</ns1:measureDescription>
</ns1:DQ_MeasureReference>
</ns1:measure>
<ns1:evaluationMethod>
<ns1:DQ_FullInspection>
<ns1:evaluationMethodType>
<ns1:DQ_EvaluationMethodTypeCode codeList="http://standards.iso.org/iso/19157/-2/mdq/1.0/codelists.xml#DQ_EvaluationMethodTypeCode" codeListValue="directInternal"/>
</ns1:evaluationMethodType>
</ns1:DQ_FullInspection>
</ns1:evaluationMethod>
<ns1:result>
<ns1:DQ_QuantitativeResult>
<ns1:value>
<ns4:Record>
<ns5:decimal>4.0</ns5:decimal>
</ns4:Record>
</ns1:value>
<ns1:valueUnit ns3:href="urn:ogc:def:uom:OGC:1.0:percent"/>
<ns1:valueRecordType>
<ns4:RecordType>decimal</ns4:RecordType>
</ns1:valueRecordType>
</ns1:DQ_QuantitativeResult>
</ns1:result>
</ns1:DQ_CompletenessOmission>
</ns1:report>
</ns1:DQ_DataQuality>
</ns0:dataQualityInfo>
Example: 2.2.4
> Request GeoDCAT-AP encoding (RDF/XML) with quality information for the product.
Listing E.35
response = requests.get( item_url,
headers={'Accept': 'application/rdf+xml;profile="http://data.europa.eu/930/"'})
xmlstr = minidom.parseString(response.text).toprettyxml(indent=' ',newl='')
md("```xml\n" + xmlstr + "\n```\n")
Listing E.36
<?xml version="1.0" ?><rdf:RDF xmlns:ldp="http://www.w3.org/ns/ldp#" xmlns:geo="http://a9.com/-/opensearch/extensions/geo/1.0/" xmlns:locn="http://www.w3.org/ns/locn#" xmlns:dct="http://purl.org/dc/terms/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dqv="http://www.w3.org/ns/dqv#" xmlns:adms="http://www.w3.org/ns/adms#" xmlns:prov="http://www.w3.org/ns/prov#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:owc="http://www.opengis.net/ont/owc/1.0/" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:eo="http://a9.com/-/opensearch/extensions/eo/1.0/" xmlns:iana="http://www.iana.org/assignments/relation/" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:os="http://a9.com/-/spec/opensearch/1.1/" xmlns:isodqm="http://www.opengis.net/def/metamodel/isodqm/" xmlns:void="http://rdfs.org/ns/void#" xmlns:time="http://a9.com/-/opensearch/extensions/time/1.0/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:vcard="http://www.w3.org/2006/vcard/ns#" xmlns:gsp="http://www.opengis.net/ont/geosparql#" xmlns:dcat="http://www.w3.org/ns/dcat#" xmlns:atom="http://www.w3.org/2005/Atom/" xmlns:foaf="http://xmlns.com/foaf/0.1/">
<dcat:Dataset rdf:about="https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026">
<foaf:depiction>http://tpm-ds.eo.esa.int/oads/meta/Tropforest/browse/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_BID.JPG</foaf:depiction>
<dct:conformsTo rdf:resource="http://www.opengis.net/def/serviceType/ogc/wcs"/>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/previews</dcat:hadRole>
<dct:title>THUMBNAIL</dct:title>
<dct:relation>http://tpm-ds.eo.esa.int/oads/meta/Tropforest/thumbnail/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_TIMG.jpg</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>image/jpeg</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>ISO19115-4</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/vnd.iso.19115-4%2Bjson</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/vnd.iso.19115-4+json</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dct:description>Dataset KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026 from TropForest acquired 2009-11-21T03:27:23Z</dct:description>
<foaf:isPrimaryTopicOf>
<dcat:CatalogRecord>
<dct:source>
<dcat:CatalogRecord rdf:about="https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/gml%2Bxml&recordSchema=om">
<dct:conformsTo>
<dct:Standard>
<dct:title>OGC10-157r4</dct:title>
</dct:Standard>
</dct:conformsTo>
</dcat:CatalogRecord>
</dct:source>
<dct:modified>2024-04-30T11:32:32Z</dct:modified>
<dct:identifier>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026</dct:identifier>
<dct:conformsTo>https://joinup.ec.europa.eu/release/geodcat-ap/20</dct:conformsTo>
</dcat:CatalogRecord>
</foaf:isPrimaryTopicOf>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>OGC 10-157r3 metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/gml%2Bxml&recordSchema=om10</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/gml+xml;profile="http://www.opengis.net/spec/EOMPOM/1.0"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>JSON-LD (schema.org) metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/ld%2Bjson;profile=https://schema.org</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/ld+json;profile="https://schema.org"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>RDF/XML metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/rdf%2Bxml</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/rdf+xml</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:distribution>
<dcat:Distribution>
<dcat:mediaType>application/zip</dcat:mediaType>
<dcat:downloadURL>https://tpm-ds.eo.esa.int/oads/data/Tropforest/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP</dcat:downloadURL>
</dcat:Distribution>
</dcat:distribution>
<dcat:endpointDescription>
<owc:Offering>
<owc:operations>
<owc:Operation>
<owc:type>image/tif</owc:type>
<owc:method>GET</owc:method>
<owc:href>https://wcs.maap.eo.esa.int/wcs?service=WCS&Request=GetCoverage&coverageId=TROPFOREST&subset=Lat(25.92713265,26.08689352)&subset=Long(95.91153308,96.09259599)&subset=time(2009-11-21T03:27:23Z,2009-11-21T03:27:23Z)</owc:href>
<owc:code>GetCoverage</owc:code>
</owc:Operation>
</owc:operations>
<owc:operations>
<owc:Operation>
<owc:type>text/xml</owc:type>
<owc:method>GET</owc:method>
<owc:href>https://wcs.maap.eo.esa.int/wcs?service=WCS&Request=DescribeCoverage&coverageId=TROPFOREST</owc:href>
<owc:code>DescribeCoverage</owc:code>
</owc:Operation>
</owc:operations>
<owc:operations>
<owc:Operation>
<owc:type>text/xml</owc:type>
<owc:method>GET</owc:method>
<owc:href>https://wcs.maap.eo.esa.int/wcs?service=WCS&request=GetCapabilities</owc:href>
<owc:code>GetCapabilities</owc:code>
</owc:Operation>
</owc:operations>
<owc:code rdf:resource="http://www.opengis.net/spec/owc-geojson/1.0/req/wcs"/>
</owc:Offering>
</dcat:endpointDescription>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/previews</dcat:hadRole>
<dct:title>QUICKLOOK</dct:title>
<dct:relation>http://tpm-ds.eo.esa.int/oads/meta/Tropforest/browse/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_BID.JPG</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>image/jpeg</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>Atom format</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/atom%2Bxml</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/atom+xml</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>STAC metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/geo%2Bjson;profile="https://stacspec.org"</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/geo+json;profile="https://stacspec.org"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>Verifiable Presentation</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/vp%2Bld%2Bjson</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/vp+ld+json</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dct:type>http://inspire.ec.europa.eu/metadata-codelist/ResourceType/dataset</dct:type>
<dct:identifier>KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026</dct:identifier>
<dct:title>KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026</dct:title>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>OGC 10-157r4 metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/gml%2Bxml&recordSchema=om</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/gml+xml;profile="http://www.opengis.net/spec/EOMPOM/1.1"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:distribution>
<dcat:Distribution>
<dcat:mediaType>image/jpeg</dcat:mediaType>
<dcat:downloadURL>http://tpm-ds.eo.esa.int/oads/meta/Tropforest/thumbnail/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_TIMG.jpg</dcat:downloadURL>
</dcat:Distribution>
</dcat:distribution>
<prov:wasGeneratedBy>
<prov:Activity>
<prov:used>
<prov:Entity>
<dct:title>KOMPSAT</dct:title>
</prov:Entity>
</prov:used>
<prov:used>
<prov:Entity>
<dct:title>MSC</dct:title>
</prov:Entity>
</prov:used>
<prov:startedAtTime>2009-11-21T03:27:23Z</prov:startedAtTime>
<prov:endedAtTime>2009-11-21T03:27:23Z</prov:endedAtTime>
</prov:Activity>
</prov:wasGeneratedBy>
<dct:language rdf:resource="http://publications.europa.eu/resource/authority/language/ENG"/>
<dct:modified>2024-04-30T11:32:32Z</dct:modified>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/up</dcat:hadRole>
<dct:title>OGC 17-084r1 metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest?mode=owc</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/geo+json</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>JSON-LD (GeoDCAT-AP) metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/ld%2Bjson;profile=http://data.europa.eu/930/</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/ld+json;profile="http://data.europa.eu/930/"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>ISO 19115-3 metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/vnd.iso.19115-3%2Bxml</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/vnd.iso.19115-3+xml</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>Turtle (GeoDCAT-AP) metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=text/turtle;profile=http://data.europa.eu/930/</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>text/turtle;profile="http://data.europa.eu/930/"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dqv:hasQualityMeasurement>
<dqv:QualityMeasurement>
<dqv:value rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">4</dqv:value>
<dqv:isMeasurementOf>
<dqv:Metric rdf:about="https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/7">
<dqv:expectedDataType rdf:resource="http://www.w3.org/2001/XMLSchema#decimal"/>
<skos:prefLabel>7 - rate of missing items</skos:prefLabel>
<skos:definition>Indication that all requirements in the referred data product specification are fulfilled.</skos:definition>
<rdfs:label>Percentage of image obscured by cloud</rdfs:label>
<isodqm:measureID>7</isodqm:measureID>
<isodqm:elementName>omission</isodqm:elementName>
<dct:publisher rdf:resource="http://dbpedia.org/resource/International_Organization_for_Standardization"/>
</dqv:Metric>
</dqv:isMeasurementOf>
</dqv:QualityMeasurement>
</dqv:hasQualityMeasurement>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>RDF/XML (schema.org) metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/rdf%2Bxml;profile=https://schema.org</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/rdf+xml;profile="https://schema.org"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>OGC 17-003r2 metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?mode=owc</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/geo+json;profile="http://www.opengis.net/spec/eo-geojson/1.0"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>HTML</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=text/html</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>text/html</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>Turtle metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=text/turtle</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>text/turtle</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>Verifiable Credential</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/vc%2Bld%2Bjson</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/vc+ld+json</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:distribution>
<dcat:Distribution>
<dcat:mediaType>image/jpeg</dcat:mediaType>
<dcat:downloadURL>http://tpm-ds.eo.esa.int/oads/meta/Tropforest/browse/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026.ZIP_BID.JPG</dcat:downloadURL>
</dcat:Distribution>
</dcat:distribution>
<dct:isPartOf rdf:resource="https://emc.spacebel.be/collections/TropForest"/>
<dct:spatial>
<dct:Location>
<locn:geometry rdf:datatype="http://www.opengis.net/ont/geosparql#gmlLiteral"><gml:Envelope srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84"><gml:lowerCorner>95.91153308 25.92713265</gml:lowerCorner><gml:upperCorner>96.09259599 26.08689352</gml:upperCorner></gml:Envelope></locn:geometry>
<locn:geometry rdf:datatype="http://www.opengis.net/ont/geosparql#wktLiteral">POLYGON((95.91153308 26.08689352,95.91153308 25.92713265,96.09259599 25.92713265,96.09259599 26.08689352,95.91153308 26.08689352))</locn:geometry>
<locn:geometry rdf:datatype="http://www.opengis.net/ont/geosparql#geoJSONLiteral">{"type":"Polygon","coordinates":[[[95.91153308,26.08689352],[95.91153308,25.92713265],[96.09259599,25.92713265],[96.09259599,26.08689352],[95.91153308,26.08689352]]] }</locn:geometry>
</dct:Location>
</dct:spatial>
<dcat:endpointDescription>
<owc:Offering>
<owc:operations>
<owc:Operation>
<owc:type>image/png</owc:type>
<owc:method>GET</owc:method>
<owc:href>https://wms.maap.eo.esa.int/wmts?service=WMS&Request=GetMap&layers=TROPFOREST:RGB&transparent=TRUE&styles=default&format=image/png&width={width}&height={height}&time=2009-11-21T03:27:23Z,2009-11-21T03:27:23Z</owc:href>
<owc:code>GetMap</owc:code>
</owc:Operation>
</owc:operations>
<owc:operations>
<owc:Operation>
<owc:type>application/xml</owc:type>
<owc:method>GET</owc:method>
<owc:href>https://wms.maap.eo.esa.int/wmts?service=WMS&request=GetCapabilities</owc:href>
<owc:code>GetCapabilities</owc:code>
</owc:Operation>
</owc:operations>
<owc:code rdf:resource="http://www.opengis.net/spec/owc-geojson/1.0/req/wms"/>
</owc:Offering>
</dcat:endpointDescription>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>Turtle (schema.org) metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=text/turtle;profile=https://schema.org</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>text/turtle;profile="https://schema.org"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>Verifiable Credential 2.0</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/vc%2Bld%2Bjson;version=2.0</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/vc+ld+json;version=2.0</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>ISO 19139 metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/vnd.iso.19139%2Bxml</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/vnd.iso.19139+xml</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dct:temporal>
<dct:PeriodOfTime>
<dcat:startDate rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2009-11-21T03:27:23Z</dcat:startDate>
<dcat:endDate rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2009-11-21T03:27:23Z</dcat:endDate>
</dct:PeriodOfTime>
</dct:temporal>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>OGC 17-069r3 metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/geo+json;profile="http://www.opengis.net/spec/ogcapi-features-1/1.0"</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
<dcat:qualifiedRelation>
<dcat:Relationship>
<dcat:hadRole>http://www.iana.org/assignments/relation/alternate</dcat:hadRole>
<dct:title>JSON-LD metadata</dct:title>
<dct:relation>https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/ld%2Bjson</dct:relation>
<dct:format>
<dct:MediaType>
<rdfs:label>application/ld+json</rdfs:label>
</dct:MediaType>
</dct:format>
</dcat:Relationship>
</dcat:qualifiedRelation>
</dcat:Dataset>
</rdf:RDF>
Example: 2.3
> Extract the Citation with the DID identifier from the ISO19115-4 metadata of a product
Listing E.37
jstr = json.dumps(data['properties']['identificationInfo']['citation'], indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.38
{
"identifier": [
{
"code": "KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026"
},
{
"code": "did:web:emc.spacebel.be:collections:TropForest:items:KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026"
}
Listing E.39
# Extract the DID (shortcut assuming it is the 2nd id for simplicity)
did = data['properties']['identificationInfo']['citation']['identifier'][1]['code']
did
Figure E.5
'did:web:emc.spacebel.be:collections:TropForest:items:KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026'
Example: 2.4
> Obtain the DID document for the product. The DID document advertizes the existence of a service to obtain the corresponding Verifiable Presentation (#vp) and the DID Registry endpoint to obtain the Verificable Credential(s). These services definitions are according to the W3C specifications https://www.w3.org/TR/did-extensions-properties/#linkedverifiablepresentation and https://www.w3.org/TR/did-extensions-properties/#credentialregistry and refer to the DIF specification https://identity.foundation/linked-vp/.
Listing E.40
# resolve DID
# The controller property in DID document for a collection should be the issuer
print(did)
response = requests.get( DID_RESOLVER + did,
headers={ 'Accept': 'application/json' })
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Figure E.6
did:web:emc.spacebel.be:collections:TropForest:items:KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026
Listing E.41
{
"controller": "did:web:emc.spacebel.be:organisations:esa_esrin",
"service": [
{
"id": "#vp",
"serviceEndpoint": "https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/vp%2Bld%2Bjson",
"type": "LinkedVerifiablePresentation"
},
{
"id": "#vc",
"serviceEndpoint": {
"registries": [
"https://emc.spacebel.be/registry/vcs/{credentialSubject.id}"
]
},
"type": "CredentialRegistry"
}
],
"id": "did:web:emc.spacebel.be:collections:TropForest:items:KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026",
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1",
"https://identity.foundation/linked-vp/contexts/v1"
],
"alsoKnownAs": [
"https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026",
"https://emc.spacebel.be/collections/TropForest/items/KO2_OTPF_KO2_MSC_2F_20091121T032723_20091121T032723_017702_E096_N026?httpAccept=application/vnd.iso.19115-4%2Bjson"
]
}
E.3.2. 2.2 Provenance information OGC 17-003r2, OGC 10-157r4
Example: 2.6
> Get ISO19115-4 metadata for a Biomass product (with provenance/lineage information) using content negotiation
Listing E.42
item_url = URL_LANDING_PAGE + 'collections/BiomassLevel1aIOC/items/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4'
response = requests.get( item_url,
headers={'Accept': 'application/vnd.iso.19115-4+json'})
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
# jstr = json.dumps(data['properties']['dataQualityInfo'], indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.43
{
"bbox": [
-70.52321,
-42.22084,
-69.409775,
-40.855946
],
"geometry": {
"coordinates": [
[
[
-70.52321,
-42.104725
],
[
-69.75153,
-42.22084
],
[
-69.409775,
-40.96954
],
[
-70.1544,
-40.855946
],
[
-70.52321,
-42.104725
]
]
],
"type": "Polygon"
},
"conformsTo": [
"https://standards.iso.org/iso/19115/-4/0.1/core",
"https://standards.iso.org/iso/19115/-4/0.1/data-quality-core",
"https://standards.iso.org/iso/19115/-4/0.1/no-ref"
],
"id": "BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4",
"type": "Feature",
"properties": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"identificationInfo": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"extent": [
{
"geographicElement": [
{
"northBoundLatitude": -40.855946,
"southBoundLatitude": -42.22084,
"type": "EX_GeographicBoundingBox",
"westBoundLongitude": -70.52321,
"eastBoundLongitude": -69.409775
}
]
}
],
"processingLevel": {
"code": "1A"
},
"parentMetadata": {
"identifier": [
{
"code": "BiomassLevel1aIOC"
},
{
"code": "did:web:emc.spacebel.be:collections:BiomassLevel1aIOC",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "BiomassLevel1aIOC"
},
"citation": {
"identifier": [
{
"code": "BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4"
},
{
"code": "did:web:emc.spacebel.be:collections:BiomassLevel1aIOC:items:BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4"
},
"abstract": "BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4"
},
"metadataStandard": [
{
"title": "ISO 19115-1:2014"
},
{
"title": "ISO 19115-4"
}
],
"contact": [
{
"role": "pointOfContact",
"party": [
{
"contactInfo": [
{
"address": [
{
"deliveryPoint": [
"Largo Galileo Galilei 1"
],
"country": "Italy",
"city": "Frascati (Roma)",
"postalCode": "00044",
"electronicMailAddress": [
"contactesrin@esa.int"
]
}
],
"phone": {
"voice": "tel:+3906941801"
}
}
],
"name": "ESA/ESRIN",
"type": "CI_Organisation"
}
]
}
],
"dataQualityInfo": [
{
"scope": {
"level": "dataset"
},
"report": [
{
"result": [
{
"type": "QuantitativeResult",
"value": [
"true"
]
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "The measure will take the value true if all the requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"MD101"
]
},
"type": "ConceptualConsistency"
},
{
"result": [
{
"valueUnit": "%",
"type": "QuantitativeResult",
"value": [
0
]
}
],
"measure": {
"measureIdentification": {
"code": "211",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Quality degradation - rate of imperfect coverage.",
"nameOfMeasure": [
"MD211"
]
},
"evaluationMethod": [
{
"type": "FullInspection",
"evaluationMethodDescription": "Automatic quality degradation check."
}
],
"type": "Omission"
}
]
}
],
"resourceLineage": [
{
"statement": "Biomass L1 Processor",
"processStep": [
{
"reference": [
{
"title": "BIOMASS L1a/b/c Products Format Specification (BPS_L1_PFD) V1.2.9"
},
{
"title": "BIOMASS Product Performance Description (BPS_PPD) V3.1.3"
}
],
"output": [
{
"source": [
{
"sourceCitation": {
"code": "did:web:emc.spacebel.be:collections:BiomassLevel1aIOC:items:BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4",
"title": "BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4"
}
}
]
}
],
"processingInformation": {
"softwareReference": {
"edition": "3.1.3",
"title": "Biomass L1 Processor"
}
},
"description": "Biomass L1 Processor",
"stepDateTime": {
"created": "2025-06-02T19:55:16Z"
},
"source": [
{
"sourceCitation": {
"title": "BIO_S1_RAW__0S_20250531T222451_20250531T222648_C_G___M___C___T____F039_01_D9M2OX"
}
},
{
"sourceCitation": {
"title": "BIO_S1_RAW__0M_20250531T221052_20250531T222854_C_G___M___C___T____F____01_D9M42F"
}
}
],
"processor": [
{
"role": "processor",
"party": [
{
"name": "Biomass CPF",
"type": "CI_Organisation"
}
]
}
]
}
]
}
],
"dateInfo": {
"revision": "2025-07-26T10:13:47Z"
},
"distributionInfo": [
{
"distributor": [],
"transferOptions": [
{
"onLine": [
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_orb.xml",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/annotation/navigation/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_orb.xml"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_att.xml",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/annotation/navigation/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_att.xml"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_lut.nc",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/annotation/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_lut.nc"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_annot.xml",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/annotation/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_annot.xml"
},
{
"function": "download",
"name": "data",
"description": "bio-l1ab-main-annotation.xsd",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1ab-main-annotation.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-l1-annotations.xsd",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1-annotations.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-l1-overlay.xsd",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1-overlay.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-l1-overlay-support.xsd",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1-overlay-support.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-common-types.xsd",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-common-types.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-aux-orbit.xsd",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-aux-orbit.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-aux-attitude.xsd",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-aux-attitude.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-l1-vrt.xsd",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1-vrt.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i_abs.tiff",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/measurement/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i_abs.tiff"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i_phase.tiff",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/measurement/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i_phase.tiff"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i.vrt",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/measurement/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i.vrt"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_orb.xml",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/annotation/navigation/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_orb.xml"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_att.xml",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/annotation/navigation/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_att.xml"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_lut.nc",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/annotation/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_lut.nc"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_annot.xml",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/annotation/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_annot.xml"
},
{
"function": "download",
"name": "data",
"description": "bio-l1ab-main-annotation.xsd",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1ab-main-annotation.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-l1-annotations.xsd",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1-annotations.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-l1-overlay.xsd",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1-overlay.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-l1-overlay-support.xsd",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1-overlay-support.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-common-types.xsd",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-common-types.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-aux-orbit.xsd",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-aux-orbit.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-aux-attitude.xsd",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-aux-attitude.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio-l1-vrt.xsd",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/schema/bio-l1-vrt.xsd"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i_abs.tiff",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/measurement/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i_abs.tiff"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i_phase.tiff",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/measurement/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i_phase.tiff"
},
{
"function": "download",
"name": "data",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i.vrt",
"linkage": "s3://biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/measurement/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_i.vrt"
},
{
"function": "browseGraphic",
"name": "previews",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_ql.png",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/preview/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_ql.png"
},
{
"function": "browseGraphic",
"name": "previews",
"description": "bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_map.kmz",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/preview/bio_s1_scs__1s_20250531t222456_20250531t222517_c_g___m___c___t____f191_map.kmz"
},
{
"function": "browseGraphic",
"name": "icon",
"description": "BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4.BI.PNG",
"linkage": "https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/public/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4.BI.PNG"
}
]
}
]
}
],
"metadataScope": [
{
"resourceScope": "dataset",
"name": "dataset"
}
]
}
}
E.4. W3C DID Identifiers
This section gives examples of DID documents. The actual DID identifiers can be found in the corresponding metadata records. An interactive DID resolver is available at https://dev.uniresolver.io/. In practice, the DID of different data providers can be of different types and are not expected to have a systematic naming convention as in this Demonstrator.
We assume that the following entities are identified via a DID:
Organisation
EO Collection
EO Product/Granule
E.4.1. 3.1 DID Identifiers for Organisations
Example DID document
Listing E.44
# resolve DID
did = DID_ISSUERS[0]
print(did)
response = requests.get( DID_RESOLVER + did,
headers={ 'Accept': 'application/json' })
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Figure E.7
did:web:emc.spacebel.be:organisations:esa_esrin
Listing E.45
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1"
],
"id": "did:web:emc.spacebel.be:organisations:esa_esrin",
"alsoKnownAs": [
"https://gcmd.earthdata.nasa.gov/kms/concept/c56b4a86-82f8-4f15-98ba-c5f7abe8ee5a",
"https://yago-knowledge.org/resource/European_Space_Agency",
"https://dbpedia.org/resource/European_Space_Agency",
"https://ror.org/03wd9za21"
],
"verificationMethod": [
{
"id": "did:web:emc.spacebel.be:organisations:esa_esrin#owner",
"type": "JsonWebKey2020",
"controller": "did:web:emc.spacebel.be:organisations:esa_esrin",
"publicKeyJwk": {
"kty": "EC",
"crv": "secp256k1",
"x": "yKemFmBtShtFrYfZHj9D3h83FntzLcCbLm8n1O4VOyI",
"y": "ssJjEkBMsd4OFejeKNiCZRhJYuTaITyEGz93Ti0gfqw"
}
}
],
"assertionMethod": [
"did:web:emc.spacebel.be:organisations:esa_esrin#owner"
]
}
E.4.2. 3.2 DID Identifiers for Collections
List a number of examples of DID for EO collections from various providers.
Example DID document
Listing E.46
# resolve DID
did = DID_COLLECTIONS[2]
print(did)
response = requests.get( DID_RESOLVER + did,
headers={ 'Accept': 'application/json' })
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Figure E.8
did:web:emc.spacebel.be:collections:AMZ1-WFI-L4-SR-1
Listing E.47
{
"controller": "did:web:emc.spacebel.be:organisations:br_inpe",
"id": "did:web:emc.spacebel.be:collections:AMZ1-WFI-L4-SR-1",
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1"
],
"alsoKnownAs": [
"https://emc.spacebel.be/collections/AMZ1-WFI-L4-SR-1",
"https://emc.spacebel.be/collections/AMZ1-WFI-L4-SR-1?httpAccept=application/vnd.iso.19115-4%2Bjson"
]
}
E.4.3. 3.3 DID Identifiers for Products
Listing E.48
did = DID_COLLECTIONS[INDEX_ESA] + ":items:" + "PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001"
print(did)
Figure E.9
did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001
Listing E.49
# resolve DID
response = requests.get( DID_RESOLVER + did,
headers={ 'Accept': 'application/json' })
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.50
{
"controller": "did:web:emc.spacebel.be:organisations:esa_esrin",
"service": [
{
"id": "#vp",
"serviceEndpoint": "https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001?httpAccept=application/vp%2Bld%2Bjson",
"type": "LinkedVerifiablePresentation"
},
{
"id": "#vc",
"serviceEndpoint": {
"registries": [
"https://emc.spacebel.be/registry/vcs/{credentialSubject.id}"
]
},
"type": "CredentialRegistry"
}
],
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001",
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1",
"https://identity.foundation/linked-vp/contexts/v1"
],
"alsoKnownAs": [
"https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001",
"https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001?httpAccept=application/vnd.iso.19115-4%2Bjson"
]
}
Obtain the corresponding VC via the VP which is directly accessible via the DID Document. See https://www.w3.org/TR/did-extensions-properties/#linkedverifiablepresentation.
Listing E.51
href = data["service"][0]['serviceEndpoint']
response = requests.get( href,
headers={ 'Accept': 'application/json' })
data = json.loads(response.text)
jstr = json.dumps(data["verifiableCredential"], indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.52
[
{
"relatedResource": [
{
"digestMultibase": "zQmYRMC8UMw4ipWvivUKvzvTWrjbKk1oywH1QpoY6w3tCQX",
"id": "https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld"
},
{
"digestMultibase": "zQmbyT7S2G7FS8N3asZsYSqSc3hCGepLkgSxvxYQUddGACD",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP_BID.PNG"
},
{
"digestMultibase": "zQmeuPEJqShU5NvJvxejNqpH8WnTM1h4RrQz1YtxCXvBEtR",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP_TIMG.jpg"
}
],
"credentialSubject": {
"date": "2016-05-05T08:36:37Z/2016-05-05T08:36:37Z",
"bbox": [
114.6,
-28.8,
114.62,
-28.76
],
"geometry": {
"coordinates": [
[
[
114.62,
-28.8
],
[
114.62,
-28.76
],
[
114.6,
-28.76
],
[
114.6,
-28.8
],
[
114.62,
-28.8
]
]
],
"type": "Polygon"
},
"links": {
"data": [
{
"href": "https://tpm-ds.eo.esa.int/oads/data/PROBA1-HRC/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP",
"title": "Download",
"type": "application/x-binary"
}
],
"previews": [
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP_BID.PNG",
"title": "QUICKLOOK",
"type": "image/png"
},
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP_TIMG.jpg",
"title": "THUMBNAIL",
"type": "image/jpeg"
}
]
},
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001",
"title": "PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001",
"updated": "2024-04-30T11:28:07Z"
},
"issuanceDate": "2026-02-12T12:41:28Z",
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001",
"proof": {
"created": "2026-02-12T12:41:28.575Z",
"jws": "eyJhbGciOiJFUzI1NksiLCJraWQiOiJiQnpXOHlHeEt1RUNMal9JeFNyTkN1eVJKOUppZ2ptTU9DeDJGZHpDcnFBIiwiY3JpdCI6WyJiNjQiXSwiYjY0IjpmYWxzZX0..xbgj6l8B22jUvhFwXjV9i-VJFlJDk1pwA42NlQ0NLjh3DsCO_1oicOKyflAlrcmC9LI1s39u4Y2hfAgkaH5cEA",
"proofPurpose": "assertionMethod",
"type": "EcdsaSecp256k1Signature2019",
"verificationMethod": "did:web:emc.spacebel.be:organisations:esa_esrin#owner"
},
"type": [
"VerifiableCredential",
"Feature"
],
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld",
{
"digestMultibase": {
"@type": "https://w3id.org/security#multibase",
"@id": "https://w3id.org/security#digestMultibase"
},
"relatedResource": {
"@type": "@id",
"@id": "https://www.w3.org/2018/credentials#relatedResource"
}
}
],
"issuer": "did:web:emc.spacebel.be:organisations:esa_esrin"
}
]
Obtain the VC via the registry endpoint provided in the DID Document. See https://www.w3.org/TR/did-extensions-properties/#credentialregistry
Listing E.53
# resolve DID
response = requests.get( DID_RESOLVER + did,
headers={ 'Accept': 'application/json' })
data = json.loads(response.text)
Listing E.54
href = data["service"][1]['serviceEndpoint']['registries'][0]
href
Figure E.10
'https://emc.spacebel.be/registry/vcs/{credentialSubject.id}'Listing E.55
didFigure E.11
'did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001'
Listing E.56
# Replace the id with the DID of the subject for which the VC is requested.
url = href.replace('{credentialSubject.id}',did)
url
Figure E.12
'https://emc.spacebel.be/registry/vcs/did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001'
Listing E.57
# Get the VCS from the registry
response = requests.get( url,
headers={ 'Accept': 'application/json' })
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.58
[
{
"relatedResource": [
{
"digestMultibase": "zQmYRMC8UMw4ipWvivUKvzvTWrjbKk1oywH1QpoY6w3tCQX",
"id": "https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld"
},
{
"digestMultibase": "zQmbyT7S2G7FS8N3asZsYSqSc3hCGepLkgSxvxYQUddGACD",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP_BID.PNG"
},
{
"digestMultibase": "zQmeuPEJqShU5NvJvxejNqpH8WnTM1h4RrQz1YtxCXvBEtR",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP_TIMG.jpg"
}
],
"credentialSubject": {
"date": "2016-05-05T08:36:37Z/2016-05-05T08:36:37Z",
"bbox": [
114.6,
-28.8,
114.62,
-28.76
],
"geometry": {
"coordinates": [
[
[
114.62,
-28.8
],
[
114.62,
-28.76
],
[
114.6,
-28.76
],
[
114.6,
-28.8
],
[
114.62,
-28.8
]
]
],
"type": "Polygon"
},
"links": {
"data": [
{
"href": "https://tpm-ds.eo.esa.int/oads/data/PROBA1-HRC/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP",
"title": "Download",
"type": "application/x-binary"
}
],
"previews": [
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP_BID.PNG",
"title": "QUICKLOOK",
"type": "image/png"
},
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001.SIP.ZIP_TIMG.jpg",
"title": "THUMBNAIL",
"type": "image/jpeg"
}
]
},
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001",
"title": "PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001",
"updated": "2024-04-30T11:28:07Z"
},
"issuanceDate": "2026-02-12T12:41:30Z",
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160505T083637_S28-078_E114-061_0001",
"proof": {
"created": "2026-02-12T12:41:30.489Z",
"jws": "eyJhbGciOiJFUzI1NksiLCJraWQiOiJiQnpXOHlHeEt1RUNMal9JeFNyTkN1eVJKOUppZ2ptTU9DeDJGZHpDcnFBIiwiY3JpdCI6WyJiNjQiXSwiYjY0IjpmYWxzZX0..2n6N-X0_dmO-2jJBkvN1_RsIkyjfNgqscsSCCaJ0owxpwKhmWl7s6YiBhLr21bhMop6aM8_ETc6tUU_0IHU02Q",
"proofPurpose": "assertionMethod",
"type": "EcdsaSecp256k1Signature2019",
"verificationMethod": "did:web:emc.spacebel.be:organisations:esa_esrin#owner"
},
"type": [
"VerifiableCredential",
"Feature"
],
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld",
{
"digestMultibase": {
"@type": "https://w3id.org/security#multibase",
"@id": "https://w3id.org/security#digestMultibase"
},
"relatedResource": {
"@type": "@id",
"@id": "https://www.w3.org/2018/credentials#relatedResource"
}
}
],
"issuer": "did:web:emc.spacebel.be:organisations:esa_esrin"
}
]
E.5. Interaction with OGC API Processes
E.5.1. 4.1 Get available processes
Listing E.59
OGC_API_PROCESSES = 'https://geoserver.ogc.secd.eu/geoserver/ogc/processes/v1'
url = OGC_API_PROCESSES + '/processes'
response = requests.get(url, headers={ 'Accept': 'application/json' })
# data = json.loads(response.text)
# jstr = json.dumps(data['processes'], indent=3)
# md("```json\n" + jstr + "\n```\n")
E.5.2. 4.2 Describe Trusted Watermarking Process
Listing E.60
url = OGC_API_PROCESSES + '/processes/gs:TrustedWatermarking'
response = requests.get(url, headers={ 'Accept': 'application/json' })
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.61
{
"id": "gs:TrustedWatermarking",
"links": [
{
"href": "https://geoserver.ogc.secd.eu/geoserver/ogc/processes/v1/processes/gs:TrustedWatermarking?f=application%2Fjson",
"rel": "self",
"type": "application/json",
"title": "This document"
},
{
"href": "https://geoserver.ogc.secd.eu/geoserver/ogc/processes/v1/processes/gs:TrustedWatermarking?f=application%2Fyaml",
"rel": "alternate",
"type": "application/yaml",
"title": "This document as application/yaml"
},
{
"href": "https://geoserver.ogc.secd.eu/geoserver/ogc/processes/v1/processes/gs:TrustedWatermarking?f=text%2Fhtml",
"rel": "alternate",
"type": "text/html",
"title": "This document as text/html"
}
],
"version": "1.0.0",
"title": "Trusted Watermarking WPS",
"description": "OGC Testbed-21 Watermarking Process that stores the provenance metadata on a Blockchain",
"jobControlOptions": [
"sync-execute",
"async-execute"
],
"inputs": {
"image_url": {
"title": "image_url",
"description": "URL of the input image to be watermarked",
"schema": {
"title": "string",
"type": "string"
},
"minOccurs": 1,
"maxOccurs": 1
},
"meta_url": {
"title": "meta_url",
"description": "URL of the STAC item describing the image (image_url) to be watermarked",
"schema": {
"title": "string",
"type": "string"
},
"minOccurs": 1,
"maxOccurs": 1
}
},
"outputs": {
"Asset": {
"title": "Asset",
"description": "The STAC Feature that is stored on the Blockchain",
"schema": {
"title": "string",
"type": "string"
}
}
}
}
E.5.3. 4.3 Execute Trusted Watermarking Process
The Watermarking Process does not use the VC as a direct input, so we cannot force in the request that it should use the VC 2.0 (if supported)
Listing E.62
url = OGC_API_PROCESSES + '/processes/gs:TrustedWatermarking/execution'
# CITE Tests, last execution - 08/01/2026 9h00 CET.
# OK - catalogue supports VC 1.0 (context compacted)
# - https://univerifier.io - OK
payload_1_proba = { 'inputs': { \
'image_url': 'http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG' , \
'meta_url': 'https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/geo%2Bjson;profile=https://stacspec.org' } }
# OK - catalogue supports VC 1.0 (context not compacted)
# - https://univerifier.io - OK
payload_2_oceansat = { 'inputs': { \
'image_url': 'http://tpm-ds.eo.esa.int/oads/meta/OceanSat2/browse/OC2_OPER_OCM2_LA_2C_20160601T115359_20160601T115728_035428_0003_0010_0141.ZIP_BID.PNG' , \
'meta_url': 'https://emc.spacebel.be/collections/OceanSat-2.NRT.data/items/OC2_OPER_OCM2_LA_2C_20160601T115359_20160601T115728_035428_0003_0010_0141?httpAccept=application/geo%2Bjson;profile=https://stacspec.org' } }
# OK - catalogue supports VC 1.0 (context not compacted)
# - https://univerifier.io - OK
payload_3_inpe = { 'inputs': { \
'image_url': 'https://data.inpe.br/bdc/data/s2-16d/v2/003/011/2025/11/01/S2-16D_V2_003011_20251101.png' , \
'meta_url': 'https://emc.spacebel.be/collections/S2-16D-2/items/S2-16D_V2_003011_20251101?httpAccept=application/geo%2Bjson;profile=https://stacspec.org' } }
# OK - catalogue supports VC 1.0 and VC 2.0 (context not compacted)
# - https://univerifier.io - OK
payload_4_dlr = { 'inputs': { \
'image_url': 'https://eoweb.dlr.de/hma/browse/dims_op_pl_eoweb1_XXXXB00000000228152914106/1/anonymous/2025-12-04-09-05-28' , \
'meta_url': 'https://emc.spacebel.be/collections/376e342e-3fb8-4d98-bd1e-51a204e1268b/items/urn:eop:DLR:EOWEB:Water_Parameter_Baltic_Sea_MERIS_seasonal_maps:%40dims_nz_pl_dfd_XXXXB00000000000113941439%40dims_nz_pl_dfd_%40%40ENVISAT.MERIS.VA.L3.RWC_PCI?httpAccept=application/geo%2Bjson;profile=https://stacspec.org' } }
# fails - catalogue supports VC 1.0 and VC 2.0 (context not compacted)
# - https://univerifier.io - OK
payload_5_jaxa = { 'inputs': { \
'image_url': 'https://gportal.jaxa.jp/gpr/img/br/P1AME020600A_P3SSW000700E0/P1AME020600A_P3SSW000700E0.jpg' , \
'meta_url': 'https://emc.spacebel.be/collections/Aqua_AMSR-E_L3_SSW_1month_0.25deg/items/P1AME020600A_P3SSW000700E0?httpAccept=application%2Fgeo%2Bjson%3Bprofile%3Dhttps%3A%2F%2Fstacspec.org' } }
# OK - catalogue supports VC 1.0 (context not compacted)
# - https://univerifier.io - OK
payload_6_biomass = { 'inputs': { \
'image_url': 'https://catalog.maap.eo.esa.int/data/biomass-pdgs-01/BiomassLevel1aIOC/2025/05/31/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4/public/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4.BI.PNG' , \
'meta_url': 'https://emc.spacebel.be/collections/BiomassLevel1aIOC/items/BIO_S1_SCS__1S_20250531T222456_20250531T222517_C_G___M___C___T____F191_01_D9M4O4?httpAccept=application/geo%2Bjson;profile=https://stacspec.org' } }
# OK - 22/01/2026 - catalogue supports VC 1.0 (context compacted)
# - https://univerifier.io - OK
payload_7_proba_chris = { 'inputs': { \
'image_url': 'http://tpm-ds.eo.esa.int/oads/meta/PROBA1-CHRIS/browse/PR1_OPER_CHR_MO1_1P_20020618T084000_N30-058_E034-008_0001.SIP.ZIP_BID.PNG' , \
'meta_url': 'https://emc.spacebel.be/collections/PROBA.CHRIS.1A/items/PR1_OPER_CHR_MO1_1P_20020618T084000_N30-058_E034-008_0001?httpAccept=application%2Fgeo%2Bjson%3Bprofile%3Dhttps%3A%2F%2Fstacspec.org' } }
payload = payload_1_proba
response = requests.post(url, json = payload, headers={ 'Accept': 'application/json' })
print(response.text)
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Figure E.13
{"stac_version":"1.0.0","assets":{"PRODUCT":{"file:checksum":"1e20cbe790d1f9193bb7ce70e7197f760c2b9188c19dabe2db8583abaa99e2b58c96","alternate":{"FACTS_Browser_Cookie":{"description":"In order to download the asset via a Web Browser, you first need to establish a connection with your wallet via https://assets.ogc.secd.eu/link so that the Asset Controller can request proof for FACTS Certificates via that secure and private connection when you try to fetch the Asset. Once you have a connection established, you can use the Download link above to fetch the GeoPackage.","href":"https://assets.ogc.secd.eu/files/683f5aa56037d688241e54cc004bc14fe3067d1c1f51c67133571efc29c6e3da","title":"Download Asset via Web Browser session cookie","type":"image/jpeg"},"FACTS_API_Key":{"auth":{"refs":["apiKey"],"roles":["download"],"schemes":{"flows":{"authorizationCode":{"authorizationApi":"https://wallet.ogc.secd.eu/user/x-facts-key","method":"get","responseField":"x-facts-key","parameters":{"expires_in":{"schema":{"examples":"300","type":"string"},"in":"query","description":"the validity of the token in seconds","required":"true"}}}},"in":"header","name":"X-FACTS-Key","description":"X-FACTS-Key represents the connection between your Wallet and the Asset Controller to request proof of required FACTS Certificates.","type":"apiKey","required":"true"}},"description":"In order to download the asset via the API, you first need to fetch an API-Key token (X-FACTS-Key) via https://wallet.ogc.secd.eu/connections/select which must be submitted as HTTP Header `X-FACTS-Key` with the asset URL from `Copy URL`. ","href":"https://assets.ogc.secd.eu/files/683f5aa56037d688241e54cc004bc14fe3067d1c1f51c67133571efc29c6e3da","title":"Download Asset via X-FACTS-Key","type":"image/jpeg"}},"href":"https://ipfs.ogc.secd.eu/files/683f5aa56037d688241e54cc004bc14fe3067d1c1f51c67133571efc29c6e3da","title":"Product","type":"image/jpeg"}},"bbox":[133.87,-23.68,133.9,-23.64],"geometry":{"coordinates":[[[133.9,-23.68],[133.9,-23.64],[133.87,-23.64],[133.87,-23.68],[133.9,-23.68]]],"type":"Polygon"},"links":[{"rel":"derived_from","href":"https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/geo%2Bjson;profile=https://stacspec.org","type":"application/geo+json","title":"Source metadata"},{"rel":"self","href":"https://ic.ogc.secd.eu/stac/collections/test_dq4ipt/items/asset_1770900095005","type":"application/geo+json","title":"asset_1770900095005"},{"rel":"collection","href":"https://ic.ogc.secd.eu/stac/collections/test_dq4ipt","type":"application/json","title":"test_dq4ipt"}],"collection":"test_dq4ipt","id":"asset_1770900095005","type":"Feature","stac_extensions":["https://stac-extensions.github.io/file/v2.1.0/schema.json","https://stac-extensions.github.io/alternate-assets/v1.1.0/schema.json","https://stac-extensions.github.io/processing/v1.2.0/schema.json","https://luciocola.github.io/stac-extension-liability-claims/json-schema/schema.json"],"properties":{"processing:level":"L1","datetime":"2026-02-12T12:41:35Z","start_datetime":"2016-02-04T07:28:52Z","end_datetime":"2016-02-04T07:28:52Z","processing:facility":"Secure Dimensions Processes","processing:lineage":"Watermarking Process","processing:datetime":"2026-02-12T12:41:35Z","liability:quality":{"scope":{"level":"series"},"report":[{"result":[{"pass":true,"specification":{"date":"2021-10-14T00:00:00Z","identifier":"https://ceos.org/spec/ard/conf","title":"CEOS ARD Normalised Radar Backscatter (CARD4L-NRB)"},"type":"ConformanceResult","resultType":"conformance"}],"measure":{"measureIdentification":{"code":"101","authority":{"alternateTitle":["ISO"],"title":"International Organization for Standardization"},"codeSpace":"https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"},"measureDescription":"The measure will take the value true if all the requirements in the referred data product specification are fulfilled.","nameOfMeasure":["Data product specification passed"]},"completeness":{"category":"completeness"},"type":"ConceptualConsistency","category":"completeness"}]},"processing:software":{"name":"Geoserver","version":"3.0-SNAPSHOT"},"ipt":{"output":{"image_height":1026,"file:checksum":"1e20cbe790d1f9193bb7ce70e7197f760c2b9188c19dabe2db8583abaa99e2b58c96","metadata_url":"https://ic.ogc.secd.eu/stac/collections/test_dq4ipt/items/asset_1770900095005","image_url":"https://assets.ogc.secd.eu/files/683f5aa56037d688241e54cc004bc14fe3067d1c1f51c67133571efc29c6e3da","image_width":1026,"image_type":"image/jpeg"},"input":{"image":{"image_height":1026,"file:checksum":"1220ecff1a367594707fe3603f73fdd6091b039b8e0b98c48d92643f84bc229cc471","image_url":"https://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG","image_width":1026,"image_type":"image/png;charset=UTF-8"},"metadata":{"metadata_url":"https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/geo%2Bjson;profile=https://stacspec.org","vc_url":"https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/vc%2Bld%2Bjson","VC_verification":true,"VC":{"relatedResource":[{"digestMultibase":"zQmYRMC8UMw4ipWvivUKvzvTWrjbKk1oywH1QpoY6w3tCQX","id":"https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld"},{"digestMultibase":"zQmeHnYH1jaUefpeAbARzC46rJSzSte8uWn52GGcQWXMcmn","id":"http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG"},{"digestMultibase":"zQmPFZfx6KoEAgPpFosgJEKQ17K7sJpsSZWtyNo7vwBHXyr","id":"http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_TIMG.jpg"}],"credentialSubject":{"date":"2016-02-04T07:28:52Z/2016-02-04T07:28:52Z","bbox":[133.87,-23.68,133.9,-23.64],"links":{"data":[{"href":"https://tpm-ds.eo.esa.int/oads/data/PROBA1-HRC/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP","title":"Download","type":"application/x-binary"}],"previews":[{"href":"http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG","title":"QUICKLOOK","type":"image/png"},{"href":"http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_TIMG.jpg","title":"THUMBNAIL","type":"image/jpeg"}]},"geometry":{"coordinates":[[[133.9,-23.68],[133.9,-23.64],[133.87,-23.64],[133.87,-23.68],[133.9,-23.68]]],"type":"Polygon"},"id":"did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001","title":"PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001","updated":"2024-04-30T11:28:07Z"},"issuanceDate":"2026-02-12T12:41:33Z","id":"did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001","proof":{"created":"2026-02-12T12:41:33.485Z","jws":"eyJhbGciOiJFUzI1NksiLCJraWQiOiJiQnpXOHlHeEt1RUNMal9JeFNyTkN1eVJKOUppZ2ptTU9DeDJGZHpDcnFBIiwiY3JpdCI6WyJiNjQiXSwiYjY0IjpmYWxzZX0..CYU_nbMuB08KuOMfv_oAgLmpgDFs8iC5aoXDQ0jqEHFuPjgpzR-dvafyfezz2y3nUEKg1DVQWY0noAt5n-8KzA","proofPurpose":"assertionMethod","type":"EcdsaSecp256k1Signature2019","verificationMethod":"did:web:emc.spacebel.be:organisations:esa_esrin#owner"},"type":["VerifiableCredential","Feature"],"@context":["https://www.w3.org/2018/credentials/v1","https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld",{"digestMultibase":{"@type":"https://w3id.org/security#multibase","@id":"https://w3id.org/security#digestMultibase"},"relatedResource":{"@type":"@id","@id":"https://www.w3.org/2018/credentials#relatedResource"}}],"issuer":"did:web:emc.spacebel.be:organisations:esa_esrin"}},"image_hash_verified":true}}}}Listing E.63
{
"stac_version": "1.0.0",
"assets": {
"PRODUCT": {
"file:checksum": "1e20cbe790d1f9193bb7ce70e7197f760c2b9188c19dabe2db8583abaa99e2b58c96",
"alternate": {
"FACTS_Browser_Cookie": {
"description": "In order to download the asset via a Web Browser, you first need to establish a connection with your wallet via https://assets.ogc.secd.eu/link so that the Asset Controller can request proof for FACTS Certificates via that secure and private connection when you try to fetch the Asset. Once you have a connection established, you can use the Download link above to fetch the GeoPackage.",
"href": "https://assets.ogc.secd.eu/files/683f5aa56037d688241e54cc004bc14fe3067d1c1f51c67133571efc29c6e3da",
"title": "Download Asset via Web Browser session cookie",
"type": "image/jpeg"
},
"FACTS_API_Key": {
"auth": {
"refs": [
"apiKey"
],
"roles": [
"download"
],
"schemes": {
"flows": {
"authorizationCode": {
"authorizationApi": "https://wallet.ogc.secd.eu/user/x-facts-key",
"method": "get",
"responseField": "x-facts-key",
"parameters": {
"expires_in": {
"schema": {
"examples": "300",
"type": "string"
},
"in": "query",
"description": "the validity of the token in seconds",
"required": "true"
}
}
}
},
"in": "header",
"name": "X-FACTS-Key",
"description": "X-FACTS-Key represents the connection between your Wallet and the Asset Controller to request proof of required FACTS Certificates.",
"type": "apiKey",
"required": "true"
}
},
"description": "In order to download the asset via the API, you first need to fetch an API-Key token (X-FACTS-Key) via https://wallet.ogc.secd.eu/connections/select which must be submitted as HTTP Header `X-FACTS-Key` with the asset URL from `Copy URL`. ",
"href": "https://assets.ogc.secd.eu/files/683f5aa56037d688241e54cc004bc14fe3067d1c1f51c67133571efc29c6e3da",
"title": "Download Asset via X-FACTS-Key",
"type": "image/jpeg"
}
},
"href": "https://ipfs.ogc.secd.eu/files/683f5aa56037d688241e54cc004bc14fe3067d1c1f51c67133571efc29c6e3da",
"title": "Product",
"type": "image/jpeg"
}
},
"bbox": [
133.87,
-23.68,
133.9,
-23.64
],
"geometry": {
"coordinates": [
[
[
133.9,
-23.68
],
[
133.9,
-23.64
],
[
133.87,
-23.64
],
[
133.87,
-23.68
],
[
133.9,
-23.68
]
]
],
"type": "Polygon"
},
"links": [
{
"rel": "derived_from",
"href": "https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/geo%2Bjson;profile=https://stacspec.org",
"type": "application/geo+json",
"title": "Source metadata"
},
{
"rel": "self",
"href": "https://ic.ogc.secd.eu/stac/collections/test_dq4ipt/items/asset_1770900095005",
"type": "application/geo+json",
"title": "asset_1770900095005"
},
{
"rel": "collection",
"href": "https://ic.ogc.secd.eu/stac/collections/test_dq4ipt",
"type": "application/json",
"title": "test_dq4ipt"
}
],
"collection": "test_dq4ipt",
"id": "asset_1770900095005",
"type": "Feature",
"stac_extensions": [
"https://stac-extensions.github.io/file/v2.1.0/schema.json",
"https://stac-extensions.github.io/alternate-assets/v1.1.0/schema.json",
"https://stac-extensions.github.io/processing/v1.2.0/schema.json",
"https://luciocola.github.io/stac-extension-liability-claims/json-schema/schema.json"
],
"properties": {
"processing:level": "L1",
"datetime": "2026-02-12T12:41:35Z",
"start_datetime": "2016-02-04T07:28:52Z",
"end_datetime": "2016-02-04T07:28:52Z",
"processing:facility": "Secure Dimensions Processes",
"processing:lineage": "Watermarking Process",
"processing:datetime": "2026-02-12T12:41:35Z",
"liability:quality": {
"scope": {
"level": "series"
},
"report": [
{
"result": [
{
"pass": true,
"specification": {
"date": "2021-10-14T00:00:00Z",
"identifier": "https://ceos.org/spec/ard/conf",
"title": "CEOS ARD Normalised Radar Backscatter (CARD4L-NRB)"
},
"type": "ConformanceResult",
"resultType": "conformance"
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "The measure will take the value true if all the requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"Data product specification passed"
]
},
"completeness": {
"category": "completeness"
},
"type": "ConceptualConsistency",
"category": "completeness"
}
]
},
"processing:software": {
"name": "Geoserver",
"version": "3.0-SNAPSHOT"
},
"ipt": {
"output": {
"image_height": 1026,
"file:checksum": "1e20cbe790d1f9193bb7ce70e7197f760c2b9188c19dabe2db8583abaa99e2b58c96",
"metadata_url": "https://ic.ogc.secd.eu/stac/collections/test_dq4ipt/items/asset_1770900095005",
"image_url": "https://assets.ogc.secd.eu/files/683f5aa56037d688241e54cc004bc14fe3067d1c1f51c67133571efc29c6e3da",
"image_width": 1026,
"image_type": "image/jpeg"
},
"input": {
"image": {
"image_height": 1026,
"file:checksum": "1220ecff1a367594707fe3603f73fdd6091b039b8e0b98c48d92643f84bc229cc471",
"image_url": "https://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG",
"image_width": 1026,
"image_type": "image/png;charset=UTF-8"
},
"metadata": {
"metadata_url": "https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/geo%2Bjson;profile=https://stacspec.org",
"vc_url": "https://emc.spacebel.be/collections/PROBA.HRC.1A/items/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001?httpAccept=application/vc%2Bld%2Bjson",
"VC_verification": true,
"VC": {
"relatedResource": [
{
"digestMultibase": "zQmYRMC8UMw4ipWvivUKvzvTWrjbKk1oywH1QpoY6w3tCQX",
"id": "https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld"
},
{
"digestMultibase": "zQmeHnYH1jaUefpeAbARzC46rJSzSte8uWn52GGcQWXMcmn",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG"
},
{
"digestMultibase": "zQmPFZfx6KoEAgPpFosgJEKQ17K7sJpsSZWtyNo7vwBHXyr",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_TIMG.jpg"
}
],
"credentialSubject": {
"date": "2016-02-04T07:28:52Z/2016-02-04T07:28:52Z",
"bbox": [
133.87,
-23.68,
133.9,
-23.64
],
"links": {
"data": [
{
"href": "https://tpm-ds.eo.esa.int/oads/data/PROBA1-HRC/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP",
"title": "Download",
"type": "application/x-binary"
}
],
"previews": [
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_BID.PNG",
"title": "QUICKLOOK",
"type": "image/png"
},
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001.SIP.ZIP_TIMG.jpg",
"title": "THUMBNAIL",
"type": "image/jpeg"
}
]
},
"geometry": {
"coordinates": [
[
[
133.9,
-23.68
],
[
133.9,
-23.64
],
[
133.87,
-23.64
],
[
133.87,
-23.68
],
[
133.9,
-23.68
]
]
],
"type": "Polygon"
},
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001",
"title": "PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001",
"updated": "2024-04-30T11:28:07Z"
},
"issuanceDate": "2026-02-12T12:41:33Z",
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160204T072852_S23-066_E133-088_0001",
"proof": {
"created": "2026-02-12T12:41:33.485Z",
"jws": "eyJhbGciOiJFUzI1NksiLCJraWQiOiJiQnpXOHlHeEt1RUNMal9JeFNyTkN1eVJKOUppZ2ptTU9DeDJGZHpDcnFBIiwiY3JpdCI6WyJiNjQiXSwiYjY0IjpmYWxzZX0..CYU_nbMuB08KuOMfv_oAgLmpgDFs8iC5aoXDQ0jqEHFuPjgpzR-dvafyfezz2y3nUEKg1DVQWY0noAt5n-8KzA",
"proofPurpose": "assertionMethod",
"type": "EcdsaSecp256k1Signature2019",
"verificationMethod": "did:web:emc.spacebel.be:organisations:esa_esrin#owner"
},
"type": [
"VerifiableCredential",
"Feature"
],
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld",
{
"digestMultibase": {
"@type": "https://w3id.org/security#multibase",
"@id": "https://w3id.org/security#digestMultibase"
},
"relatedResource": {
"@type": "@id",
"@id": "https://www.w3.org/2018/credentials#relatedResource"
}
}
],
"issuer": "did:web:emc.spacebel.be:organisations:esa_esrin"
}
},
"image_hash_verified": true
}
}
}
}
E.5.4. 4.4 Access the Immutable Catalogue with the result
https://ic.ogc.secd.eu/stac/collections/test_dq4ipt/items/asset_1764089807154
The Processing server stores the results of the processing in the Immutable Catalogue. The collection and id can be found in the Execute response.
Listing E.64
data['id']
Figure E.14
'asset_1770900095005'
Listing E.65
data['collection']
Figure E.15
'test_dq4ipt'
Listing E.66
item_url = URL_IMMUTABLE_CAT_LANDING_PAGE + '/collections/' + data['collection'] + '/items/' + data['id']
item_url
Figure E.16
'https://ic.ogc.secd.eu/stac//collections/test_dq4ipt/items/asset_1770900095005'
Listing E.67
# Retrieve metadata of Processing result from Immutable Catalogue
response = requests.get(item_url, headers={ 'Accept': 'application/geo+json' })
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.68
{
"code": 404,
"description": "missing"
}
E.6. NASA Examples
E.6.1. 5.1 NASA CMR Collection
Note that the metadata shown contains (fixed) quality information that was added for the purpose of examples and do not originate from the original metadata. Additional work is needed to extract this from the NASA catalogue endpoint.
Example: 5.1
> Access a NASA CMR collection.
Listing E.69
# response = requests.get(URL_LANDING_PAGE + 'collections/C2734289572-ORNL_CLOUD?parentIdentifier=EOP%3ANASA%3ACMR')
# C3246892554-LPCLOUD (Landsat)
# C2734289572-ORNL_CLOUD (Gedi)
response = requests.get(URL_LANDING_PAGE + 'collections/C3246892554-LPCLOUD?parentIdentifier=EOP:NASA:CMR', \
headers={'Accept': 'application/vnd.iso.19115-4+json'})
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.70
{
"geometry": {
"coordinates": [
[
[
-180,
-90
],
[
180,
-90
],
[
180,
90
],
[
-180,
90
],
[
-180,
-90
]
]
],
"type": "Polygon"
},
"conformsTo": [
"https://standards.iso.org/iso/19115/-4/0.1/core",
"https://standards.iso.org/iso/19115/-4/0.1/data-quality-core",
"https://standards.iso.org/iso/19115/-4/0.1/no-ref"
],
"id": "C3246892554-LPCLOUD",
"type": "Feature",
"properties": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"identificationInfo": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"parentMetadata": {
"identifier": [
{
"code": ""
},
{
"code": "did:web:emc.spacebel.be:collections:",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": ""
},
"citation": {
"identifier": [
{
"code": "C3246892554-LPCLOUD"
},
{
"code": "did:web:emc.spacebel.be:collections:C3246892554-LPCLOUD",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "HLS Operational Land Imager Vegetation Indices Daily Global 30 m V2.0"
},
"abstract": "C3246892554-LPCLOUD"
},
"metadataStandard": [
{
"title": "ISO 19115-1:2014"
},
{
"title": "ISO 19115-4"
}
],
"contact": [
{
"role": "pointOfContact",
"party": [
{
"contactInfo": [
{
"address": [
{
"deliveryPoint": [
"Largo Galileo Galilei 1"
],
"country": "Italy",
"city": "Frascati (Roma)",
"postalCode": "00044",
"electronicMailAddress": [
"eohelp@esa.int"
]
}
],
"phone": {
"voice": "tel:+3906941801"
}
}
],
"name": "ESA/ESRIN",
"type": "CI_Organisation"
}
]
}
],
"dataQualityInfo": [
{
"scope": {
"level": "dataset"
},
"report": [
{
"result": [
{
"type": "QuantitativeResult",
"value": [
"true"
]
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "The measure will take the value true if all the requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"MD101"
]
},
"type": "ConceptualConsistency"
},
{
"result": [
{
"valueUnit": "%",
"type": "QuantitativeResult",
"value": [
0
]
}
],
"measure": {
"measureIdentification": {
"code": "211",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Quality degradation - rate of imperfect coverage.",
"nameOfMeasure": [
"MD211"
]
},
"evaluationMethod": [
{
"type": "FullInspection",
"evaluationMethodDescription": "Automatic quality degradation check."
}
],
"type": "Omission"
}
]
}
],
"dateInfo": {
"revision": "2025-02-18T00:00:00.000Z"
},
"distributionInfo": [
{
"distributor": [],
"transferOptions": [
{
"onLine": [
{
"function": "download",
"name": "data",
"description": "Download",
"linkage": "https://search.earthdata.nasa.gov/search/granules?p=C3246892554-LPCLOUD"
},
{
"function": "download",
"name": "data",
"description": "Download",
"linkage": "https://appeears.earthdatacloud.nasa.gov/"
},
{
"function": "browseGraphic",
"name": "icon",
"description": "QUICKLOOK",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-public/HLSL30_VI.020/HLS-VI.L30.T10TFR.2025042T185002.v2.0/HLS-VI.L30.T10TFR.2025042T185002.v2.0.jpg"
}
]
}
]
}
],
"metadataScope": [
{
"resourceScope": "dataset",
"name": "dataset"
}
]
}
}
E.6.2. 5.2 NASA CMR Product
Example: 5.3
> Access a NASA CMR Product (STAC).
Listing E.71
# https://radiantearth.github.io/stac-browser/#/external/emc.spacebel.be/
# collections/EOP:NASA:CMR:GEDI_L4A_AGB_Density_GW_2028/items/G2734290436-ORNL_CLOUD?httpAccept=application%2Fgeo%2Bjson%3Bprofile%3Dhttps%3A%2F%2Fstacspec.org
# GEDI
# response = requests.get(URL_LANDING_PAGE + 'collections/EOP:NASA:CMR:GEDI_L4A_AGB_Density_GW_2028/items/G2734290436-ORNL_CLOUD?httpAccept=application%2Fgeo%2Bjson%3Bprofile%3Dhttps%3A%2F%2Fstacspec.org')
# https://radiantearth.github.io/stac-browser/#/external/emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application%2Fgeo%2Bjson%3Bprofile%3Dhttps%3A%2F%2Fstacspec.org
# Landsat
response = requests.get(URL_LANDING_PAGE + 'collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application%2Fgeo%2Bjson%3Bprofile%3Dhttps%3A%2F%2Fstacspec.org')
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.72
{
"stac_version": "1.0.0",
"assets": {
"enclosure_10": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.TVI.tif",
"type": "image/tiff",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.TVI.tif"
},
"thumbnail": {
"roles": [
"thumbnail"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-public/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.jpg",
"type": "image/jpeg",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.jpg"
},
"metadata_iso_19139": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/vnd.iso.19139%2Bxml",
"title": "ISO 19139 metadata",
"type": "application/vnd.iso.19139+xml"
},
"enclosure_3": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.MSAVI.tif",
"type": "image/tiff",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.MSAVI.tif"
},
"enclosure_4": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NBR.tif",
"type": "image/tiff",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NBR.tif"
},
"enclosure_1": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T59WNT.2013101T001445.v2.0/HLS.L30.T59WNT.2013101T001445.v2.0.Fmask.tif",
"type": "image/tiff",
"title": "Download Fmask quality layer HLS.L30.T59WNT.2013101T001445.v2.0.Fmask.tif"
},
"enclosure_2": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.EVI.tif",
"type": "image/tiff",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.EVI.tif"
},
"metadata_ogc_10_157r3": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/gml%2Bxml&recordSchema=om10",
"title": "OGC 10-157r3 metadata",
"type": "application/gml+xml;profile=\"http://www.opengis.net/spec/EOMPOM/1.0\""
},
"metadata_ogc_10_157r4": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/gml%2Bxml&recordSchema=om",
"title": "OGC 10-157r4 metadata",
"type": "application/gml+xml;profile=\"http://www.opengis.net/spec/EOMPOM/1.1\""
},
"metadata_ogc_17_069r3": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD",
"type": "application/geo+json;profile=\"http://www.opengis.net/spec/ogcapi-features-1/1.0\"",
"title": "OGC 17-069r3 metadata"
},
"metadata_iso_19115_4": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/vnd.iso.19115-4%2Bjson",
"title": "ISO19115-4",
"type": "application/vnd.iso.19115-4+json"
},
"metadata_ogc_17_003r2": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?mode=owc",
"title": "OGC 17-003r2 metadata",
"type": "application/geo+json;profile=\"http://www.opengis.net/spec/eo-geojson/1.0\""
},
"enclosure_9": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.SAVI.tif",
"type": "image/tiff",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.SAVI.tif"
},
"metadata_iso_19115_3": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/vnd.iso.19115-3%2Bxml",
"title": "ISO 19115-3 metadata",
"type": "application/vnd.iso.19115-3+xml"
},
"metadata_iso_19157_2": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/vnd.iso.19157-2%2Bxml",
"title": "ISO 19157-2 metadata",
"type": "application/vnd.iso.19157-2+xml"
},
"enclosure_7": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDVI.tif",
"type": "image/tiff",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDVI.tif"
},
"enclosure_8": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDWI.tif",
"type": "image/tiff",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDWI.tif"
},
"metadata_html": {
"roles": [
"metadata"
],
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=text/html",
"title": "HTML",
"type": "text/html"
},
"enclosure_5": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NBR2.tif",
"type": "image/tiff",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NBR2.tif"
},
"enclosure_6": {
"roles": [
"data"
],
"href": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDMI.tif",
"type": "image/tiff",
"title": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDMI.tif"
}
},
"bbox": [
170.9994682,
69.2990206,
173.9164473,
70.3060175
],
"geometry": {
"coordinates": [
[
[
173.7835564,
69.2990206
],
[
173.9164473,
70.2824267
],
[
170.9994682,
70.3060175
],
[
170.9994925,
69.3213967
],
[
173.7835564,
69.2990206
]
]
],
"type": "Polygon"
},
"links": [
{
"rel": "self",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/geo%2Bjson;profile=https://stacspec.org",
"type": "application/geo+json;profile=\"https://stacspec.org\""
},
{
"rel": "icon",
"href": "s3://lp-prod-public/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.jpg",
"type": "image/jpeg",
"title": "This link provides direct download access via S3 to the granule"
},
{
"rel": "collection",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI?parentIdentifier=EOP:NASA:CMR&httpAccept=application/json",
"type": "application/json",
"title": "EOP:NASA:CMR:HLSL30_VI"
},
{
"rel": "parent",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI?parentIdentifier=EOP:NASA:CMR&httpAccept=application/json",
"type": "application/json",
"title": "EOP:NASA:CMR:HLSL30_VI"
},
{
"rel": "up",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI?parentIdentifier=EOP:NASA:CMR&mode=owc",
"type": "application/geo+json",
"title": "OGC 17-084r1 metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/atom%2Bxml",
"type": "application/atom+xml",
"title": "Atom format"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/ld%2Bjson",
"type": "application/ld+json",
"title": "JSON-LD metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/ld%2Bjson;profile=https://schema.org",
"type": "application/ld+json;profile=\"https://schema.org\"",
"title": "JSON-LD (schema.org) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/ld%2Bjson;profile=http://data.europa.eu/930/",
"type": "application/ld+json;profile=\"http://data.europa.eu/930/\"",
"title": "JSON-LD (GeoDCAT-AP) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/rdf%2Bxml",
"type": "application/rdf+xml",
"title": "RDF/XML metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/rdf%2Bxml;profile=https://schema.org",
"type": "application/rdf+xml;profile=\"https://schema.org\"",
"title": "RDF/XML (schema.org) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/rdf%2Bxml;profile=http://data.europa.eu/930/",
"type": "application/rdf+xml;profile=\"http://data.europa.eu/930/\"",
"title": "RDF/XML (GeoDCAT-AP) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=text/turtle",
"type": "text/turtle",
"title": "Turtle metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=text/turtle;profile=https://schema.org",
"type": "text/turtle;profile=\"https://schema.org\"",
"title": "Turtle (schema.org) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=text/turtle;profile=http://data.europa.eu/930/",
"type": "text/turtle;profile=\"http://data.europa.eu/930/\"",
"title": "Turtle (GeoDCAT-AP) metadata"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/vc%2Bld%2Bjson",
"type": "application/vc+ld+json",
"title": "Verifiable Credential"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/vp%2Bld%2Bjson",
"type": "application/vp+ld+json",
"title": "Verifiable Presentation"
},
{
"rel": "alternate",
"href": "https://emc.spacebel.be/collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD?httpAccept=application/vc%2Bld%2Bjson;version=2.0",
"type": "application/vc+ld+json;version=2.0",
"title": "Verifiable Credential 2.0"
}
],
"id": "G3680032246-LPCLOUD",
"collection": "EOP:NASA:CMR:HLSL30_VI",
"type": "Feature",
"stac_extensions": [
"https://stac-extensions.github.io/projection/v2.0.0/schema.json",
"https://stac-extensions.github.io/external-ids/v1.0.0/schema.json"
],
"properties": {
"proj:epsg": 4326,
"externalIds": [
{
"scheme": "https://www.w3.org/ns/did/v1",
"value": "did:web:emc.spacebel.be:collections:EOP%3ANASA%3ACMR%3AHLSL30_VI:items:G3680032246-LPCLOUD"
}
],
"title": "G3680032246-LPCLOUD",
"updated": "2026-02-12T12:41:40Z"
}
}
Example: 5.4
> Access a NASA CMR Product (ISO19115-4).
Listing E.73
# GEDI
# response = requests.get( URL_LANDING_PAGE + 'collections/EOP:NASA:CMR:GEDI_L4A_AGB_Density_GW_2028/items/G2734290436-ORNL_CLOUD', \
# headers={'Accept': 'application/vnd.iso.19115-4+json'})
# Landsat
response = requests.get( URL_LANDING_PAGE + 'collections/EOP:NASA:CMR:HLSL30_VI/items/G3680032246-LPCLOUD', \
headers={'Accept': 'application/vnd.iso.19115-4+json'})
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.74
{
"bbox": [
170.9994682,
69.2990206,
173.9164473,
70.3060175
],
"geometry": {
"coordinates": [
[
[
173.7835564,
69.2990206
],
[
173.9164473,
70.2824267
],
[
170.9994682,
70.3060175
],
[
170.9994925,
69.3213967
],
[
173.7835564,
69.2990206
]
]
],
"type": "Polygon"
},
"conformsTo": [
"https://standards.iso.org/iso/19115/-4/0.1/core",
"https://standards.iso.org/iso/19115/-4/0.1/data-quality-core",
"https://standards.iso.org/iso/19115/-4/0.1/no-ref"
],
"id": "G3680032246-LPCLOUD",
"type": "Feature",
"properties": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"identificationInfo": {
"defaultLocale": {
"language": "eng",
"characterEncoding": "utf8"
},
"extent": [
{
"geographicElement": [
{
"northBoundLatitude": 70.3060175,
"southBoundLatitude": 69.2990206,
"type": "EX_GeographicBoundingBox",
"westBoundLongitude": 170.9994682,
"eastBoundLongitude": 173.9164473
}
]
}
],
"parentMetadata": {
"identifier": [
{
"code": "EOP:NASA:CMR:HLSL30_VI"
},
{
"code": "did:web:emc.spacebel.be:collections:EOP%3ANASA%3ACMR%3AHLSL30_VI",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "EOP:NASA:CMR:HLSL30_VI"
},
"citation": {
"identifier": [
{
"code": "G3680032246-LPCLOUD"
},
{
"code": "did:web:emc.spacebel.be:collections:EOP%3ANASA%3ACMR%3AHLSL30_VI:items:G3680032246-LPCLOUD",
"codeSpace": "https://www.w3.org/ns/did/v1"
}
],
"title": "G3680032246-LPCLOUD"
},
"abstract": "G3680032246-LPCLOUD"
},
"metadataStandard": [
{
"title": "ISO 19115-1:2014"
},
{
"title": "ISO 19115-4"
}
],
"contact": [],
"dataQualityInfo": [
{
"scope": {
"level": "dataset"
},
"report": [
{
"result": [
{
"type": "QuantitativeResult",
"value": [
"true"
]
}
],
"measure": {
"measureIdentification": {
"code": "101",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "The measure will take the value true if all the requirements in the referred data product specification are fulfilled.",
"nameOfMeasure": [
"MD101"
]
},
"type": "ConceptualConsistency"
},
{
"result": [
{
"valueUnit": "%",
"type": "QuantitativeResult",
"value": [
0
]
}
],
"measure": {
"measureIdentification": {
"code": "211",
"authority": {
"alternateTitle": [
"ISO"
],
"title": "International Organization for Standardization"
},
"codeSpace": "https://standards.isotc211.org/19157/-3/1/dqc/content/qualityMeasure/"
},
"measureDescription": "Quality degradation - rate of imperfect coverage.",
"nameOfMeasure": [
"MD211"
]
},
"evaluationMethod": [
{
"type": "FullInspection",
"evaluationMethodDescription": "Automatic quality degradation check."
}
],
"type": "Omission"
}
]
}
],
"resourceLineage": [
{
"processStep": [
{
"output": [
{
"source": [
{
"sourceCitation": {
"code": "did:web:emc.spacebel.be:collections:EOP%3ANASA%3ACMR%3AHLSL30_VI:items:G3680032246-LPCLOUD",
"title": "G3680032246-LPCLOUD"
}
}
]
}
],
"processingInformation": {}
}
]
}
],
"dateInfo": {
"revision": "2026-02-12T12:41:42Z"
},
"distributionInfo": [
{
"distributor": [],
"transferOptions": [
{
"onLine": [
{
"function": "download",
"name": "data",
"description": "Download Fmask quality layer HLS.L30.T59WNT.2013101T001445.v2.0.Fmask.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T59WNT.2013101T001445.v2.0/HLS.L30.T59WNT.2013101T001445.v2.0.Fmask.tif"
},
{
"function": "download",
"name": "data",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.EVI.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.EVI.tif"
},
{
"function": "download",
"name": "data",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.MSAVI.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.MSAVI.tif"
},
{
"function": "download",
"name": "data",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NBR.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NBR.tif"
},
{
"function": "download",
"name": "data",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NBR2.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NBR2.tif"
},
{
"function": "download",
"name": "data",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDMI.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDMI.tif"
},
{
"function": "download",
"name": "data",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDVI.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDVI.tif"
},
{
"function": "download",
"name": "data",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDWI.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.NDWI.tif"
},
{
"function": "download",
"name": "data",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.SAVI.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.SAVI.tif"
},
{
"function": "download",
"name": "data",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.TVI.tif",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.TVI.tif"
},
{
"function": "browseGraphic",
"name": "icon",
"description": "Download HLS-VI.L30.T59WNT.2013101T001445.v2.0.jpg",
"linkage": "https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-public/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.jpg"
},
{
"function": "browseGraphic",
"name": "icon",
"description": "This link provides direct download access via S3 to the granule",
"linkage": "s3://lp-prod-public/HLSL30_VI.020/HLS-VI.L30.T59WNT.2013101T001445.v2.0/HLS-VI.L30.T59WNT.2013101T001445.v2.0.jpg"
}
]
}
]
}
],
"metadataScope": [
{
"resourceScope": "dataset",
"name": "dataset"
}
]
}
}
E.7. Registry Interface
E.7.1. 6.1 Get VCs for a subject supporting 1 VC version.
Listing E.75
URL_REGISTRY = URL_LANDING_PAGE + 'registry/'
subject_did = 'did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160204T060957_N37-039_E141-001_0001'
response = requests.get(URL_REGISTRY + 'vcs/' + subject_did)
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.76
[
{
"relatedResource": [
{
"digestMultibase": "zQmYRMC8UMw4ipWvivUKvzvTWrjbKk1oywH1QpoY6w3tCQX",
"id": "https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld"
},
{
"digestMultibase": "zQmXuxqvw6ZdkXvG7Tb6WQP2kkNuHrtkCZR7LtsAqBmum8i",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T060957_N37-039_E141-001_0001.SIP.ZIP_BID.PNG"
},
{
"digestMultibase": "zQmTKNSFeikcQ1Kp75vfCRNiPkWjjEYmjws8X8Zv1qRAcw1",
"id": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160204T060957_N37-039_E141-001_0001.SIP.ZIP_TIMG.jpg"
}
],
"credentialSubject": {
"date": "2016-02-04T06:09:57Z/2016-02-04T06:09:57Z",
"bbox": [
140.98,
37.37,
141.05,
37.41
],
"links": {
"data": [
{
"href": "https://tpm-ds.eo.esa.int/oads/data/PROBA1-HRC/PR1_OPER_HRC_HRC_1P_20160204T060957_N37-039_E141-001_0001.SIP.ZIP",
"title": "Download",
"type": "application/x-binary"
}
],
"previews": [
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/browse/PR1_OPER_HRC_HRC_1P_20160204T060957_N37-039_E141-001_0001.SIP.ZIP_BID.PNG",
"title": "QUICKLOOK",
"type": "image/png"
},
{
"href": "http://tpm-ds.eo.esa.int/oads/meta/PROBA1-HRC/thumbnail/PR1_OPER_HRC_HRC_1P_20160204T060957_N37-039_E141-001_0001.SIP.ZIP_TIMG.jpg",
"title": "THUMBNAIL",
"type": "image/jpeg"
}
]
},
"geometry": {
"coordinates": [
[
[
141.05,
37.37
],
[
141.05,
37.41
],
[
140.98,
37.41
],
[
140.98,
37.37
],
[
141.05,
37.37
]
]
],
"type": "Polygon"
},
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160204T060957_N37-039_E141-001_0001",
"title": "PR1_OPER_HRC_HRC_1P_20160204T060957_N37-039_E141-001_0001",
"updated": "2024-04-30T11:28:07Z"
},
"issuanceDate": "2026-02-12T12:41:43Z",
"id": "did:web:emc.spacebel.be:collections:PROBA.HRC.1A:items:PR1_OPER_HRC_HRC_1P_20160204T060957_N37-039_E141-001_0001",
"proof": {
"created": "2026-02-12T12:41:43.190Z",
"jws": "eyJhbGciOiJFUzI1NksiLCJraWQiOiJiQnpXOHlHeEt1RUNMal9JeFNyTkN1eVJKOUppZ2ptTU9DeDJGZHpDcnFBIiwiY3JpdCI6WyJiNjQiXSwiYjY0IjpmYWxzZX0..9VVDezJvc3o65Vv_8jnMXGPlkhDjJQmbns1cllC5vLYQhHxS4f7GXq8w-LdyHOaeHqWMOTH5L6QgxTpa-SygtA",
"proofPurpose": "assertionMethod",
"type": "EcdsaSecp256k1Signature2019",
"verificationMethod": "did:web:emc.spacebel.be:organisations:esa_esrin#owner"
},
"type": [
"VerifiableCredential",
"Feature"
],
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld",
{
"digestMultibase": {
"@type": "https://w3id.org/security#multibase",
"@id": "https://w3id.org/security#digestMultibase"
},
"relatedResource": {
"@type": "@id",
"@id": "https://www.w3.org/2018/credentials#relatedResource"
}
}
],
"issuer": "did:web:emc.spacebel.be:organisations:esa_esrin"
}
]
E.7.2. 6.2 Get VCs for a subject supporting 2 VC versions.
Listing E.77
subject_did = 'did:web:emc.spacebel.be:collections:ADEOS-II_GLI_L3B_NW_1day_9km:items:A2GL10301010301310_PNW000B000M0002100000'
response = requests.get(URL_REGISTRY + 'vcs/' + subject_did)
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.78
[
{
"credentialSubject": {
"date": "2003-01-25T00:42:22.14Z/2003-01-25T14:09:02.61Z",
"hasGeometry": {
"asWKT": "POLYGON((-179.999 90.0,-179.999 -90.0,180.0 -90.0,180.0 90.0,-179.999 90.0))"
},
"bbox": [
-179.999,
-90,
180,
90
],
"links": {
"data": [
{
"href": "https://gportal.jaxa.jp/download/standard/ADEOS-2/ADEOS-2.GLI-1km/L3B.NW000/210/2003/01/A2GL10301010301310_PNW000B000M0002100000.01",
"title": "Download",
"type": "application/x-binary"
}
]
},
"id": "did:web:emc.spacebel.be:collections:ADEOS-II_GLI_L3B_NW_1day_9km:items:A2GL10301010301310_PNW000B000M0002100000",
"title": "A2GL10301010301310_PNW000B000M0002100000",
"updated": "2005-06-05T02:25:07.00Z"
},
"issuanceDate": "2026-02-12T12:41:45Z",
"id": "did:web:emc.spacebel.be:collections:ADEOS-II_GLI_L3B_NW_1day_9km:items:A2GL10301010301310_PNW000B000M0002100000",
"proof": {
"created": "2026-02-12T12:41:46.103Z",
"jws": "eyJhbGciOiJFZERTQSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2V9..E3XJCsONV3W9okldMTvviPPf_W8mF3pvCXqPR8CxBNivDAUy47uj-gIkg3RbW3GADYw3KdEOjBCH2i83XSSxCw",
"proofPurpose": "assertionMethod",
"type": "Ed25519Signature2018",
"verificationMethod": "did:web:emc.spacebel.be:organisations:jp_jaxa_saoc#owner"
},
"type": [
"VerifiableCredential",
"Feature"
],
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://schemas.opengis.net/eo-geojson/1.0/eo-geojson.jsonld",
{
"digestMultibase": {
"@type": "https://w3id.org/security#multibase",
"@id": "https://w3id.org/security#digestMultibase"
},
"relatedResource": {
"@type": "@id",
"@id": "https://www.w3.org/2018/credentials#relatedResource"
}
}
],
"issuer": "did:web:emc.spacebel.be:organisations:jp_jaxa_saoc"
},
{
"credentialSubject": {
"hasGeometry": {
"asWKT": "POLYGON((-179.999 90.0,-179.999 -90.0,180.0 -90.0,180.0 90.0,-179.999 90.0))"
},
"date": "2003-01-25T00:42:22.14Z/2003-01-25T14:09:02.61Z",
"bbox": [
-179.999,
-90,
180,
90
],
"links": {
"data": [
{
"href": "https://gportal.jaxa.jp/download/standard/ADEOS-2/ADEOS-2.GLI-1km/L3B.NW000/210/2003/01/A2GL10301010301310_PNW000B000M0002100000.01",
"type": "application/x-binary",
"title": "Download"
}
]
},
"id": "did:web:emc.spacebel.be:collections:ADEOS-II_GLI_L3B_NW_1day_9km:items:A2GL10301010301310_PNW000B000M0002100000",
"title": "A2GL10301010301310_PNW000B000M0002100000",
"updated": "2005-06-05T02:25:07.00Z"
},
"id": "did:web:emc.spacebel.be:collections:ADEOS-II_GLI_L3B_NW_1day_9km:items:A2GL10301010301310_PNW000B000M0002100000",
"validFrom": "2026-02-12T12:41:47Z",
"proof": {
"proofValue": "z5cbr79ZL7t83RgX3W55EXrd3YFtmh3rZdtmKMwNDGFrGLfwCPqqAfrS9j74GQwr37aHgatXU4e41d4gLmL59UjvX",
"created": "2026-02-12T12:41:47.872105",
"proofPurpose": "assertionMethod",
"type": "Ed25519Signature2020",
"verificationMethod": "did:web:emc.spacebel.be:organisations:jp_jaxa_saoc#owner"
},
"type": [
"VerifiableCredential",
"Feature"
],
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://w3id.org/security/suites/ed25519-2020/v1",
{
"date": "dct:date",
"asWKT": "gsp:asWKT",
"gj": "https://purl.org/geojson/vocab#",
"data": "iana:enclosure",
"gsp": "http://www.opengis.net/ont/geosparql#",
"bbox": {
"@id": "gj:bbox",
"@container": "@list"
},
"coordinates": "gj:coordinates",
"icon": "iana:icon",
"title": "dct:title",
"Feature": "gj:Feature",
"hasGeometry": "gsp:hasGeometry",
"dct": "http://purl.org/dc/terms/",
"previews": "iana:icon",
"owc": "http://www.opengis.net/ont/owc/1.0/",
"iana": "http://www.iana.org/assignments/relation/",
"geometry": "gj:geometry",
"links": {
"@id": "owc:links",
"@context": {
"@vocab": "http://www.iana.org/assignments/relation/",
"href": "@id",
"type": "http://www.w3.org/2005/Atom/type"
}
},
"href": "@id",
"id": "@id",
"atom": "http://www.w3.org/2005/Atom/",
"Polygon": "gj:Polygon",
"updated": "dct:modified"
}
],
"issuer": "did:web:emc.spacebel.be:organisations:jp_jaxa_saoc"
}
]
E.7.3. 6.3 Get DID document
Listing E.79
did = 'did:web:emc.spacebel.be:collections:ADEOS-II_GLI_L3B_NW_1day_9km:items:A2GL10301010301310_PNW000B000M0002100000'
response = requests.get(URL_REGISTRY + 'did/' + did)
data = json.loads(response.text)
jstr = json.dumps(data, indent=3)
md("```json\n" + jstr + "\n```\n")
Listing E.80
{
"controller": "did:web:emc.spacebel.be:organisations:jp_jaxa_saoc",
"service": [
{
"id": "#vp",
"serviceEndpoint": "https://emc.spacebel.be/collections/ADEOS-II_GLI_L3B_NW_1day_9km/items/A2GL10301010301310_PNW000B000M0002100000?httpAccept=application/vp%2Bld%2Bjson",
"type": "LinkedVerifiablePresentation"
},
{
"id": "#vc",
"serviceEndpoint": {
"registries": [
"https://emc.spacebel.be/registry/vcs/{credentialSubject.id}"
]
},
"type": "CredentialRegistry"
}
],
"id": "did:web:emc.spacebel.be:collections:ADEOS-II_GLI_L3B_NW_1day_9km:items:A2GL10301010301310_PNW000B000M0002100000",
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1",
"https://identity.foundation/linked-vp/contexts/v1"
],
"alsoKnownAs": [
"https://emc.spacebel.be/collections/ADEOS-II_GLI_L3B_NW_1day_9km/items/A2GL10301010301310_PNW000B000M0002100000",
"https://emc.spacebel.be/collections/ADEOS-II_GLI_L3B_NW_1day_9km/items/A2GL10301010301310_PNW000B000M0002100000?httpAccept=application/vnd.iso.19115-4%2Bjson"
]
}