ISO/IEC 5087-2:2024

International
Standard
ISO/IEC 5087-2
First edition
Information technology — City
2024-04
data model —
Part 2:
City level concepts
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 .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms and namespace prefixes . 3
5 Unique identifiers . 4
6 City-level ontologies . 5
6.1 General .5
6.2 Code pattern .5
6.2.1 General .5
6.2.2 Key classes and properties .6
6.2.3 Formalization .6
6.3 Infrastructure pattern .6
6.3.1 General .6
6.3.2 Key classes and properties .6
6.3.3 Formalization .7
6.4 Transportation Infrastructure pattern .7
6.4.1 General .7
6.4.2 Key classes and properties .7
6.4.3 Formalization .9
6.5 Building pattern .10
6.5.1 General .10
6.5.2 Key classes and properties .10
6.5.3 Formalization . 12
6.6 Land Use pattern . 13
6.6.1 General . 13
6.6.2 Key classes and properties . 13
6.6.3 Formalization . 13
6.7 Person pattern . 13
6.7.1 General . 13
6.7.2 Key classes and properties .14
6.7.3 Formalization . 15
6.8 City Resident pattern .16
6.8.1 General .16
6.8.2 Key classes and properties .16
6.8.3 Formalization .17
6.9 Household pattern .18
6.9.1 General .18
6.9.2 Key classes and properties .18
6.9.3 Formalization .18
6.10 City Organization pattern.18
6.10.1 General .18
6.10.2 Key classes and properties .19
6.10.3 Formalization .21
6.11 City pattern . . 22
6.11.1 General . 22
6.11.2 Key classes and properties . 22
6.11.3 Formalization . 23
6.12 City Service pattern . 23
6.12.1 General . 23
6.12.2 Key classes and properties . 23
6.13 Contract pattern . 26

© ISO/IEC 2024 – All rights reserved
iii
6.13.1 General . 26
6.13.2 Key classes and properties . 26
6.13.3 Formalization .27
6.14 Bylaw pattern . 28
6.14.1 General . 28
6.14.2 Use cases . 28
6.14.3 Key classes and properties . 28
6.14.4 Formalization . 30
6.15 Contact pattern .31
6.15.1 General .31
6.15.2 Key classes and properties .31
6.15.3 Formalization .32
6.16 Sensors pattern . 33
6.16.1 General . 33
Annex A (informative) Relationship to existing standards .34
Annex B (informative) Extending the Land Use pattern with multiple classification systems.42
Annex C (informative) Location of pattern implementations .46
Bibliography . 47

© ISO/IEC 2024 – All rights reserved
iv
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.
A list of all parts in the ISO/IEC 5087 series can be found on the ISO and IEC websites.
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
v
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 have traditionally operated as silos. 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 needs 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; and
— enable the automated detection of city data inconsistency, and the root causes of variations.
With a clear semantics for the terminology, it is possible to perform consistency analysis, and thereby
validate the correct use of the document.
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 (this document), 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

© ISO/IEC 2024 – All rights reserved
vi
logical, computational definitions for representing service specific concepts that are used by other services
1)
across the city. For example, ISO/IEC TS 5087-3:— is intended to define the transportation 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
There are other existing standards that overlap conceptually with some of the terms presented in this
document. The relationship between this document and existing standards that address similar or related
concepts is identified in Annex A.
1) Under preparation. Stage at the time of publication: ISO/IEC AWI TS 5087-3:2024.

© ISO/IEC 2024 – All rights reserved
vii
International Standard ISO/IEC 5087-2:2024(en)
Information technology — City data model —
Part 2:
City level concepts
1 Scope
This document defines an ontology for city-level concepts defined using terms specified in ISO/IEC 5087-1.
City-level concepts are used to represent data that is shared across multiple services and stakeholders in the
city. City-level concepts are distinguished by their data being read and updated 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.
SEMANTIC SENSOR NETWORK ONTOLOGY, W3C Recommendation 19 October 2017, https:// www .w3 .org/
TR/ vocab -ssn/
ISO/IEC 5087-1, Information technology — City data model — Part 1: Foundation level concepts
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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/
3.1
cardinality
number of elements in a set
[SOURCE: ISO/TS 21526:2019, 3.11]
3.2
description logic
DL
family of formal knowledge representation languages that are more expressive than propositional logic but
less expressive than first-order logic
[SOURCE: ISO/IEC 21972:2020, 3.2]
3.3
manchester syntax
compact, human readable syntax for expressing Description Logic descriptions
[SOURCE: https:// www .w3 .org/ TR/ owl2 -manchester -syntax/ (Copyright © 2012. World Wide Web
Consortium. https:// www .w3 .org/ Consortium/ Legal/ 2023/ doc -license).]

© ISO/IEC 2024 – All rights reserved
3.4
measure
value of the measurement (via the numerical_value property) which is linked to both Quantity and Unit_
of_measure
[SOURCE: ISO/IEC 21972:2020, 3.4]
3.5
namespace
collection of names, identified by a URI reference, that are used in XML documents as element names and
attribute names
Note 1 to entry: Names may also be identified by an IRI reference.
[SOURCE: ISO/IEC 21972:2020, 3.5, modified — Note 1 to entry has been added.]
3.6
ontology
formal representation of phenomena of a universe of discourse with an underlying vocabulary including
definitions and axioms that make the intended meaning explicit and describe phenomena and their
interrelationships
[SOURCE: ISO 19101-1:2014, 4.1.26]
3.7
ontology web language
ontology language for the Semantic Web with formally defined meaning
Note 1 to entry: OWL 2 ontologies provide classes, properties, individuals and data values and are stored as Semantic
Web documents.
[SOURCE: ISO/IEC 21972:2020, 3.7, modified — The preferred term "OWL 2 Web Ontology Language" has
been replaced by the preferred term "ontology web language".]
3.8
quantity
property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed
as a number and a reference
Note 1 to entry: Quantities can appear as base quantities or derived quantities.
EXAMPLE 1 Length, mass, electric current (ISQ base quantities).
EXAMPLE 2 Plane angle, force, power (derived quantities).
[SOURCE: ISO/IEC Guide 99:2007, 1.1, modified — NOTEs 1 to 6 have been removed; new Note 1 to entry and
two EXAMPLEs have been added.]
3.9
Semantic Web
W3C’s vision of the Web of linked data
Note 1 to entry: Semantic Web technologies enable people to create data stores on the Web, build vocabularies, and
write rules for handling data.
[SOURCE: https:// www .w3 .org/ standards/ semanticweb/ (Copyright © 2015. World Wide Web Consortium.
https:// www .w3 .org/ Consortium/ Legal/ 2023/ doc -license).]
3.10
unit_of_measure
definite magnitude of a quantity, defined and adopted by convention and/or by law
[SOURCE: ISO/IEC 21972:2020, 3.9]

© ISO/IEC 2024 – All rights reserved
4 Abbreviated terms and namespace prefixes
AAFC Agriculture and Agri-Foods Canada
CGRM Canadian Government Reference Mode
CLUMP Canada Land Use Monitoring Program
DL description logic
IPCC International Panel on Climate Change
IRI international resource identifier
LBCS Land Based Classification Standards
OWL ontology web language
RDF resource description framework
RDFS resource description framework schema
UML Unified Modelling Language
The following namespace prefixes are used in this document:
— activity: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ Activity/
— agent: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ Agent/
— agreement: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ Agreement/
— building: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Building/
— bylaw: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Bylaw/
— city: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ City/
— cityresident: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ CityResident/
— cityunits: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ CityUnits/
— code: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Code/
— contact: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Contact/
— contract: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Contract/
— genprop: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ GenericProperties/
— geo: http:// www .opengis .net/ ont/ geosparql #
— i72: http:// ontology .eil .utoronto .ca/ ISO21972/ iso21972/
— infras: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Infrastructure/
— landuse: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Landuse/
— org: http:// www .w3c .org/ ns/ org #
— org_s: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ Or ganizationStructure/
— org_city: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Organization/
— owl: https:// www .w3 .org/ 2002/ 07/ owl #
— partwhole: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ Mereology/
— person: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Person/
— rdf: https:// www .w3 .org/ 1999/ 02/ 22 -rdf -syntax -ns #

© ISO/IEC 2024 – All rights reserved
— rdfs: https:// www .w3 .org/ 2000/ 01/ rdf -schema #
— recurringevent: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ RecurringEvent/
— resource: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ Resource/
— loc: https:// standards .iso .org/ iso -iec/ 5087/ -1/ ed -1/ en/ ontology/ SpatialLoc/
— service: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ CityService/
— transinfras: https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Transport
ationInfrastructure/
— time: https:// www .w3 .org/ 2006/ time #
— xsd: https:// www .w3 .org/ 2001/ XMLSchema #
The formalization of the classes in this document is specified using the following table format, which is a
simplification of description logic (DL) where the first column identifies the class name, the second column
its properties and the third column each property’s range restriction It shall be read as: The is a
subClassOf the conjunction of the associated s with their s. Range restrictions are
specified using the Manchester syntax. For example, Table 1 specifies that Agent is an rdfs: subClassOf the
intersection of (Person or Organization) and org: memberOf only Organization.
Table 1 — Example formalization of the Agent class
Class Property Value Restriction
Agent rdfs: subClassOf Person or org _s: Organization
org _s: memberOf 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 value restrictions of the class it is an instance of.
The formalization of the properties in this document is done similarly, using the following table format
that allows for the identification of properties and their sub-properties, inverse properties, or other
characteristics. It is to 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 patterns defined in this document have also been implemented in OWL and made available online. The
location of these encodings is identified in Annex C.
5 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 ISO/IEC 5087-2 (this document) in an

© ISO/IEC 2024 – All rights reserved
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 Clause 4, the Agent class’s unique identifier would be:
https:// standards .iso .org/ iso -iec/ 5087/ -2/ ed -1/ en/ ontology/ Agent/ Agent
Breaking the IRI down:
— “5087” identifies the series number
— “-2” identifies the part number
— “ed-1” indicates that the class is defined in edition 1 of the document
— “en” indicates that the class is defined in a pattern implemented in English
— The first “Agent” identifies the Agent Pattern
— The second “Agent” identifies the Agent class within the Agent Pattern
The IRI can be shortened using the prefix’s defined in Clause 4:
a g ent : A g ent
where agent: is the prefix for the Agent Pattern.
Properties are identified in the same manner. The IRI’s of individuals created by an application of
ISO/IEC 5087-2 would have IRIs unique to the application.
6 City-level ontologies
6.1 General
Much as the foundational concepts defined in ISO/IEC 5087-1 are common across arbitrary domains,
concepts also exist that are generic across all cities. These concepts define the domain upon which city
services operate. They are common for all cities but not specific to any one service. The city data model
defines sixteen city-level ontologies, or patterns, to capture these concepts. These are described in the
following subclauses. The content of these ontologies defines terms needed to capture these concepts at a
generic level. They are not intended to be exhaustive, nor to capture the variety of classification systems
and taxonomies that are potentially of interest for different user groups. The common terms defined here
provide the foundational, common language that may be extended by different users as required.
The patterns presented here shall conform to the foundational concepts defined in ISO/IEC 5087-1. Specific
references to foundational content defined in ISO/IEC 5087-1 are identified in text descriptions of pattern
imports, as well as through the explicit identification of terms from ISO/IEC 5087-1.
The cardinality restrictions specified in the pattern formalizations are weakened intentionally in many
cases to support the pragmatic implementation of the ISO/IEC 5087 series. For example, while common
sense dictates that all persons should have at exactly one legal name, in practice there are many possible
applications of city data where persons may be represented with no name at all. Users of this document are
encouraged to extend and strengthen these restrictions where possible or warranted by the application.
6.2 Code pattern
6.2.1 General
The Code pattern provides a structure to address the challenge of value enumeration with a general
approach. In city data there are many classes of things that are intended to be instantiated using a set list
of values (e.g. classification systems). However, these values can change based on application or context.
In such cases it is not desirable for a standard to prescribe a restricted set of possible values which will
potentially not satisfy the needs of all applications. On the other hand, leaving the values completely open-

© ISO/IEC 2024 – All rights reserved
ended provides no utility for interoperability. The Code Pattern provides an intermediate solution for this
challenge by introducing a generic set of classes and properties that can be used to extend such classes to
define various classification systems in an integrated way.
Instead of enumerating value sets for classes in this document, values can be defined with an associated
Code that specifies additional metadata about the value and its origins. This allows these classes to be
extended with various value-systems as required by a particular application, while providing the necessary
information to support interpretation and integration as needed.
6.2.2 Key classes and properties
The key classes and properties are formalized in Table 3 and Table 4, respectively. A code is introduced to
capture the possible value of an object, according to a predefined system of values. It has the following key
properties:
— definedBy: identifies the Organization that defined the code.
— specification: specifies a URI where the definition of the code can be found.
— hasIdentifier: identifies a unique identifier for the code.
— g enpr op: h a s Na me: specifies a name or title for the code.
— g enpr op: h a sD e s c r ip t ion: specifies a description of the code.
6.2.3 Formalization
Table 3 — Key classes in the Code pattern
Class Property Value restriction
Code definedBy max 1 org _s: Organization
specification only xsd: string
genprop: hasIdentifier max 1 xsd: string
genprop: hasName only xsd: string
g enpr op: h a sD e s c r ip t ion only xsd: string
Table 4 — Key properties in the Code pattern
Property Characteristic Value (if applicable)
hasCode rdfs: range Code
6.3 Infrastructure pattern
6.3.1 General
The Infrastructure pattern defines the concepts needed to capture various types of city infrastructure, such
as buildings and roads. The Infrastructure pattern reuses the Spatial Location pattern (from ISO/IEC 5087-1)
in order to capture the location of these Infrastructure Elements.
It is extended by the Building pattern, and the Transportation Infrastructure pattern. It can be extended
with other types of infrastructure as required.
6.3.2 Key classes and properties
The key classes are formalized in Table 5. An Infrastructure Element is a generic representation of a city
structure of interest. All Infrastructure Elements may have a defined, where locations are spatial geometries
as defined in ISO/IEC 5087-1. The Mereology pattern (from ISO/IEC 5087-1) is also reused in order to support

© ISO/IEC 2024 – All rights reserved
the possible representation of infrastructure parts (e.g. road segments) and their associated wholes (e.g. the
entire road). The following are its properties:
— loc: hasLocation: specifies the location of the element as a loc: Location.
— p a r t w hole: h a sP r op erP a r t: specifies any sub-parts of the element.
— genprop:h asIdentifier: specifies identifiers for the element provided by the city.
— g enpr op: h a s Na me: specifies names of the element.
— g enpr op: h a sD e s c r ip t ion: specifies descriptions of the element.
— c ont ac t : h a s A dd r e s s: specifies the address of the element as a contact: Address.
— i72: h a sVa lue: identifies the value of a Building as a cityunits: MonetaryValue. Distinctions may be made
between different types of value, such as the government-assessed value of a building or the purchase
price. Subproperties of hasValue may be introduced to distinguish these types as required. Suggested
possible extensions include: hasCost (purchase price), hasGovernmentAssessedValue (government
assessed value for tax purposes), hasCollateralValue (value assessed in relation to a loan), hasInsuredValue
(value determined by insurance policy).
6.3.3 Formalization
Table 5 — Key classes in the Infrastructure pattern
Class Property Value restriction
InfrastructureElement lo c: h a sL o c a t ion only loc: Location
p a r t w hole: h a sP r op erP a r t only InfrastructureElement
genprop: hasIdentifier only xsd: string
genprop: hasName only xsd: string
g enpr op: h a sD e s c r ip t ion only xsd: string
c ont ac t : h a s A dd r e s s only contact: Address
i72: hasValue only i72: MonetaryValue
6.4 Transportation Infrastructure pattern
6.4.1 General
The Transportation Infrastructure pattern defines the concepts that are relevant in describing the physical
transportation infrastructure and their characteristics. This includes the concepts of a Road, Bridge and
Tunnel. The Infrastructure pattern is reused here, as these transportation structures are all defined as
types of (subclasses) Infrastructure Elements.
6.4.2 Key classes and properties
The key classes are formalized in Table 6. They include the common structural elements that comprise the
physical (land) transportation infrastructure: Roads, Rail Lines, Bridges and Tunnels.
A Travelled Way is a type of Infrastructure Element that enables travel. It is defined with the following
property:
— aggregationOf: identifies a Travelled Way Link that is aggregated to form the Travelled Way.
aggregationOf is distinct from parthood in that a Travelled Way Link does not depend on the Travelled
Way in order to exist.
© ISO/IEC 2024 – All rights reserved
A Travelled Way Link represents a (continuous) length of a Travelled Way. The start and end of a Travelled
Way is typically identified according to operational or managerial significance. It has the following property:
— aggregateOf: identifies a Travelled Way that aggregates the Travelled Way Link.
Travelled Way Links can be decomposed into Travelled Way Segments. Travelled Way Segments are
typically defined based on some physical characteristics of the infrastructure (e.g. lane additions/removals,
intersections). A Travelled Way Segment has the following property:
— p a r t w hole: pr op erP a r t O f: identifies the Travelled Way Link that it is part of.
A Road is a type of Travelled Way. It describes a part of the physical transportation infrastructure that has
been improved to allow travel by motor vehicles, persons, bicycles, and similar methods of conveyance. It is
identified as a Road as such by a given governing body. It is defined with the following property:
— aggregationOf: identifies the Road Link that a Road may be decomposed into in order to represent its
lengths at a finer granularity.
A Road Link is a type of Travelled Way Link that is represents a length of a Road. It has the following property:
— aggregateOf: identifies the Road that aggregates the Road Link.
A Road Segment is a type of Travelled Way Segment that represents a part of a Road Link. It has the following
property:
— p a r t w hole: pr op erP a r t O f: identifies the Road Link that the Road Segment is a part of.
— networkType: identifies the RoadNetworkType of the Road Segment. The Road Network Type identifies
the modes of travel permitted or otherwise supported on a particular Road Segment (e.g. bicycles,
motorized vehicles). Its values may be defined more precisely with the use of the code: hasCode property.
The network types for Road Links and Roads may be defined based on the Road Segments they contain.
A Rail Line is a type of Travelled Way. It describes a part of th
...