Interdisciplinary analyses are prone to misunderstandings associated with rich discipline-specific semantics. The research of low-carbon energy systems is an example of such applications where concepts coming from multiple expert groups collide. One relevant case is the transport-energy nexus where 'sector coupling' analyses are performed. In this context battery electric vehicle charging infrastructure comprises a main point of interaction between both research disciplines. Ontologies like the Open Energy Ontology (OEO) were conceived to aid in the concretization of agreement in such interdisciplinary research. However since it is a tool whose focus is energy systems research, it falls short in concepts associated with transportation research. In this paper, we propose a FAIR Ontology, which should work as a first interoperability layer between ontologies and data models intending to represent concepts associated with battery electric vehicle charging infrastructure. We rely on the Basic Formal Ontology (BFO) as top-level ontology, to ensure compatibility with OEO. We develop this ontology using a methodology inspired by the OEO with a stricter requirements engineering approach. This methodology relies strongly on motivating scenarios and competency questions to keep the ontology slim. Current achievements are a documented development environment, the implementation of core terms like charging station, and the reutilization of existing ontology terms coming from ontologies like the OEO, the Common Core Ontologies, and the iCity Transport Planning Suite of Ontologies.
Energy systems analysis is a discipline where specialized software tools are used to study
the development of possible future energy systems. One modern example of such studies
is [
In this paper, we propose the theoretical basis and development plan of an ontology that
should allow us to represent concepts associated with the process of charging an electric vehicle
from the point of view of energy systems analysis and a transport research. The rest of this paper
is divided into six sections. Section 2 consists of the justification, philosophy, and approach for
the designing of an ontology that allows the description of concepts and phenomena associated
with the charging of battery electric vehicles, we also use this section to introduce the Basic
Formal Ontology (BFO) [
The need for an ontology that represents entities and phenomena associated with charging
infrastructure was identified first during the process of implementing the FAIR principles on
the data published by the German Federal Network Agency [
Katsumi and Fox [
There are some other vocabularies and models that deal with charging infrastructure, but
most of them are constrained by their specific applications, as they prescribe what would be
expected from the data models produced out of them. Relevant examples are the vocabularies
provided by standards such as the Open Charge Point Protocol (OCPP) 2 and the ISO 15118,
such standards despite their widespread use in the industry have strict copyright licences which
can hinder the reusability of their contents. Another important mention is the work from [
Top-level ontologies or foundational ontologies intend to model domain-neutral categories and
relations [
BFO sacrifices expressivity for a simpler modeling intuition. It has weaknesses in the field of modal propositions which are prominent in both transportation research en energy systems analysis, particularly in the context of forecasts and simulation3. Unlike the TPSO foundational modules, BFO delegates its time indexing to the applications by keeping it outside the OWL implementation. The perdurant component of entities is handled by pointing to their ‘history’, a practical and versatile construct. BFO has a rather simple initial learning curve that can be used to facilitate the inclusion of new developers. But still becomes steep when dealing with some of its more complex terms (i.e. ‘process prolfie’, ‘disposition’ vs ‘quality’), this can lead to frustrations and misuses.
There are some important features of BFO that we intend to take advantage of. The first is that it allows the existence of ‘sites’ in the same dimension as ‘material entities’. This is because 2https://openchargealliance.org/protocols/open-charge-point-protocol/ 3However this weakness is addressed by CCO with their ModalRelationOntology which we consider importing. charging events depend on the dynamics of vehicles being present and absent. We also need these entities to characterize the mereotopology of charging stations which usually consider parking spaces as their parts which in place can be part of parking lots along other parking spaces. To address this, we will rely on reinterpreting the axioms from the TPSO in the context of BFO, in a future stage we intend to explore the possibility of unintended models (i.e. a vehicle becoming infrastructure). A second important feature is the concept of ‘process profiles’ since we consider that the charging event can have multiple dimensions that can describe it that have to be associated with each other. Using those we can describe events by virtue of their occupancy, power rates, and energy transfers among other characteristics.
One of the key aspects of FAIR ontologies is that they are reusable and profit from the reusability
of existing ontologies [
The OEO has been in active development since 2021 with several releases since then. It exists to
address a technical gap associated with knowledge management in the field of energy systems
analysis. Said gap is the lack of common semantics to annotate and share datasets and tools
associated with the mentioned discipline. One of the characteristics that make this and other
FAIR ontologies transparent and accessible is the fact that it is being openly developed in a
shared repository4. An important work on the inclusion of concepts coming from the transport
sector was performed by Mittermeier [
In our charging infrastructure ontology, we need a way of describing vehicles, particularly electric vehicles. The OEO has a rich taxonomy of vehicles. This taxonomy has two parallel ramifications, one associated with its energy consumption mode like ‘electric vehicle’, ‘internal combustion vehicle’, and ‘gas turbine vehicle’ and another associated with its operational medium such as ‘land vehicle’, ‘aircraft’ or ‘watercraft’. The former has axiomatization significant for electric grid and energy systems models which can be seen in figure 1(b) the latter has no own axioms and relies mainly on the former. For our application is only interesting to use the taxonomy of electric vehicles, which should include plug-in hybrid electric vehicles (Figure 1(a)). Its land vehicle taxonomy is rich (figure ??) and contains elements that might produce conflicts with any future implementation in a transport ontology. Because of this, we rely on the Common Core Ontologies (CCO) for a lighter vehicle taxonomy. 4https://github.com/OpenEnergyPlatform/ontology
grid supplied electric vehicle electric vehicle fuel cell electric vehicle battery electric vehicle electric vehicle
The CCO are twelve mid-level ontologies built as an extension of BFO and the Relations Ontology (RO) intended to be used as a basis to model domains of interest such as transportation infrastructure and spacecraft [16]. Like BFO, it is a realist ontology, which means that it intends to model the entities data represent. The ontology avoids being prescriptive and instead lets data modelers decide which asserted class axioms are relevant for their particular applications. It also comes with a guide that lets non-ontology experts understand how to implement terms which is helpful to involve domain experts of other fields in ontology development. We extract multiple terms, taxonomies and some axioms from these ontologies. These are explained in the rest of this section.
From the ‘Artifact Ontology’ we extract terminology associated with vehicles. We consider that they ofer a more manageable and expandable taxonomy of vehicles that can be utilized across diferent fields of application. The OEO classifies vehicles based on their energy consumption which is practical for their applications but, since we are not interested in non-electric vehicles, these become superfluous. Another reason to use the ‘Artifact Ontology’ axiomatization is to profit from the other declarations coming from the same suite of ontologies. The top upper levels of both taxonomies are slightly diferent besides both using BFO. The OEO classifies vehicles as ‘artificial objects’ whereas the CCO as ‘material artifacts’. The lower levels, despite being developed independently, are so similar that they are practically already interoperable.
The CCO ofers a construct that aids in classifying ‘material artifacts’ as infrastructure. It uses what in BFO are called ‘roles’. This allows arbitrary assignment of the class. This is practical to us because charging stations in reality are not always infrastructure, they are only in virtue of the agents who assign them this role. In this sense, a home wall box is not infrastructure for a government agency but a public column is. Infrastructure rarely comes as units but as complex aggregates of ‘artifacts’, this is the way we opt to import the concept of ‘infrastructure system’. These axioms can be visualized in figure 2.
Equivalence restriction
Infrastructure
Element
bearer of Infrastructure
Role material entity
Infrastructure
System Transportation Infrastructure
We also import terms from the facility, information entity, and geospatial ontologies. We use the facility ontology to handle concepts like parking lots and dedicated charging stations. An alternative would be to stick to using material entities, but we consider this diferentiation practical in the long run. The information entity ontology provides us with the ‘designates’ relation which the CCO recommends using to designate geospatial data to entities. The geospatial ontology provides terms like city and continent which we use to manage addresses.
The TPSO has a module for terminology associated with parking which provides concepts like parking spaces, areas, and fees. It also ofers axioms for charging stations, but these are too shallow for our applications as they are at most features of parking spaces. The subclassification of charging stations are ‘standard’, ‘medium’, and ‘fast’ which are based on the definitions of some ‘Environmental Protection Department’ whose source was not explicitly pointed. Whether having such a classification is meaningful to our applications is yet to be defined. The TPSO has its own top-level ontology modules which supply axiom definitions for change, mereology, and time. These modules are incompatible with the BFO. The Change module of the ontology relies on the utilization of a four-dimensional approach to model time-changing concepts. This means that every object has a perdurant and its manifestations bear their changes. Since we are not intending to axiomatize time relations in OWL and instead delegate that to data modelers we opt not to share that approach. BFO handles descriptions of change diferently, this will be addressed in its respective section. Some axioms that are interesting to us from the TPSO Parking ontology, excluding mereology of parking areas, can be visualized in figure 3. Our approach to reutilize them consists of doing an implementation using BFO and then adding mappings to this ontology.
Equivalence restriction
ICP:ParkingArea ICC:manifestationOf ICC:hasManifestation
ICP:hasEVCharger ICP:ParkingAreaPD
ICP:ParkingSpace
ICP:EVCharger ICP:GreenVehicleParkingSpace
ICP:QuickEVCharger
ICP:StandardEVCharger
ICP:MediumEVCharger ICP:EVParkingSpace
ICP:hasParkingPolicy
ICP:EVParkingPolicy
The ontology development loop is inspired by the open collaborative development of the OEO developing team. This consists of having user needs, stated in public issues, as the primary driving force of ontology development. This was not decided based on some detailed evaluation of ontology development methods but on the positive experience and satisfactory results that manifest in the OEO’s relatively consistent release cycle. The main diference consists of a stricter approach regarding new terminology coming into the ontology. Instead of implementing single terms per request, we will expect users and developers to either adjust their proposed terms to existing applications or propose a new complete motivating scenario. This is to overcome scoping issues that often arise during the development of OEO.
Motivating scenarios are descriptions of potential real or theoretical applications of the ontology which comprise the kind of questions that the ontology is intended to address. They were first proposed as a method used for the Toronto Virtual Enterprise (TOVE) ontology development [17]. We take inspiration from the original approach but adapt it to a modern context where we take advantage of ticket systems and public development based on version control. Competency questions are the smallest component of a scenario and in our development approach they are ifrst-class citizens. The rest of this section will show the first motivating scenarios considered for this ontology along with some exemplary competency questions. Notice that some competency questions are written as statements that can be used as true/false queries in SPARQL or as an entailment test with a reasoner. The enumeration of the competency questions is not sequential, this is intended as they are excerpts of the full list of questions which can be found in the documentation of the ontology5 5https://github.com/dlr-ve-esy/charging-ontology Scenario 1: The charging infrastructure register This scenario is heavily inspired by the German charging infrastructure register [18], and it probably captures most of the requirements of this ontology. The scenario covers terminology and axioms necessary to perform descriptions concerning where infrastructure is found, which power they can deliver and what kind of connector they have.
Competency question 1.0 A public charging station is a kind of transportation infrastructure.
Competency question 1.5 A charging station has commissioning and decommissioning dates which delimit its lifetime.
This scenario is an extract of the iCity project by Katsumi and Fox. Particularly the section smart parking applications [19]. These are selected examples of the subset of questions relevant to us. They are interesting because charging infrastructure is intimately connected with parking infrastructure. These queries are mostly geographical and may overlap with scenario 1, but they have a perspective more in line with the daily operation of the stations. For more details on the ontology visit its repository6.
Competency question 2.6 How many parking spots are designated for electric vehicles in a particular parking lot? Competency question 2.7 What types of electric vehicle chargers are available in a particular parking lot?
Being at an early development stage, the ontology is in the process of being implemented. At the time of this publication the ontology has an open git repository7. This repository has developer documentation where the motivating scenarios along with their competency questions are written. For the ontology documentation and the IRI resolution, we are still exploring solutions. We are tending towards Widoco8.
We implemented a test suite that allows the incremental development of the ontology using competency questions. This suite classifies the queries into two types. Those who act on classes (TBox) like CQ 1.1 and those that act on individuals (ABox) like CQ 2.0. To handle the ABox queries we rewrite the natural language questions as ASK queries in SPARQL that returns either true or false values. We also declare a model in Turtle Syntax that instantiates the referred classes. For example CQ 2.0 is written as listing 5.1 and its corresponding model 5.2 populates the ABox. The TBox questions are evaluated by checking entailment using DL queries such as the one in listing 5.3 which corresponds to CQ 1.1. 6https://github.com/EnterpriseIntegrationLab/icity 7https://github.com/dlr-ve-esy/charging-ontology 8https://github.com/dgarijo/Widoco
ASK WHERE {
SELECT (COUNT(?parkingSpaces) AS ?vehicleCapacity) WHERE { :SomeParkingArea obo:BFO_0000178 ?parkingSpaces .
?parkingSpaces rdf:type chio:CHIO_00000002 . }
HAVING ( ?vehicleCapacity = 2 ) } Listing 5.1: Example ABox query. (Given a parking area with two parking places) What is the (vehicle) capacity of parking lot P? (2). The namespaces are omitted.
:SomeParkingSpaceA a chio:CHIO_00000002 . :SomeParkingSpaceB a chio:CHIO_00000002 . :SomeParkingArea a chio:CHIO_00000001 ; obo:BFO_0000178 :SomeParkingSpaceA, :SomeParkingSpaceB .
Listing 5.2: Example ABox instances. Two charging spaces (that can hold at most one car at a time) are part of some parking area. Namespace prefixes are omitted, the chio namespace refers to the charging ontology.
'charging station' SubClassOf 'parking facility'
and 'has continuant part' some 'charging column' Listing 5.3: Example DL Query used to evaluate TBox competency. A charging station is a kind of parking facility and has charging columns as parts.
Since we aim for a high rate of reusability, most of the eforts have been aimed towards ifnding concepts from existing ontologies. We import the entire CCO version of the BFO which already includes basic RO axioms. We import the excerpts from OEO and CCO mentioned in section 4, we do this by providing scripts that ensure transparency and reproducibility. In some cases, we reimplemented terms and pointed out the ones from other ontologies by using mappings. This was the case for the axioms from the TPSO Parking Ontology (figure 3). Our interpretation of parking areas and spaces is similar, but we rely on the mereology of BFO. Instead of assigning the charging stations to parking spaces directly we opt to use the facility axioms from CCO. These implementations can be visualized in figure 4.
One of the main disadvantages of writing competency questions as queries for most concepts is that implementations are slow. We consider that the benefits outweigh the drawbacks as the outputs are ensured to be concise without much further validation, as the validation occurs during the question definition (think Test Driven Development [ 20]). Sometimes is challenging to come up with competency questions when there are no implementations to refer to. The CCO provides clear documentation that we can turn to in such cases. Another problem is that parking facility parking
area charging station continuant part of the actual software implementation relies on calling java as a subprocess from Python. We are optimistic that thanks to new OWL-aware tools like horned-owl and its respective python embedding py-horned-owl9 we will eventually be able to migrate to a pure python solution.
In its current state, the ontology is not yet ready to be considered FAIR. The first two principles are to a major degree currently beyond the design tasks. To be Findable it needs to be hosted in an indexed repository where it can be assigned a persistent identifier. To be accessible such repository should be callable by HTTPS or similar protocols and have means of preservation of the ontology. Interoperability is achieved by using a widespread format (OWL) and the reutilization of existing ontologies. We enable Reusability by providing licences compatible with the imported ontologies.
Questions on electrification of the transport sector and other research trends have as the ultimate goal to put a stop to climate-change driving carbon emissions. These study fields deal with complex systems whose boundaries tend to difer based on the research questions themselves. These diferences become troublesome when exchanging data because, in most cases, the person producing it is not always available to clarify misunderstandings. Metadata annotations improve this situation significantly, but their content is also subject to interpretation. Ontologies ofer a way of explicitly declaring meta(data) semantics. With this ontology project, we intend to ofer a reference point for communication not only between transport and energy researchers and computer agents developed by them. One of the most important lessons we learned during this work is that reutilization is the most valuable tool we have when developing FAIR ontologies. The ontology development is streamlined thanks to the efort that we invested in testing infrastructure. However, there are some open tasks to make the ontology FAIR and complete. Further activities consist of the completion and live hosting of the ontology. In the future we also expect to use our approach to create, map, and expand ontologies usable for transportation research and cover other niches that are out of the scope of infrastructure ontologies like the OEO, the CCO, and the TPSO. 9https://github.com/phillord/horned-owl, https://github.com/jannahastings/py-horned-owl 978-3-030-61244-3{\textunderscore}18. [16]R. Rudnicki, An overview of the common core ontologies: Documentation, 23 September 2020. URL: https://github.com/CommonCoreOntology/CommonCoreOntologies/blob/ master/documentation. [17]M. Gruninger, M. Fox, Methodology for the design and evaluation of ontologies, Workshop on Basic Ontological Issues in Knowledge Sharing IJCAI-95 (1995). URL: https: //api.semanticscholar.org/CorpusID:16641142. [18]Bundesnetzagentur, Elektromobilität: Öffentliche ladeinfrastruktur (archived), 27 Oct 2023.
URL: https://tinyurl.com/2p95vhh2. [19]M. Katsumi, M. Fox, icity transportation planning suite of ontologies, 2020. URL: https: //enterpriseintegrationlab.github.io/icity/iCityOntologyReport_1.2.pdf. [20]E. S. Arellano Ruiz, U. Frey, C. Hoyer-Klick, Competency questions for a test first development of an energy systems analysis ontology, The Joint Ontology Workshops (2022). URL: https://ceur-ws.org/Vol-3249/paper2-Ensusto.pdf.