ISO/TR 25100:2008

Intelligent transport systems — Systems architecture — Harmonization of ITS data concepts

The scope of ISO/TR 25100:2008 is harmonization of data concepts that are being managed by data registry and data dictionaries such as those described in ISO 14817:2002.

Systèmes intelligents de transport — Architecture des systèmes — Harmonisation des concepts de données SIT

General Information

• Status: Withdrawn
• Publication Date: 30-Mar-2008
• Withdrawal Date: 30-Mar-2008
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 1 - Architecture
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 13-Sep-2012

Relations

• Revised: ISO/TR 25100:2012 - Intelligent transport systems — Systems architecture — Harmonization of ITS data concepts
• Effective Date: 07-May-2011

Standards Content (Sample)

TECHNICAL ISO/TR
REPORT 25100
First edition
2008-04-01

Intelligent transport systems — Systems
architecture — Harmonization of ITS data
concepts
Systèmes intelligents de transport — Architecture des systèmes —
Harmonisation des concepts de données SIT



Reference number
ISO/TR 25100:2008(E)
©
ISO 2008

---------------------- Page: 1 ----------------------
ISO/TR 25100:2008(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


COPYRIGHT PROTECTED DOCUMENT


©  ISO 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO 2008 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/TR 25100:2008(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope .1
2 Terms and definitions .1
3 Abbreviated terms .1
4 Background issues.2
4.1 Proprietary data concepts .2
4.2 Semantic differences.2
4.3 Structural differences.2
4.4 Difficulty of application of existing data concepts.3
4.5 Report of investigation.3
5 Harmonization — General discussion.3
5.1 Introduction to harmonization.3
5.2 Illustration of the need for harmonization.3
5.3 Harmonization scenarios in data modelling terms .4
5.4 Iterative harmonization process.6
6 Current approaches to harmonization in ITS International Standards .6
6.1 Three approaches.6
6.2 ISO 14817 harmonization .7
6.3 TBG17 business process & core components .7
6.4 UK Highways Agency, Transport Information Highway (TIH) Metadata registry — Review
guidelines .8
7 Harmonization as a means to improve efficiency .9
8 Conclusions .10
Annex A (informative) Harmonization “Use Case” .11
Annex B (informative) ISO 14817 organization and functional operations .13
Bibliography .15

© ISO 2008 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/TR 25100:2008(E)
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In exceptional circumstances, when a technical committee has collected data of a different kind from that
which is normally published as an International Standard (“state of the art”, for example), it may decide by a
simple majority vote of its participating members to publish a Technical Report. A Technical Report is entirely
informative in nature and does not have to be reviewed until the data it provides are considered to be no
longer valid or useful.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TR 25100 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
iv © ISO 2008 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/TR 25100:2008(E)
Introduction
The objective of this Technical Report is to provide user guidance for the harmonization of data concepts
where there are similarities in definitions, including semantics.
Harmonization has been discussed by several groups and there has already emerged some preliminary
guidance and principles for the effective harmonization of data concepts for intelligent transport systems [ITS].
It should be clearly recognized that harmonization is not essential for interoperability, which can usually be
achieved given sufficient investment of knowledge and resources. Nevertheless, this generally leads to
duplication and other unnecessary, even futile work being undertaken. This also assumes that there are
unlimited resources available to achieve the desired interoperability, whereas, in practice, time, budget and
shortage of skilled personnel often cause compromise. Additionally, interoperability in one aspect is
sometimes achieved by the lack or loss of interoperability in another. Harmonization is intended to reduce the
inconsequential work, increase efficiency and thereby reduce the incidence of errors and faults.
This Technical Report describes a proposed process for harmonization of data concepts to arrive at preferred
definitions for use in formal standards, specifications, technical reports and information architecture (data)
models. The proposal is based on consideration of the harmonization process used by three international
groups involved in transport and logistics information and control systems.
Harmonization provides a means by which to improve efficiency and effectiveness of ITS, by helping to
remove duplication, inefficiency, ambiguity and confusion, and thereby improve clarity, comprehension, safety
and efficiency.

© ISO 2008 – All rights reserved v

---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/TR 25100:2008(E)

Intelligent transport systems — Systems architecture —
Harmonization of ITS data concepts
1 Scope
The scope of this Technical Report is the harmonization of data concepts that are being managed by data
registries and data dictionaries such as those described in ISO 14817:2002.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
core component
aggregate information entities and the embedded entities within them
data concept
data dictionary structures defined in this Technical Report (i.e. object class, property, value domain, data
element concept, data element, data frame, message, interface dialogue, association) referring to abstractions
or things in the natural world that can be identified with explicit boundaries and meaning and whose properties
and behaviour all follow the same rules
harmonization
process to resolve differences in synonymous terminology when expressed precisely in syntactic form
3 Abbreviated terms
ACC aggregate core components
CEFACT United Nations Centre for Trade Facilitation and Electronic Business
CCC change control committee
CCTS core components technical specification
IEC International Electrotechnical Commission
ISO International Organization for Standardization
ITS intelligent transport systems
TBG17 UN/CEFACT Trade and Business Processes Group working group 17
TC technical committee
TICS transport information and control system
TIH transport information highway (UK)
UML unified modeling language
UN United Nations
© ISO 2008 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/TR 25100:2008(E)
UTC coordinated universal time
WD working draft
WG working group
4 Background issues
Development of information systems and networks supporting business processes for transport and logistics
frequently encounters multiple similar data concepts, any or all of which may be in widespread use. The need
for harmonization of these synonymous concepts has been acknowledged to enhance interoperability and
reusability, but there are significant issues to be overcome.
Current approaches to achieve the data interoperability are principally to write ad-hoc data interface programs
for each pair of communicating systems. Experience shows that development and maintenance of these
programs is expensive in terms of both time and money. If you consider this problem and its cost implications
further, it can be seen that the total effort required increases with the square of the number of communicating
systems.
4.1 Proprietary data concepts
The first issue is that many data concepts are proprietary or are deeply embedded in proprietary systems,
which work well within their intended domain but are not freely accessible for broader use. There is an
opportunity cost for a system whenever there is a similar but nevertheless separately defined and
implemented concept in use in another domain that is not applied to the subject system.
4.2 Semantic differences
A second issue is where the concepts are subjects of widely used standards, but are not identical and have
subtle semantic differences in their use. In this case, the standards development organizations (SDO) have
generally been protective of their own approaches out of concern about the cost of enforced changes to
already deployed systems. This has resulted in diminished success in harmonization processes (in the USA
for example).
Semantic clashes are clashes between concepts of different standards, or more precisely, between specific
conceptual models or ontologies behind different standards. Typical semantic clashes are completely different
concepts, different naming of concepts or different granularity.
4.3 Structural differences
Structural clashes are caused by the heterogeneity of representation which is possible with many techniques,
such as XML representation. For example, using XML format the same concept can be expressed in several
different ways.
(ISO 24531, Intelligent transport systems — System architecture, taxonomy and terminology — Using XML in
ITS standards, data registries and data dictionaries, provides assistance in these respects for the use of XML
in the ITS sector.)
XML schema enables constraining of XML documents, but this was designed for constraining the content of
XML documents, not the conceptual representation. Within XML, structural clashes are mainly caused by the
different usage of specific constructs, for example a different usage of attributes, rather than embedded
elements, or by expressing concepts in enumeration values.
Usually freely designed XML documents used for specific application purposes do not provide sufficient
information about the semantics of the data. The semantics of XML elements used by web applications is
hard-coded into the applications and is typically not available in machine processable form. This applies also
to documents with available structural schemata (XML schema), which in the most cases define the
syntactical structure of XML documents without unified implicit representation of their meaning.
Other forms of representation, with the possible exception of ASN.1, allow similar clashes to exist.
2 © ISO 2008 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/TR 25100:2008(E)
4.4 Difficulty of application of existing data concepts
A further issue is that there is the requirement in addressing a new application domain to reuse concepts that
already exist as proprietary or open standards but for which the mechanism to render them usable is unclear.
This generally results from semantical differences or uncertainty in the application of the concept, or because
significant domain knowledge is required for the successful reuse of a data concept from a different domain.
4.5 Report of investigation
Harmonization is often touted as the means to resolve these issues, but has been much more difficult to
achieve than expected. This Technical Report is based on an on-going investigation being carried out on
behalf of ISO/TC 204/WG 1 [Intelligent transport systems, Architecture] into various approaches used for
harmonization. This Technical Report presents tentative conclusions regarding the effectiveness of the
approaches for general use in intelligent transport systems, and the wider sector of transport and logistics.
5 Harmonization — General discussion
5.1 Introduction to harmonization
Harmonization is a process to resolve differences in synonymous terminology when expressed precisely in
syntactic form. However, successful achievement of the harmonization process remains a problem in many
areas. Members of ISO/TC 204/WG 1 have been considering this matter for some time and propose solutions
to the requirement for effective harmonization at syntactic, relationship and semantic levels. These solutions
are provided in this Technical Report for harmonization.
Progress in this respect has also been achieved in the United Nations office for trade facilitation and electronic
business (UN/CEFACT) by the Trade and Business processes working group (TBG), specifically TBG17, as
discussed below.
5.2 Illustration of the need for harmonization
It is helpful to consider the nature of the problem to be resolved. Take for example the need for integrated use
of travel information in an advanced national traveller information service (NTIS). One class of information for
the traveller information system will be timetables for various travel services. To take an example from
Australia where two timetables are to be merged but the times of service departure are expressed differently:
⎯ Travel service A departure time format: local time in New South Wales (time zone UTC+10 h or
UTC+11 h), 12-hour clock, subject to daylight savings time (Concept A).
⎯ Travel service B departure time format: 24-hour clock based on Western Australia (time zone UTC+8 h)
and not subject to daylight saving time (Concept B).
Of course, if the travel service were totally local, and travellers had no mobility, the only criteria would be local
custom. However, as the object of travel is mobility, we may expect a traveller to move from one locality to
another, or a travel provider to be providing travel information to traveller information systems elsewhere, or,
in these days of Internet, we may expect direct enquiries from elsewhere. There is, therefore, a significant
benefit to be gained from harmonization. It will be apparent that there is a need for a series of conversions and
business rules to be applied to arrive at a compatible format, which could be in either of the proponent
formats. Alternatively, a third (preferred) option could be the use of a standard time such as UTC (Concept P)
with the conversion to the time format as preferred by the person making the enquiry (query) to be made at
the time of a query.
A second example can be taken from a European project (Harmonise) for the Conceptual Normalization of
XML Data for Interoperability in Tourism. This project studies problems in using XML data in the tourist
industry and, while much of its harmonization resolution is very specific to XML, it provides a methodology that
in process (if not in detail) is similar to that proposed in this Technical Report, and provides some good
examples of the problems involved. These are shown clearly in Table 1 and Table 2.
© ISO 2008 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/TR 25100:2008(E)
Table 1 — Sample of semantic clashes
Different naming PostCode vs. PostalCode
Different position Postcode in Address rather than in ContactInfo
TelephonePrefix and TelephoneNumber separated vs.
Different scope
PrefixTelephoneNumber as a single concept

The example in Table 2 shows three technically correct, according to the standards, but different ways of
expressing the concept PostalCode in XML.
Table 2 — Structural heterogeneity of XML

Wannaby Street 59, Dreamtown

Wannaby Street 59
Dreamtown
X-1220

Wannaby Street 59,
X-1220
Dreamtown

Harmonization has thus to deal with issues at a semantic level, at a structural level, and at a content level.
5.3 Harmonization scenarios in data modelling terms
The essential process of harmonization is to resolve the differences between two or more data concepts in an
agreed manner that has wider usage than merely the original data concepts. In simple terms this is shown in
Figure 1:
4 © ISO 2008 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/TR 25100:2008(E)

Figure 1 — Simple illustration of harmonization
Harmonization can then be defined as follows:
For any pair of data concepts (A,B) harmonization is the selection of preferred concept P based on the
attributes, relationships and semantics for individual data concepts A and B
P = h(A,B) where h is the harmonization preference function.
For the example above, the following scenarios apply to the harmonization function h.
5.3.1 Scenario 1: h{ [name(A)], [name(B)] } ⇒ name(P)
Harmonization shall generate a preferred name for the preferred data concept.
However, in generating the ‘name’ a process of ‘conceptual normalization’ (source: ‘Harmonise’ project) is an
intrinsic part of this first part of the harmonization process.
By first agreeing a preferred name, an agreed basis for the object of the data concept is agreed at a highly
abstracted level, without getting concerned at this early stage with the structure of the concept.
The separation between semantic and structural clashes indicates the need for a distinction between
corresponding steps in the overall transformation process. This step enables a separation of semantic
mapping (resolution of the semantic clashes) from the concrete physical representation of data being
transformed. If different physical representations are used in the future, the semantic mapping definitions will
still remain valid.
NOTE Whereas project ‘Harmonise’ only dealt with XML schema and proposed taking the conceptual normalization
not only to include the name but also to ‘provide a unified human and machine understandable description of the concepts
of local systems and relations among them’, both human and machine understandable description are only possible where
there is a high degree of consensus concerning the form of the data concept (i.e. in the project ‘Hamonise’ context it is
already a precondition that it is an XML schema) prior to commencement of the harmonization process. The process
recommended in this deliverable takes a more pragmatic approach, and one that, the authors believe will overcome some
of the potential weaknesses in agreeing schemata too early at a conceptual level.
5.3.2 Scenario 2: h{ [attribute (A)], [attribute (B)] } ⇒ attribute (P)
n n n
Each attribute of concept A shall be harmonized with each corresponding attribute of concept B to produce a
corresponding attribute of preferred concept P.
Where the complexity of the semantical use of the attribute precludes direct harmonization, each attribute
shall be expanded to a new data concept and the harmonization function applied iteratively until resolved (as
discussed below).
5.3.3 Scenario 3: h[ rel(A,X), rel(B,Y) ] ⇒ rel(A,X), rel(B,X), rel(A,Y), rel(B,Y), rel(A,B)
Each relationship between the proponent concept and another concept shall be replicated for the other
proponent concept. A relationship shall also be defined between the proponent concepts.
© ISO 2008 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/TR 25100:2008(E)
5.3.4 Scenario 4: h[ semantics(A), semantics(B) ] ⇒ (business rules for A, B, P)
The semantics of employment of the proponent concepts shall be encapsulated in business rules that include
the semantics for the preferred concept also.
These scenarios may be described in a use-case template format as shown in Annex A (format source
ISO/TR 25102).
5.4 Iterative harmonization process
Scenario 2 requires that attributes of the proponent data concepts (A,B) are harmonised to produce attributes
of the preferred data concept P. This can also be considered as an iterative process as shown in Figure 2
In this iterative process, existence of recommended data concepts is very important. They are referred,
reused, and preferred in the ITS community which contributes to harmonization.

Figure 2 — Iterative harmonization of attributes
6 Current approaches to harmonization in ITS International Standards
6.1 Three approaches
The three approaches to harmonization in the ITS sector discovered in our investigation are described in 6.1.1
to 6.1.3 below.
6.1.1 ISO 14817 approach
The approach developed by ISO/TC 204/WG 1 is described in ISO 14817, Transport information and control
systems — Requirements for an ITS/TICS central Data Registry and ITS/TICS Data Dictionaries.
6 © ISO 2008 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/TR 25100:2008(E)
6.1.2 UN/CEFACT TBG17 approach
This is the approach developed within UN/CEFACT TBG17 as described in TBG17 (2004).
6.1.3 TIH approach
This is the approach taken by working group WG3 of the Transport Information Highway community in the UK.
The three approaches have been investigated to validate the proposed harmonization approach described in
this document.
6.2 ISO 14817 harmonization
ISO 14817:2002, describes its harmonization process in Clause A.6, ITS/TICS data harmonization and reuse
procedures, of Annex A, ITS/TICS functional operating procedures (for the ITS data registry and data
dictionaries).
ISO 14817:2002, A.6.1, Introduction, states “These procedures detail how the ‘Change Control Committee'
[CCC] and the ‘Stewards’ execute their responsibilities… regarding identification, reconciliation and
documentation of data concept overlaps and duplications…”. See Annex B.
ISO 14817:2002, Annex A describes a ten-step process for identification and resolution of issues in
overlapping or redundant data concepts arising from analysis of data element names, definitions, common
property/object/representation terms and common or similar value domains.
A first stage of analysis is to understand the respective semantics of competing data concepts. If the
semantics are different then both concepts should be retained separately.
If the semantics are equivalent then the change control committee and the stewards may decide to use one of
them in preference to the other, or to modify one of them for use, to agree on a new concept that replaces
both of those under consideration.
ISO 14817:2002, Annex A states that a harmonization listing will be distributed to the members of the change
control committee for consideration.
6.3 TBG17 business process & core components
6.3.1 Harmonization team submission guidelines and procedures
The following excerpts provide a summary view of the harmonization processes in use by UN/CEFACT.
‘This document describes the process by which business domain groups can ensure the common taxonomy
used in one business domain can be interoperable.’ [TBG17 (2004) p. 6]
‘The Core Components [CC] User Community… requires interoperability of business information. This
interoperability covers both interactive and batch exchanges of business data between applications through
the use of Internet and Web based information exchanges as well as traditional Electronic Data Interchange
(EDI) systems.’ (ibid)
‘This document will detail each of the steps necessary for a valid submission to the Harmonization Group.’
[TBG17 (2004) p. 7]
‘During its harmonization work TBG17 realised that there is a need for a further clarification of… relationships
(between CCTS (CC Technical Specification) object types) and for a description of how to express them using
UML.’ [TBG17 (2004) p. 12]
© ISO 2008 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO/TR 25100:2008(E)
‘Harmonization should ensure that a single semantic concept is captured in one and only one Core
Component structure. This may conflict with different views on that concept in different contexts and it conflicts
with the emergence of new submissions.’ [TBG17 (2004) p. 20]
‘If it is agreed, that there is a need to have two or more core component structures for the same semantic
concept, then the core components library administration has to make sure that they refer to each other in
order to guarantee that any further development will be a consistent one.’ [TBG17 (2004), Clause 4.6.5, p. 20]
TBG17 (2004), Clause 4.6.5, Derived Core Components, provides a helpful diagrammatic explanation of
referencing between competing data structures, and several textual examples. From these it draws important
conclusions:
‘These examples demonstrate that, if all user structures are supported in the library, uniqueness becomes a
problem.’
‘Flattened data structures can reference to complex data structures without many problems… reference from
complex to flat structures would usually not be possible without loss of semantics. This means that the Core
Components library… should always be the most complex structure…’ [TBG17 (2004), p. 22]
‘While inserting the various submitted user structures in the library, in order to avoid redundancy, the simpler
core components structures should reference the more complex structures that contain the same semantic
concept. This allows the users to keep their (more flattened) models and messages that reference the (more
complex) structures in the… library.’ (ibid)
‘The harmonization team will use the UML concept of “Derived Classes” and “Derived Attributes” for
...