June 2026 - In this interview, Sophie Lathouwers (SL) discusses her applied research on data interoperability. Sophie works for TNO, which is an independent research organization in the Netherlands that connects stakeholders in large information ecosystems.
Q: Would you begin with by introducing your background and professional responsibilities?
SL: I began my academic career doing a PhD in a topic unrelated to my current interests. I was researching software verification and other aspects related to software reliability and engineering. While working on my PhD, I tended to get involved in structuring and organizing things. That is what led me to switch topics and continue working on ontologies. Ontologies can be used to define a common language or understanding of a specific domain.
During my studies, I was already thinking about a career in applied research. I looked at research organizations and research departments in business organizations. That led me to a position in TNO’s Data Science department, after obtaining my PhD. Now, my work combines software engineering and ontologies.
Q: For context, what work topics does your department at TNO get involved in?
SL: I work in the Data Science group, which is quite a large one involving nearly sixty people. We are active in several areas, and I will talk about a few to give you an overall sense of what is going on. Some of my colleagues are working on generative AI and building GPT-NL which is a Dutch language model. I am in a different area that focuses more on knowledge-driven AI. Then we have people that try to combine the two in what we call hybrid AI. A shared goal among us is using AI responsibly in real world settings.
Our projects involve a lot of different organizations. We participate in a variety of EU projects. We also work with governmental agencies in the Netherlands. For example, there was a project with the agency in charge of driving tests. We also get involved with B2B projects involving industry partners.
Q: You also participate in the HEDGE-IoT project. Would you describe what the project is about?
SL: Firstly, the name HEDGE-IoT comes from the project title, “Holistic Approach towards Empowerment of the DiGitalization of the Energy Ecosystem” through the adoption of IoT solutions. The project began in 2024 which leaves just over year left for its three-and-a-half-year term. It is a large project with forty-two partners from thirteen different countries, and a budget of about EUR22 million.
The project centers on six pilots. Our pilot in the Netherlands “looks behind the meter” to manage energy consumption and resilience. Let me explain that further. In the Netherlands, businesses agree on a threshold for energy consumption with their energy supplier. There are financial penalties whenever they exceed the agreed level. For the business park, there is therefore an incentive to monitor and manage energy consumption in real time to avoid getting fined. Through our pilot, we used IoT to give the business park visibility and flexibility in how it consumes energy to avoid going over the limit.
Another factor in the project is to use IoT to add resilience to the system. We can achieve this by detecting when anomalies are developing and taking corrective action. You can think in terms of running a digital twin of the business park’s electrical grid and using it for causal analysis. To do that, however, we need to connect all kinds of devices for different uses and from a multitude of suppliers to gain insight into what is happening on the park.
Q: Before going into more detail about your pilot, are there any commonalities across the six pilots?
SL: Yes, all the pilots focus on digitizing the energy grid and optimization strategies. When it comes to grid digitalization, we need to work across organizational boundaries and share data in a trusted manner. This leads us to the concept of data spaces. We are essentially working to establish a data space for Europe’s energy sector so that organizations can share data in a trusted way.
Q: Let us return to your HEDGE-IoT pilot. Would you tell us more about it?
SL: I am going to talk about what we are doing at the Arnhems Buiten business park. There are a lot of different kinds of devices on the park with which we want to extract and share information. For example, we have solar panels from which we collect data through a vendor-specific API. Then, there are electric vehicle (EV) chargers, for which we work with two different manufacturers; they provide information in different ways. Then, there is a building management system and many smart meters. Because of these siloed systems, a business owner that wants insights into their energy usage needs six or seven dashboards to access data from these systems. Even then, they only get a narrow view of their energy footprint.
What we aim to provide is information via a single platform. If our business owner notices a spike in energy consumption, they can trace it to a specific building or device. That is not possible today because data is poorly shared, unless you build custom integrations manually.
For effective data sharing, a necessary step is to annotate the data with semantic meaning. Here is an example of what that means in practice. Instead of processing a data measurement of 22, it would be better to state that the system has a measurement of 22 degrees Celsius for a given floor and room in a building that is at a specific location on the business park. With annotated data, we can exchange data between different devices and different services in a unified manner. That way, business owners do not have to deal with seven or eight different manufacturers or partners, each of which provides data in the format of their choosing.
Q: Is what you describe not straightforward once you bring all data feeds into a cloud or hyperscaler environment and process it there?
SL: I would say that if you are working with one organization, it is easier to bring your data and manage it in a single place. However, it is not straightforward if you want to cross organizational boundaries.
There is also the challenge that organizations do not want to store their data with a competitor. So, that is where you reach the point where a centralized solution is just not what the industry wants to use.
Q: Let us talk about the effort involved in the annotation process. Is it manual and time-consuming?
SL: You can think of an ontology as a data model, which is a standardized way to describe your data. The ontology for a sensing device, for example, contains details of the device’s characteristics, the functions it can execute, and the parameters for measurements it provides.
Now, let me describe the annotation process in terms of accessing data via an API for a known IoT device or machine. First, we would look at what data is available and what data we want to share. Then, we search for available ontologies related to the IoT entity and which parts of the data model are relevant. Next, we would programme a connector to request data via the API and transform that data using the RDF semantic format with reference to the chosen ontologies that we found previously. This is the process we followed for the Dutch pilot and its devices.
Q: To put these ideas into practice, what is your implementation approach for the pilot project?
SL: For the business park system we have been discussing, there are two parts to think about. One is the Knowledge Engine and the other is the Connector(s). The Knowledge Engine provides several reusable software components needed to share data in a distributed network. For example, it has the Knowledge Directory which is essentially the “phone book” that records which information sources are available and what data they can provide.
The Connectors are semantic adapters. They allow users to connect to different services. Connectors function as translators to add the semantic information we discussed earlier. They make the IoT data available, across the network, in a common format and for everyone to use. When a user has a data query, their Connector will look to see if any other organization can supply that data. The Connector will then fetch that data for you.
For the HEDGE-IoT project, we are building the Knowledge Engine, as an infrastructure component that does actual data exchange. That means being able to share data between various kinds of information sources. Communications can take place via an API or Modbus or whichever protocol a user chooses.
One of the challenges is the Knowledge Engine’s reasoning component. This comes into play when a user is looking for data. The Knowledge Engine must decide which sources in the network to contact to provide an answer to the user. This does not just do a straightforward one-to-one mapping but also takes account of the need to contact multiple information sources to answer the user’s question. This topic remains a research challenge and one that has an impact on system performance.
For the pilot implementation, we have twenty-four different devices and services ranging from EV charging points to utility meters, and dashboards. We can add devices progressively as the scope of the system expands. Some devices report on a near real-time basis; smart meters report every minute, for example, while the anomaly detector reports immediately. The energy usage application reports once a day. The system collects about 800 Mbytes of data per day and six million tuples on an average day.
An important principle for the project is to build an open ecosystem. If a building contains proprietary lightbulbs, for example, we want building owners to access the lightbulb data through their Connector.
Q: Did you find that component vendors are willing participate in such an open ecosystem?
SL: Our approach is to contact vendors to request documentation for their encoding protocols. We need to know what data from a sensor means, for example. Is a measurement reading a real-time value or a stored one? What are its units of measurement? Each of these parameters gives meaning to the data which the system needs before it can begin encoding it and programming the Connector.
This approach has mostly worked because we chose to use sub-systems designed for openness. Some companies are very proactive towards the open ecosystem approach. For others, it is not a priority. You discussed this topic with my colleague Laura Daniele who noted that companies are starting to realize the importance of providing semantic data, so the market is starting to change.
Q: What research and industry benefits are you targeting from this work?
SL: We have spoken a lot about the Knowledge Engine, which is available to researchers and industry as an open-source implementation on GitHub.
There is also an important benefit to industry from collaboration and expertise sharing across disciplines. I want to recognize the contributions of other partners who brought a mix of research, consultancy, and manufacturing sector expertise to developing the Knowledge Engine. This group consists of Vrije Universiteit Amsterdam (research), INESC TEC (research), VizLore (research), Arnhems Buiten Electricity Campus (problem owner), Nationaal Crisiscentrum België (user and contributor) and many others.
We hope to have a much greater impact on the energy scene through our partnership with the Linux Foundation where we are collaborating on a semantic energy framework for Europe. For the second part of the system, our vision is to have an App store for Connectors.
Following our Netherlands pilot implementation, we are creating a blueprint that other business parks can follow.
Q: While we have covered many topics, are there additional insights you want to highlight from this project?
SL: Yes, there are two observations I want to add. Firstly, I am a big believer in usability to ensure that technology is easy to use. That is an essential factor in driving industry adoption.
My second point is about the importance of building open ecosystems. This is not specific to the energy domain. It also applies to transportation-sector and industrial applications. If I can connect this back to our work, the Knowledge Engine is reusable across multiple industry sectors; all that remains is to build sector-specific Connectors.
I believe that these ideas will lead us to open ecosystems where all devices are linked and interoperable, with little to no human involvement. Looking at it from the point of view of the electricity grid, I think that this will improve resilience. It will also allow grid users to do new things that were previously not possible due to a lack of semantically enriched IoT data.
Q: What advice would you offer to organizations where semantic interoperability is a part of their future?
SL: It is not as difficult as it looks, and first steps can already be very useful! Start by ensuring that the protocols that you use are clear, preferably based on accepted industry standards. Then, make sure that you document what data is available and what it means.
A next step is then to add semantic information to your endpoint or data such that this information is machine readable. For this you can look at existing ontologies such as SAREF or Smart Data Models.
If you want to dive even deeper, then consider implementing or joining a data space as a standard way to exchange data.
We recognize that these steps might present implementation hurdles for other organizations. There is no ‘Google’ equivalent for finding all the ontologies in existence, for example. An area for future research is to create a methodology and supporting tools that the industry can easily use. We need to improve the usability of an ontology or data model mapping system if we want to drive industry adoption.
Q: How can readers learn more about this initiative?
SL: For those who would like to learn more, here are some useful references:
Introduction to the Dutch pilot: https://www.youtube.com/watch?v=MTnvpVNeYnY
Video about technical details of the Dutch pilot: https://www.youtube.com/watch?v=djvNi0Wl-PI
Open-source Knowledge Engine software: https://github.com/TNO/knowledge-engine and corresponding documentation: https://docs.knowledge-engine.eu/
Semantic Energy Framework with the Linux Foundation: https://lfenergy.org/projects/semantic-energy-framework-sef/
