SIST EN 12896-1:2026

• Abstract:

  This document incorporates data structures used by all other data domains of Transmodel. It is composed of the following data packages:; - versions and validity;; - responsibility;; - generic framework;; - reusable components;; - explicit frames referring to generic data.; The data structures represented in this part are either generic patterns that can be explicitly reused in other domains (e.g., a generic model for version frames, a generic grouping mechanism, etc.) or are referenced by different other parts (e.g., service calendar model).; This document itself is composed of the following parts:; - main document representing the data model for the concepts shared by the different domains covered by Transmodel (normative);; - Annex A containing the data dictionary and attribute tables, i.e., the list of all the concepts present in the main document, together with their definitions (normative);; - Annex B, indicating the data model evolutions (informative),; - Annex C, presenting the Transmodel development history (informative),; - Annex D, describing all conventions, methodology and notations for conceptual modelling (informative),; - Annex E, providing a clear overview to help readers understand the core principles, structure, and purpose of Transmodel (informative),; - Annex F, providing information on the Functional domains and Modes of operation (informative).; - Annex G, providing details of the significant technical changes between this document and EN 12896-1:2015 (informative).

• Status: Published
• Public Enquiry End Date: 15-Feb-2026
• Publication Date: 13-Sep-2026
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ITC - Information technology
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 13-Aug-2026
• Due Date: 18-Oct-2026
• Completion Date: 14-Sep-2026
• Directive: Harmonized Standard2016/797/EU - Directive (EU) 2016/797 of the European Parliament and of the Council of 11 May 2016 on the interoperability of the rail system within the European Union (Text with EEA relevance)
• Ref Project: EN 12896-1:2026 - Public transport - Reference data model - Part 1: Common concepts

• Replaces: SIST EN 12896-1:2017 - Public transport - Reference data model - Part 1: Common concepts
• Effective Date: 01-Oct-2026
• Referred By: SIST EN 12896-5:2026 - Public transport - Reference data model - Part 5: Fare management
• Effective Date: 25-Aug-2026
• Referred By: SIST EN 12896-4:2026 - Public transport - Reference data model - Part 4: Operations monitoring and control
• Effective Date: 25-Aug-2026
• Referred By: SIST EN 12896-7:2026 - Public transport - Reference data model - Part 7: Driver management
• Effective Date: 25-Aug-2026
• Referred By: SIST EN 12896-3:2026 - Public transport - Reference data model - Part 3: Timing information and vehicle scheduling
• Effective Date: 25-Aug-2026
• Referred By: SIST EN 12896-2:2026 - Public transport - Reference data model - Part 2: Public transport network
• Effective Date: 15-Jul-2026
• Referred By: SIST-TS CEN/TS 16614-4:2026 - Public transport - Network and Timetable Exchange (NeTEx) - Part 4: Passenger Information European Profile
• Effective Date: 08-Jul-2026
• Referred By: SIST-TS CEN/TS 16614-6:2024 - Public transport - Network and timetable exchange (NeTEx) - Part 6: European Passenger Information Accessibility Profile
• Effective Date: 08-Jul-2026
• Referred By: SIST-TS CEN/TS 17402:2020 - Intelligent transport systems - Urban ITS - Use of regional traffic standards in a mixed vendor environment
• Effective Date: 08-Jul-2026
• Referred By: SIST-TS CEN/TS 16614-1:2020 - Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange format
• Effective Date: 08-Jul-2026
• Referred By: SIST-TS CEN/TS 16614-1:2014 - Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange format
• Effective Date: 08-Jul-2026
• Referred By: SIST EN 12896-10:2023 - Public transport - Reference data model - Part 10: Alternative Modes
• Effective Date: 08-Jul-2026
• Referred By: SIST-TS CEN/TS 15531-1:2009 - Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework
• Effective Date: 08-Jul-2026
• Referred By: SIST-TS CEN/TS 16614-4:2020 - Public transport - Network and Timetable Exchange (NeTEx) - Part 4: Passenger Information European Profile
• Effective Date: 08-Jul-2026
• Referred By: SIST EN 15531-1:2015 - Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework
• Effective Date: 08-Jul-2026

Overview

SIST EN 12896-1:2026 - "Public transport - Reference data model - Part 1: Common concepts" - is a European standard that defines the core reference data model for public transport information systems, commonly known as Transmodel. Established by the Slovenian Institute for Standardization (SIST) and standardized across Europe through CEN/TC 278, this document provides a foundation of shared concepts and data structures built for interoperability in public transport applications.

This standard forms the backbone for all other Transmodel data domains, establishing common patterns and reusable components essential for data integration, system design, and reliable data exchange between diverse transport systems. Adhering to SIST EN 12896-1:2026 supports consistent data handling, effective system communication, and compliance with European public transport IT infrastructure requirements.

Key Topics

• Versions and Validity
  • Models for versioning and validity of data, crucial for managing updates and lifecycle states in public transport information systems.
• Responsibility
  • Structures for representing responsibilities, organizations, and roles within transport operations, fostering clear delineation of authority and accountability.
• Generic Framework
  • Provides abstract and reusable elements such as generic grouping mechanisms, location systems, and event models, facilitating flexibility and extensibility across applications.
• Reusable Components
  • Includes patterns for vital transport entities, such as service calendars, vehicle types, equipment, facilities, organizations, messages, and more.
• Explicit Frames
  • Offers frameworks to reference and manage generic data sets, ensuring that component data can be consistently applied and reused across various domains.

The accompanying annexes provide further support, including:

• A comprehensive data dictionary and attribute tables.
• Details on model evolution and the history of Transmodel's development.
• Guidance on conventions, methodologies, and notations for conceptual modelling.

Applications

SIST EN 12896-1:2026 is pivotal for organizations involved in designing, developing, and maintaining public transport information systems, including:

• Transport Authorities and Operators
  • Streamline the integration of operational data (schedules, fleets, infrastructure) across agencies and jurisdictions.
• Software Providers and System Integrators
  • Develop interoperable IT solutions that communicate consistently with other transport systems.
• Urban Mobility Platforms
  • Aggregate data reliably from multiple sources for passenger information, journey planning, fare management, and real-time updates.
• Consultants and Planners
  • Ensure that new implementations align with recognized European models for transport data, improving system reliability, data accuracy, and user experience.
• Regulatory Bodies
  • Assess and promote compliance with standards to support unified and accessible public transport networks.

By leveraging this standard, stakeholders can ensure harmonized data models, reduce integration complexity, improve data quality, and enable scalable, future-proof IT infrastructure for multimodal transport.

Related Standards

SIST EN 12896-1:2026 is part of the broader Transmodel suite of standards, each addressing specific functional domains:

• SIST EN 12896-2 and onward: Cover specialized areas such as journey planning, fare management, real-time data, and infrastructure.
• NeTEx (CEN/TS 16614 series): Implements the concepts of Transmodel for network and timetable exchange formats.
• SIRI (CEN/TS 15531): Standardizes interfaces for the exchange of real-time information.
• EN 12896-1:2016: The earlier version superseded by this release.

For optimal results, organizations should use SIST EN 12896-1:2026 in conjunction with other related standards to achieve comprehensive, interoperable public transport IT solutions.

Keywords

Public transport, reference data model, Transmodel, interoperability, data exchange, transport IT standards, transport information systems, reusable components, urban mobility, European standards, SIST, CEN, public transport integration, IT applications in transport.

SLOVENSKI STANDARD
01-oktober-2026
Nadomešča:
SIST EN 12896-1:2017
Javni prevoz - Referenčni podatkovni model - 1. del: Splošni pojmi
Public transport - Reference data model - Part 1: Common concepts
Öffentlicher Verkehr - Datenreferenzmodell - Teil 1: Gemeinsame Konzepte
Transports publics - Modèle de données de référence - Partie 1: Concepts communs
Ta slovenski standard je istoveten z: EN 12896-1:2026
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 12896-1
EUROPEAN STANDARD
NORME EUROPÉENNE
July 2026
EUROPÄISCHE NORM
ICS 35.240.60 Supersedes EN 12896-1:2016
English Version
Public transport - Reference data model - Part 1: Common
concepts
Transports publics - Modèle de données de référence - Öffentlicher Verkehr - Datenreferenzmodell - Teil 1:
Partie 1: Concepts communs Gemeinsame Konzepte
This European Standard was approved by CEN on 15 April 2026.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 12896-1:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
3.1 General information technology terms. 7
3.2 Domain-specific terms . 9
4 Abbreviations . 10
5 Common concepts domains . 11
5.1 Introduction to the common concepts . 11
5.1.1 General. 11
5.1.2 Core framework mechanisms . 11
5.1.3 Generic framework elements . 11
5.1.4 Reusable framework components . 12
5.2 Versions and validity . 15
5.2.1 Introduction . 15
5.2.2 Version and Validity – Model overview . 15
5.2.3 Generic Entity – Conceptual MODEL. 16
5.2.4 Generic Versioning . 16
5.2.5 Generic Version Frame . 17
5.2.6 Generic Validity – Conceptual MODEL . 19
5.2.7 Generic Delta – Conceptual MODEL . 19
5.2.8 Generic Type of Value – Conceptual MODEL . 20
5.3 Responsibility . 21
5.3.1 Introduction . 21
5.3.2 Responsibility – Model overview . 22
5.3.3 Generic Responsibility . 22
5.3.4 Responsibility Role – Conceptual MODEL . 23
5.3.5 Generic Organisation . 25
5.4 Explicit frames . 27
5.4.1 General. 27
5.4.2 Composite Frame – Conceptual MODEL . 27
5.4.3 General Frame – Conceptual MODEL . 28
5.4.4 Resource Frame – Conceptual MODEL . 28
5.4.5 Service Calendar Frame – Conceptual MODEL . 29
5.4.6 Other explicit frames . 30
5.5 Generic framework model . 31
5.5.1 Overview . 31
5.5.2 Generic framework - Overview . 31
5.5.3 Location Systems – Conceptual MODEL . 32
5.5.4 Generic Grouping . 33
5.5.5 Generic Points and Links . 34
5.5.6 Generic Point and Link Sequences . 37
5.5.7 Generic Zones and Features . 38
5.5.8 Generic Layer – Conceptual MODEL . 40
5.5.9 Generic Projection . 41
5.5.10 Generic Place – Conceptual MODEL . 46
5.5.11 Generic Path and Navigation MODEL – Conceptual Model . 46
5.5.12 Generic Assignment – Conceptual MODEL . 47
5.5.13 Generic Loggable Object – Conceptual MODEL . 48
5.5.14 Generic Event – Conceptual MODEL . 49
5.5.15 Generic Security List – Conceptual MODEL . 49
5.5.16 Generic Accessibility . 50
5.5.17 Alternative Text – Conceptual MODEL . 53
5.5.18 Generic Views – Conceptual MODEL . 54
6 Reusable Components . 54
6.1 General . 54
6.2 Reusable Components – Modes . 55
6.2.1 General . 55
6.2.2 Transport Mode – Conceptual MODEL . 55
6.2.3 Transport Submode – Conceptual MODEL . 55
6.2.4 The Transport Mode of Operation – Conceptual MODEL . 56
6.3 Reusable Components – Place & Organisation. 57
6.3.1 General . 57
6.3.2 Topographic Place – Conceptual MODEL. 58
6.3.3 Transport Organisation . 58
6.3.4 Additional Organisation – Conceptual MODEL . 60
6.3.5 Employee – Conceptual MODEL . 61
6.3.6 Role Models . 61
6.4 Reusable Components – Time Element Models . 67
6.4.1 Service Calendar . 67
6.4.2 Availability Condition – Conceptual MODEL . 69
6.4.3 Transfer Times – Conceptual MODEL . 70
6.5 Reusable Components – Vehicle Types . 71
6.5.1 General . 71
6.5.2 Vehicle Type – Conceptual MODEL . 71
6.5.3 Train Types – Conceptual MODEL . 72
6.5.4 Train Element Type – Conceptual MODEL . 74
6.5.5 Fleet Equipment – Conceptual MODEL . 75
6.5.6 Deck Plan - MODEL . 76
6.5.7 Seating Plan – Conceptual MODEL . 81
6.5.8 Seat Affinity – Conceptual MODEL . 82
6.5.9 Deck Path – Conceptual MODEL . 83
6.6 Reusable Components – Vehicles and Fleets . 84
6.6.1 Vehicle – Conceptual MODEL . 84
6.6.2 Fleet – Conceptual MODEL . 85
6.6.3 Train Composition – Conceptual MODEL . 86
6.7 Reusable Components – Equipment . 87
6.7.1 General . 87
6.7.2 Facility – Conceptual MODEL . 88
6.7.3 Generic Equipment – Conceptual MODEL . 88
6.7.4 Actual Vehicle Equipment – Conceptual MODEL . 89
6.7.5 Onboard Vehicle Recharging Equipment Profile – Conceptual MODEL . 90
6.7.6 Energy Equipment – Conceptual MODEL . 91
6.7.7 Spot Equipment – Conceptual MODEL . 92
6.7.8 Vehicle Passenger Equipment – Conceptual MODEL . 93
6.7.9 Deck Sensor Equipment – Conceptual MODEL . 94
6.8 Reusable Message Model . 95
6.8.1 General. 95
6.8.2 Notice – Conceptual MODEL . 95
6.8.3 Notice Assignment – Conceptual MODEL . 96
6.8.4 Message – Conceptual MODEL . 97
6.8.5 Publication Scope – Conceptual MODEL . 98
6.9 Reusable General Elements . 99
6.9.1 General. 99
6.9.2 Alternative Name – Conceptual MODEL . 99
6.9.3 Service Restriction – Conceptual MODEL . 99
6.9.4 Environmental Properties – Conceptual MODEL . 100
6.9.5 Booking Arrangements – Conceptual MODEL. 100
6.9.6 Check Constraint – Conceptual MODEL . 101
6.9.7 Schematic Map – Conceptual MODEL . 102
Annex A (normative) Data dictionary . 108
Annex B (informative) Data model evolution . 216
Annex C (informative) Transmodel development history . 219
Annex D (Informative) Conventions and Methodology for Conceptual Modelling . 227
Annex E (informative) Understanding transmodel . 250
Annex F (informative) Functional domains and Modes of operation . 255
Annex G (informative) Significant technical changes between this document and the
previous edition . 262
Bibliography . 263

European foreword
This document (EN 12896-1:2026) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport system”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by January 2027, and conflicting national standards shall
be withdrawn at the latest by January 2027.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 12896-1:2015.
This document is part of the European standard EN 12896, known as “Transmodel”. This European
standard is a series of documents that comprises of the following ones:
— EN 12896-1, Public transport - Reference data model - Part 1: Common concepts,
— EN 12896-2, Public transport - Reference data model - Part 2: Public transport network,
— EN 12896-3, Public transport - Reference data model - Part 3: Timing information and vehicle
scheduling,
— EN 12896-4, Public transport - Reference data model - Part 4: Operations monitoring and control,
— EN 12896-5, Public transport - Reference data model - Part 5: Fare management,
— EN 12896-6, Public transport - Reference Data model - Part 6: Passenger information,
— EN 12896-7, Public transport - Reference data model - Part 7: Driver management,
— EN 12896-8, Public transport - Reference data model - Part 8: Management information and
statistics,
— EN 12896-10, Public transport – Reference data model – Part 10: Alternative modes.
Together these documents create Transmodel version 6.2 and thus replace Transmodel V6.0.
In addition to the nine normative Parts of this European Standard, a Technical Report (Public Transport
– Reference Data Model – Informative Documentation) was published in 2016 under the reference
CEN/TR 12896-9. It provides additional information to help those implementing projects involving the
use of Transmodel. It is intended that this Technical Report will be extended and republished as soon as
all the normative parts are revised.
The split into several documents is intended to ease the task of users interested in particular functional
domains. It corresponds to the modularisation of Transmodel into functionally related parts, each made
up of distinct UML packages and subpackages that describe a particular aspect of public transport. The
NeTEx UML model follows the same modularisation, allowing a direct mapping from the conceptual
model to the implementation.
Annex C provides details of the significant technical changes between this document and EN 12896-
1:2015
Annex D describes all conventions, methodology and notations for conceptual modelling, applicable to
the EN 12896 series.
Annex E provides a clear overview to help readers understand the core principles, structure, and purpose
of Transmodel.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
1 Scope
This document incorporates data structures used by all other data domains of Transmodel. It is composed
of the following data packages:
- versions and validity;
- responsibility;
- generic framework;
- reusable components;
- explicit frames referring to generic data.
The data structures represented in this part are either generic patterns that can be explicitly reused in
other domains (e.g., a generic model for version frames, a generic grouping mechanism, etc.) or are
referenced by different other parts (e.g., service calendar model).
This document itself is composed of the following parts:
- main document representing the data model for the concepts shared by the different domains
covered by Transmodel (normative);
- Annex A containing the data dictionary and attribute tables, i.e., the list of all the concepts
present in the main document, together with their definitions (normative);
- Annex B, indicating the data model evolutions (informative),
- Annex C, presenting the Transmodel development history (informative),
- Annex D, describing all conventions, methodology and notations for conceptual modelling
(informative),
- Annex E, providing a clear overview to help readers understand the core principles, structure,
and purpose of Transmodel (informative),
- Annex F, providing information on the Functional domains and Modes of operation
(informative).
- Annex G, providing details of the significant technical changes between this document and EN
12896-1:2015 (informative).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions.
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 General information technology terms
3.1.1.
attribute
property of an entity
3.1.2.
conceptual data model
admitted term
description of a real world domain in terms of entities, relationships and attributes, in an implementation
independent manner, which should provide a structure on which the rest of the development of an
application system can be based
3.1.3.
conceptual level
conceptual data model in the context of data modelling
3.1.4.
database
collection of data; often used in the sense of the physical implementation of a data model
3.1.5.
data domain
data structure (in this document, a part of the Reference data model for public transport) made up of data
related to each other, through the fact that there is a functional area or group of functions using this data
set as a whole
3.1.6.
data model
description of a real world domain in terms of data and relationships
3.1.7.
entity
object (data) that has its own existence (as opposed to an attribute)
3.1.8.
function
activity, or in this document, sub-activity of a functional area
3.1.9.
functional area
arbitrarily defined set of activities, used, in this European Standard, to define the objectives and limits of
the data model
3.1.10.
GDF database
database containing geographical information on the road network in a particular application area,
possibly including information on the location of public transport points, links and services (routes)
3.1.11.
interoperability
ability of (sub)systems to interact with other (sub)systems according to a set of predefined rules
(interface)
3.1.12.
logical data model
data design, that takes into account the type of database to be used, but does not consider means of
utilization of space or access
3.1.13.
logical denormalized model
relational data model that is not fully normalized, i.e., does not completely follow the normalization rules
and thus can be redundant
3.1.14.
logical level
logical data model in the context of data modelling
3.1.15.
relational data model
type of logical data model giving the information as series of tables (relations) and attributes
Note to entry: It will have the following characteristics: 1. all attribute values are atomic; 2. all “tuples”
(rows/occurrences) are distinct; 3. no part of the primary key may be null; 4. foreign key values will correspond to
an existing primary key in another relation or be null.
3.1.16.
object oriented data model
data structure expressed according to principles that allow for a direct implementation as an object-
oriented database, where information is represented in form of objects, i.e., respecting the principle of
encapsulation meaning in particular that each data is accessed or modified through operations (methods)
belonging to it
3.2 Domain-specific terms
NOTE Terms which are also used as the names of Transmodel ENTITies are not included here.
3.2.1.
fare management
all activities related to the collection of money from passengers
3.2.2.
management information
all activities allowing the company management to collect the information necessary to meet problem-
solving needs
Note to entry: Data of operational systems are filtered and aggregated for this purpose, and made available to the
user interactively, or in the form of pre-defined reports and summaries. Such functions are in principle related to
all functional areas of a company, with particular reference to the management of statistical results.
3.2.3.
operations monitoring and control / real-time control
all activities related to the transportation process, i.e., real-time functions related to the driving and
transportation of passengers according to given instructions, including the monitoring of the driving
process and its control in case of deviations, as well as all activities that support the driving process
(traffic light priority, track switching, bay selection, advance/delay advice etc.)
Note to entry: Such functions are often assisted by computer-aided tools, known as Automated Vehicle Monitoring
(AVM)
3.2.4.
passenger information
all activities related to informing the users either about the planned or about the actual transportation
services
3.2.5.
personnel disposition
all activities related to the mid-term and short-term management of drivers
3.2.6.
tactical planning / scheduling
all activities related to the tactical planning of transportation, split into vehicle scheduling, driver
scheduling, rostering
4 Abbreviations
API Application Programming Interface
AVM Automatic Vehicle Monitoring
CC Common Concepts
GIS Geographical Information System
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
IFOPT Identification of Fixed Objects in Public Transport
ISO International Standards Organisation
IT Information Technology
NeTEx Network and Timetable Exchange
PT Public Transport
PTO Public Transport Operator
OJP Open Journey Planner
OpRa Operating Raw Data and statistics exchange
RC Reusable Component
SIRI Service Interface for Real-time Information
TM Transmodel
UML Unified Modelling Language
URI Uniform Resource Identifier
URL Universal Resource Locator
VDV Verband Deutscher Verkehrsunternehmen (Germany)
WGS World Geodetic Standard
5 Common concepts domains
5.1 Introduction to the common concepts
5.1.1 General
This section describes the common concepts and components (CC) of Transmodel that are shared by all
Transmodel functional parts. This data domain has three main aspects: a core framework, a set of generic
framework elements, and a set of reusable components.
5.1.2 Core framework mechanisms
The Core framework provides mechanisms for common aspects of all Transmodel objects that are
needed for effective data management and exchange, such as versioning, validity, grouping, and
responsibility tracking. The mechanisms, implemented through common super types and containers, and
specialised in the various Transmodel functional modules, can be understood and implemented
uniformly for all Transmodel components, rather than on an ad hoc basis. The framework splits into:
Versions and Validity model: describes the successive versions of data elements and the conditions to
be attached to elements to precisely know when they should be used:
— generic entity model;
— generic version model;
— generic version frame model;
— generic validity model;
— generic type of value model;
— generic delta model.
Responsibility model: describes the type of responsibility or role the different organisations may have
over the data:
— generic responsibility model;
— generic responsibility role model;
— generic organisation model.
5.1.3 Generic framework elements
Generic framework: describes a number of generic objects and representational mechanisms that are
not specific to transport but which are specialised or used by Transmodel transport related objects. This
part splits into:
— generic location model;
— generic grouping model;
— generic point and link model;
— generic point and link sequence model;
— generic section model;
— generic zone model;
— generic feature model;
— generic layer model;
— generic projection model;
— generic place model;
— generic path & navigation model;
— generic assignment model;
— generic loggable object model;
— generic event model.`
— generic security list model;
— alternative text model;
5.1.4 Reusable framework components
Reusable components: Certain common low-level components, for example TRANSPORT MODE,
SERVICE CALENDAR, DAY TYPE, etc. are not specific to any particular functional part of Transmodel but
are widely used in several different functional areas. Such components are defined centrally as part of
the common concepts.
The Reusable components models describe generic and reusable objects specific to public transport.
These are organised into a number of functional areas:
— Reusable mode models characterising the different transport modes;
— transport mode model;
— transport submode model;
— travel means model;
— transport mode of operation model;
— Reusable place & organisation models characterising the places and organisations related to in
public transport;
— topographic place model;
— topographic projection model;
— transport organisations model;
— additional organisations model;
— employee model;
— Reusable role models characterising the roles acted by organisations and individuals in public
transport;
— common role model;
— service organisation role model;
— administrative organisation role model;
— technology organisation role model;
— messaging role model;
— transport user role model;
— employee role model;
— Reusable time element models characterising commonly used temporal concepts;
— service calendar model;
— availability condition model;
— transfer timing model;
— Reusable vehicle type models characterising vehicle types;
— deck plan model;
— deck path model;
— seating plan model;
— seating affinity model;
— vehicle type model;
— fleet equipment profile model;
— train type model;
— train element type model;
— Reusable vehicle models characterising vehicles;
— vehicle model;
— fleet model;
— train composition model;
— Reusable equipment models characterising commonly used equipment concepts;
— facility model;
— generic equipment model;
— actual vehicle equipment model;
— energy equipment model;
— spot equipment model;
— deck sensor equipment model;
— vehicle passenger equipment model;
— recharging equipment model;
— Reusable message models characterising messages and their scope;
— notice model;
— notice assignment model;
— message model;
— publication scope model;
— Reusable general elements characterising low level features such as text annotations;
— alternative name model.
— service restriction model;
— environmental properties model;
— booking arrangements model;
— accessibility model;
— check constraint model;
— schematic map model;
The Explicit frames model describes the mechanisms useful to build coherent sets of versioned data.
Part 1 presents explicit frames for data from the common concepts domain.
— composite frame model;
— general frame model;
— resource frame model;
— service calendar frame model;
The present document is structured according to the model structure as shown above.
5.2 Versions and validity
5.2.1 Introduction
Information systems for public transport operation typically require the definition of many different
types of data, produced by different organisations or operating divisions, and are subject to a multistage
lifecycle; from planning through to production and realization in real-time. These data are continuously
evolving and are subject to a variety of different validity conditions as to when they are current, and as
to which data are needed for a particular purpose. Transmodel includes uniform version and validity
mechanisms to address these requirements; the mechanisms are part of the Transmodel framework and
that can be applied to all data elements throughout their various lifecycles.
The versioning model allows successive versions of data elements to be identified, allowing the fine-
grained identification of just those elements that have changed, and the auditing of changes. All
references can also be versioned so that for composite data sets that comprise a number of related
elements it is possible to be precise as to which version of each element is required. The versioning model
also allows schemes where the responsibility for maintaining different parts of the data is split among
several organisations and systems, each providing its partial data separately. In this case, references to
external data are not explicitly versioned, but instead the correct version of the different referenced
entities are deduced from validity conditions when combining the data.
A version frame mechanism provides a versionable container that allows a coherent set of related
elements to be managed as a set or exchanged. Since pragmatically actual systems that contain data to be
exchanged differ in the sophistication of their support for versioning, the mechanisms are designed so
that they may be used either just in a course-grained manner at the level of the whole data set, or if
support is available, in a more powerful way at the level of the individual data element.
The validity model allows conditions to be attached to elements as to when they are current or the
circumstances in which they should be used. Validity conditions can be attached to specific elements and
also, through version frames, to whole sets of objects so that it is possible to be explicit about the exact
conditions governing the coherence and relevance of data. This makes it possible for systems to express
the currency conditions for data they require and to describe the validity of data that is returned by a
system.
5.2.2 Version and Validity – Model overview
The versioning mechanisms are part of the core Transmodel framework, and are provided by a common
set of modules that are referenced by all other Transmodel modules. The fundamental models are
described in detail in the following sections.
— the ENTITY model describes the Transmodel basic object structure;
— the VERSION model adds in version control elements and attributes. VERSION FRAMES group
multiple instances of versions of entities that make up a coherent version set;
— the RESPONSIBILITY model adds in metadata for ENTITY ownership and roles for data
management;
— the VALIDITY package defines generic validity conditions for use in the framework;
— the DELTA package refers to the detailed changes of a given ENTITY IN VERSION from one
VERSION to the next one.
5.2.3 Generic Entity – Conceptual MODEL
The entity ENTITY represents an actual object instance of data present in an exchanged data set. An
ENTITY may represent any instance of a CLASS IN REPOSITORY, corresponding to an instance of the
object as stored in a specific database. All Transmodel objects are formal descendants of ENTITY.
CLASSes IN REPOSITORY can be grouped into sets of coherent versions using a CLASS IN FRAME. CLASS
IN REPOSITORY and CLASS IN FRAME are part of the Transmodel conceptual model and help to make
clear the difference between classes of objects effectively present in a repository (CLASS IN REPOSITORY)
and classes of objects grouped to be managed as a coherent set (e.g., to be exchanged). Instances of objects
are ENTITies, more precisely a repository may contain many versions of an ENTITY. The TYPE of ENTITY
defines a set of sub-categories that can be used to make arbitrary classifications of a specific ENTITY.
Thus, it is really a “category of ENTITY” rather a class or type. TYPE OF ENTITY is an abstract mechanism
that is present in Transmodel to indicate the possibility of categorization. Actual Transmodel objects
generally have a more specific categorization, e.g., TYPE OF POINT, etc. that specifies a category that is
specific to the ENTITY type.
Figure 1 – Generic Entity – Conceptual MODEL
5.2.4 Generic Versioning
5.2.4.1 Overview
The modelling of versions in Transmodel is in effect a version description model, not a model of a version
management system. It allows for fine grained versioning, and uses a uniform and generic approach that
can be used for any time of complex data object. This versioning mechanism is available on all Transmodel
elements, but not mandatory, thus allowing legacy systems without any versioning mechanism to use
Transmodel in a basic manner simply by omitting the detailed versioning attributes. In practice,
versioning will be often just done at an aggregate level and not that of the individual data instance.
Public transport data are in a permanent process of evolution; schedule and operational data typically
undergo a regular cycle of planning, distribution and execution, while reference data describing the
network, such as stop and line data, will change if the network or physical environment is modified. It is
therefore necessary to be able to organise data elements to support such a lifecycle, with multiple
versions of a given element being in use concurrently, and different assemblies of data referencing
different versions for different purposes. This is achieved in Transmodel with VERSIONs and VERSION
FRAMEs.
5.2.4.2 Generic Version – Conceptual MODEL
Each state of an object, or a set of objects, is called a VERSION. VERSIONs of an object may be consecutive
or competitive. Consecutive VERSIONs describe the successive states of an object, while competitive
VERSIONs describe an alternative version to use in particular circumstances, i.e., under specific VALIDITY
CONDITIONs (cf. Generic VALIDITY – conceptual model below). For example, there may be for a single
line at the same time competitive versions of the line; a simulated line (for planning work or for study),
and the operational line for particular operating periods.
The VERSION describes the identifier and purpose of a version state. The actual version state of the
objects is described by an instance of ENTITY IN VERSION. Thus, in a given repository or documents there
will be a single instance of each Transmodel ENTITY and one or multiple instances of ENTITY IN
VERSIONs for that ENTITY; these will be tried together by a common identifier and differentiated by
distinct VERSION identifiers. For example, an instance of the entity SCHEDULED STOP POINT may have
multiple SCHEDULED STOP POINT IN VERSION instances, etc.
The purpose of the VERSION may be categorised with an arbitrary classification using a TYPE OF
VERSION, for example planning, scheduled, operational, etc.

Figure 2 – Generic version – Conceptual MODEL
5.2.5 Generic Version Frame
VERSION FRAMEs allow data to be managed and exchanged as a coherent version, that is, a set of
instances (ENTITies IN VERSION) of different entity types that are consistent and correct as to referential
integrity and other business semantics and so are suitable for use without extensive consistency
checking, for example, by an importing application. A VERSION FRAME contains a list of specific versions
of an entity, that is, instances of ENTITY IN VERSION.
Th
...