ISO/TS 5087-3:2026

• Abstract:

  This document defines an ontology for service level concepts defined for the transport domain using terms specified in ISO/IEC 5087-1 and ISO/IEC 5087-2. The values for service-level concepts defined in this document are intended to be managed by the transport domain but accessible by multiple city services and stakeholders.

• Status: Published
• Publication Date: 27-Jul-2026
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204 - Intelligent transport systems
• Current Stage: 6060 - International Standard published
• Start Date: 28-Jul-2026
• Due Date: 11-Jul-2026
• Completion Date: 28-Jul-2026

Overview

ISO/TS 5087-3:2026, Information technology - City data model - Part 3: Service level concepts for transport, specifies a standardized ontology for the transport domain within city data models. Developed by ISO, this technical specification builds upon foundational terminology and concepts from ISO/IEC 5087-1 (foundation level) and ISO/IEC 5087-2 (city level) to create a framework that enables the precise, unambiguous description and integration of transport-related data across diverse urban services and stakeholders.

This standard is designed for municipal information systems, urban planners, software developers, and any organization engaged in smart city projects, intelligent transport systems, or city-level data management. Its ontology-based approach addresses the challenges of semantic interoperability, allowing institutions to break down data silos and use city transport data in a consistent and coordinated manner.

Key Topics

• Transport Domain Ontology: Defines the key service-level concepts for transport, including core object classes, properties, and relationships necessary for representing various types of transport networks.
• Semantic Interoperability: Focuses on enabling data from multiple sources to be understood, combined, and validated with consistency.
• Components of Transport Networks:
  • NetworkElement: Fundamental building block, representing any portion of a transport network, with unique identifiers and status characteristics.
  • TransportNetwork: A collection of network elements, enabling representation at multiple levels of detail.
  • TransportNode & Junction: Points within the network, including nodes and connection points.
  • TravelledWay, TravelledWayLink, and TravelledWaySection: Represent continuous or aggregated paths, with properties for direction, connectivity, and operational strategies.
  • TravelledWayLane & TravelledWaySegment: Specify lanes and segments for more granular representation.
  • ScheduledCode: Encodes status information (e.g., open/closed) for network elements, relevant for city services and travelers.
• Formalization: Standardizes the classes and properties using consistent naming conventions, unique identifiers (IRIs), and formal restrictions, supporting both human understanding and machine readability.
• Pattern Specialization: Includes specialized patterns for road, rail, micromobility, pedestrian, and public transport networks, ensuring adaptability to various city contexts.

Applications

Implementing ISO/TS 5087-3:2026 offers substantial practical value for smart cities and digital transformation projects:

• Integrated City Services: Supports cross-departmental collaboration by providing a shared vocabulary and structure for transport data, reducing ambiguity and the risks of inconsistent interpretation.
• Decision Support & Planning: Facilitates advanced analytics, smart mobility applications, and scenario modelling by enabling reliable data sharing between city services such as transport, emergency response, utilities, and citizen engagement platforms.
• Intelligent Transport Systems (ITS): Enables the development of interoperable ITS applications that can access, utilize, and contribute to a shared pool of transport network data.
• Open Data Initiatives & Digital Twins: Contributes to the publication of open, linked transport data, supporting applications like urban digital twins and open government data platforms.
• Automated Validation & Quality Assurance: The clear, formal semantics allow for consistency analysis and automated detection of data inconsistencies, enhancing data quality and trust.

Related Standards

ISO/TS 5087-3:2026 is part of the ISO/IEC 5087 series, designed for comprehensive city data modelling:

• ISO/IEC 5087-1: Foundation level concepts, underlying classes, properties, and logical definitions for general data representation.
• ISO/IEC 5087-2: City-level concepts, addressing domain-neutral concepts common to all city services.
• ISO/TS 14812: Vocabulary for intelligent transport systems.
• ISO/IEC/IEEE 24765: Systems and software engineering vocabulary.

Aligning with these standards ensures robust, future-proof data management architectures and supports international best practices in information technology and city governance.

---

Keywords: ISO/TS 5087-3:2026, city data model, transport ontology, semantic interoperability, transport network, smart city, intelligent transport systems, data integration, urban mobility, open data, standardized transport data, city services

Technical
Specification
ISO/TS 5087-3
First edition
Information technology — City data
2026-07
model —
Part 3:
Service level concepts for transport
Technologies de l'information — Modèle de données urbaines —
Partie 3: Concepts de niveau de service dans le domaine des
transports
Reference number
© ISO 2026
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms and namespace prefixes . 1
5 Conventions . 2
5.1 Documentation format .2
5.2 Datatypes .3
5.3 Unique identifiers.3
5.4 Official URLs .3
6 Service-level ontologies for transport . 4
6.1 General .4
6.2 Transport network pattern .4
6.2.1 Overview .4
6.2.2 Key classes and properties .4
6.2.3 Formalization .10
6.3 Road network pattern . 12
6.3.1 Overview . 12
6.3.2 Key classes and properties . 12
6.3.3 Formalization .17
6.4 Rail network pattern.18
6.4.1 Overview .18
6.4.2 Key classes and properties .18
6.4.3 Formalization . 22
6.5 Micromobility network pattern . 22
6.5.1 Overview . 22
6.5.2 Key classes and properties . 22
6.5.3 Formalization . 26
6.6 Pedestrian network pattern .27
6.6.1 Overview .27
6.6.2 Key classes and properties .27
6.6.3 Formalization .31
6.7 Travel corridor pattern .32
6.7.1 Overview .32
6.7.2 Key classes and properties .32
6.7.3 Formalization . 34
6.8 Public transport system pattern . 34
6.8.1 Overview . 34
6.8.2 Key classes and properties . 34
6.8.3 Formalization . 38
6.9 Transport alert pattern . 39
6.9.1 Overview . 39
6.9.2 Key classes and properties . 39
6.9.3 Formalization .41
Annex A (informative) Understanding UML diagrams .43
Bibliography .48

iii
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 204, Intelligent transport systems, in
collaboration with Joint Technical Committee ISO/IEC JTC 1, Information technology.
A list of all parts in the ISO/IEC 5087 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
Introduction
The intended audience for this document includes municipal information systems departments, municipal
software designers and developers, and organizations that design and develop software for municipalities.
Cities today face a challenge of how to integrate data from multiple, unrelated sources where the semantics
of the data are imprecise, ambiguous and overlapping. This is especially true in a world where more and
more data of interest are being openly published by various organizations. A morass of data is increasingly
becoming available to support city planning and operations activities. In order to be used effectively, it is
necessary for the data to be unambiguously understood so that it can be correctly combined, avoiding data
silos. Early successes in data “mash-ups” relied upon an independence assumption, where unrelated data
sources were linked based solely on geospatial location, or a unique identifier for a person or organization.
More sophisticated analytics projects that require the combination of datasets with overlapping semantics
entail a significantly greater effort to transform data into something useable. It has become increasingly
clear that integrating separate datasets for this sort of analysis requires an attention to the semantics of the
underlying attributes and their values.
A common data model enables city software applications to share information, plan, coordinate and execute
city tasks, and support decision making within and across city services, by providing a precise, unambiguous
representation of information and knowledge commonly shared across city services. This requires a clear
understanding of the terms used in defining the data, as well as how they relate to one another. This
requirement goes beyond syntactic integration (e.g. common data types and protocols), it requires semantic
integration: a consistent, shared understanding of the meaning of information.
To motivate the need for a standard city data model, consider the evolution of cities. Cities deliver physical
and social services that traditionally have operated as silos. In other words, data are generated, processed
and used by systems that are nominally under the control of one or more parties with similar interest, and
are thus handled in such a way as to facilitate the business processes of those parties. Parties with other
interests and business needs develop their own data, often with different requirements and data sharing
among the different groups is limited.
If during the process of becoming smarter, transportation, social services, utilities, etc. were to develop
their own data models, the result would be smarter silos. To create truly smart cities, data need to be shared
across these silos. This can only be accomplished through the use of a common data model. For example,
“Household” is a category of data that is commonly used by city services. Members of Households are
the source of transportation, housing, education, and recreation demand. This category represents who
occupies a home, their age, their occupations, where they work, their abilities, etc. Though each city service
can potentially gather and/or use different aspects of a Household, much of the data need to be shared.
Supporting this interoperability among city datasets is particularly challenging due to the diversity of the
domain and the heterogeneity of its data sources. The purpose of this document is to support the precise
[1],[2]
and unambiguous specification of city data using the technology of ontologies as implemented in the
[3]
Semantic Web. By doing so it will:
— enable the computer representation of precise definitions thereby reducing the ambiguity of
interpretation;
— remove the independence assumption, thereby allowing the world of Big Data, open-source software,
mobile apps, etc., to be applied for more sophisticated analysis;
— achieve semantic interoperability, namely the ability to access, understand, merge and use data available
from datasets spread across the Semantic Web;
— enable the publishing of city data using Semantic Web and ontology standards;
— enable the automated detection of city data inconsistency, and the root causes of variations, and
— support semantic interoperability of city data in SMART transformation and smart governance.
With a clear semantics for the terminology, it is possible to perform consistency analysis and thereby
validate the correct use of the standard.

v
Figure 1 identifies the three levels of the ISO/IEC 5087 series. The lowest level, defined in ISO/IEC 5087-1,
provides the classes, properties and logical, computational definitions for representing the concepts that
are foundational to representing any data. The middle level, defined in ISO/IEC 5087-2, provides the classes,
properties and logical, computational definitions for representing urban-specific concepts common to
all city services but not specific to any service. The top level provides the classes, properties, and logical,
computational definitions for representing service-specific concepts that are used by other services across
the city. For example, ISO/TS 5087-3 (this document) defines the transport concepts. In the future, additional
parts will be added to the ISO/IEC 5087 series covering services such as education, water, sanitation, energy,
etc.
Figure 1 — Stratification of city data model
Figure 2 depicts example concepts for the three levels.
Figure 2 — Example concepts for each level

vi
Technical Specification ISO/TS 5087-3:2026(en)
Information technology — City data model —
Part 3:
Service level concepts for transport
1 Scope
This document defines an ontology for service level concepts defined for the transport domain using
terms specified in ISO/IEC 5087-1 and ISO/IEC 5087-2. The values for service-level concepts defined in this
document are intended to be managed by the transport domain but accessible by multiple city services and
stakeholders.
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 5087-1, Information technology — City data model — Part 1: Foundation level concepts
ISO/IEC 5087-2, Information technology — City data model — Part 2: City level concepts
ISO/IEC/IEEE 24765, Systems and software engineering — Vocabulary
ISO/TS 14812, Intelligent transport systems — Vocabulary
Manchester Syntax, W3C Editor's Draft 28 November2008, https:// www .w3 .org/ 2007/ OWL/ draft/ ED -owl2
-manchester -syntax -20081128/
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC/IEEE 24765, ISO/TS 14812,
ISO/IEC 5087-1 and ISO/IEC 5087-2 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/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Abbreviated terms and namespace prefixes
DL description logic
OWL ontology web language
RDF resource description framework
RDFS resource description framework schema
IRI international resource identifier
The following namespace prefixes are used in this document:
— cdm1: https:// w3id .org/ citydata/ part1/ v1/

— cdm2: https:// w3id .org/ citydata/ part2/ v1/
— geo: http:// www .opengis .net/ ont/ geosparql #
— rdfs: https:// www .w3 .org/ 2000/ 01/ rdf -schema #
— time: https:// www .w3 .org/ 2006/ time #
— xsd: https:// www .w3 .org/ 2001/ XMLSchema #
5 Conventions
5.1 Documentation format
The formalization of the classes in this document is specified using the table format shown in Table 1, which
is a simplification of description logic (DL) where the first column identifies the class name, the second
column identifies its properties, the third column indicates the multiplicity of the property (i.e. how many
instances of the property can occur for each instance of the class), and the fourth column identifies each
property’s value restriction. It shall be read as: "The is a conjunction of the associated
with their specified and ". Value restrictions are specified according to
Manchester syntax as defined by the W3C. For example, Table 1 specifies that Agent is a subclass of the
intersection of (Person or Organization) and can be an org _s: memberOf of zero or more Organizations. Value
restrictions are interpreted as follows:
— “only Organization” is interpreted as the value of the property is restricted to being instances of the class
Organization or of one of its subclasses. In the UML diagrams, this is depicted as an «only» restriction.
— “min 1 Organization” is interpreted as the value of the property is restricted to having at least one value
that is an instance of the class Organization or of one of its subclasses. In UML diagrams, this is depicted
as an «min 1» restriction.
— “max 2 Organization” is interpreted as the value of the property is restricted to having at most two
values that are instances of the class Organization or of its subclasses. In UML diagrams, this is depicted
as an «max 2» restriction.
Table 1 — Example formalization of the Agent class
Class Property Mult. Value restriction
Agent rdfs: subClassOf Person or org _s: Organization
org _s: memberOf 0.* only Organization
individual {joe, frank}
CamelCase is used for specifying classes, properties and instances. For example, “legalName” instead of
“legal_name”. The first letter of a class name is capitalized. The first letter of a property and instance name
are not capitalized.
An instance of a class shall satisfy the class’s definition. The instance’s properties and values shall satisfy the
multiplicity and value restrictions of the class it is an instance of.
The formalization of properties in this document is achieved similarly to the formalization of classes, using
the table format shown in Table 2, which allows for the identification of properties and their sub-properties,
inverse properties
or other characteristics. It shall be read as: "The is of ", or simply
"the is " if no value is applicable. For example, in Table 2 hasPrivilege is a sub-
property of the agentInvolvedIn property. Characteristics are specified using the Manchester syntax.

Table 2 — Example property formalization
Property Characteristic Value (if applicable)
hasPrivilege rdfs: subPropertyOf agentInvolvedIn
Irreflexive
In the case of DL definitions of classes where the simplified table representation is insufficient, the DL
specification will be supplied as an addition to the content in the table.
The table-based definitions are supplemented by informative UML diagrams according to the conventions
defined in Annex A.
The patterns defined in this document are formally defined at https:// w3id .org/ citydata/ part3/ v1/ as open-
source material. This document recognizes release 0.0 of that open-source ontology (https:// w3id .org/
citydata/ part3/ v1/ 5087 -3/ r0 .0/ ) as forming part of an ISO standard. However, the latest v1 release should
always be considered.
NOTE Ontology version and release numbers follow the logic of semantic versioning, but the major version is
kept with the ontology IRI as the “v” number while the minor version and patch number only appear in the version
IRI as the “r” number. This allows for stable IRIs for updates that are backwards compatible. The ontology files are
maintained based on user demand while the ISO standards capture snapshots of these ontologies at distinct points
in time. By comparison, the edition number on an ISO standard is a sequential integer and unrelated to the semantic
version of the ontology.
5.2 Datatypes
The datatypes assigned to data properties use XML schema datatypes in conformance with widely accepted
data practices within the web ontology language and city data model communities. The datatypes provided
are intended to describe the range of values intended for the data property but are not intended to constrain
the representation to XML.
5.3 Unique identifiers
All classes, properties and instances of classes have a unique identifier that conforms to Linked Data/
Semantic Web standards. The unique identifier is an IRI. When using this document in an application, a class
is identified by the IRI for the pattern of which it is a member, followed by the class name. In the Agent
example in 5.1, the unique identifier for the Agent class, which is formally defined in ISO/IEC 5087-1 would
be:
https:// w3id .org/ citydata/ part1/ v1/ Agent
Breaking the IRI down:
— “https:// w3id .org/ citydata/ part1/ v1/ ” identifies the ontology IRI
— “Agent” identifies the Agent class within the ontology.
The IRI can be shortened using the prefix defined in Clause 4:
cdm1: Agent
where cdm1: is the prefix for the Agent Pattern.
Properties are identified in the same manner. The IRIs of individuals created by an application of
ISO/IEC 5087-2 would have IRIs unique to the application.
5.4 Official URLs
The official ontologies referenced by this document can be found at the locations indicated by the IRI and
making the request for the “application/rdf” file, which is typical of ontology tools. When using a web
browser, the IRIs can default to a webpage instead, which then provides the link to the ontology file. The

official ontology for the content of this document can be found at https:// w3id .org/ citydata/ part3/ v1/ 5087
-3 .owl/ r0 .0.
6 Service-level ontologies for transport
6.1 General
The service-level documents of the ISO/IEC 5087 series provide representations for concepts that are used
by services that operate in the city context. The following concepts can be used (consumed) by multiple
different city services and stakeholders but are typically only generated by the city service area identified in
the part name (i.e. in the case of this document, the data are typically only generated by transport services).
The patterns defined in the service-level documents of the ISO/IEC 5087 series conform to the foundational
and city-level concepts defined in ISO/IEC 5087-1 and ISO/IEC 5087-2, respectively. Specific references to
content defined in ISO/IEC 5087-1 and ISO/IEC 5087-2 are identified in text descriptions of pattern imports,
as well as through the explicit identification of terms from ISO/IEC 5087-1 and ISO/IEC 5087-2.
6.2 Transport network pattern
6.2.1 Overview
The Transport network pattern models the core concepts involved in describing a transport network. This
includes an identification of both physical and administrative characteristics. The most general class is that
of the NetworkElement, which can be further classified as one of several types of NetworkElements.
A key feature of this pattern is the formalization of the hasProperPart relationship from a NetworkElement
to another NetworkElement. This allows for a representation of networks at multiple levels of detail.
For example, at one level, a motorway interchange can be modelled as a single node. But that node is a
NetworkElement that can be defined to consist of an entire TransportNetwork that has a node for each
junction within the interchange.
6.2.2 Key classes and properties
6.2.2.1 Network element
A NetworkElement represents any element of a transport network. It can be a part of another NetworkElement
and can be decomposed into smaller NetworkElements. Each NetworkElement is characterized with a
unique identifier. A NetworkElement can be characterized by its status. Figure 3 provides an overview of a
NetworkElement.
Figure 3 — Network element model

6.2.2.2 Transport network
A TransportNetwork is a NetworkElement that is a collection of other network elements that jointly represent
a network of paths along which entities (e.g. vehicles, pedestrians) of a specified mode can operate. Figure 4
provides an overview of a TransportNetwork.
Figure 4 — Transport network model
6.2.2.3 Transport node
A TransportNode is a NetworkElement that represents a node on the transport network that can be used to
designate an end to a link or to join links. Each TransportNode is a part of at least one TransportNetwork. A
TransportNode is characterized by ingress and egress TravelledWayLinks. The ingress and egress link can
be the same link if it is bi-directional (e.g. a cul-de-sac). Figure 5 provides an overview of a TransportNode.

Figure 5 — Transport node model
6.2.2.4 Junction
A Junction is a TransportNode that allows a traveller to connect from one TravelledWayLink to another.
6.2.2.5 Travelled way
A TravelledWay is a type of NetworkElement and transinfras: TravelledWay that represents the curvilinear
length of a transport route that is identified by a specific designator. It is a generalized class that can be
specialized into mode-specific terms (e.g. for a road or for a rail corridor).
Each TravelledWay is defined as being a part of at least one TransportNetwork and can be decomposed into
TravelledWayLinks. TravelledWays are identified with a unique designator. Figure 6 provides an overview
of a TravelledWay.
Figure 6 — Travelled way model

6.2.2.6 Travelled way link
A TravelledWayLink is a type of NetworkElement and transinfras: TravelledWayLink. It represents a
contiguous length of a TravelledWay between two TransportNodes of operational or managerial significance.
Each TravelledWayLink is a part of at least one TransportNetwork and can form a part of TravelledWays
and TravelledWaySections. A TravelledWayLink can be composed of only TravelledWaySegments.
A TravelledWayLink starts from one TransportNode and connects to a second TransportNode. A
TravelledWayLink can be characterized by its allowed directions of travel (e.g. forward from the first node
to the second node, reverse from the second node to the first, bi-directional, closed).
For example, a TravelledWayLink can be defined from one signalized intersection to the next or from one
bus stop to the next. Figure 7 provides an overview of a TravelledWayLink.
Figure 7 — Travelled way link model
6.2.2.7 Travelled way section
A TravelledWaySection is a type of NetworkElement that represents an aggregation of TravelledWayLinks
and TravelledWaySegments that jointly represent a contiguous length of a path that shares the same
management and operational strategies (within the scope of interest of the implementation). Each
TravelledWaySection is part of at least one TransportNetwork. It can only be parts of TransportNetworks
and TravelledWays. A TravelledWaySection consists of only TravelledWayLinks.
For example, a TravelledWaySection can be used to represent the portion of a TravelledWay that uses the
same traffic signal coordination strategy. It can also be used to represent a bus line or subway line. Figure 8
provides an overview of a TravelledWaySection.

Figure 8 — Travelled way section model
6.2.2.8 Travelled way segment
A TravelledWaySegment is a type of a transinfras: TravelledWaySegment and NetworkElement that represents
a contiguous length of a TravelledWayLink characterized by the same physical characteristics. Each
TravelledWaySegment is a part of at least one TravelledWayLink and can be a part of a TravelledWaySection
(e.g. if the section does not end at a TransportNode). A TravelledWaySegment consists of one or more
TravelledWayLanes.
For example, a TravelledWayLink can be defined to connect two TransportNodes. If the number of lanes
changes in the middle of the TravelledWayLink, the unique physical characteristics of each component part
of the TravelledWayLink can be defined by defining separate TravelledWaySegments.
Any TravelledWaySegment can be defined to be a part of a TravelCorridorSegment. Figure 9 provides an
overview of a TravelledWaySegment.

Figure 9 — Travelled way segment model
6.2.2.9 Travelled way lane
A TravelledWayLane is a NetworkElement that is a portion of TravelledWaySegment intended to
accommodate a single line of moving material entities (e.g. vehicles) along its length. Figure 10 provides an
overview of a TravelledWayLane.
Figure 10 — Travelled way lane model

6.2.2.10 Scheduled code
A NetworkElement may have a status that specifies the status of the node, e.g. Open or Closed. The status
property links to an instance of ScheduledCode which in turn specifies the period of time for the status
using both a period of time representation and separate hasStartTime and hasEndTime properties that use
xsd: DateTime formats. The value of the code property is an instance of the code: Code class, which can refer
to a unique identifier in any existing taxonomy for node/link statuses. Figure 11 provides an overview of
ScheduledCode.
Figure 11 — Scheduled code model
6.2.3 Formalization
The key classes and properties are formalized in Table 3.
Table 3 — Key classes in the Transport network pattern
Class Property Value restriction
Junction rdfs: subClassOf TransportNode
NetworkElement rdfs: subClassOf geo: Feature
p a r t w hole: h a sP r op erP a r t only NetworkElement
status only Status
partwhole: properPartOf only NetworkElement
genProp: hasIdentifier only xsd: string
genProp: hasIdentifier exactly 1 xsd: string
ScheduledCode code only code: Code
timeInterval only time: DateTimeInterval
timeInterval exactly 1 time: DateTimeInterval
TransportNetwork rdfs: subClassOf NetworkElement
p a r t w hole: h a sP r op erP a r t only (TransportNode or TravelledWayLink or TravelledWay
or TransportNetwork or TravelledWaySection)
partwhole: properPartOf only TransportNetwork

TTabablele 3 3 ((ccoonnttiinnueuedd))
Class Property Value restriction
TransportNode rdfs: subClassOf NetworkElement
partwhole: properPartOf only TransportNetwork
partwhole: properPartOf min 1 TransportNetwork
egress only TravelledWayLink
egress min 1 TravelledWayLink
ingress only TravelledWayLink
ingress min 1 TravelledWayLink
TravelledWay rdfs: subClassOf NetworkElement
rdfs: subClassOf transinfras: TravelledWay
p a r t w hole: h a sP r op erP a r t only TravelledWayLink
partwhole: properPartOf only TransportNetwork
partwhole: properPartOf min 1 TransportNetwork
designator only xsd: string
designator exactly 1 xsd: string
TravelledWayLane rdfs: subClassOf NetworkElement
partwhole: properPartOf only TravelledWaySegment
partwhole: properPartOf exactly 1 TravelledWaySegment
TravelledWayLink rdfs: subClassOf NetworkElement
rdfs: subClassOf transinfras: TravelledWayLink
partwhole: properPartOf only TransportNetwork
partwhole: properPartOf min 1 TransportNetwork
partwhole: properPartOf only (TravelledWay or TravelledWaySection)
from only TransportNode
from exactly 1 TransportNode
to only TransportNode
to exactly 1 TransportNode
p a r t w hole: h a sP r op erP a r t only TravelledWaySegment
allowedDirections only code: Code
allowedDirections max 1 code: Code
TravelledWaySection rdfs: subClassOf NetworkElement
p a r t w hole: h a sP r op erP a r t only (TravelledWaySegment or TravelledWayLink)
partwhole: properPartOf only TransportNetwork
partwhole: properPartOf min 1 TransportNetwork
TravelledWaySegment rdfs: subClassOf NetworkElement
rdfs: subClassOf transinfras: TravelledWaySegment
partwhole: properPartOf only TravelledWayLink
partwhole: properPartOf min 1 TravelledWayLink
partwhole: properPartOf only TravelledWaySection
p a r t w hole: h a sP r op erP a r t only TravelledWayLane
p a r t w hole: h a sP r op erP a r t min 1 TravelledWayLane
travelCorridorSegment only TravelCorridorSegment

6.3 Road network pattern
6.3.1 Overview
The Road network pattern specializes the Transport network pattern to address the needs for vehicular
travel. Road networks that are primarily designed for the movement of micromobility vehicles should
generally be defined using the Micromobility network pattern, which is a specialization of this pattern.
6.3.2 Key classes and properties
6.3.2.1 Road network
A RoadNetwork is a type of TransportNetwork using a stabilized base designed for the movement of vehicles,
other than rail or air vehicles, that conform to a specified set of requirements but may be used by others as
well.
RoadNetworks are made up of RoadLinks, Roads, and RoadSections.
Figure 12 provides an overview of the RoadNetwork.
Figure 12 — Road network
6.3.2.2 Road
A Road is a type of TravelledWay and transinfras: Road that is made up of RoadLinks. Roads form a proper
part of RoadNetworks.
The extent of a Road is defined by the extent of the roadway that shares the designator assigned to the Road.
As such, a single RoadLink can be designated to be part of multiple Roads. For example, Interstate 10 (I-10)
and US-90 are defined as two distinct roads that run across the southern United States. In various locations,

I-10 and US-90 share the same physical infrastructure and those RoadLinks form part of both Roads.
Further, portions of I-10 have localized names. For example, the stretch of I-10 from downtown Houston to
Katy, Texas is also known as "Katy Freeway". This can be defined as its own distinct Road, which is entirely
aligned with I-10, but has a much shorter length. Figure 13 provides an overview of Road.
Figure 13 — Road
6.3.2.3 Road link
A RoadLink is a type of TravelledWayLink and transinfras: RoadLink using a stabilized base designed for the
movement of vehicles that conform to a specified set of requirements but that can be used by others as well.
TravelledWayLinks that are primarily designed as air strips or for use by rail vehicles should not be defined
as a RoadLinks.
RoadLinks can be grouped to form Roads (i.e. a sequence of RoadLinks that share a common designator) and
RoadSections (i.e. a sequence of RoadLinks that are grouped for operational purposes). RoadLinks can be
subdivided into multiple RoadSegments.
A RoadLink can be characterized by its capacity, the maximum number of lanes defined in the link, and
RoadLinkUserType characteristics that can define characteristics such as the speed limit or average travel
time for the link based on the type of user. For example, the speed limit for lorries can be different from the
speed limit for light duty vehicles.
Figure 14 provides an overview of RoadLink.

Figure 14 — Road link model
6.3.2.4 Road section
A RoadSection is a type of TravelledWaySection that groups RoadLinks and RoadSegments for a useful
operational purpose (e.g. assigning a speed limit, designating a traffic control scheme). RoadSections can be
defined as part of a RoadNetwork. Figure 15 provides an overview of RoadSection.

Figure 15 — Road section model
6.3.2.5 Road segment
A RoadSegment is a type of TravelledWaySegment and transinfas: RoadSegment that represents a portion
of a RoadLink with common physical characteristics. A RoadSegment can be defined to be a part of a
RoadSection, for example, when the RoadSection does not span an entire RoadLink. A RoadSegment consists
of one or more RoadLanes. A RoadSegment can be characterized by its number of lanes, width and pavement
type. Figure 16 provides an overview of RoadSegment.

Figure 16 — Road segment model
6.3.2.6 Road lane
A RoadLane is a type of TravelledWayLane that forms part of a RoadSegment. A RoadLane can be characterized
by its width. A road lane can connect to road lanes associated with the next or previous RoadSegment to
indicate how the lanes of the two segments align. For example, when a lane is added expanding a RoadLink
from three to four lanes, there will be two RoadSegments that form part of the RoadLink. The lanes of each
RoadSegment can be linked to indicate where the new lane is added. Figure 17 provides an overview of
RoadLane.
Figure 17 — Road lane model
6.3.3 Formalization
The key classes and properties are formalized in Table 4.
Table 4 — Key classes in the Road network pattern
Class Property Value restriction
Road rdfs: subClassOf TravelledWay
rdfs: subClassOf transinfras: Road
partwhole: properPartOf only RoadNetwork
p a r t w hole: h a sP r op erP a r t only RoadLink
p a r t w hole: h a sP r op erP a r t min 1 RoadLink
RoadLane rdfs: subClassOf TravelledWayLane
previous only RoadLane
partwhole: properPartOf only RoadSegment
partwhole: properPartOf min 1 RoadSegment
next only RoadLane
width only int
width exactly 1 int
RoadLink rdfs: subClassOf TravelledWayLink
rdfs: subClassOf transinfras: RoadLink
partwhole: properPartOf only (Road or RoadNetwork or RoadSection)
p a r t w hole: h a sP r op erP a r t only RoadSegment
usedBy only RoadLinkUserType
primaryUser only RoadLinkUserType
primaryUser max 1 RoadLinkUserType
maxLanes only nonNegativeInteger
maxLanes exactly 1 nonNegativeInteger
capacity only nonNegativeInteger
capacity exactly 1 nonNegativeInteger
RoadLinkUserType uses only RoadLink
uses exactly 1 RoadLink
uses only RoadLink
uses exactly 1 RoadLink
speedLimit only Part 1:Speed
speedLimit max 1 Part 1:Speed
travelTime only Part 1:Duration
travelTime max 1 Part 1:Duration
userCategory only RoadUserCategoryEnum
userCategory exactly 1 RoadUser
...