Applying the LOT Methodology to a Public Bus Transport Ontology aligned with Transmodel: Challenges and Results

1.Introduction

Open data initiatives across public administrations worldwide date back to more than a decade ago. In the specific case of Spanish cities, the most relevant landmarks are associated to the first transposition of the EU Public Sector Information directive in 2007,11 the publication of the UNE 178301:2015 technical norm on Open Data for Smart Cities,22 and the development of the open data guide by the Spanish Federation of Municipalities and Provinces (FEMP) in 2017 [8] and the catalogue of high-value open datasets for cities in 2019 [9].

Domains that have been addressed in these initiatives include public sector, demography, environment, economy, commerce, transport and treasury, among others. As part of the initiatives and projects that have led the advancement of open data among cities in Spain we can cite the Ciudades Abiertas33 project, a public-private collaborative project led by four Spanish municipalities (Zaragoza, Madrid, Santiago de Compostela and A Coruña) with the general aim to facilitate the implementation of common Open Government policies that are reusable by many other municipalities inside and outside Spain.

Among the project actions on open data, several (12) ontologies are being developed using the Linked Open Terms (LOT) methodology [5,17]. These ontologies allow publishing Open Data homogeneously across cities, using common CSU structures, as well as following Linked Data principles [29]. They are being added to those that had been already developed in the context of the Spanish network of Open Data for Smart Cities,44 and they correspond to a subset of the catalogue of datasets included in the aforementioned FEMP open data guide [9]. All of the ontologies are publicly available and versioned in GitHub,55 with the corresponding repositories including use cases and user stories, requirements, the ontology implementation in OWL, the ontology HTML documentation in Spanish and English, and example data and queries.

In the area of transport, three ontologies have been developed so far under the umbrella of these initiatives, focused on the representation of open data about Public Bicycles, Motor Vehicle Traffic and Public Bus Transport. In this paper, we will discuss the latter, an ontology that has been specifically developed for structuring how to publish open data about public buses in cities, beyond the current publication as GTFS feeds (Google Transit Feed Specification) as well as using ad-hoc formats and APIs. We have named it the Public Bus Transport ontology (http://vocab.ciudadesabiertas.es/def/transporte/autobus). Its corresponding GitHub repository with all the intermediate and final artefacts is available at https://github.com/CiudadesAbiertas/vocab-transporte-autobus including a Readme in English.66

The scope of this ontology on public bus transportation is focused on the representation of static information related to lines, routes, stops and timetables, and real time information on expected arrival times to bus stops. Having this data on public buses (extensible to other means of transport) is a very valuable element for municipalities and citizens, as well as for third parties. Such data is used for the management of services by transport operators, for the use of these services by citizens, and also for the provision of third-party services in different areas such as traffic management, road infrastructure design and trip planning.

One important assumption that we needed to consider in the development of this ontology was the alignment with European policies, in particular the regulation 2017/1926 [3] that states that starting December 2019, any operator or transport authority must offer its data in formats that are compatible with Transmodel [19], the European reference data model for public transport information developed by the European Committee for Standardization (CEN). Transmodel underpins two concrete data formats that have been established for the exchange of transport data: NeTEx [15] and SIRI [23]. The importance of having the Public Bus ontology aligned to Transmodel lies in the purpose of the standard itself: interoperability among transportation systems of different transport agencies and operators thus facilitating multi modal transport and also the use of transport systems across borders.

This alignment to Transmodel has been fulfilled through the application of the Linked Open Terms (LOT) methodology, a reuse-based methodology specifically focused on developing ontologies and vocabularies for the generation of Linked Data. Initially, in a usual ontology reuse fashion, we tried to map the concepts in our domain with those developed in the Transmodel component ontologies, i.e. ontologies in the SNAP project vocabulary catalog [27].

The European SNAP project [24], where the authors of this paper have been also involved, had already developed an initial ontological transposition of Transmodel in order to facilitate interoperability among these formats and other popular formats such as GTFS. There were drawbacks to this reuse process related to the complexity of the SNAP ontologies and to the fact that they are the result of a partial transposition, i.e. the project focused on the GTFS transposition of some concepts in Transmodel and NeTEx. Therefore, we adapted the reuse process in LOT, in order to consider the non-ontological Transmodel UML specification.

Based on the nature of the concepts defined in Transmodel, we divided our ontological conceptualization into three major modules: (1) Agencies, operators and the lines they manage, (2) Lines, routes, stops, and journey patterns, and (3) Planned vehicle journeys with timetables and service calendars. However, the encoding was done as one single ontology file in order to simplify its publication and future maintenance.

Because of the complexity of the conceptual design, we set ourselves to generate by hand RDF examples of real-world data annotated with the ontology concepts, which could be used for ontology validation purposes. Additionally, as part of the LOT methodology, RDF data were generated automatically taking as input the GTFS feed provided by the Madrid public bus transport provider (Empresa Municipal de Transportes de Madrid). Data transformations were expressed using RML mappings [20], and materialised into RDF, and SPARQL queries corresponding to the competency questions were tested.

The main contributions of this work can be summarized as follows:

In the next sections we describe related standards and vocabularies for the transportation domain, and preliminaries on the SNAP project and the LOT methodology. Following, we describe our adaptation of the LOT methodology and its application to our use case. The next section describes in detail the three modules of the Public Bus Transport ontology. Then we describe the alignment to Transmodel and the challenges encountered, and finally we give our conclusions and future lines of work.

2.Related work

This section provides an overview of relevant data standards and vocabularies for the representation and exchange of data in the domain of transport.

2.1.Transport data standards

This section describes two well-adopted standards for the representation of transport data, the GTFS standard and Transmodel.

2.1.1.GTFS

The General Transit Feed Specification (GTFS) [16] is a de-facto standard developed by Google and split into a static component, GTFS Static, and a real-time component, GTFS Realtime, that contains arrival predictions, vehicle positions and service advisories. It has become popular due to its simplicity and to the fact that it has been adopted not only by Google Maps, but also by other route planning systems such as Open Trip Planner, or Navita.io.

GTFS Static was developed for sharing the transit static information on agencies, routes and their stops, schedules, fares, among others. The specification defines the headers of seventeen CSV files. In particular, Madrid’s transport authority (CRTM) and Madrid’s public bus operator (EMT) provide a GTFS feed that includes information on all of the entities except for Fares. The most recent data is of April 2020.

2.1.2.Transmodel Data Model

The Transmodel European Reference Data Model for Public Transport, from now on denoted as Transmodel, has been developed in the context of the Directive 2010/40/EU [3] on the framework for the deployment of Intelligent Transport Systems (ITS). In particular the priority action A includes the definition of the necessary requirements to make EU-wide multi-modal travel information services accurate and available across borders to ITS users. This includes the availability of existing and accurate multi-modal transport data, and the facilitation of electronic data exchange between public transport stakeholders.

Transmodel provides a complete and extensive set of related concepts that covers diverse aspects of Public Transport information for different transport modes. The standard covers concepts on eight sub-domains [19]: Network, Timing Information, Vehicle Scheduling, Operational Monitoring and Control, Fare Management, Passenger Information, Driver Management, and Management Information and Statistics. The connections among these sub-domains are shown in Fig. 1.

Fig. 1.

Sub-domains of the Transmodel ontology, their relationships and associated standards.

Our Public Bus Transport ontology covers agencies, operators, lines, routes and their stops, timetables, and arrival times. It does not cover passenger, driver or fare information, nor operational monitoring and control or management statistics. Thus, we will describe the main concepts represented in the Network and in the Vehicle Scheduling, and the Timing Information sub-domains.

The Network sub-domain [26] represents the topological descriptions of the spatial structure of a public transport network which is built with points. An entity Point is defined as the most basic entity of the network model. It marks the location of bus stops, parking places or other types of points. Links represent 1-dimensional connections between points. An ordered set of points or links is called a Link Sequence. These are the generic building blocks of the Public Transport network model. Their specialisations represent concrete special Public Transport objects, like scheduled stop points, routes, journey patterns, among others.

The Timing Information and Vehicle Scheduling subdomains [26], represent a Vehicle Journey to describe the movements of a transport vehicle from the start point to the end point of a journey pattern on an operating day. Among the common concepts that cut across the subdomains are the ones related to organisations [26], as different aspects of public transport could be handled by different organisation parts, and sometimes are subcontracted to third parties.

2.1.3.Transmodel UML specification

The current Transmodel UML specification is the revised V6.0 version (http://www.transmodel-cen.eu/model/index.htm). It has been divided into eight packages, seven of these packages correspond to the sub-domains enumerated above, Timing Information and Vehicle Scheduling have been joined into one package. Besides these packages, there is a Common Concepts package [26] that covers concepts that are shared by the different functional domains. Models in each package are subdivided into more specific sub-models up to three levels. We would like to point out that time-related concepts are represented in the Service Calendar sub-model in the Common Concepts package, in the Tactical Planning Components sub-model in the Network Topology package, and in all of the sub-models in the Timing Information and Vehicle Scheduling package. This gives an idea of the extension and complexity of the specification.

Our Public Bus Transport ontology is aligned to concepts in the Network and the Vehicle Scheduling and Timing Information packages. Additionally, regarding the Common Concepts package, it is aligned to concepts in the Responsibility, Generic Framework, and Reusable Components models.

3.Preliminaries

This section describes the initial effort made within the SNAP project for the development of an ontology based on Transmodel and the general stages of the LOT methodology used for our ontology development activities.

3.1.The SNAP project. Semantic National Access Point

The European regulation 2017/1926, requires each European Member State to set up a National Access Point (NAP), for multi-modal travel information for all transport modes. Each transport stakeholder, should contribute to the NAP with their static and dynamic data, using a set of standard data formats identified by the regulation and based on the European Standard Public Transport Reference Data Model, i.e., Transmodel. Specifically, concerning the exchange of static scheduled data, the relevant data in the NAP should use the CEN data exchange standard NeTEx [15]. For the exchange of real-time public transport data, the relevant parts of the CEN public transport data exchange standard SIRI [23] are used.

The SNAP project developed a solution for transport stakeholders that need to convert their data into formats required by the regulation. The proposed solution, based on Semantic Web technologies, implements data conversion, meanwhile, supporting the constitution of a knowledge graph of multi-modal transport data [22]. The SNAP converter adopts a reference ontology as a global conceptual model enabling a two-step conversion between two standards in the transport domain: first, from the input standard to the ontology, and then from the ontology to the target standard. To enable this solution, the SNAP project kick-started an effort to define an ontological transposition of Transmodel,1010 as the reference ontology used in the conversion process.

As already mentioned, Transmodel is a really large and complex model. The SNAP project, to start validating the proposed solution, implemented a first version of the ontology focusing on a portion of the overall specification. The initial modules of the Transmodel ontology have been defined to enable the conversion of a static GTFS [16] feed, widely adopted among transport stakeholders, to NeTEx, the required standard by the European regulation. Given that NeTEx is almost a serialization of Transmodel, the GTFS specification has been used to identify the relevant portion of Transmodel that should be prioritized in the ontology engineering process.

The Transmodel ontology currently defines five modules, shown in Fig. 2, that cannot be directly mapped on the presented Transmodel sub-domains, but reuse their terminology to define concepts and properties. To obtain a proper ontological transposition, the implemented modules integrate newly defined entities with already available vocabularies (e.g., the Organization ontology,1111 the Geo WGS84 ontology,1212 etc.). The Commons module defines general concepts and properties that can be reused across all the other modules. The Organisations module can be used to describe different information about entities operating and/or offering transportation services. The Journeys module can be used to represent data related to a transportation service, e.g., time tables, routes, vehicles and their scheduling, etc.. The Facilities module contains concepts and properties to describe facilities and, in particular, stations and stop places. Finally, the Fares module contains a simplified model for information about fares, that needs to be extended to support the full related Transmodel sub-domain.

Fig. 2.

Initial modules of the Transmodel ontology and their relations.

3.2.LOT methodology

LOT is a lightweight methodology for the development of ontologies and vocabularies [17]. It is based on the previous NeOn methodology and includes the following four major stages that can be seen in Fig. 3: (1) Requirements Specification, (2) Implementation, (3) Publication, and (4) Maintenance.

Fig. 3.

Linked Open Data Methodology (LOT) stages.

The aim of the ontology Requirements Specification stage is to identify and define the requirements the ontology should fulfil [5]. At the beginning of this stage, the goal and scope of the ontology is defined, following this, the domain is analyzed in more detail by looking at documentation, data that has been published, standards, formats, among others. Also, the use cases and user stories are identified. Then, the requirements in form of competency questions and statements are specified and validated by the stakeholders.

The goal of the Implementation stage is to build the ontology using a formal language, based on the ontological requirements identified by the domain experts [5]. This stage is iterative through several sprints and it is comprised of the Conceptualization, Encoding, and Evaluation processes. During the conceptualization process, an ontology model is built and represented in a graphical language. We follow the Chowlk visual notation1313 that “provides a set of visual blocks to represent each element from the OWL ontology implementation language…”.

One of the activities of the implementation stage is ontology reuse. LOT is based on the NeOn methodology which develops nine scenarios for the development of ontology networks. Among these scenarios there is Scenario 3 on reusing ontological resources. In this scenario, ontology developers reuse ontological resources (ontologies as a whole, ontology modules, and/or ontology statements). Developers search, assess, compare, select, and integrate the ontological resources. Terms that have been extracted from the requirements, that correspond to entities and relationships, may be used for searching existing ontologies that cover these concepts. Scenario 2 considers the reuse of non-ontological resources (NORs), it is meant for the transformation of mostly textual NORs with underlying low expressiveness models such as thesaurus, classification schemes, etc.

In the Encoding process, the ontology development team generates a computable model represented in the OWL language. The Evaluation process includes two aspects: (1) ensuring that the requirements are fulfilled; this is done through the translation of the competency questions into the corresponding SPARQL queries, and executing these queries against RDF test data that has been annotated with terms in the ontology, (2) guaranteeing that the ontology does not have syntactic, modelling or semantic errors. The syntactic validation may be done with any existing OWL validator tool, and the semantic and modelling evaluation is done by running an OWL (DL) reasoner, and by discovering modelling pitfalls. Currently, we use the OOPS! tool [18] for this task.

The aim of the Publication stage is to provide an online human-readable documentation which generally includes metadata (e.g. creators, contributors, creation date, version), a description of the conceptual model diagram, and all of the class and property restrictions and annotation properties. The ontology and all of its associated documents are usually published as a public repository. The Maintenance stage includes updates to ontology requirements that were not originally identified, and improvements, which in consequence may trigger another ontology development iteration.

4.Adaptation of the LOT methodology

The description of the adaptation of the LOT methodology is focused on the ontology Implementation stage, specifically we have adapted the activities of conceptualization, ontology reuse, and evaluation in order to carry out the alignment to Transmodel.

For the Public Bus ontology, the reuse includes ontological as well as non-ontological resources (the Transmodel UML specification, the glossary of Transmodel terms and the NeTEx Schema). We have also extended the Evaluation activity and have included an additional form of evaluation, that is, the validation through RDF real-world examples. The adaptation of the Implementation stage can be seen in Fig. 4.

Although LOT is based on the NeOn methodology, because it is a lightweight methodology it only considers the reuse of ontological resources [5,17]. Besides this, non-ontological resources considered in “Scenario 2: Reusing and Re-engineering Non-Ontological Resources” in the NeOn [25] methodology refer to low-expressiveness resources; in this case there was reuse of a very rich and expressive non-ontological resource.

Fig. 4.

Public Bus Transport Ontology. Adaptation of LOT Implementation Stage. The “Ontology reuse” activity is expanded and the “Evaluation through Examples” has been added to the Evaluation activity.

For the Public Bus Transport ontology, we developed an initial conceptual model without reuse of Transmodel, which satisfied the requirements identified in the first stage of the methodology. Next, in the reuse activity, under the scenario 2 of reuse of ontological resources, we initially tried to map the concepts in the initial conceptualization with those developed in the Transmodel component ontologies, i.e. ontologies in the SNAP Vocabulary catalog [24]. We reused some of the concepts in these component ontologies such as Transmodel Organisations, but were not able to reuse the rest of the ontologies in the SNAP catalogue. The main drawbacks were that some of the component ontologies are quite large and complex because they encompass several of the models in the original UML specification (e.g. the Journeys ontology) and also some classes, attributes and implicit constraints of the UML specification (e.g, cardinality, optionality) were not developed: the SNAP ontologies contain those concepts where there exists a mapping from the GTFS feed specification to Transmodel.

Because of these drawbacks it was necessary to resort to scenario 2 of the NeOn methodology that covers the reuse of non-ontological resources (NORs), in this case the reuse of the UML Transmodel specification. To this effect, the NeOn methodology [25] defines a re-engineering pattern which is comprised of three main activities: (1) NOR reverse engineering to create an abstract representation of the resource, (2) NOR transformation to create the ontological model, and (3) Ontology forward engineering to generate an implementation of an ontology. Although these activities are meant for the transformation of NORs such as thesaurus, classification schemes, lexicons, etc., they can be applied to semantically richer UML specifications. For UML specifications there is already an abstract representation of the resource, so step (1), reverse engineering, is not required. NOR transformation implies translating the UML representation to an ontology representation, and Ontology forward engineering consists in the implementation of the relevant parts of the reused resource. It should be mentioned that although we reused the UML specification, prefixes and entity names that are defined in the Transmodel ontologies were used in our conceptualization.

Additionally, because of the complexity and sometimes contrived conceptual design, we set ourselves to generate examples of real-world data annotated with the ontology. In the LOT methodology these examples are part of the Publication stage. However, they were used during the evaluation activity to validate with the public transport experts if the Transmodel concepts included in our ontology did in fact represent our specific Public Bus Transport domain. This verification triggered some adjustments on the ontology conceptual design.

5.Public Bus Transport Ontology Development

In this section we will describe the application and results of the LOT stages and activities.

5.2.Implementation

The implementation stage includes the activities of ontology conceptualization and reuse, encoding, and evaluation.

5.2.1.Conceptualization and reuse

The conceptualization is aligned with the ontology design principles defined in [28] as follows:

• – Clarity. Documentation is provided where all of the classes and properties are described with extensions to the description of these concepts in the Transmodel and SNAP documentation. Examples from the city of Madrid are included in order to make the documentation clearer.

• – Coherence. The ontology is coherent in its natural language documentation and also in its logical axioms, as shown by the results of the reasoner execution.

• – Extensibility.The ontology has been divided into three major and intrinsically cohesive parts. Extending this ontology with other sub-domains of public bus transport such as Fares is feasible and would require to align it with Transmodel using our LOT adaptation and to interconnect its classes with existing classes in the rest of the ontology.

• – Minimal ontological commitment. This guideline is related to extensibility and in this ontology it is followed. The idea is that the representation of the domain should cater to the needs of different users, in our case it is a shared conceptualization among different municipalities in Spain that are representative of cities of different size and also with diverse types of transport requirements. Additionally, whenever there are properties that are not shared by all the cities, these are defined with no minimum cardinality restrictions.

• – Minimal encoding bias. The ontology is represented in a graphical notation and shared and discussed with the municipalities and experts before it is encoded.

The color code and graphical notation for the conceptual diagrams as well as the ontology namespaces can be seen in Fig. 5. An initial conceptualization model was developed with reuse of the GeoSPARQL [10] ontology to represent the stop location as a Point, and of the https://schema.org/ Organization class and properties. The model covers roughly the main entities and relationships in the requirements as can be seen in Fig. 6. It should be noted that in case of following a no-reuse approach, this model would have needed further refinement in order to cover aspects of the requirements such as different route patterns, timetables, and expected arrival times.

Fig. 5.

Namespaces and Graphical Notation for the Ontology Conceptual Models.

Fig. 6.

Public Bus Transport Ontology. Initial Conceptual Model.

In a next step we mapped concepts in our domain to those in the following ontologies:

• – The GeoSPARQL [10] ontology’s Location pattern to represent the stop location, specifically its Location pattern that has a Feature class, i.e. the entity that has a location, related to Geometry, which in turn is related to the Point class for the representation of the location coordinates.

• – Schema.org [21] which is a general vocabulary for structured data on the Web. We reuse its ContactPoint class and properties for contacts in the organizations involved in public bus management, and also several other attributes such as startDate, endDate, name, and url.

• – The dcterms vocabulary [7] which is maintained by the Dublin Core Metadata Initiative. Terms identifier and description are reused.

• – The SOSA ontology [13] where the property resultTime was reused in order to represent the arrival time of buses as observations related (hasFeatureOfInterest) to the stops where they arrive in each route.

The next activity in this stage involved the reuse of the Transmodel ontologies developed in the SNAP project as well as other reference ontologies. A first attempt to reuse these ontologies resulted in a very large and complex conceptual model. At this point we divided the ontology into three modules that correspond to its sub-domains: (1) Bus organisations and management, (2) Bus routes and journey patterns, and (3) Bus planned vehicle journeys. Each of these modules has a high degree of cohesion, i.e., most of the classes and properties belong together in the same module.

Part I – Bus organisations (Base Model)

This portion of the ontology represents an overview of the organisation and management of public bus transport in cities. This conceptualization covers the following information:

• – Bus operators and the authorities they serve to.

• – The lines that they manage together with their graphical “presentation’.

• – The routes made by each line (journeys and timetables are expanded in the other parts).

• – Incidents for which we reuse the Traffic vocabulary1616 developed in the context of the Ciudades Abiertas project.

• – Reuse of SNAP Organisations ontology (tmorg).

• – Reuse the Transmodel Line concept, however, a subclass esautob:Line was created to relate the line to the incidents that affect it.

The conceptual model is shown in Fig. 7.

Fig. 7.

Public Bus Transport Ontology. Organisation Conceptual Model (Base Model).

Part II – Bus routes

We followed the steps described in Section 4 for the reuse of the non-ontological Transmodel UML specification: (2) NOR transformation to create the ontological model, and (3) Ontology forward engineering to create an implementation. The ontological graphical representation (step (2)) of parts of the Line Network and Route sub-models of the UML specification can be seen in Fig. 8; this step was necessary to ensure the correct (semantic) reuse of these concepts. We then integrated this partial model into the complete conceptual model (step (3)) that is shown in Fig. 9.

Fig. 8.

NOR Transformation of Transmodel UML Network building blocks: points, points in link sequences and link sequences.

Fig. 9.

Public Bus Transport Ontology. Route, Journey Pattern, Stop Conceptual Model.

The conceptualization of this module includes the following:

• – Reuse of the Transmodel Line concept. Again, the subclass esautob:Line is defined in order to relate the line to the stops at the beginning and end of the line.

• – A line is made up of several routes, and each route is composed of a series of points on the route, each point in the route is associated to a point that is the functional centroid for a certain place, i.e. the point represents the centre of the bus stop.

• – We defined a class for stop, esautob:Stop, as a subclass of Place, due to the need to represent data and object properties that are very specific to this domain.

• – We relate the stop to the postal address; we reuse the existing Postal Address ontology.1717

• – The location of the stop is represented through the GeoSPARQL geolocation pattern (this was also part of the initial conceptual model).

• – Each route may have several journey patterns, requirements state that stops may vary for example during weekends, and a different journey pattern may have been generated by an incident.

• – For expected stop arrival times, we reused the SOSA ontology [13] in order to represent the arrival times as observations.

Note that the Journeys ontology prefix (tmjourney) and its entity names were reused. An example of RDF data for this model where there are two journey patterns is shown in Fig. 10.

Fig. 10.

Example of Lines, Routes and Journey Patterns. There are two journey patterns for route 138a, the second journey pattern was generated by an incident and has changed its first stop.

Part III – Bus vehicle journeys

This part presented in Fig. 11 represents the planned vehicle journeys and its service data (timetables). Similarly to Part II, we represented the corresponding portions of the UML specification in our graphical notation, and then integrated this partial model into the conceptual model. The following information was represented in this module:

• – A vehicle journey follows a certain journey pattern and can be made in one or more day types such as a holiday or weekday.

• – A service calendar has beginning and ending dates, and each day in the service calendar is associated to a day type. Thus, on a certain date, the information on which vehicle journeys are planned for that date may be extracted from the model.

• – Each vehicle journey, because it is frequency-based, is associated to a headway journey group which is determined by minimum, maximum and planned headway intervals.

This module mainly reuses the tmjourney prefix.

Fig. 11.

Public Bus Transport Ontology. Vehicle Journey Conceptual Model.

5.2.2.Encoding

Once the reuse activity was completed, we encoded the ontology using the Protegé tool.1818

5.2.3.Evaluation

We used the OOPS! tool to evaluate modelling pitfalls. The report is shown in Fig. 12. Results indicate several pitfalls related to properties in reused ontologies that do not define domain and range. Another group of pitfalls indicates that inverse properties have not been declared; again, this is not critical unless it is required for querying the annotated datasets. The complete OOPS! report1919 is available in the GitHub repository. The Hermit reasoner2020 was executed determining that the ontology is consistent.

Fig. 12.

Evaluation Report Generated by OOPS!.

Next, we developed a few real-world examples that allowed us to validate if the model is adequate for representing the data in our domain. This was specially important for the concepts of Route, JourneyPattern and VehicleJourney. With these examples we determined the need to simplify the third module on bus vehicle journeys.

Finally, as part of the LOT methodology, directed-by-data evaluation was carried out, i.e., evaluation through semantified data real-world examples that aims to test the ontology against the competency questions. RDF data was produced using (CSV to RDF) RML mappings that were generated with the Mapeathor tool [12], a tool that eases mapping rules creation by using a spreadsheet for the specification. Source data was the GTFS feed provided by the Madrid Regional Transport Consortium. Once the mappings were generated, we constructed several knowledge graphs (KG) using the RDFizer tool [11]. Again the mappings and KG were divided in correspondence with the three modules. Examples of the input to Mapeathor, the mappings, and the KG are presented in Fig. 13. SPARQL queries that correspond to the competency questions were developed. Queries can be tried out through the GitHub repository.2121 The examples generated by hand to validate the ontology and those generated thorugh mappings are available in the GitHub repository.2222

Fig. 13.

CSV to RDF mappings specified in Mapeathor.

6.Alignment with Transmodel

In this section we describe the main challenges encountered in the development of the Public Bus Transport ontology and we give details on the alignment with the Transmodel UML specification. Table 1 presents the challenges and solutions.

Globally, challenges are related to taking a UML model and transforming it into an OWL ontology, which although it may seem as a straightforward process it is not so: UML models do not encode all the needed elements to address the domain restrictions and are not necessarily consistent (as it happens in TransModel). Additionally, the reused resources were developed under different perspectives of the domain (Transmodel, NeTEx and SNAP), each with its own documentation, glossary of concepts and implementations. Therefore, when we deal with ontologies that cover specific aspects of this broad domain, we come across with issues like breadth of documentation, over-representation, and ambiguity. Details of the alignment to the UML Transmodel specification follow:

7.Conclusions

In this work we have presented an ontology for the representation of data about public buses operating in cities. This ontology is aligned to the Transmodel reference model. For this development we followed the LOT methodology and adapted the Reuse activity to the scenario of reuse of non-ontological resources, in our case the Transmodel UML specification.

Although the Open Cities project did not require this alignment we considered it as an added value, due to the fact that such an alignment may facilitate the generation of Transmodel-compliant data in the future, as required by the corresponding EU regulation. The ontology development team had also participated in the development of the initial version of the Transmodel ontology in the context of the SNAP project. Therefore, both the complexity of the UML specification and the early state of development of the SNAP ontologies were known beforehand and were an advantage to the development of the alignment.

In order to identify the Transmodel concepts that represented the requirements, we followed a bottom-up approach where we identified the concepts through the Transmodel glossary, and then we built the graphical representation of these concepts by examining portions of the UML models and submodels, and building our conceptualization. This may be a useful experience for other ontology developers in this or other domains who wish to address similar ontology development problems.

Future work includes improving the ontologies originally developed in SNAP with updates to existing concepts from Transmodel, as well as adding other classes and associations from the specification that were not developed in the initial version of those ontologies. Additionally, we suggest dividing the encoding of the Public Bus Transport ontology into the three portions that were conceptualized and presented in this paper.