Ontological Harmonization of Railway Transport Information Systems Viktor Shynkarenko and Larysa Zhuchyi Dnipro National University of Railway Transport named after Academician V. Lazaryan, 2 Lazaryana str., Dnipro, 49010, Ukraine Abstract 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. Keywords 1 Ontology, modular ontology, subontology, railway, information system, Web Ontology Language, Protégé 1. Introduction 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 [1, 2] and the use of a constructive approach [3, 4]. 2. Problem statement and purpose 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 COLINS-2021: 5th International Conference on Computational Linguistics and Intelligent Systems, April 22–23, 2021, Kharkiv, Ukraine EMAIL: shynkarenko_vi@ua.fm (V. Shynkarenko); larisa_zhuchiy@ukr.net (L. Zhuchyi) ORCID: 0000-0001-8738-7225 (V. Shynkarenko); 0000-0002-9209-7262 (L. Zhuchyi) ©️ 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings (CEUR-WS.org) 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. 3. Related works Ontological support allows solving a wide range railway transport problems, for example, harmonization of developing information systems problem [3] are suggested to solve with the help of their ontological support; elimination of contradictions in determining the location of the train according to different information systems [5]. 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 [6] in the context of the Directive on Interoperability in Railway Transport [7, 8]. The second one is Booking & Ticketing Ontology for multimodal transportation. 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 [9]. However, the existing transportation ontologies [9-11] are mostly focused on the infrastructure and rolling stock of railways. In this paper, we model the freight transportation processes and their intellectualization by OWL tools. They are, for example, the procedure for inspection of the company's railway car for transportation on the Ukrzaliznytsia network and its harmonization with UZ regulations. 4. Methods for ontology development 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» [12]. 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 [13] using nonontological resources [14] and normalization ontology design pattern [15]. The modular approach is applied since the ACS FT UZ-U is based on the models corresponding to the subsystems of the railway and they are easier to operate individually than a general complex taxonomy. For each OWL module, a story, a competency question, and a SPARQL query test are specified. 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» [13] or «ontology merging» [17]. One of the systems for ontology «bridging» is OntoMerge [18], the authors of which develop «bridging axioms» to merge ontologies. The well-known «bridging ontology» – UBERON [19] is used to combine ontologies using «bridging» [20] or «cross-product» [21], where the following construction is applied: 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 [9] the concepts of the different railway subsystems are merged, such as «track» and «automatic blocking». 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 [3, 4] it is done in a constructive- productive way by generative mappings. Higher-level ontologies can also be used for «ontology merging». 5. Results: Base Ontological Model To combine the ACS FT UZ-U models and their individual ontologies, Base Ontological Model is developed – a frame of modular ontology, which includes ontologies of ACS FT UZ-U models, UZ regulations and databases of client enterprises. The ACS FT UZ-U includes the following models:  train – slots of train timetable;  station – station diagrams and standard times of technological operations;  railway car – the dislocation of railway cars;  freight – freight in railway cars. The following UZ regulations is formalized by ontological means (natural linguistic constructions [22]):  state building standards of Ukraine for Railway Transport Facilities of 1520 mm Gauge Design Norms DBN B.2.3-19-2008 (hereinafter – SBN);  instructions for the development of the train timetable;  rules of the railway car exploitation;  regulations for the transportation of dangerous freight (DFTR). Each Base Ontological Model node is a sub-ontology: the square node is the ACS FT UZ-U model and the filled round node – to UZ regulation, the round node without a fill – to the client's enterprise database (Figure 1). The whole model and each square correspond to the concept of a modular ontology, and each circle to a module ontology. The «owl:import» construct is used to connect module ontologies. In addition to it, E-Connections means can also be used [23]. In [9] ontologies are formed in a modular way using hierarchies. But hierarchical relations between modules are designed using «is-a» relations between different levels of abstraction. And in this paper concepts are not «instantiated» but «complicated» by adding new constraints, which corresponds to the pattern of aggregation in modular ontologies [24]. For mutual enrichment and unification of ontology-modules the corresponding classes – concepts are introduced. Figure 1: Base Ontological Model 5.1. Classification in the station model 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. Classification of the railway car model 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. 5.3. Classification of the train 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. Classification of the freight model 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. 6. Results: sub-ontology frames of the Base Ontological Model Let's consider parts of ontologies addressing some technological processes, relating to several sub- ontologies and, accordingly, several information subsystems of ACS FT UZ-U. 6.1. Station model 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. 6.1.1. Enterprise track model – module of station model sub-ontology 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). Figure 2: Idividuals of class stations (Dnipro), industrial station (Azovstal) and connection track (1A) Figure 3: The necessary condition in Protégé 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. Figure 4: Test query of enterprise paths with SPARQL query in Protégé 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. 6.1.2. The SBN model is a sub-ontology module of the station model 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). Figure 5: SBN ontology test query (SPARQL in Protégé) 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. 6.1.3. Formation of the sub-ontology of the station model 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. Figure 6: Logical definition of the station model track in Protégé Figure 7: The reasoner infers the model_track type for connection track individual 1A SNAP SPARQL hierarchy query performed in SPARQL 1.1 Entailment regime to get track information after reasoning on the ontology (Figure 8). Figure 8: Test query for the station model hierarchy in Protégé 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). Table 1 Ontological support of the station model Function of a sub- Definition OWL axioms ontology Finding rail track in the connection :connection_track rdf:type owl:Class ; the enterprise track is the rdfs:subClassOf :rail_track , database railway track of [ rdf:type owl:Restriction ; Enterprise tracks ... enterprise, owl:onProperty :connects_enterprise_station ; which connects owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ; the station ... owl:onClass :enterprise_station] , with the [ rdf:type owl:Restriction ; enterprise owl:onProperty :connects_station ; station .. owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ; owl:onClass :station] . Inspection of the it is allowed to :has_gradient rdf:type owl:DatatypeProperty ; track for use the ... rdfs:range [ rdf:type rdfs:Datatype ; compliance with UZ gradient of up owl:onDatatype xsd:integer ; SBN regulations to 40 ‰ on the owl:withRestrictions ( [ xsd:minInclusive 0] track of [ xsd:maxInclusive 40])]. category VII Entering the track Class: station_model:model_track rdf:type owl:Class ; into the UZ station model_track owl:equivalentClass [ owl:intersectionOf ( Station model model if an EquivalentTo: паспорт_колії:connection_track enterprise track connection_trac [ rdf:type owl:Restriction ; corresponds to the k and owl:onProperty дбн:has_gradient ; UZ regulations has_gradient owl:someValuesFrom xsd:integer]) ; some ≤40 rdf:type owl:Class] . 6.2. Sub-ontology of the car model The ontology corresponding to the enterprise rail car database is conceptualized based on eight- digit 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 non- consistent 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). Table 2 Ontological support of the car model Function Definition OWL axioms Finding of a rail car freight cars – :car rdf:type owl:Class ; Enterprise at an enterprise cars designed rdfs:subClassOf [ rdf:type owl:Restriction ; rail cars database to carry owl:onProperty :carries ; freight owl:allValuesFrom :freight ] ; owl:disjointWith :freight . Inspection of a car … defects ... :has_flange rdf:type owl:DatatypeProperty ; exploitation for defects from of the wheels rdfs:range [ rdf:type rdfs:Datatype ; Rail car rules TOR ... (vertical owl:onDatatype xsd:integer ; flange … over owl:withRestrictions ( [ xsd:minInclusive 0] 18 mm) [ xsd:maxInclusive 14])]. Entering the car of Class: model car_model:model_car rdf:type owl:Class ; the enterprise into boxcar owl:equivalentClass [ owl:intersectionOf ( the car model of EquivalentTo: enterprise_cars:car Rail car model the station using boxcar and [ rdf:type owl:Restriction ; the formalization has_flange owl:onProperty car_model:have_location ; of knowledge some ≤18 and owl:someValuesFrom corresponding to have_location station_model:model_track] the enterprise rail some [ rdf:type owl:Restriction ; car database and model_track owl:onProperty car_normatives:has_flange ; the rules of the rail owl:someValuesFrom xsd:integer]) ; car exploitation rdf:type owl:Class] . 6.3. Sub-ontology of the train model 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). Table 3 Ontological support of the train model Function Definition OWL axioms Finding the train –… set of :train rdf:type owl:Class ; Enterprise train management train at the cars with… owl:equivalentClass [ rdf:type owl:Class ; station of the locomotives owl:oneOf ( :train_1)] ; enterprise rdfs:subClassOf [ rdf:type owl:Restriction ; regulations owl:onProperty :has_locomotive ; owl:someValuesFrom :locomotive] , [ rdf:type owl:Restriction ; owl:onProperty :has_locomotive ; owl:minQualifiedCardinality "1"^^xsd:nonNegativeInteger ; owl:onClass :locomotive] . Inspection of Railways :has_weight rdf:type owl:DatatypeProperty ; Instructions for the of the train for determine the rdfs:range [ rdf:type rdfs:Datatype ; the train timetable compliance weight of the owl:onDatatype xsd:integer ; with train for each owl:withRestrictions ( [ xsd:minInclusive 400] instructions for section by the [ xsd:maxInclusive 3400])] . the power of the development of locomotive, taking the train into account line timetable gradient Adding a train Class: model_train train_model:model_train rdf:type owl:Class ; to a train EquivalentTo: owl:equivalentClass [ owl:intersectionOf ( model by train and enterprise_trains:train Train model formalization of has_weight some [ rdf:type owl:Restriction ; the enterprise ≤3400 and owl:onProperty train_model:has_location ; train database has_location owl:someValuesFrom station_model:model_track] knowledge, as some model_track [ rdf:type owl:Restriction ; well as weight owl:onProperty train_normatives:has_weight ; norms owl:someValuesFrom xsd:integer]) ; rdf:type owl:Class] . 6.4. Sub-ontology of the freight model 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. Table 4 Ontological support of the freight model Sub- Function of a Definition OWL axioms ontology sub-ontology (normative / developed) Finding freight Dangerous goods – :has_class rdf:type owl:DatatypeProperty ; in the substances that are rdfs:range [ rdf:type rdfs:Datatype ; Enterprise freight enterprise classified as one of owl:oneOf [ rdf:type rdf:List ; database the classes of rdf:first "1"^^xsd:int ; dangerous rdf:rest [ rdf:type rdf:List ; substances rdf:first "2"^^xsd:int ; rdf:rest [ rdf:type rdf:List ; rdf:first "3"^^xsd:int ; rdf:rest rdf:nil]]]] . Inspection of Alkyldimethylamine :some_freight rdf:type owl:Class ; Regulations for the dangerous freight the cargo with oxide freight can be rdfs:subClassOf [ rdf:type owl:Class ; transportation of the rail car for transported in owl:unionOf ( [ rdf:type owl:Restriction ; correspondence boxcars and owl:onProperty :carried_by ; by UZ worker universal owl:someValuesFrom :normative_boxcar] containers [ rdf:type owl:Restriction ; owl:onProperty :carried_by ; owl:someValuesFrom :normative_container])] . Acceptance of Class: freight_model:model_freight rdf:type owl:Class the freight by model_freight ; formalizing EquivalentTo: owl:equivalentClass [ owl:intersectionOf ( Freight model restrictions on enterprise_freight enterprise_freight:gas the conformity and carried_by [ rdf:type owl:Restriction ; of freight to rail some model_car owl:onProperty normative_freight:carried_by ; car, as well as owl:someValuesFrom car_model:model_car]) ; an enterprise rdf:type owl:Class] . database 7. Conclusions and future work 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 [11]. 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. 8. References [1] M. Katsumi, M. Fox, Ontologies for transportation research: A survey, Transportation Research Part C: Emerging Technologies, (2018), vol. 89, pp. 53–82, doi: 10.1016/j.trc.2018.01.023. [2] C. Morris, J. Easton, C. Roberts, Position Paper: Ontology in the Rail Domain - The Railway Core Ontologies, Proceedings of the 7th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management, 2015, doi: 10.5220/0005613702850290. [3] V. Skalozub, V. Ilman, V. Shynkarenko, Development of ontological support of constructive- synthesizing modeling of information systems, Eastern-European Journal of Enterprise Technologies, (2017), vol. 6, no. 4 (90), pp. 58–69, doi: 10.15587/1729-4061.2017.119497. [4] V. Skalozub, V. Ilman, V. Shynkarenko, Ontological support formation for constructive- synthesizing modeling of information systems development processes, Eastern-European Journal of Enterprise Technologies, (2018), vol. 5, no. 4 (95), pp. 55–63, doi: 10.15587/1729- 4061.2018.143968. [5] C. Morris, J. Easton, use of ontology for data integration in a degraded mode signalling system, Computers in Railways XVI: Railway Engineering Design and Operation, (2018), doi: 10.2495/cr180191. [6] S. Verstichel et al., Efficient data integration in the railway domain through an ontology-based methodology, Transportation Research Part C: Emerging Technologies, (2011), vol. 19, no. 4, pp. 617–643, doi: 10.1016/j.trc.2010.10.003. [7] Directive 2008/57/EC of the European Parliament and of the Council on the interoperability of the rail system within the Community. 2009. [8] P. Umiliacchi, Predictive maintenance of railway subsystems using an Ontology based modelling approach, in: Proceedings of 9th world conference on railway research, May 2011. [9] J. Tutcher, Development of semantic data models to support data interoperability in the rail industry, Dissertation, University of Birmingham, 2016. [10] R. Lewis, A semantic approach to railway data integration and decision support, Dissertation, University of Birmingham, 2015. [11] M. Katsumi, M. Fox, iCity Transportation Planning Suite of Ontologies, Jun. 2020. [12] M. C. Daconta, Leo Joseph Obrst, K. T. Smith, The Semantic Web: a guide to the future of XML, Web services, and knowledge management. Indianapolis, Ind.: Wiley Pub, 2003. [13] A. Rector, When and Why to use a Classifier? URL: https://protege.stanford.edu/conference/2005/slides/5.2_Rector_Why_classify_Protege_worksho p_2005-v2.pdf. [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 CO- ODE Tools Edition 1.2 Chapter 1, 2009. URL: http://phd.jabenitez.com/wp- content/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.