ISO/TR 22126-2:2025

Technical
Report
ISO/TR 22126-2
First edition
Financial services — Semantic
2025-01
technology —
Part 2:
OWL representation of the ISO
20022 metamodel and e-repository
Services financiers — Technologie sémantique —
Partie 2: Représentation OWL du métamodèle et du référentiel de
l'ISO 20022
Reference number
© ISO 2025
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Abbreviated terms .2
4 Overview . 2
4.1 Graph transformations . .2
4.1.1 General .2
4.1.2 Graphs derived from the XML document .4
4.1.3 Conversion to a FIX AE message .4
4.1.4 Graphs aligned with message and business components .4
5 Methods . 5
5.1 Multiple local RDF graphs .5
5.2 Open linked data .6
6 Reconciling differences between Ecore, RDF and OWL . 7
6.1 Introducing Ecore .7
6.2 Differences between Ecore and RDF standards .7
6.3 Separation of schema objects and instances .8
6.4 Python, pyecore and RDF .8
6.5 Ordering and structured data in RDF .9
6.5.1 General .9
6.5.2 Unordered relationships.9
6.5.3 RDF collections .9
6.5.4 RDF containers .10
6.5.5 Blank nodes and triples turned sideways .10
6.6 Internationalization in RDF .11
6.7 SHACL, another RDF schema language .11
7 Processing ISO 20022 instance messages in RDF .12
7.1 The G graph — Converting an ISO 20022 XML message to RDF instance data . . 12
7.2 Querying ISO 20022 message data with SPARQL .14
7.3 The G graph — Maintaining ordering information .14
7.4 Compatibility with OWL and RDFS inference — G graph .14
7.5 The G3 graph — Converting the auth.016 message to a FIX AE message . 15
8 Mechanical conversion of the e-Repository .18
8.1 File and namespace prefixes — M and B graphs .18
C C
8.2 OrganisationIdentification — Business components and attributes .18
8.3 Message components and attributes .21
8.4 CodeSets . 23
8.4.1 General . 23
8.4.2 Empty CodeSet . 23
8.4.3 CodeSet with codes .24
8.5 Coining unique identifiers . 25
8.5.1 The problem . . 25
8.5.2 Composite names . 25
8.5.3 Arbitrary disambiguators . 25
8.5.4 External id . 25
8.5.5 Internal id . 26
8.5.6 Random id. 26
8.5.7 Skolemization . 26

iii
9 Representing the ISO 20022 e-Repository in OWL and RDFS .26
9.1 Methodology . 26
9.2 RDFS modelling of a business component . 28
9.3 Datatype and object properties in OWL . 29
9.4 Representing enumerated types . 30
9.5 Restrictions on data types .31
9.6 Disjoint classes .31
9.7 Miscellaneous objects and annotation properties.32
9.8 Containment relationships and inference .32
9.9 OWL inference and its limits . 33
10 Instances aligned to the e-Repository .34
10.1 The G graph — Message expressed with message components . 34
10.2 The G graph — Abstract instance of a trade . 35
10.3 Concepts missing in the business components .37
11 Conclusion .38
Annex A (informative) A preliminary OWL 2 ontology as a semantic model for ISO 20022 .40
Bibliography .45

iv
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 document 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 68, Financial services, Subcommittee SC 9,
Information exchange for financial services.
A list of all parts in the ISO 22126 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
Introduction
The purpose of this document is to demonstrate the feasibility and explore the design space for the
representation of the ISO 20022 e-Repository in OWL DL, a decidable dialect of the OWL ontology language.
This document demonstrates multiple representations of the auth.016 sample messages illustrating possible
modelling choices.
The current e-Repository is constructed in a purpose-built system comprising multiple layers of object-
oriented modelling built on the Eclipse Modeling Framework, a specialization of the Essential Meta-Object
Facility (EMOF) standardized by the Object Management Group (OMG). This system can create class
1)
definitions and object instances in a computer language such as Java that serve as containers for data,
but does not define the semantics, or meaning, of those objects. The EMOF model is a foundation to write
software on (a “blank slate”) but requires custom software to establish the meaning and behaviour of those
objects.
In OWL DL, on the other hand, it is possible to construct concepts based on logical definitions. Although
custom software can still be necessary, an OWL DL ontology has a meaning and defined behaviours when
used with OWL standard tools. Out-of-the-box an OWL ontology works with ontology editors, reasoners
and graph databases that allow queries with the SPARQL language. An OWL ontology can be used together
with other OWL ontologies. Unlike more expressive systems such as ISO Common Logic, however, OWL DL is
based on a subset of first-order logic that is decidable so that in addition to reasoning instances (for instance
querying instances that match a logical definition) it can prove the consistency of an ontology. (As OWL is
defined in terms of first-order logic, OWL axioms can be exported to other logic-based tools that can be
more expressive, such as theorem provers, or more application-oriented, such as business rules engines.)
It is common for schemas and documentation for message families such as ISO 20022, FIX Protocol and
SWIFT MT to be written in formats idiosyncratic to the family. Although ISO 20022 messages conform to an
XML schema, authoritative definitions exist in the e-Repository as a set of Ecore-serialized objects specific
to ISO 20022. The elements of FIX messages (which can be encoded in various wire formats) are defined in
FIX Orchestra, an XML file which is specific to the FIX trading community. Tools designed to work with the
schema of one standard do not natively work for other standards.
Applications that process financial messages have their own schemas that exist either explicitly or implicitly,
for instance a set of tables, constraints, stored procedures and other projects in a relational database, or
a hierarchy of classes in a programming language such as Java. Although disparate descriptions for the
structure of messages and software systems fulfil the requirements of each system, technologists lack the
global view necessary to take rapid and correct action.
To have that global view, it is desirable to bring schemas and instances from disparate systems into a single
system which can be queried to support software development, make visualizations and do inference. RDF
is a suitable framework for this: not only does it come with standard vocabularies such as RDFS, OWL and
SHACL for representing schemas, but it can represent arbitrary data structures as a graph of nodes that
possess datatype properties and are interconnected with object attributes. Some major features of RDF are:
a) the XML schema datatypes are available to represent common primitive data types that occur in general
computing;
b) nodes and predicates, relationships between nodes, are named with URIs to establish a global namespace
in which terms from arbitrary vocabularies can be combined;
c) text strings are tagged with ISO 639 language codes to provide a straightforward mechanism to
represent labels and descriptions in multiple languages.
It is possible, as seen in Clause 7, to represent any kind of message in RDF through a simple form of mechanical
translation – it possible in RDF to work without a schema of any kind. Clauses 9 and 10 demonstrate that,
with more effort, it is possible to express the e-Repository and ISO 20022 messages as an OWL DL ontology.
1) Java is an example of a suitable product available commercially. This information is given for the convenience of users
of this document and does not constitute an endorsement by ISO of this product.

vi
The EMOF form of the e-Repository is built in a number of layers starting from the M3 layer (the foundation
of EMOF), the M2 layer (an object model used to describe the M1 model) and the M1 layer (definitions of
business components, message components, etc.). Users of the e-Repository can create instances of objects
defined at the M1 layer in the M0 layer that define individual messages or business objects. For the most
part, the ontology is contained in the M1 layer and defined in terms of an idiosyncratic vocabulary defined in
the M2 layer. This vocabulary is fit for purpose, but incompatible with other schema and ontology definition
systems.
OWL DL requires a flatter organization where there is a clear separation between ontology objects
(definitions of classes and properties) and instance objects (instances of the defined classes.) Most
terminology from the M2 layer is replaced with terminology from the OWL standard, making the ontology
automatically interoperable with other ontologies. Properties that cannot be expressed with built-in OWL
properties, such as XML element names for the message components, are represented with annotation
properties which, as defined in the ontology, not participate in inference. Objects in the e-Repository
which are not naturally treated as class or property definitions are defined as instances in OWL DL with
corresponding definitions derived from the M3 layer.
Users of this ontology can add additional instance and ontology objects. OWL, in particular, allows users to
write logical definitions in terms of specific lists of objects, the attributes of objects and logical combinations
such as AND, OR and NOT thereof. This makes it possible for a business or regulator to define a particular
kind of transaction (a subclass) in terms of size, the time it took place, the security traded, the attributes
of the organizations involved, etc. Annex A demonstrates that many categories defined and discussed in
regulation and documents are straightforward to express in this manner, a significant step towards making
business documents interpretable by machines.

vii
Technical Report ISO/TR 22126-2:2025(en)
Financial services — Semantic technology —
Part 2:
OWL representation of the ISO 20022 metamodel and
e-repository
1 Scope
This document is concerned with the representation of the ISO 20022 e-Repository contents in RDF and
OWL by developing a case study around the ISO 20022 auth.016 sample message (hereafter simply referred
to as “auth.016”). This includes:
a) transformation of the sample message into an RDF instance graph;
b) demonstrating a set of SPARQL rules that transform the auth.016 message into a FIX
TradeCaptureReport(35=AE) message (hereafter simply referred to as “FIX AE”);
c) expressing the metamodel, business components and message components exactly with a custom RDF
vocabulary;
d) representing those schemas as OWL schemas using OWL vocabulary when possible and annotation
properties otherwise;
e) creating instance graphs for the auth.016 sample messaging using the vocabulary of the business
components and message components.
This document also discusses the choices that arise in structuring RDF documents equivalent to documents
in XML, and FIX Tag-Value format balancing considerations such as preserving the order of parts of the
message versus creating graphs that are suitable for RDFS and OWL inference.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 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/

3.2 Abbreviated terms
API application programming interface
CORBA Common Object Request Broker Architecture
DCOM Distributed Component Object Model
EMOF Essential Meta-Object Facility
FIX Financial Information Exchange
JVM Java Virtual Machine
LEI Legal Entity Identifier
MOF Meta-Object Facility
OMG Object Management Group
OWL DL Web Ontology Language – Description Logic
RDF Resource Description Framework
RDFS RDF Schema
RMI Remote Method Invocation
SHACL Shapes Constraint Language
SKOS Simple Knowledge Organization System
SPARQL SPARQL Protocol and RDF Query Language
SPIN SPARQL Inferencing Notation
SWIFT MT SWIFT Message Type
SWRL Semantic Web Rule Language
UML Unified Modelling Language
URI Uniform Resource Identifier
UUID Universally Unique Identifier
XML Extensible Markup Language
XSD XML Schema Definition
4 Overview
4.1 Graph transformations
4.1.1 General
Figure 1 depicts the data transformations described in this document.

Key
A auth.016 XML message
B FIX AE message
C graphs aligned to message and business components
A sample auth.016 message as XML document
G A translated mechanically into RDF retaining element order
1 16
G simplified graph that removes inessential information such as element ordering from G
2 1
G a FIX AE message equivalent to A expressed as key-value pairs in RDF
3 16
F G converted to a complete FIX AE tag-value message
AE 3
G G rewritten using vocabulary defined in M (message components)
4 2 c
G G rewritten using vocabulary defined in B (business components)
5 4 c
M message Components Ontology in OWL
c
B business Components Ontology in OWL
c
NOTE Circles represent RDF graphs. Squares represent data in some other format. Blue lines represent
transformations that have been implemented. Red lines implement transformations that remain unimplemented. Blue
objects represent instance information (a message). Green objects represent schema and ontology information.
Figure 1 — Data transformations of RDF to and from other formats
A is the auth.016 sample message in XML format. In Clause 7, this message is represented as the G and
16 1
G graphs which are close to the structure and vocabulary of the XML document. Furthermore, a set of
production rules are demonstrated that can convert the A message into an equivalent F FIX AE message,
16 AE
a practical data transformation task.
Clauses 8 and 9 develop representations of the message components M and business components B in RDF.
c c
Clause 8 represents the contents of the e-Repository translated mechanically while Clause 9 represents the
contents of the e-Repository in OWL.
In Clause 10 the message is converted to the G and G graphs. The G graph precisely represents the A
4 5 4 16
content using vocabulary from M , a process which can be mechanically implemented. The final destination
c
is the G graph which uses vocabulary from B which is shared between multiple messages. Complete
5 c,
capture of the message’s meaning, however, requires additional terms that do not exist in B .
c
4.1.2 Graphs derived from the XML document
The method used to create G is mechanical and can be tuned to convert a wide range of XML documents to
RDF graphs.
Graph G was produced by combining the A sample message with information from the XSD schema. XML
1 16
element and attributes were rewritten to RDF property names by concatenation: for instance, an element
named is rewritten as the property ns:Pric where is ns is a chosen RDF namespace prefix. Leaf
nodes of the XML document are written as datatype properties while upper nodes are connected with object
properties. The XSD schema provides default values and resolves question such as “does this instance of the
string ‘55’ represent an integer or a character string?”.
G retains information about the order of elements in the document as well as information about where
nodes (in terms of line number and character position) appear in the source document. As the order of
elements is not essential to the meaning of the message, graph G is a simplified graph that strips away
information idiosyncratic to the source document.
4.1.3 Conversion to a FIX AE message
The FIX AE message is equivalent to the auth.016 in meaning and purpose. The G graph represents the
meaning of the auth.016 sample message in a vocabulary based on the FIX tag-value standard. A FIX tag such
as 35 is written with the predicate fix:f35 where fix is a chosen namespace, f means “field” and 35 is the
tag number. As with the XML document, the tree structure of the FIX message is represented as a tree of
RDF nodes.
The G graph was created from the G graph by matching patterns in G to equivalent patterns in G ,
3 2 2 3
a process that can be performed in either direction. The process of creating G does most of the work to
creating a FIX message equivalent to A . The remaining task to write a tag-value FIX message is to write
tag-value pairs from G the right order, calculate a checksum, append headers and attend to other details
based on information from FIX Orchestra.
4.1.4 Graphs aligned with message and business components
Although the G graph captures enough meaning to translate the message, it is unsuitable for RDFS and OWL
inference. For example, A represents the price at which a trade took place such as:



13.5



Specifically, the element embeds another element inside itself. auth.016 allows the outer price
element to contain either a or a element depending on whether a price is specified. As a
result, in the G and G graphs the ns:Pric predicate is used in two different parts of the graph with two
1 2
different meanings. This is allowed in RDF (SPARQL queries can be written against such a graph) but RDFS
and OWL expect that the same meaning is intended wherever a predicate is used.
The G graph is structurally similar to the G graph and continues to represent the complete content of the
4 2
message. The main difference is that G is written in a vocabulary based on the message components, which,
unlike the elements of the XML document, have a context-independent meaning. The same vocabulary is
used in the M OWL schema compatible with the G graph.
c 4
The G graph represents messages accurately at the cost of:
a) not sharing concepts between messages;
b) having little semantic information about the meaning of message parts.

For instance, multiple messages in the e-Repository concern concepts such as financial transactions and
assets. In the message components, different objects are used to represent different financial transactions
in different messages. As such, every message part can be said to have precisely the meaning it is expected
to have in that message.
Some objects from the e-Repository (such as message definitions, message components and choice
components) are represented as OWL classes, while other objects (such as message attributes, message
association ends and message building blocks) are represented as OWL properties. While translating and
XML document, properties are used to represent XML elements and attributes while classes represent the
data types contained inside elements and attributes.
The G graph writes the auth.016 message in terms of the business components, which are more general
than message components and can be reused between messages. Aligned with the M graph, the G graph
c 5
continues the process of discarding idiosyncrasies of the message in favour of the essential meaning of the
message. The cost of this, however, is that the business components are insufficient to capture 100 % of the
meaning of the message. (Ideally the G graph can be used for message processing tasks such as creating the
G graph to write a FIX message, however, the lossless nature of G made translation G directly to G a safe
3 2 2 3
approach to the translation task.)
NOTE The e-Repository contains data objects (such as such as Business Area and a Message Definition Identifier)
which are not naturally represented as properties and classes records and classes. Objects of this type can be
represented as RDF instances conforming to classes and properties imported from the metamodel. Objects that map
to OWL schema objects have properties such as XML tag names and registration status that do not exist in the OWL
vocabulary, but these can be added to the OWL ontology in the form of annotation properties to capture 100 % of the
content of the e-Repository.
Annex A considers an alternative approach to representing the business components in which message-
related objects from the e-Repository are exclusively and consistently represented as objects as opposed
to the alternating classes and properties in the G graph. In this representation, a single property, denoting
that one message part directly contains another message part, is the only property used to build message
instances. At the cost of introducing additional nodes, this representation can capture the sequencing of
message parts in both the schema and instances by adding sequence numbers to the RDF nodes.
5 Methods
5.1 Multiple local RDF graphs
2)
Much of the work described in this document was done using in-memory graphs from the Python rdflib
3)
library. Like a client-server triple store (e.g. OpenLink Virtuoso, Ontotext GraphDB, AllegroGraph ), an
in-memory graph can be queried with SPARQL. The in-memory graph also allows direct interaction with
individual triples and nodes which can be helpful when working with list and tree structures. The Jena
framework provides similar in-memory graphs which are used internally with the Protégé ontology viewer
and editor.
In-memory graphs scale well for graphs in the range of 1 to 10 million triples and are adequate for handling
schemas the size of the ISO 20022 e-Repository; a system that processes instance messages can have a few
large graphs that for schemas and large number of small graphs which contain individual instance messages.
Unlike the client-server triple store, in-memory graphs are lost when the application shuts down. If the
process for creating the graph is repeatable, it can be constructed from the source material as necessary.
[1]
Alternately, the graph can be serialized to a Turtle or other RDF format file and later restored or exported
to other RDF tools. Client-server triple stores can handle much larger data sets than in-memory stores
(billions of triples) and can persist triples for long periods of time. Most client-server triple stores work on
2) Python is an example of a suitable product available commercially. This information is given for the convenience of
users of this document and does not constitute an endorsement by ISO of this product.
3) AllegroGraph is an example of a suitable product available commercially. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO of this product.

RDF data sets, which can contain a number of named RDF graphs, a mechanism to represent a collection of
multiple RDF graphs.
Working with structures involving blank nodes can be awkward with a client-server triple store. One issue
is that complex structures are traversed in a way that requires many round trips between the client and
server with long latencies compared to an in-memory graph. Although most client-server databases provide
facilities to work with blank nodes, those facilities are not completely portable and can require adaptation
to work with various triple stores.
A client-server triple store applies to a situation where multiple parties are making changes to a graph
through an API: for instance, a system that provides a web interface to edit an ontology.
5.2 Open linked data
Open linked data is a major trend in the RDF world, which centres around the use of http-based RDF
4)
resources such as which corresponds to the Wikipedia page
for the German city. It is possible to retrieve this document using an http client such as curl. In that case, the
DBpedia web server returns a document with facts extracted from Wikipedia about that city in a format
[2]
such as Turtle or RDF/XML as specified in the Accept http header.
Linked data provides a simple way to browse a data set: instead of downloading all facts in a graph (which
can contain billions of facts as in the case of DBpedia) it is possible to traverse the graph subject-by-subject
and selectively retrieve only the necessary facts out of a large database. A global view can be had efficiently
by downloading the entire database and loading it into a triple store, but linked data are practical when it is
necessary to traverse just a small part of the graph.
RDF ontology projects can interact with linked data in two ways:
a) a project can incorporate data published in linked data form;
b) it can publish linked data.
This document is based on data entirely from the e-Repository, sample messages and FIX Orchestra and did
not require additional linked data.
Linked data are a potential information source for research and development. For instance, concepts from
the e-Repository can be aligned to concepts in generic databases such as DBpedia.
Linked data poses risks for applications, such as production software that works with financial message.
Linked data, for instance, depends on a working internet connection and linked data services being online.
Linked data can be updated without warning, and such changes can break an application. The continuing
function of an application depends on the availability of data and requires that the linked data publishers
maintain their service indefinitely. Linked data can be curated together with other data to produce
operational graphs which are inspected, tested, versioned and proven fit for purpose.
The graphs described in this document are not published on the web and thus primarily use URIs that are
non-resolvable, such as


The urn scheme is a global namespace with prefixes uniquely registered amongst organizations, as does the
http scheme. Unlike the http scheme, however, there is no expectation that a urn URI be resolvable.
If and when an official and stable RDF translation of the e-Repository is ready, that translation can use http
URIs and have the facts published on the web. In fact, this option is open to any organization which wishes
to publish their own version of the ISO 20022 e-Repository, or that wishes to publish their own instance
documents using vocabulary defined in the e-Repository.
4) Wikipedia is an example of a suitable product available commercially. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO of this product.

6 Reconciling differences between Ecore, RDF and OWL
6.1 Introducing Ecore
The ISO 20022 repository is represented in Ecore, an implementation of Meta-Object Facility (MOF) which
[3]
corresponds closely to the EMOF dialect of MOF. Ecore was created for the Eclipse Modeling Framework
to represent Java class hierarchies as part of their CASE tool. MOF, more generally, is intended to be the
foundation to define UML and applications of UML by bootstrapping from a small core.
MOF uses a simple vocabulary (M3) to define a richer vocabulary, such as UML 2 (M2). The M1 model is
written in the vocabulary defined in the M2 (this can be a UML model that describes a set of Java classes) and
the actual set of Java classes generated by a CASE tool (that which is modelled) comprise M0.
This layering is used in the ISO 20022 e-Repository, which uses the M3 vocabulary from MOF to write a M2
metamodel that defines the vocabulary used to describe business areas, messages, message components,
business components and similar objects. The message definitions and related concepts comprise the
M1 model. Finally, the M0 level contains the set of ISO 20022 message instances, objects representing
those instances and automatically generated software (e.g. Java classes) that support working with that
representation.
Ecore is focused on modelling objects from the Java programming language (generics are supported directly
in M3); however, MOF in general is consistent with the OMG’s goal of being able to access an object on another
server (as in RMI, CORBA or DCOM) or to otherwise provide access to objects in a foreign system (such as
access a Java object from a C program in the same address space).
6.2 Differences between Ecore and RDF standards
Ecore looks similar to OWL and RDFS in that it contains similar-sounding concepts such as classes, properties
and relationships. Ecore and OWL similarly makes a distinction between object properties (relationships
between two instance objects such as the relationship between a trade and the participant of a trade)
and datatype properties (an attribute which is expressed in terms of primitive types such as strings and
numbers such as the LEI of a trade participant).
Seen as documentation, Ecore models and OWL schemas look similar, yet the meaning of the models and
schemas is quite different.
An Ecore schema is a blueprint for defining classes in a statically typed language such as Java. In Java, class
definitions are defined and compiled to class files. Instances are only created later when those classes are
loaded into a JVM and those classes are constructed. In Java, the definition of fields in the source code allocates
a location in memory where attributes are stored so it is not possible to add new attributes at run time.
In RDF, on the other hand, it is not necessary to have a schema at all to process data. Arbitrary triples can be
inserted into the graph with arbitrary URIs for subjects and predicates at any time. Arbitrary triples can be
queried with SPARQL, traversed with a graph library or serialized to a format such as Turtle. A particular
graph can fail to validate with SHACL, OWL or other tools. The ontologies described in Clause 9 and Annex A
conform to the requirements of OWL DL, but general RDF graphs can use any vocabulary whatsoever.
In OWL DL, the graph is conceptually divided into two parts: the T-Box and the A-Box. Ontology objects such
as classes and properties comprise the T-Box or “terminology component” and the instance data described
by the ontology is the A-Box or “assertion component”. An RDFS or OWL schema is a set of T-Box axioms that
enable an inference engine
...