ISO/TR 19115-4

• Status: Not Published
• ICS: 35.240.70 - IT applications in science
• Technical Committee: ISO/TC 211 - Geographic information/Geomatics
• Drafting Committee: ISO/TC 211 - Geographic information/Geomatics
• Current Stage: 6000 - International Standard under publication
• Start Date: 05-Aug-2026
• Completion Date: 19-Sep-2026

• Consolidates: ISO 4561:2023 - Wood raw parquets elements — Classification
• Effective Date: 22-Jun-2024

Overview

ISO/TR 19115-4: Geographic information - Metadata - Part 4: JSON schema implementation of metadata fundamentals is a technical report developed by ISO/TC 211. This document addresses the implementation of ISO 19115-1 and ISO 19157-1 conceptual models for geographic metadata using JSON (JavaScript Object Notation) schema. The standard aims to facilitate the exchange and publication of geographic metadata by providing guidance on how core metadata concepts can be represented in JSON, leveraging widely used web technologies.

The primary goal of ISO/TR 19115-4 is to establish a proof-of-concept for representing core metadata from ISO 19115-1 and data quality concepts from ISO 19157-1 in JSON schema, validating the feasibility and practicality of this approach. The report provides both a methodology and schema files, but is not intended as a definitive JSON encoding standard. Instead, it offers an initial framework for broad adoption by the geographic information community.

Key Topics

• JSON Schema Implementation: Describes how to derive JSON schemas from the conceptual models in ISO 19115-1 and ISO 19157-1 to support interoperability across diverse systems and applications.
• Simplified Core Subset: Focuses on a core operational subset of ISO 19115-1 and ISO 19157-1, prioritizing commonly used metadata classes and elements for maximum relevance and simplicity.
• GeoJSON Integration: Uses GeoJSON feature structures to encode metadata, ensuring compatibility with existing spatial data tools and enhancing visualization capabilities.
• Automated Schema Generation: Details the workflow for converting UML implementation models into JSON schema files, including automated and manual processes to ensure schema quality.
• UML to JSON Encoding Rules: Applies and adapts best practices from OGC’s UML to JSON encoding guidelines, clarifying key transformations, treatment of abstract classes, and type inheritance.
• Multilingual Support: Addresses approaches for managing multilingual metadata through mechanisms native to JSON and web platforms.
• Profile and Validation: Outlines how a JSON reference instance document is used to test, iterate, and validate the generated schemas for operational use.

Applications

ISO/TR 19115-4 has practical value for organizations and professionals involved in geographic data management, sharing, and publication. Key applications include:

• API-Based Metadata Exchange: Enables the use of robust, standards-based JSON schemas for geographic metadata in web APIs, such as OGC API Records, increasing ease of integration and system interoperability.
• Metadata Publication and Discovery: Facilitates the publication of geographic metadata on the web in modern, user-friendly formats, supporting improved search, discovery, and visualization in mapping applications.
• Interoperability Between Systems: Offers a common framework for exchanging geographic metadata between diverse software platforms, reducing translation issues and supporting broader data sharing.
• Data Quality Integration: Incorporates essential data quality elements from ISO 19157-1, ensuring published metadata includes key quality metrics and assessments in a consistent, accessible manner.
• Baseline for Further Development: Serves as a foundation for the development of a formal ISO standard for JSON-based geographic metadata, with community feedback driving expansion and refinement.

Related Standards

• ISO 19115-1: Geographic information - Metadata - Part 1: Fundamentals
  Defines the core conceptual model and structure for describing geographic information resources.
• ISO 19157-1: Geographic information - Data quality - Part 1: General requirements
  Specifies the principles and metrics for data quality relevant to geographic datasets and associated metadata.
• OGC Best Practice: UML to JSON Encoding Rules
  Provides reference guidelines and encoding rules for transforming UML conceptual models into valid JSON or GeoJSON representations.
• ISO/TS 19139-1: Geographic information - XML schema implementation
  Outlines XML encoding rules that serve as a comparison point for JSON schema implementations.
• GeoJSON (IETF RFC 7946)
  Standard format for encoding a variety of geographic data structures in JSON, widely adopted in web mapping and spatial analysis applications.

---

By using ISO/TR 19115-4, organizations can harness the power of JSON-based schema to streamline the handling, sharing, and interpretation of geographic metadata, supporting greater interoperability and accessibility in spatial data ecosystems.

FINAL DRAFT
Technical
Report
ISO/DTR 19115-4
ISO/TC 211
Geographic information —
Secretariat: SIS
Metadata —
Voting begins on:
2026-05-11
Part 4:
JSON schema implementation of
Voting terminates on:
2026-08-03
metadata fundamentals
Information géographique — Métadonnées —
Partie 4: Mise en œuvre des principes fondamentaux des
métadonnées par des schémas JSON
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
ISO/DTR 19115-4:2026(en) © ISO 2026

FINAL DRAFT
ISO/DTR 19115-4:2026(en)
Technical
Report
ISO/DTR 19115-4
ISO/TC 211
Geographic information — –
Secretariat: SIS
Metadata —
Voting begins on:
Part 4:
JSON schema implementation of
Voting terminates on:
metadata fundamentals
Information géographique — Métadonnées —
Partie 4: Mise en œuvre des principes fondamentaux des
métadonnées par des schémas JSON
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ISO/DTR 19115-4:2026(en) © ISO 2026

ii
ISO/DTR 19115-4:2026(en)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Basic approach and design decisions. 1
4.1 Overview .1
4.2 General approach and workflow .1
4.3 JSON representation .2
4.4 Profile on conceptual content .3
4.5 ISO 19115-4 (this document) UML and ISO 19157-1 UML implementation models for
JSON .3
4.6 JSON reference instance document .4
4.7 UML to JSON encoding rules and automated generation of JSON schema .5
4.8 Multilingual adaptability .5
5 Encoding approach and rules . 5
5.1 UML to JSON encoding rules .5
5.1.1 Overview .5
5.1.2 General rules for transforming UML to JSON schema .5
5.1.3 Details and deviations .5
5.1.4 Code lists .7
5.1.5 Missing JSON base types .8
5.2 Modularization .9
5.3 UML implementation model for JSON implementation.9
Annex A (informative) Defined profile (subset) on ISO 19115-1 and ISO 19157-1 .12
Annex B (informative) Geographic metadata JSON schema resources .17
Annex C (informative) Implementation example .18
Bibliography . 19

iii
ISO/DTR 19115-4:2026(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 211, Geographic information/Geomatics, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC 287,
Geographic Information, in accordance with the Agreement on technical cooperation between ISO and CEN
(Vienna Agreement), and in collaboration with the Open Geospatial Consortium (OGC).
A list of all parts in the ISO 19115 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

iv
ISO/DTR 19115-4:2026(en)
Introduction
[1]
ISO 19115-1 explains the importance of metadata, specifies a model for describing geographic information
resources by defining metadata entities, elements and terminology, and establishes an extension procedure
for additional metadata content. This document investigates the JSON implementation of this same
[2]
conceptual model including relevant parts of ISO 19157-1 . A resulting JSON encoding is developed for
a subset of the named conceptual models showing the principles used. In this regard the defined JSON
encoding is not intended to be a formal JSON encoding but serves as a proof of concept.
The primary use case envisioned for the JSON implementation illustrated in this document is the exchange
and publication of geographic metadata through APIs. The intention in publishing this document is that the
community can begin using this approach and can feed back improvements so that a formal specification
can be developed.
JSON has become one of the major encodings used by current web applications, for example in many
implementations of OGC API Records. A JSON encoding to standardize a JSON implementation of metadata
[1]
types is needed. This document describes a JSON encoding of ISO 19115-1 including the data quality
[2]
concepts in ISO 19157-1 . In this document only a subset of both standards is implemented. A subset,
considered to be the core part of both standards, currently satisfies the need for an initial evaluation and
proof of concept for the JSON encoding. This document and the resulting JSON encoding are regarded as
mature within the context of an ISO technical report, encompassing a broad range of content. In the future,
the scope will potentially be expanded to include the complete content of the ISO 19115 series conceptual
models.
[1] [2]
The integrated JSON schema was derived from the ISO 19115-1 and ISO 19157-1 conceptual models in
UML. Since standardized UML-to-JSON encoding rules do not yet exist, the OGC document Best Practice for
[3]
OGC - UML to JSON Encoding Rules was used as a reference.
This implementation model described in this document does not alter the semantics of the source conceptual
models, but profiles content required for efficient JSON implementation and adds UML elements to facilitate
UML to JSON transformation software. The JSON schemas were created automatically from the UML model,
based on UML to JSON encoding rules as well as on a manually generated JSON reference instance document.
[3]
Automated generation is according to the encoding rules described in OGC best practice report: Best
Practice for OGC - UML to JSON Encoding Rules. The JSON reference instance document was created based
[4]
on a manually created ISO 19115-3 XML document.

v
FINAL DRAFT Technical Report ISO/DTR 19115-4:2026(en)
Geographic information — – Metadata —
Part 4:
JSON schema implementation of metadata fundamentals
1 Scope
[5] [1] [2]
This document describes a ECMA 404:2017 JSON implementation of ISO 19115-1 and ISO 19157-1 as
a proof of concept. The resulting JSON encoding is not a formal json specification but is intended to proof the
feasibilty of the approach taken and the implicated encoding principles.
[6]
The document provides a set of JSON schema files which define a JSON encoding of the concepts defined by
[1] [2]
conceptual schemas in ISO 19115-1 and ISO 19157-1 . The JSON representation is scoped to exchange via
[1] [2]
HTTP. In this document, only a subset of the content of both ISO 19115-1 and ISO 19157-1 is included, in
order to simplify the process of defining the resulting JSON schema. For the same reason, ISO 19115-2:2019
[7] [1]
is currently not included. The subset is chosen to be a core operational set of both ISO 19115-1 and
[2]
ISO 19157-1 .
This document describes the procedure used to generate JSON schema from ISO geographic information
conceptual models related to metadata. The procedure includes creation of an UML implementation model
[1] [2]
for JSON implementation derived from the ISO 19115-1 and ISO 19157-1 conceptual schemas.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Basic approach and design decisions
4.1 Overview
This clause describes the approach that was taken to generate the metadata JSON schema. The approach
consists of a workflow identifying several steps. The workflow and the separate steps are described and
include formulated design decisions and requirements set for the JSON schema to be produced.
4.2 General approach and workflow
A general approach and workflow has been followed to guide the process for the realization of the JSON
schemas and the related document. This workflow was based on a combination of requirements and
decisions that are explained in the following subclauses. Figure 1 explains the approach and workflow and
shows six steps and several products.

ISO/DTR 19115-4:2026(en)
Figure 1 — Schematic view of general approach and workflow
[1] [2]
— Step 1a) — The conceptual schemas of ISO 19115-1 and ISO 19157-1 are the conceptual input for the
[2]
UML implementation model for JSON described in ISO 19157-1 and in this document. For ISO 19157-1
[2]
, a JSON implementation model is developed only from the perspective of this document. This means
that for this document, no overall evaluation of ISO 19157 series elements is included. This can be
anticipated in a separate, future ISO 19157 series JSON implementation.
— Step 1b) — A JSON reference dataset is created that defines the preferred JSON encoding against which
the generated JSON schema were tested and improved.
— Step 2) — The UML implementation model described in this document is input for an automated and rule-
[2]
based transformation to a JSON schema encoding. Since ISO 19157-1 is referenced from this document,
this is also transformed to a JSON schema.
— Step 3) — The generated JSON schemas are tested against the JSON reference dataset. In an iterative
process, results of this test are fed back to adapting the UML implementation models and/or
[2]
transformation parameters of this document and ISO 19157-1 . The updated JSON schemas are
tested again. Requirements set by the JSON reference dataset that cannot be met by automated schema
generation and existing encoding rules are adapted manually.
— Step 4) — The JSON reference dataset is verified against the JSON schemas and vice versa and the schema
is accepted for publication.
[2]
— 5)  The verified JSON schemas for this profile of this document and ISO 19157-1 are published within
the context of this document.
Detailed descriptions of these steps are presented in the following subclauses.
4.3 JSON representation
The JSON representation to encode ISO 19115-4 in this document has several specifics.
[8]
A MD_Metadata record is represented as a IETF RFC 7946:2016 GeoJSON feature. The following points
apply:
— the metadata identifier is set as the "id" member;
— the spatial extent is in the "geometry" and/or "bbox" members;
— all other properties of the record are in the "properties" member;
— when the MD_Metadata does not have a spatial reference, i.e. no spatial extent is present, the geometry
member is set to null;
ISO/DTR 19115-4:2026(en)
— it is recognized that GeoJSON uses only WGS84 as coordinate reference system. In cases where this is not
appropriate, for instance when data cannot be referenced to the Earth, the geometry member can be set
to null.
The structure of the properties is in general a straightforward mapping of the UML model to JSON:
— properties with structured values (data types, classifiers) are mapped to a JSON object;
— all other properties are mapped to the JSON types string, number or boolean;
— properties with a maximum multiplicity greater than one are wrapped in a JSON array.
[9]
This representation has similarities with the XML representation specified by the ISO/TS 19139-1
encoding rule. The main differences are as follows.
— The JSON representation is "flatter" as in XML an extra tag is used for each object, grouping the tags of
each property, while in JSON simply a JSON object is used. In cases where the type of the object is unclear,
since multiple instantiable types can be the property value due to the use of inheritance in the model, an
additional member "type" is added with the name of the type in the model. In XML the type is expressed
in the name of the tag of the object.
— The XML representation also represents base types like a string as an object to support representing
sub-types, which is an edge case, while the JSON representation removes this capability to simplify the
use of the data.
— The XML encoding rules in the ISO 19139 series added a capability to add metadata to a property without
value. This capability is not included in the conceptual model and has not been included in the JSON
representation.
More details of the encoding rule for representing a MD_Metadata record is provided in 4.6.
The reason for this representation is that GeoJSON is the most widely supported JSON format for spatial data.
As a result, those metadata records in JSON that include a spatial extent (at least those metadata records
that include a geographic extent) can be shown on a map in almost all mapping tools and libraries .
[10]
Those that want to link members of a JSON document to an ontology can add a JSON-LD context to the
JSON instance. Nesting capabilities are also available thanks to the support of JSON-LD at core level.
4.4 Profile on conceptual content
[1]
The source of the conceptual content are the conceptual models as described by ISO 19115-1 and the
[2]
data quality standard ISO 19157-1 . Nesting capabilities are also available thanks to the support of JSON-
LD at core level. However, to handle complexity in this phase and first get a working operational JSON
implementation, which can be reviewed and later extended, the input conceptual models are profiled or sub-
setted to a selection of metadata classes.
The requirements for this subset were set to meet two criteria: that the subset covers most of the common
use of metadata defined in the ISO 19115 series, and that the subset excludes complex constructs that
currently do not add much to the applicability of this JSON implementation. The profile is called "ISO 19115-4
Core".
[1] [2] [11]
"ISO 19115-4 Core" is defined by a profile on ISO 19115-1 and ISO 19157-1 . No content of ISO 19115-2
[1] [2]
is included in this 19115-4 Core. For ISO 19115-1 and ISO 19157-1 , the subset is described in Annex A.
4.5 ISO 19115-4 (this document) UML and ISO 19157-1 UML implementation models for
JSON
Two UML implementation models were created:
— ISO 19115-4 Core
— ISO 19157-1 Core
ISO/DTR 19115-4:2026(en)
[1] [2]
The ISO 19115-4 Core JSON was created based on the ISO 19115-1 conceptual model. For ISO 19157-1 ,
the ISO 19157-1-core JSON was created. These UML implementation models define the ISO 19115-4 Core
[4]
profile and serve as an input for automated JSON schema derivation. The ISO 19115-3 implementation
model was not used as it is an XML implementation profile. The ISO 19115-4 Core UML implementation
model is intentionally a straight forward copy of the conceptual models. Specifications are only added at
the level of UML tagged values to steer the automated JSON schema generation. The advantage of this is an
easier maintenance relation between conceptual and implementation model.
4.6 JSON reference instance document
It was concluded that a straightforward rule-based generation of JSON schemas from the ISO 19115-4
Core UML implementation model did not result in a JSON schema optimized for an efficient JSON data
implementation.
There were two main reasons:
— JSON schema does not support the concept of type inheritance. There are ways to represent type
inheritance in JSON schema, but they all have their advantages and disadvantages depending on how
type inheritance is used in the model. A consequence is that it is often beneficial to modify the JSON
representation on a case-by-case basis.
— In some cases, for example, the uses of CI_Date, a direct mapping of the conceptual model results in an
unnecessarily complex JSON representation that could be improved (in general, the conceptual model
could be improved in those cases, too; in the CI_Date case, a qualified association to DateTime with the
dateType as the qualifier expresses the semantics more accurately than the current model).
To agree on an efficient JSON data implementation a JSON reference instance document was created.
This JSON reference instance document was used to adapt the rules and specifications for automatically
generating a JSON schema from the ISO 19115-4 Core implementation model.
NOTE These adaptations will be proposed to OGC for a revision of their Best Practice document.
The JSON reference instance document was created manually on the basis of an existing and adapted
[4]
ISO 19115-3 XML dataset. This XML dataset was chosen from an existing metadata dataset and adapted to
[4]
cover the most common operational part of the ISO 19115-3 implementation model and therefore reflect
a good representation of the planned content of the ISO 19115-4 Core. In Annex A, the classes contained in
the JSON reference instance document are presented and related to the core profile. In Annex C the JSON
reference instance document is presented.
The creation of the reference instance document led to a first list of basic requirements:
a) MD_Metadata is the starting object of a JSON metadata document. This MD_Metadata object will be
encoded as a GeoJSON feature collection or feature (when the metadata only refers to a single area). This
approach makes a JSON metadata document implementable in a GeoJSON environment.
b) All properties of a MD_Metadata record are encoded in the "properties" object of that GeoJSON feature.
The relevant geometry properties will be mapped to the GeoJSON feature geometry elements.
c) The default encoding of associations will be inline. By reference encoding will only be specified where
the inline option is not appropriate, typically because of re-use or recursive inline inclusions.
d) One or only a limited set of JSON schemas is preferred as this will provide a simpler schema handling.
[1] [2]
The modularization as is found in the ISO 19115-1 andISO 19157-1 conceptual models will not be
expressed in separate JSON schemas.
e) Tailoring a JSON metadata schema for specific profiles can be done as a separate process. This is not
part of this document.
ISO/DTR 19115-4:2026(en)
4.7 UML to JSON encoding rules and automated generation of JSON schema
The UML to JSON encoding started with rules from the Best Practice for OGC - UML to JSON encoding
[3] [12]
rules . This comprises encoding rules to plain JSON, GeoJSON and JSON-FG 0.1 and is considered to be
a mature specification in this domain. The ISO 19115-4 Core implementation model was used as input in
UML to JSON schema transformation software implementing the mentioned encoding rules. As remarked in
4.6, the result was not an optimal JSON schema for efficient JSON data implementation. Testing the results
against the content and structure of the JSON reference instance document led to updated conversion rules,
adapted transformation settings and some manual reworking of the ISO 19115-4 Core JSON schema. These
deviations from the defined encoding rules are documented in 5.1.3.
4.8 Multilingual adaptability
The web architecture and HTTP support access to content in a specific language which is applicable to most
multilingual situations envisaged for the ISO 19115 series.
JSON is generally used within a web context. Both web architecture and JSON have native ways to handle
multiple languages which are applicable to most multilingual situations envisaged for the ISO 19115 series.
For example, in this specific case of localized text: On the web, a resource representation is typically in a
[13]
single language, expressed via Reference the "Content-Language" header. At the back-end, the resource
can be (and often is) multilingual. When requested via HTTP, the result is a representation in a single
language. The language will be determined based on the request (e.g. a language-specific URL or an "Acce
...

ISO/TC 211
Style Definition: Heading 1: Indent: Left: 0 cm, First
line: 0 cm
ISO/CD TRDTR 19115-4(en)
Style Definition: Heading 2: Font: Bold, Indent: Left: 0
cm, First line: 0 cm
ISO/TC 211
Style Definition: Heading 3: Font: Bold, Indent: Left: 0
cm, First line: 0 cm
Secretariat:  SIS
Style Definition: Heading 4: Font: Bold, Indent: Left: 0
cm, First line: 0 cm
Date: 2026-04-23
Style Definition: Heading 5: Font: Bold, Indent: Left: 0
cm, First line: 0 cm
Style Definition: Heading 6: Font: Bold
Style Definition: IntroHeading1: Font: Bold, Indent:
Left: 0 cm, First line: 0 cm
Style Definition: IntroHeading2: Font: Bold, Indent:
Geographic information — – Metadata —
Left: 0 cm, First line: 0 cm
Style Definition: IntroHeading3: Font: Bold, Indent:
Left: 0 cm, First line: 0 cm
Style Definition: IntroHeading4: Font: Bold, Indent:
Left: 0 cm, First line: 0 cm
Style Definition: IntroHeading5: Font: Bold, Indent:
Left: 0 cm, First line: 0 cm
Part 4:
Style Definition: IntroHeading6

Style Definition: IntroHeading7
JSON schema implementation of metadata fundamentals
Style Definition: IntroHeading8
Information géographique — Métadonnées —
Style Definition: IntroHeading9
Style Definition: ANNEX
Partie 4: Mise en œuvre des principes fondamentaux des métadonnées par des schémas JSON
Style Definition: Key Text
Style Definition: Key Title
Style Definition: List Continue 1
Style Definition: List Continue 2: Indent: Left: 0.71 cm,
Hanging: 0.71 cm, Bulleted + Level: 1 + Aligned at:
1.35 cm + Indent at: 1.98 cm
Style Definition: TermNum2: Font: Bold, Indent: Left:
0 cm, First line: 0 cm
Style Definition: TermNum3: Font: Bold, Indent: Left:
0 cm, First line: 0 cm
Style Definition
...
Style Definition
...
Style Definition: TermNum6: Font: Bold
Style Definition: Body Text
Style Definition: boxedText
TTTTTTTTTTThhhhhhhhhhhiiiiiiiiiiisssssssssss d d d d d d d d d d drrrrrrrrrrraftaftaftaftaftaftaftaftaftaftaft i i i i i i i i i i isssssssssss s s s s s s s s s s suuuuuuuuuuubbbbbbbbbbbmmmmmmmmmmmiiiiiiiiiiittttttttttttttttttttttededededededededededed t t t t t t t t t t tooooooooooo      a pa pa pa pa pa pa pa pa pa pa parararararararararararallel vallel vallel vallel vallel vallel vallel vallel vallel vallel vallel vooooooooooottttttttttte e e e e e e e e e e iiiiiiiiiiinnnnnnnnnnn I I I I I I I I I I ISSSSSSSSSSSOOOOOOOOOOO,,,,,,,,,,, C C C C C C C C C C CEEEEEEEEEEENNNNNNNNNNN.
Style Definition: Boxed List Continue 1
Style Definition: boxedTitle
Style Definition: FooterCentered
Style Definition: FooterPageNumber
Style Definition: FooterPageRomanNumber
Style Definition: FooterCenteredContinued
Style Definition: TPS Markup Base
Formatted: zzCover large
ISO/CD TR 19115-4:2026(en)
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
E-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
ISO/CD TR 19115-4:2026(en)
Contents
Foreword . iii
Introduction . iii
Scope . iii
Normative references . iii
Terms and definitions . iii
Basic approach and design decisions . iii
Introduction . iii
General approach and workflow . iii
JSON representation . iii
Profile on conceptual content . iii
19115-4 UML and 19157-1 UML implementation models for JSON . iii
JSON reference instance document . iii
UML to JSON encoding rules and automated generation of JSON schema . iii
Multilingual adaptability . iii
Encoding approach and rules . iii
UML to JSON encoding rules. iii
Modularization . iii
UML implementation model for JSON implementation . iii
(informative) Defined profile (subset) on ISO 19115-1 and ISO 19157-1 . iii
(informative) Geographic metadata JSON schema resources . iii
(informative) Implementation example:. iii
Bibliography . iii
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Basic approach and design decisions . 1
4.1 Overview . 1
4.2 General approach and workflow . 2
4.3 JSON representation . 3
4.4 Profile on conceptual content . 4
4.5 ISO 19115-4 (this document) UML and ISO 19157-1 UML implementation models for
JSON . 4
4.6 JSON reference instance document . 5
4.7 UML to JSON encoding rules and automated generation of JSON schema . 5
4.8 Multilingual adaptability . 6
5 Encoding approach and rules . 6
5.1 UML to JSON encoding rules . 6
5.2 Modularization . 10
5.3 UML implementation model for JSON implementation . 11
Annex A (informative) Defined profile (subset) on ISO 19115-1 and ISO 19157-1 . 14
Annex B (informative) Geographic metadata JSON schema resources . 20
iii
ISO/CD TR 19115-4:2026(en)
Annex C (informative) Implementation example . 21
Bibliography . 23

iv
ISO/CD TR 19115-4:2026(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Field Code Changed
Attention is drawnISO draws attention to the possibility that some of the elementsimplementation of this
document may beinvolve the subjectuse of (a) patent(s). ISO takes no position concerning the evidence,
validity or applicability of any claimed patent rights. in respect thereof. As of the date of publication of this
document, ISO had not received notice of (a) patent(s) which may be required to implement this document.
However, implementers are cautioned that this may not represent the latest information, which may be
obtained from the patent database available at www.iso.org/patents. ISO shall not be held responsible for
identifying any or all such patent rights. Details of any patent rights identified during the development of the
document will be in the Introduction and/or on the ISO list of patent declarations received (see
www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation onof the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following URL:
www.iso.org/iso/foreword.html), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 211 Geographic information., Geographic
information/Geomatics, in collaboration with the European Committee for Standardization (CEN) Technical
Committee CEN/TC 287, Geographic Information, in accordance with the Agreement on technical cooperation
between ISO and CEN (Vienna Agreement), and in collaboration with the Open Geospatial Consortium (OGC).
A list of all parts in the ISO 19115 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
ISO/CD TR 19115-4:2026(en)
Introduction
ISO 19115-1ISO 19115-1 explains the importance of metadata, specifies a model for describing geographic
information resources by defining metadata entities, elements and terminology, and establishingestablishes
an extension procedure for additional metadata content. This technical reportdocument investigates the JSON
implementation of this same conceptual model including relevant parts of ISO 19157-1ISO 19157-1. A
resulting JSON encoding is developed for a subset of the named conceptual models showing the principles
used. In this regard the defined jsonJSON encoding is not intended to be a formal jsonJSON encoding but serves
as a proof of concept.
The primary use case envisioned for thisthe JSON implementation illustrated in this document is the exchange
and publication of geographic metadata through APIs. The intention in publishing this reportdocument is that
the community can begin using this approach and can feed back improvements so that a formal specification
can be developed.
JSON has become one of the major encodings used by current web applications, for example in many
implementations of OGC API Records. A JSON encoding to standardize a JSON implementation of metadata
types is needed. This document describes a JSON encoding of ISO 19115-1ISO 19115-1 including the data
quality concepts in ISO 19157-1.ISO 19157-1. In this document only a subset of both standards is
implemented. A subset, considered to be the core part of both standards, currently satisfies the need for an
initial evaluation and proof of concept for the JSON encoding. This core partdocument and the resulting JSON
encoding are regarded as mature within the context of an ISO technical report, encompassing a broad range
of content. In the future, the scope maywill potentially be expanded to include the complete content of the ISO
19115 series conceptual models.
The integrated JSON schema was derived from the ISO 19115-1ISO 19115-1 and ISO 19157-1ISO 19157-1
conceptual models in UML. Since standardized UML-to-JSON encoding rules do not yet exist, the OGC
[3][3]
document Best Practice for OGC - UML to JSON Encoding Rules was used as a reference.

vi
ISO/DTR 19115-4:2026(en)
Geographic information – Metadata —
This implementation model described in this documentPart 4:
JSON schema implementation of metadata fundamentals
1 Scope
This document describes a ECMA 404 JSON implementation of ISO 19115-1 and ISO 19157-1as a proof of
concept. The resulting JSON encoding is not a formal json specification but is intended to proof the feasibilty
of the approach taken and the implicated encoding principles.
[5]
The document provides a set of JSON schema files which define a JSON encoding of the concepts defined by
conceptual schemas in ISO 19115-1 and ISO 19157-1. The JSON representation is scoped to exchange via
HTTP. In this version of the technical report only a subset of the content of both ISO 19115-1 and ISO 19157-
1 is included. This is done to simplify the process of defining the resulting JSON schema. For the same reason
for now ISO 19115-2is not included. The subset is chosen to be a core operational set of both the ISO 19115-
1 and ISO 19157-1.
The document describes the procedure used to generate JSON schema from ISO geographic information
conceptual models related to metadata. The procedure includes creation of an UML implementation model for
JSON implementation derived from the ISO 19115-1 and ISO 19157-1 conceptual schemas.
The ISO 19115-4 implementation model does not alter the semantics of the source conceptual models, but
profiles content required for efficient JSON implementation and adds UML elements to facilitate UML to JSON
transformation software. The JSON schemas were created automatically from the UML model, based on UML
to JSON encoding rules as well as on a manually generated JSON reference instance document. Automated
[3][3]
generation is according to the encoding rules described in OGC best practice report: Best Practice for OGC
- UML to JSON Encoding Rules. The JSON reference instance document was created based on a manually
created ISO 19115-3ISO 19115-3 XML document.
vii
ISO/CD TRDTR 19115-4:2026(en)
Geographic information — – Metadata —
Part 4:
JSON schema implementation of metadata fundamentals
1 Scope
This document describes a ECMA 404:2017 JSON implementation of ISO 19115-1 and ISO 19157-1 as a proof
of concept. The resulting JSON encoding is not a formal json specification but is intended to proof the feasibilty
of the approach taken and the implicated encoding principles.
[6]
The document provides a set of JSON schema files which define a JSON encoding of the concepts defined by
conceptual schemas in ISO 19115-1 and ISO 19157-1. The JSON representation is scoped to exchange via
HTTP. In this document, only a subset of the content of both ISO 19115-1 and ISO 19157-1 is included, in order
to simplify the process of defining the resulting JSON schema. For the same reason, ISO 19115-2:2019 is
currently not included. The subset is chosen to be a core operational set of both ISO 19115-1 and ISO 19157-
1.
This document describes the procedure used to generate JSON schema from ISO geographic information
conceptual models related to metadata. The procedure includes creation of an UML implementation model for
JSON implementation derived from the ISO 19115-1 and ISO 19157-1conceptual schemas.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, no specific newNo terms and definitions were createdare listed in this
document.
ISO and IEC maintain terminologicalterminology databases for use in standardization at the following
addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— — ISO Online browsing platform: available at
Formatted: Body Text
http://www.iso.org/obphttps://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
4 Basic approach and design decisions
4.1 Introduction
4.1 In this chapterOverview
This clause describes the approach is described that was taken to generate the metadata JSON schema. The
approach consistconsists of a workflow identifying several steps. The workflow and the separate steps are
described and include formulated design decisions and requirements set for the JSON schema to be produced.
ISO/CD TRDTR 19115-4:2026(en)
4.2 General approach and workflow
A general approach and workflow has been followed to guide the process for the realization of the JSON
schemas and the related document. This workflow was based on a combination of requirements and decisions
that are explained in the following clausessubclauses. Figure 1 explains the approach and workflow and shows
six steps and several products.
19115-4
19115-1
19157-1
19157-1
UML UML Veri�ied Published
JSON
Conceptual Application ShapeChange JSON JSON
schema
schema schema schema schema
testing
adapting encoding
JSON
reference
dataset
Figure 1 — Schematic view of general approach and workflow
Figure 1 explains the approach and workflow and shows six steps and several products.
— Step 1a) — The conceptual schemas of the ISO 19115-1 and ISO 19157-1ISO 19115-1 and ISO 19157-1
Formatted: List Continue 1
are the conceptual input tofor the ISO 19115-4 and ISO 19157-1 UML implementation model for JSON.
ISO19115-4 is the -4 part of the ISO 19115 series. described in ISO 19157-1 and in this document. For the
ISO 19157-1ISO 19157-1, a JSON implementation model is developed only from the ISO 19115-4
perspective. of this document. This means that for this TRdocument, no overall evaluation of ISO 19157
series elements is included. This can be anticipated in a separate, future ISO 19157 separateseries JSON
implementation;.
— Step 1b) — A JSON reference dataset wasis created that defines the preferred JSON encoding against which
the generated JSON schema were tested and improved;.
ISO/CD TRDTR 19115-4:2026(en)
— Step 2) — The ISO 19115-4 UML implementation model described in this document is input for an
automated and rule -based transformation to a JSON schema encoding. Since the ISO 19157-1ISO 19157-
1 is referenced from the ISO 19115-4 this wasdocument, this is also transformed to a JSON schema.
— Step 3) — The generated JSON schemas wereare tested against the JSON reference dataset. In an iterative
process, results of this test wereare fed back to adapting the ISO 19115-4 and ISO 19157-1 UML
implementation models and/or transformation parameters. of this document and ISO 19157-1. The
updated JSON schemas again wereare tested again. Requirements set by the JSON reference dataset that
could notcannot be met by automated schema generation and existing encoding rules wereare adapted
manually;.
— Step 4) — The JSON reference dataset wasis verified against the JSON schemas and vice versa and the
schema is accepted for publication;.
— 5) the  The verified JSON schemas for this profile of ISO 19115-4this document and ISO 19157-1ISO
19157-1 are published within the context of this document.
Detailed descriptions of these steps are presented in the next paragraphsfollowing subclauses.
4.3 JSON representation
The JSON representation to encode ISO 19115-4 in this document has several specifics.
A MD_Metadata record is represented as a IETF RFC 7946IETF RFC 7946:2016 GeoJSON feature with. The
following points apply:
— the metadata identifier is set as the "id" member;
— the spatial extent is in the "geometry" and/or "bbox" members;
— all other properties of the record are in the "properties" member;
— when the MD_Metadata does not have a spatial reference, i.e. no spatial extent is present, the geometry
member is set to null;
— it is recognized that GeoJSON uses only WGS84 as coordinate reference system. In cases where this is not
appropriate, for instance when data cannot be referenced to the earthEarth, the geometry member can be
set to null.
The structure of the properties is in general a straightforward mapping of the UML model to JSON:
— properties with structured values (data types, classifiers) are mapped to a JSON object;
— all other properties are mapped to the JSON types string, number or boolean;
— properties with a maximum multiplicity greater than one are wrapped in a JSON array.
This representation has similarities with the XML representation specified by the ISO/TS 19139-1ISO/TS
19139-1 encoding rule. The main differences are: as follows.
— The JSON representation is "flatter" as in XML an extra tag is used for each object, grouping the tags of each
property, while in JSON simply a JSON object is used. In cases where the type of the object is unclear, since
multiple instantiable types can be the property value due to the use of inheritance in the model, an
additional member "type" is added with the name of the type in the model - in. In XML the type is expressed
in the name of the tag of the object.
ISO/CD TRDTR 19115-4:2026(en)
— The XML representation also represents base types like a string as an object to support representing sub-
types, which is an edge case, while the JSON representation removes this capability to simplify the use of
the data.
— The XML encoding rules in the ISO 19139 series added a capability to add metadata to a property without
value. This capability is not included in the conceptual model and has not been included in the JSON
representation.
More details of the encoding rule for representing a MD_Metadata record is provided in the next Clause.4.6.
The reason for this representation is that GeoJSON is the most widely supported JSON format for spatial data.
As a result, those metadata records in JSON that include a spatial extent (at least those metadata records that
include a geographic extent) can be shown on a map in almost all mapping tools and libraries - at least those
metadata records that include a geographic extent.
[9][10]
Those that want to link members of a JSON document to an ontology maycan add a JSON-LD context to
the JSON instance. Nesting capabilities are also available thanks to the support of JSON-LD at core level.

4.4 Profile on conceptual content
The source of the conceptual content are the conceptual models as described by the ISO 19115-1ISO 19115-1
and the data quality standard ISO 19157-1.ISO 19157-1. Nesting capabilities are also available thanks to the
support of JSON-LD at core level. However, to handle complexity in this phase and first get a working
operational JSON implementation, which can be reviewed and later extended, the input conceptual models are
profiled or sub-setted to a selection of metadata classes.
The requirements for this subset were set to meet two criteria: that the subset should covercovers most of the
common use of metadata defined in the ISO 19115 series, and that the subset should leave outexcludes
complex constructs that for nowcurrently do not add much to the applicability of this JSON implementation.
The profile is called "ISO 19115-4 Core.".
The"ISO 19115-4 Core" is defined by a profile on ISO 19115-1ISO 19115-1 and ISO 19157-1.ISO 19157-1. No
content of the ISO 19115-2ISO 19115-2 is included in this 19115-4 Core. For the other two partsISO 19115-1
and ISO 19157-1, the subset is described in Annex AAnnex A.
4.5 ISO 19115-4 (this document) UML and ISO 19157-1 UML implementation models for
JSON
Two UML implementation models were created:
— ISO 19115-4-core Core
— ISO 19157-1-core Core
The ISO 19115-4 coreCore JSON was created based on the ISO 19115-1ISO 19115-1 conceptual model. For the
[2]
19157-1 , the ISO 19157-1-core JSON was created. These UML implementation models define the ISO 19115-
4 Core profile and serve as an input for automated JSON schema derivation. The 19115-3The ISO 19115-3
implementation model was not used as it is an XML implementation profile. The ISO 19115-4 Core UML
implementation model is intentionally a straight forward copy of the conceptual models. Specifications are
only added at the level of UML tagged values to steer the automated JSON schema generation. The advantage
of this is an easier maintenance relation between conceptual and implementation model.
ISO/CD TRDTR 19115-4:2026(en)
4.6 JSON reference instance document
It was concluded that a straight forwardstraightforward rule -based generation of JSON schemas from the ISO
19115-4 Core UML implementation model did not result in a JSON schema optimized for an efficient JSON data
implementation.
There were mainly two main reasons:
— JSON Schemaschema does not support the concept of type inheritance. There are ways to represent type
inheritance in JSON Schemaschema, but they all have their advantages and disadvantages depending on
how type inheritance is used in the model. A consequence is that it is often beneficial to tweakmodify the
JSON representation on a case-by-case basis.
— In some cases, for example, the uses of CI_Date, a direct mapping of the conceptual model results in an
unnecessarily complex JSON representation that could be improved (note that, in general, the conceptual
model could be improved in those cases, too; in the CI_Date case, a qualified association to DateTime with
the dateType as the qualifier expresses the semantics more accurately than the current model).
To agree on an efficient JSON data implementation a JSON reference instance document was created. This JSON
reference instance document was used to adapt the rules and specifications for automatically generating a
JSON schema from the ISO 19115-4 Core implementation model.
NOTE These adaptations will be proposed to OGC for a revision of their Best Practice document.
Formatted: Note
The JSON reference instance document was created manually on the basis of an existing and adapted 19115-
3ISO 19115-3 XML dataset. This XML dataset was chosen from an existing metadata dataset and adapted to
cover the most common operational part of the 19115-3ISO 19115-3 implementation model and therefore
reflect a good representation of the planned content of the ISO 19115-4 coreCore. In Annex AAnnex A, the
classes contained in the JSON reference instance document are presented and related to the core profile. In
Annex CIn Annex C the JSON reference instance document is presented.
The creation of the reference instance document led to a first list of basic requirements:
a) MD_Metadata is the starting object of a JSON metadata document. This MD_Metadata object will be
Formatted: Numbered + Level: 1 + Numbering Style: a,
encoded as a GeoJSON feature collection or feature (when the metadata only refers to a single area). This
b, c, … + Start at: 1 + Alignment: Left + Aligned at: 0
approach makes a JSON metadata document implementable in a GeoJSON environment.
cm + Indent at: 0 cm
b) All properties of a MD_Metadata record are encoded in the "properties" object of that GeoJSON feature.
Formatted: Numbered + Level: 1 + Numbering Style: a,
The relevant geometry properties will be mapped to the GeoJSON feature geometry elements.
b, c, … + Start at: 2 + Alignment: Left + Aligned at: 0
cm + Indent at: 0 cm
c) The default encoding of associations will be inline. By reference encoding will only be specified where the
Formatted: Numbered + Level: 1 + Numbering Style: a,
inline option is not appropriate, typically because of re-use or recursive inline inclusions.
b, c, … + Start at: 3 + Alignment: Left + Aligned at: 0
cm + Indent at: 0 cm
d) One or only a limited set of JSON schemas is preferred as this will provide a simpler schema handling. The
Formatted: Numbered + Level: 1 + Numbering Style: a,
modularization as is found in the ISO 19115-1ISO 19115-1 and ISO 19157-1ISO 19157-1 conceptual
b, c, … + Start at: 4 + Alignment: Left + Aligned at: 0
models will not be expressed in separate JSON schemas.
cm + Indent at: 0 cm
e) Tailoring a JSON metadata schema for specific profiles can be done as a separate process. This is not part
Formatted: Numbered + Level: 1 + Numbering Style: a,
of this technical reportdocument. b, c, … + Start at: 5 + Alignment: Left + Aligned at: 0
cm + Indent at: 0 cm
4.7 UML to JSON encoding rules and automated generation of JSON schema
[3]
The UML to JSON encoding started with are rules from the Best Practice for OGC - UML to JSON encoding
[3] [10][12]
rules. It consists of . This comprises encoding rules to plain JSON, GeoJSON and JSON-FG 0.1 and is
ISO/CD TRDTR 19115-4:2026(en)
considered to be a mature specification in this domain. The ISO 19115-4 Core implementation model was used
as input in UML to JSON schema transformation software implementing the mentioned encoding rules. As
remarked in 4.64.6, the result was not an optimal JSON schema for efficient JSON data implementation. Testing
the results against the content and structure of the JSON reference instance document led to updated
conversion rules, adapted transformation settings and some manual reworking of the ISO 19115-4 Core JSON
schema. These deviations from the defined encoding rules are documented in clause 5.1.35.1.3.
4.8 Multilingual adaptability
The web architecture and HTTP support access to content in a specific language which is applicable to most
multilingual situations envisaged for the ISO 19115 series.
JSON is generally used within a web context. Both web architecture and JSON have native ways to handle
multiple languages which are applicable to most multilingual situations envisaged for the ISO 19115 series.
For example, in this specific case of localized text: On the web, a resource representation is typically in a single
[11] [13]
language, expressed via Reference the "Content-Language" header. At the back-end, the resource can be
(and often will beis) multilingual. When requested via HTTP, you getthe result is a representation in a single
language. The language will be determined based on the request (e.g. a language-specific URL or an "Accept-
Language" header).
If used in a web context there is no need for a LocalisedCharacterString in JSON. The language used in the
particular JSON document / representation is represented by the "Content-Language" header and maybe also
a property that could be added to the JSON object itself.
5 Encoding approach and rules
5.1 UML to JSON encoding rules
5.1.1 Introduction
5.1.1 Overview
The encoding of the ISO 19115-4 coreCore metadata UML implementation model into JSON schema is rule -
based. Encoding rules are used and or defined to encode the the UML model into a resulting JSON schema. In
this chapterclause, several aspects are described that led to a final set of rules for the UML to JSON schema
encoding, as well as rules that describe conversion rules at the instance level.
5.1.2 General rules for transforming UML to JSON schema
[3] [3]
The basis for the UML to JSON schema encoding is the Best Practice for OGC - UML to JSON encoding rules. .
This best practice document describes encoding rules structured into requirements classes that can be
specified for specific requirements set for specific encoding use cases. For details is referred to the mentioned
document.
5.1.3 Details and deviations
Several details and also deviations with respect to the general encoding rules were defined. Some of these
came from the requirements as they arepoints formulated in 4.44.4 and some came from the JSON reference
document.
JSON Schemaschema level extra encoding rules:
a) abstractAbstract classes are omitted from the JSON schema. JSON does not have a concept for abstract
Formatted: Numbered + Level: 1 + Numbering Style: a,
classes. For this reason, and at the same time simplifyingin order to simplify the structure of the schema,
b, c, … + Start at: 1 + Alignment: Left + Aligned at: 0
these abstract classes are not included. Properties of these classes are 'copied down'"copied down" to
cm + Indent at: 0 cm
ISO/CD TRDTR 19115-4:2026(en)
subtypes following the inheritance relationship. A specific union construct is added to resolve the
associations to abstract classes as being redirected to the subtypes. These union constructs are named in
the format 'Abstract_'+'name"Abstract_"+"name of source class'+'Union'.class"+"Union".
EXAMPLE 1
"Abstract_ConstraintUnion": {
"$anchor": "Abstract_ConstraintUnion",
oneOf": [
{ "$ref": "#MD_Constraints" },
{ "$ref": "#MD_LegalConstraints" },
{ "$ref": "#MD_SecurityConstraints" } ] }
b) The 'type' property has been deleted except for subclasses (subtypes) where this is needed to recognize
Formatted: Numbered + Level: 1 + Numbering Style: a,
the subtype. In that case a type value of string is added which is restricted to a constant value being the
b, c, … + Start at: 2 + Alignment: Left + Aligned at: 0
name of the subclass. cm + Indent at: 0 cm
EXAMPLE 2 CI_Individual that has a type value which is a constant value being ‘CI_Individual’.
c) CI_Date and CI_Telephone are changed to object and not array of objects. This minimizes data complexity
Formatted: Numbered + Level: 1 + Numbering Style: a,
and handles structure and multiplicity by introducing key-value pairs.
b, c, … + Start at: 3 + Alignment: Left + Aligned at: 0
cm + Indent at: 0 cm
EXAMPLE 3 Instance example:
"dateInfo": {
"revision": "2018-04-20T06:19:51Z",
"creation": "2010-02-04T00:00:00Z"},
d) Date-time is changed to a type DateOrDateTime, including year month. This is according to DateTime
Formatted: Numbered + Level: 1 + Numbering Style: a,
specifications in ISO 19115-1, annexISO 19115-1:2014, B.2.2.
b, c, … + Start at: 4 + Alignment: Left + Aligned at: 0
cm + Indent at: 0 cm
e) Values of attributes that reference code lists are reduced to string values.
Formatted: Numbered + Level: 1 + Numbering Style: a,
b, c, … + Start at: 5 + Alignment: Left + Aligned at: 0
f) MD_Metadata.identificationInfo has been reduced to a single value, not an array. Containing multiple
cm + Indent at: 0 cm
identificationInfo properties within on MD_Metadata is seen as an edge case, and can be handled by using
Formatted: Numbered + Level: 1 + Numbering Style: a,
several metadata instances.
b, c, … + Start at: 6 + Alignment: Left + Aligned at: 0
cm + Indent at: 0 cm
g) Codelists are reduced to data types of type string. Codelist values are therefore reduced to string using
Formatted: Numbered + Level: 1 + Numbering Style: a,
the code. See 5.1.45.1.4 for discussion.
b, c, … + Start at: 7 + Alignment: Left + Aligned at: 0
cm + Indent at: 0 cm
EXAMPLE 4 "MD_ClassificationCode": { "$anchor": "MD_ClassificationCode", "type": "string" },
h) Several external data types that are referenced in the conceptual models do not have standardized JSON
Formatted: Numbered + Level: 1 + Numbering Style: a,
schema definitions. In the JSON schema these are mapped to specific solutions described in paragraph
b, c, … + Start at: 8 + Alignment: Left + Aligned at: 0
5.1.55.1.5. cm + Indent at: 0 cm
JSON instance level encoding rules:
Formatted: Numbered + Level: 1 + Numbering Style: a,
i) The metadata identifier code (MD_Metadata.metadataIdentifier) has been copied into the GeoJSON
b, c, … + Start at: 9 + Alignment: Left + Aligned at: 0
feature 'id'."id".
cm + Indent at: 0 cm
ISO/CD TRDTR 19115-4:2026(en)
j) The bounding box extent (EX_GeographicBoundingBox) has been copied into the GeoJSON feature
Formatted: Numbered + Level: 1 + Numbering Style: a,
'geometry'"geometry" and 'bbox'."bbox". b, c, … + Start at: 10 + Alignment: Left + Aligned at: 0
cm + Indent at: 0 cm
k) The data type 19103:Record is mapped to a JSON value.
Formatted: Numbered + Level: 1 + Numbering Style: a,
b, c, … + Start at: 11 + Alignment: Left + Aligned at: 0
5.1.4 Code lists
cm + Indent at: 0 cm
Values governed by code lists in this reportdocument have been implemented as a simple string. This
paragraphsubclause provides suggestions for future solutions, showing that the chosen approach provides
the simplest JSON instances and that there is no clear better practice.
A code list, is an extensible list of identifiers (“codes”) for concepts. At least that was its definition in the ISO
19103 , the standard the 19115-1:2024 adheres to. (see ISO 19103). The code lists in the ISO 19115 series are
managed by ISO/TC 211. They can be extended, but ISO 19115-1ISO 19115-1:2014 states “Extending code
liststhat this is discouraged, even in profiles. When they must be extended care should be takenextension is
necessary, it is important to minimize the number of additional entries. Also, and to ensure that the extended
code list should beis published or otherwise made available.”.
Until 2025, ISO/TC 211 published the code lists as CT_CodeListCatalogue files in accordance with the XML-
based code list catalogue component defined in ISO/TS 19139:2007,ISO/TS 19139:2007, 7.4.4. ISO/TC 211
recently published code lists at https://def.isotc211.org/https://def.isotc211.org/ as a
[13]
http://www.w3.org/TR/skos-reference http://www.w3.org/TR/skos-reference SKOS ConceptScheme
with each code accessible directly as a SKOS Concept.
ISO 19115-1ISO 19115-1 specifies that the codes are language neutral identifiers; each code also has an
English concept name and a definition. In almost all cases in the ISO 19115 series, the code and the English
concept name are the same, in that ISO 19115-1ISO 19115-1 provides “English” concept names that conform
to the lower camel case convention for a code list concept identifier. There are a few exceptions to this, such
as the MD_RestrictionCode concept with name “sensitiveButUnclassified” and code “SBU”.
A property which has a code list as its type can take any one value from that code list. It is a string with a
controlled range of allowable values. The JSON Schemas for this reportdocument allow any string, expecting
the concept name to be used, "role": "pointOfContact". This could be automatically validated but not
within the JSON Schema files; doing that would constrain the code list to being an enumeration: a code list that
can only be changed by changing the standard.
In order to provide more semantic context for yourthe metadata record, you couldit is possible to include a
reference to the code list (concept scheme) so that users can access the definition of the concept. This is
especially important if you extendwhen extending the ISO 19115 series code lists, that is,i.e. if you
includeincluding concepts whichthat do not exist in the ISO 19115 series. It could also improve the
interoperability of the metadata in relation to metadata conforming to other standards. There are several ways
to do this in JSON:
— JSON-LD context: Give the code list (concept scheme) as a JSON-LD context (JSON-LD 1.1) .{"@).
Formatted: Font: Not Bold
— {"@context": {"rc": "http://def.isotc211.org/common/RoleCode/"}} "role": "rc:pointOfContact"

— As each code list would have a different context, this would require a schema change with each code
list controlled property becoming an object with a context and value. It would work better if the code lists
concepts were in a hierarchy so the context could be on an existing containing object such as
CI_ResponsibleParty.
ISO/CD TRDTR 19115-4:2026(en)
— ISO/TC 211 publishes a JSON Context file to support this approach:
https://def.isotc211.org/common/context.json.
— JSON Reference: provide the concept identifier alongside the code (concept name) "role":
Formatted: Font: Not Bold
{$ref:http://def.isotc211.org/common/RoleCode/pointOfContact,
"pointOfContact"}; this would require a schema change and increase the complexity of the metadata
record, with each code list controlled property becoming an object with a reference (JSON Reference $ref)
as well as the value (concept name).
— Provide the concept identifier instead of the code (concept name) "role":
http://def.isotc211.org/common/RoleCode/pointOfContact; this does not require a
schema change but makes it harder to find the actual concept name: the identifier would be used to
retrieve the SKOS:prefLabel of the concept. In practice, people mightusers can potentially try to rely inon
parsing the iden
...