The problem of unification and intellectualization of Ukrainian railway transport information systems is investigated employing ontological support. A base frame model of modular ontology, which includes 12 components connected by logical definitions, has been developed. It provides ontological support of technological processes taking into account the formalized normative-legal documentation. The possibilities of ontologies for the railway transport models coordination have been established. The application of the developed methods and tools makes it possible to achieve greater decentralization of information systems and unification of railway technological processes representation. Further research involves extending the formalization of instructions and increasing the expressiveness of ontologies by developing new constructs and linking them with higher level of abstraction ontologies. Ontology, modular ontology, subontology, railway, information system, Web Ontology COLINS-2021: 5th International Conference on Computational Linguistics and Intelligent Systems, April 22-23, 2021, Kharkiv, Ukraine
The development of information systems for railway transport began with the solution of individual, topical at the time tasks in Ukraine. Then more general systems appeared, such as «Automated control system of marshalling station», «Automated system of operational transportation management». Currently, there is a centralized system «Automated Control System for Freight Traffic – Unified» (ACS FT UZ-U), which unites the main operational subsystems of Ukrzaliznytsia (UZ). It is designed to meet the needs of more than 40 departments and 30 branches.
Since ACS FT UZ-U was designed combining and finalizing individual subsystems, it still suffers from fragmentation, which is a certain problem. Also, there was a need for some decentralization due to the reorganization of Ukrzaliznytsia and the creation of several companies on its basis and cooperation with information systems of foreign countries, other carriers and some customers. This corresponds to the «Strategy of Ukraine Railway Transport Informatization», which includes the development of information systems and their closer cooperation with foreign systems.
One of the directions that partly allows solving the problems and challenges encountered is the
development of rail transport ontological support [
Integration of individual UZ subsystems is based on a centralized relational database, which does not meet evolution needs of the system and its extensibility. For example, in the case of the
2021 Copyright for this paper by its authors. emergence of new operators on the Ukraine railroad network or the division of UZ into companies on a functional basis: the infrastructure operator «UZ Infra» and the freight branch «UZ Cargo». Due to the centralized nature of ACS FT UZ-U, it is difficult to use and modify following the needs of such companies.
At the moment, all the instructions of the Ukraine railway transport are not formalized and data exchange between subsystems is performed using electronic messages. The purpose of this work is the decentralization the information system based on ontological support and usage of Web Ontology Language (OWL), where the integration of models is performed utilizing description logic. This involves an increase increasing of the systems usage efficiency by data enrichment with formalized definitions according to regulatory documentation and the use of intelligent processing tools.
Ontological support allows solving a wide range railway transport problems, for example,
harmonization of developing information systems problem [
In the European Union, railway transport ontologies have received considerable attention. There
are projects such as InteGRail and Shift2Rail. The first one developed an ontology for Network
Statement Checker [
The RailTopoModel and the European Rail Traffic Management System (ERTMS) are used to
unify the representation of the railway infrastructure and link subsystems of European railways. The
third level of ERTMS provides for automatic train control. Dispatchers have direct access to the
locomotive's onboard computer systems, which was developed based on a unified conceptual model –
RailTopoModel. In the UK, tracking faults in trains during their movement and mapping of new and
old navigation systems is based on the Rail Core Ontology. RailML (XML-based) representations of
railway terms vocabularies are implemented in RailTopoModel and Rail Core Ontology [
However, the existing transportation ontologies [
The concept of ontology is defined differently depending on the goals and directions of the
research. We will stick to the following: «An ontology defines the common words and concepts
(meanings) used to describe and represent an area of knowledge, and so standardizes the meanings. ...
An ontology includes the following:
classes (general things) in the many domains of interest;
instances (particular things);
relationships among those things;
properties (and property values) of those things;
functions of and processes involving those things;
constraints on and rules involving those things» [
OWL and Protégé were chosen as ontology representation tools, due to their high prevalence and availability. The ontologies of the ACS FT UZ-U, UZ regulations, and databases models were developed.
The ontology development is based on the modular approach [
Poly-hierarchies were not used in the ontology, due to their complex support. Therefore, instead of «is-a» relations, «defined class» constraints were set [15]. Modules of ontologies were linked using «loose coupling» (logical definitions) instead of «strong relationship» (rdfs:subclass).
According to [16], three kinds of defined, partial and primitive classes can be defined in Protégé for OWL. The first one includes necessary and sufficient conditions (set in the «Equivalent to» field in Protégé), the second one includes only necessary conditions (Subclass of Protégé), the third one includes nothing. Partial classes and defined classes are demonstrated in the case study.
The process of ontology combination is called «ontology linking» [
Class: passenger train EquivalentTo: train and carry some passenger
The frame of ontological models of ACS FT UZ-U and their linking with the harmonization of UZ
regulations with the infrastructure of client enterprises is developed. The ontologies of the different
railroad subsystems are combined, for example, «rolling stock» and «infrastructure». Similarly [
Ontology merge can be done automatically as in [18] or manually as in this paper and [19].
There are other ways of linking ontologies in the literature. In [
The Glossary of Train Management Regulations (TMR) includes the terms for line and station tracks. The developed ontology classes define the properties of serviceability and location of a track at a company or a station.
Based on the fact that «bridges» are used for «reframing ... terminology in an engineering context» [25], the definition of a connection track is restructured. Taking into account the SBN limitation, we get the definition «station model connection track is a connection track that connects a UZ station with an enterprise station and complies with the UZ regulations».
Thus, the definition transformation in the context of its technical characteristics and the integration of the enterprise track, track regulations and station model ACS FT UZ-U were developed. 5.2.
According to the eight-digit numbering system for 1520mm gauge rail cars, the following types of railway cars are defined: box car, special car, platform, own car, gondola car, tank car, isothermal car, other cars. We take into account the serviceability properties of the rail car and its location at an enterprise or UZ station.
As a «bridge» the definition «wagon of the wagon model – such that, conforming to the standards of the UZ and located on the track of the station model» is used. This wording implies compliance with the technical characteristics of the rail car, according to the operating rules, and its location. It combines the company rail car, the UZ rules of the rail car exploitation and the ACS FT UZ-U rail car model. It also combines rail car and station models, which will be further formalized as a «necessary and sufficient condition» for «adding» rail car to the car model.
According to the «Comments and explanations on the application of the rules of technical operation of the Ukrainian railways» trains are distinguished by priority (regular, extra, appointed in case of special conditions), and for passenger trains – by type of communication (local, suburban and long-distance). We take into account these properties: the weight of the train and the location at the enterprise or UZ station.
In the context of train weight standards according to the instructions for the development of the train timetable, the definition is formulated as «a train of the train model – the one that has an allowable weight and is located at the track of the station model». This definition allows for the station model and train model to be combined. 5.4.
According to the DFTR, freight is classified according to its properties. Here, loading in the corresponding DFTR rail car, properties of being at the enterprise or UZ station are taken into account. Accordingly, freight and car correspondence can be considered as a classification by function, as in [26, 27].
When freight is loaded into some rail car according to the DFTR, it is defined as «freight of the freight model – such that it is loaded into the rail car of the rail car model and complies with the rules of the DFTR. This definition is used to combine the freight model with the rail car model, and then with the station model.
Let's consider parts of ontologies addressing some technological processes, relating to several subontologies and, accordingly, several information subsystems of ACS FT UZ-U. 6.1.
The railway network of Ukraine has public and non-public tracks. Stations of enterprises are connected to UZ stations with the help of the connection tracks. For the inspection of a new connection track, representatives of the enterprise develop a technical passport and if it meets the requirements of the SBN, it can become part of UZ station tracks list. Enterprise rail tracks do not have to meet UZ regulations. They have train management regulations (TMR) and Technical Operating Rules (TOR) for industrial transportation. If the UZ determines compliance with the SBN standards, such tracks are added to the ACS FT UZ-U information subsystems.
We will consider three models. Models of tracks compliant and non-compliant with UZ regulations (UZ station tracks and enterprise tracks), and the model of UZ regulations.
The process of assigning tracks to UZ tracks can be described as a sequence of the following operations: design of a track passport by a representative of the enterprise; inspection the passport for compliance with the requirements of the SBN by UZ representative (for example, the gradient of the track cannot exceed 40 permille); addition of a track to the station model by UZ computer center employee.
Taking into account the general purpose of the work and the possibilities of ontologies in the enrichment of the track list relational table, one can take into account the restrictions of the TMR. The competence question of this ontology is «What enterprise station is connected by the connection track?» The definition from TOR as a restriction for the ontology is «the connection track is the railway track of ... enterprise, which connects the station ... with the enterprise station ...».
Conceptualization of the connection track passport was performed as follows using the above definition. An individual 1A of connection_track subclass of rail_track class was linked with an individual Azovstal of enterprise_station class and an individual Dnipro of «UZ» station class. Such classes correspond to the usual OWL classes. The passport corresponds to the first of the taxonomies to be merged. The track is «in the state» of the enterprise track.
One can link the ontology with the track list relational database using the Cellfie plugin and transformation rules. For example, the above-described connection track individual is added to the ontology as follows:
Individual: @В4 Types: connection_track.
The development of the ontology is done in Protégé (Figure 2 - Figure 4).
By definition, a track connects only one industrial and one public station.
We have three components from the ontology definition: classes, relations and restrictions. A SPARQL query corresponding to the competency question was developed as a test, and the expected answer was obtained, more specifically what enterprise stations are connected by a connection track.
Several terms from the TOR are linked with a class-subclass relation into the taxonomy and enriched with a necessary condition: connection track generally does not connect more than one enterprise and UZ station.
The developed ontological support allows one to control the process of adding the connection track to the station model of ACS FT UZ-U, taking into account the restrictions of the ontology.
The function of the module is conceptualization and formalization of the SBN regulations for further import into the modular ontology of the station model. The competence question is «What is the gradient of the connection track?», and the restriction from the SBN is «it is allowed to use the ... gradient of up to 40 ‰ on the track of category VII». The idea is to take into account the SBN restriction in the ACS FT UZ-U subsystem of station tracks.
For such a constraint, the OWL language has constructs for the values of data properties, in this case for the property has_gradient. SBN corresponds to the second of the taxonomies to be merged.
The necessary condition is that rail track has no different gradients owl:maxCardinality and a gradient greater than xsd:maxInclusive 40. The connection_track class is defined as partial. Here the gradient is a datatype property, while the connects_enterprise_station property is an object property.
With the SPARQL query, one can find out what gradients are on which connection track (Figure 5).
Now when UZ worker adds an individual of the track with a gradient greater than the normative to the ontology, the reasoner explains to her why the track does not meet the UZ regulations of the connection tracks. Thus the restriction on the value of the gradient was formalized with the construction xsd:maxInclusive 40.
The function of the modular ontology is to align the enterprise database, the TOR of enterprises and the UZ SBN. The competency question is «What are the connection tracks of the station?»
This ontology uses the ontology design pattern approach [15] – loose coupling, specifically the station model tracks are defined like concepts from the two above-mentioned modules (SBN and TOR) using logical definition without use of «strong relations».
For the development of the station model ontology, the track passport ontology and the restriction from the SBN for the connection tracks ontology are imported. They are linked by necessary and sufficient condition bridging axiom. In OWL, this is done with the owl:equivalentClass construct. As stated earlier, for an enterprise track to be part of the OWL station track list, it must have a gradient of less than 40 permille. Then this condition can be formulated as (Figure 6):
Class: model_track EquivalentTo: connection_track and has_gradient some ≤40
This construction is called a «logical definition» and when one adds a sufficient condition to an enterprise track individual in the form of a has_gradient datatype property, for example, 35 permille, it will be re-classified by the reasoner as an individual of the model_track class (Figure 7). The track goes from the «state» of the enterprise track to the «state» of the UZ track. Which corresponds to the second and third steps of the aforementioned procedure for the station model.
The model_track class is a «defined class» and the ontology code uses the constructs owl:equivalentClass (for necessary and sufficient condition) and owl:intersectionOf (for the intersection of connection_track and ≤40 has_gradient sets) for this.
In the OWL the «necessary and sufficient condition» can be considered as the rules. In that, we have the four components of the ontology definition.
SNAP SPARQL hierarchy query performed in SPARQL 1.1 Entailment regime to get track information after reasoning on the ontology (Figure 8).
It becomes possible to use the reasoner for the work that is currently performed by UZ workers by formalization of the track passport data and restrictions from the SBN. As a result, we have two modules of the track list and UZ regulations, a logical definition bridging axiom of the connection track and a modular ontology of the station model. Below is a summary table with ontologies (Table 1). :connection_track rdf:type owl:Class ; rdfs:subClassOf :rail_track , [ rdf:type owl:Restriction ; owl:onProperty :connects_enterprise_station ; owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ; owl:onClass :enterprise_station] , [ rdf:type owl:Restriction ; owl:onProperty :connects_station ; owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ; owl:onClass :station] . :has_gradient rdf:type owl:DatatypeProperty ; rdfs:range [ rdf:type rdfs:Datatype ; owl:onDatatype xsd:integer ; owl:withRestrictions ( [ xsd:minInclusive 0] [ xsd:maxInclusive 40])].
The ontology corresponding to the enterprise rail car database is conceptualized based on eightdigit wagon numbering, and the hierarchical relationships of the taxonomy using strong relationships (rdfs:subclassOf). As a necessary condition and the universal quantifier owl:allValuesFrom, a restriction on the assignment of rail car to transport freight from the TOR for enterprises is presented. But for rail car worker to let a rail car to the station tracks, there must be no defects that hazard the safety of train traffic. As an example, the wheel flange height restriction from the TOR for UZ was formalized using the following OWL constructs owl:withRestrictions and xsd:maxInclusive. The enterprise database ontology modules and restrictions from the UZ regulations are imported into the rail car model ontology and linked together using the owl:intersectionOf relationship as a necessary and sufficient condition (loose coupling):
Class: model boxcar EquivalentTo: boxcar and has_flange some ≤18 and have_location some model_track
Then, when rail car individual is entered into the rail car model of the enterprise, rail car is reclassified by the reasoner as a rail car of the ACS FT UZ-U car model if the conditions of TOR for enterprises and UZ are met.
Here in terms of ontology definition, the boxcar concept is related by the relation has_flange with the flange value and has_location with the station_track. The ontology includes OWL axioms, for example, stating that every boxcar is a car (subclass) and that individual car_111 is located at the track 2A of the station model. There are also theorems that, for example, if a boxcar has a wheel flange, it should not exceed 14 mm.
That is, in the case of car-related modules, the reasoner looks for instances that do not meet the necessary conditions (serviceability and suitability for freight transport) to highlight the nonconsistent cars, as well as individuals that meet sufficient conditions to add them from the enterprise model to the UZ model. Below is a summary table with ontologies (Table 2).
The ontology of enterprise trains is developed by conceptualization based on the enterprises TOR glossary. As a necessary condition, a restriction on the number of locomotives of a train is presented using the owl:minQualifiedCardinality construct. For a train to be added to the train timetable, its weight must meet the instructions for the development of the train timetable, which is achieved with the necessary condition owl:withRestrictions and xsd:maxInclusive in the ontology module. In the ontology of the train model, modules of enterprise trains and UZ regulations are imported and linked together using the intersection relation owl:intersectionOf
Class: model_train EquivalentTo: train and has_weight some ≤3400 and has_location some model_track When a train individual is entered into the enterprise model, if it has a locomotive and its weight is less than the normative, it will be reclassified by the reasoner as a model train.
In terms of ontology definition, the concept of train, like a rail car, is related by the relation has_weight with the weight value and by the relation has_location with the station track. For example, the ontology includes the following axioms, the weight of the train is 3400 tons, the train is located at the station model track and theorems, for example, if the train is located at the station track and its weight does not exceed the normative, then it is added to the UZ train model. Below is a summary table with ontologies (Table 3).
The enterprise freight ontology is developed by conceptualization based on freight classification from the DFTR. As a necessary condition, a restriction on the assignment of a hazard class to the cargo is presented. For a freight in a rail car to be allowed for transportation on UZ tracks, the UZ workers must make sure that the freight corresponds to the rail car that meets the requirements of Appendix 2 of the DFTR. The ontology of the freight model imports the ontology of enterprise freight modules and restrictions from DFTR which are linked together using the intersection relationship owl:intersectionOf:
Class: model_freight EquivalentTo: enterprise_freight and carried_by some model_car When one enters an individual in the freight ontology of the enterprise, if it is assigned the right class and rail car, it will be reclassified by the reasoner in the ACS FT UZ-U freight model.
In terms of ontology definition, the concept freight is related by the relation of has_class with the value of class and carried_by with a rail car. The ontology includes axioms on assigning freight to class 2 and loading it into some rail car. There is also, for example, a theorem: if a freight is in a rail car assigned to it by the DFTR, then it belongs to the ACS FT UZ-U freight model.
Inspection of teh fo th the cargo with
g r n ie the rail car for fo io r itsno ttrapo frseuo cboyrUreZspwoonrdkeernce lau sn gn geR tra ad
Acceptance of the freight by formalizing restrictions on the conformity of freight to rail car, as well as an enterprise database
A base frame model of ontology was developed, which allows for reasoning to support technological processes of railway transport, corresponding to the UZ regulations. In particular, the process of acceptance for transportation on the UZ network of the railway car with the freight of the client's enterprise is considered.
It is shown what kind of knowledge can be used as conditions for the work of the reasoner, the current system bottlenecks are identified. Suggestions for the use of information of normative-legal documentation in automated systems are given. Based on the study, the applicability of modular ontologies and logical definitions for formalization and harmonization of ACS FT UZ-U models can be concluded.
The developed frame of railway transport technological processes ontological support can be
extended and enriched based on existing open access ontologies for a time, OWL lists and transport
infrastructure [
Formalization of instructions and increase the expressiveness of ontologies are intended to be extended by developing new constructs and linking and harmonization them with higher level of abstraction ontologies.
[14] M. C. Suárez-Figueroa et al., Ontology Engineering in a Networked World. Berlin Springer
Berlin, 2014. [15] A. Rector, M. Aranguren, Submissions:Normalization - Odp URL: http://ontologydesignpatterns.org/wiki/Submissions:Normalization [16] M. Horridge et al., A Practical Guide To Building OWL Ontologies Using Protégé 4 and COODE Tools Edition 1.2 Chapter 1, 2009. URL: http://phd.jabenitez.com/wpcontent/uploads/2014/03/A-Practical-Guide-To-Building-OWL-Ontologies-Using-Protege-4.pdf. [17] J. de Bruijn et al., Ontology Mediation, Merging, and Aligning, Semantic Web Technologies, pp.
(2006), 95–113, doi: 10.1002/047003033x.ch6. [18] D. Dou, D. McDermott, P. Qi, Ontology Translation by Ontology Merging and Automated Reasoning, Whitestein Series in Software Agent Technologies, (2005), pp. 73–94, doi: 10.1007/3-7643-7361-x_4. [19] C. J. Mungall et al., Uberon, an integrative multi-species anatomy ontology, Genome Biology, (2012), vol. 13, no. 1, p. R5, doi: 10.1186/gb-2012-13-1-r5. [20] S. Köhler et al., Construction and accessibility of a cross-species phenotype ontology along with gene annotations for biomedical research, F1000Research, (2013), vol. 2, p. 30, doi: 10.12688/f1000research.2-30.v1. [21] Cross Product Guide - GO Wiki, URL: http://wiki.geneontology.org/index.php/Cross_Product_Guide [22] V. Shynkarenko, O. Kuropiatnyk, Constructive Model of the Natural Language, Acta
Cybernetica, (2018), vol. 23, no. 4, pp. 995–1015, doi: 10.14232/actacyb.23.4.2018.2. [23] M. D’Aquin et al., D1.1.3: NeOn Formalisms for Modularization: Syntax, Semantics, Algebra,
HAL Archives Ouvertes, 2008. URL: https://hal.archives-ouvertes.fr/hal-01242833 [24] S. Ben Abbes, et al., Characterizing Modular Ontologies, In: 7th International Conference on
Formal Ontologies in Information Systems-FOIS 2012 (2012), 13-25. [25] S. McInerney et al., E2BMO: Facilitating User Interaction with a BioMimetic Ontology via Semantic Translation and Interface Design, Designs, (2018), vol. 2, no. 4, p. 53, doi: 10.3390/designs2040053. [26] D. Osumi-Sutherl, Cell ontology in an age of data-driven cell classification, BMC
Bioinformatics, (2017), vol. 18, no. S17, doi: 10.1186/s12859-017-1980-6. [27] J. Bard, S. Y. Rhee, M. Ashburner, An ontology for cell types, Genome Biology, (2005), vol. 6, no. 2, p. R21, doi: 10.1186/gb-2005-6-2-r21.