ISO/IEC 18975:2024

International
Standard
ISO/IEC 18975
First edition
Information technology —
2024-11
Automatic identification and data
capture techniques — Encoding and
resolving identifiers over HTTP
Technologies de l'information — Techniques automatiques
d’identification et de saisie de données — Encodage et résolution
des identifiants via HTTP
Reference number
© ISO/IEC 2024
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
© ISO/IEC 2024 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
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 URI structures . 2
4.1 Framework .2
4.2 Structured path approach .2
4.3 Query string approach .4
4.4 Semantic differences .4
4.5 Canonicalization .4
5 Resolution . 5
5.1 Linkset .5
5.2 LinkType parameter .5
6 Online considerations . 5
Annex A (informative) Examples . 7
Annex B (informative) Code size optimization. 8
Annex C (informative) Background information . 9
Annex D (informative) Querying an identified item .11
Bibliography . 14

© ISO/IEC 2024 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
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 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 or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take 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 and IEC 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 and https://patents.iec.ch. ISO and IEC 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.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, SC 31,
Automatic identification and data capture techniques.
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 and
www.iec.ch/national-committees.

© ISO/IEC 2024 – All rights reserved
iv
Introduction
There are many identifier systems in use today, some of which enjoy widespread usage and long histories.
Examples include the International Air Travel Association (IATA) airport codes and identifiers such as digital
[5] [7]
object identifiers (DOIs) (see ISO 26324 ), and country and currency codes. The ISO/IEC 15459 series provides
the basis for all identifier issuing agencies in the field of Automatic Identification and Data Capture (AIDC).
[7]
The ISO/IEC 15459 series defines methods for ensuring that identifiers are globally unique in the world
of AIDC without any reliance on, for example, the internet’s domain name system or any given data service.
This is critical for use cases where internet connectivity and the availability of online services cannot be
allowed to affect whether a process can be completed, such as the purchase of an item.
However, existing identifiers can be usefully encoded in Hypertext Transfer Protocol Uniform Resource
Identifiers (HTTP URIs) following Linked Data principles so that when connectivity is available, they can be
used in multiple methods of online lookup, data query and data integration.
It is important to note that identity on the internet is defined by the domain name system. The Internet
[2]
Engineering Task Force (IETF)’s Best Current Practice makes it clear that each domain is sovereign over
[8]
the URIs under that domain. This document brings the internet, Linked Data and AIDC together to allow
the discovery of online data related to physical objects in a way that recognizes and respects both approaches
to globally unique identity. It further defines a common approach to how those URIs can be associated with
links to multiple sources of data in addition to the one encoded directly in the HTTP URI.
This document focuses primarily on environments in which the URI is parsed offline to extract identifiers
that are globally unique in their own right, irrespective of the internet domain name used. This applies
[7]
especially, but not only, to identifiers that conform to the ISO/IEC 15459 series . For use cases and
environments where it is appropriate to rely on the internet domain name to confer global uniqueness
[17[18]
on some or all aspects of identification, the IEC 61406 series is likely to be relevant, especially for
technical/engineering industries.

© ISO/IEC 2024 – All rights reserved
v
International Standard ISO/IEC 18975:2024(en)
Information technology — Automatic identification and data
capture techniques — Encoding and resolving identifiers
over HTTP
1 Scope
This document specifies the different approaches for using HTTP URIs to encode globally unique identifiers.
It specifies a dual use data structure. It is both an HTTP URI and a composition of structured item
identification properties and optionally descriptive attributes. These can be decomposed and interpreted on
their own and/or be used as a pointer to additional information.
Methods are described to enable identification uniqueness in the context of AIDC. These rely on either:
[7]
a) identifiers, such as described in the ISO/IEC 15459 series , in the path or query string independent of
the internet domain name; or,
b) the internet domain name.
The document further defines a basic common API for querying online services for information about
identified items.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Harmonized vocabulary
RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. T Berners-Lee, R Fielding, L Masinter. IETF 2005
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www. iso. org/o bp
— IEC Electropedia: available at https:// www.electropedia . org/
3.1.1
dereference
look something up on the internet
Note 1 to entry: For a full definition, see RFC 3986.

© ISO/IEC 2024 – All rights reserved
3.2 Abbreviated terms
[14]
AI Application Identifier, as defined in ISO/IEC 15418
AIDC Automatic Identification and Data Capture (barcodes, RFID tags, etc.)
API Application Programming Interface
CURIE Compact URI (defined in Reference [4])
[14]
DI Data Identifier, as defined in ISO/IEC 15418
GTIN Global Trade Item Number
HTTP Hypertext Transfer Protocol (the underlying internet communication protocol for the World
Wide Web)
HTTP URI equivalent to the better-known term “URL” (Uniform Resource Location) but in this context,
the term URI is more appropriate.
IANA Internet Assigned Numbers Authority
JSON JavaScript Notation Language – a data structure commonly used in online data exchange
[15]
(defined in ISO/IEC 21778 )
URI Uniform Resource Identifier (defined in RFC 3986)
4 URI structures
4.1 Framework
Subclauses 4.2 and 4.3 define two frameworks on top of which more precise definitions may be added
to create rules for encoding specific types of identifier in an HTTP URI. This document does not define a
complete system that can be implemented directly without the additional detail provided in other standards
and guidelines.
4.2 Structured path approach
The structured path approach makes a clear distinction between strings of characters that are identifiers
and those that are descriptive attributes. Identifiers, such as the item’s class identifier and serial number,
are encoded in an ordered sequence in the path. Descriptive attributes such as the mass or size of an item
are not part of the identification of the item and are encoded in the query string as name=value pairs.
In many cases, the descriptive attributes are aligned with the identifiers and may be retrieved through a
lookup of the HTTP URI. For example, the expiration date of a perishable product may be known by looking
up its product identifier and the identifier of the batch in which it was produced. The presence of such
descriptive attributes in the HTTP URI is a convenience designed to eliminate the need for a lookup in high-
speed environments, and the HTTP URI will function equally well without it in most use cases.
[7]
Applying this logic to encoding the ISO/IEC 15459 series identifiers in HTTP URIs leads to a design
principle for the structured path approach, as follows:
— Identifiers shall be encoded in path segments in order of increasing granularity from left to right.
— Descriptive attributes shall be encoded, in any order, in the HTTP URI’s query string.
At a high level, this creates the structure shown in Figure 1 in which the structure itself is part of the data
payload.
© ISO/IEC 2024 – All rights reserved
[10]
NOTE The example.com domain name is used as defined in RFC 6761 .
Figure 1 — High-level view of a URI following the structured path approach
[7]
Any identifier issued by an Issuing Agency conforming to the ISO/IEC 15459 series will come with
information about the identifier's qualifier. These can be considered as parameter names for which the
identifiers themselves are the values. The identifier qualifiers are an important part of the data payload
whether encoded in a URI or some other syntax. Bearing this in mind, a more detailed version of the path
segments for the example in Figure 1 is as shown in Figure 2.

Figure 2 — Detailed view of the path segments of a URI following the structured path approach.
The components of a URI following the structured path approach shown in Figure 2 are as follows:
a) As defined by RFC 3986, all URIs begin with the scheme followed by a colon. HTTP URIs therefore
begin with http: or https:. This is followed by a double forward slash (//) and the internet domain
name. Optionally, the domain name may be replaced by an IP address and either may be followed by a
port number. When constructing an HTTP URI following the structured path approach defined in this
document, the port number, username and password shall not be used.
b) The URI may include arbitrary path segments after the internet domain name.
c) For emphasis, those arbitrary path segments and the internet domain name are not part of the
identification of the item. They do, however, provide a convenient method for looking up online
information about the identified item.
d) Every URI following the structured path approach shall have exactly one primary qualifier and identifier.
e) The primary qualifier, i.e. the type of identifier, is the first path segment that contributes to the identity
of the item. This may be either a class-level or instance-level identifier.
f) This is followed by a path segment containing the primary identifier itself.
g) Depending on the type of identifier and any rules defined for its use, primary qualifiers and identifiers
may be followed by further path segments that identify sub-classes and/or instances. For example, if the
primary qualifier and identifier identify a class of pump, the next two path segments can be a qualifier
and identifier for a specific batch of pumps, followed by two further path segments that provide a unique
item identifier.
h) The query string comprises 0 or more name=value pairs of qualifiers and data that describe, but do not
identify, the item. To extend the pump example, they can describe the size or date of production.
i) Although RFC 3986 allows a number of different delimiters to be used in query strings, HTTP URIs
conforming to this document shall use the ampersand (&).
j) Reserved characters, as defined by RFC 3986, shall be percent encoded when they appear as identifiers
or their values.
An example using the structured path approach is provided in Annex A.

© ISO/IEC 2024 – All rights reserved
4.3 Query string approach
As with the structured path approach, in the query string approach, the scheme and domain name may be
followed by arbitrary path segments. However, all the qualifiers and identifiers, and descriptive attributes,
are provided as name=value pairs in the query string, delimited by ampersands (&s). See Figure 3.

Figure 3 — Generic example of a URI following the query string approach
Qualifiers used as names in the query string may be preceded by one or more characters to indicate that
the qualifier and its identifier may be treated as being globally unique in accordance with the rules of the
identification system used independent of the internet domain name in the URI. Other parameter names
and their values contained in the query string that are not preceded by the same character(s) shall not be
treated as part of the system that confers globally unique identification, but only as parameters relevant to
the specified internet domain.
An example using the query string approach is provided in Annex A.
4.4 Semantic differences
At a high level, both the structured path and query string approach achieve the same goals. The HTTP URI is
a convenient method to find information about the identified item. However, there are important differences
in the semantics of the two approaches.
The domain name and path segments of an HTTP URI form a hierarchy that identifies a specific resource
on the web. The query string contains name=value pairs that are passed as parameters to that resource.
This means that the structured path approach identifies a different online resource for each identified
item. Applying Linked Data principles means that information about an item can be inherited from higher
up the hierarchy where available. In contrast
...