DTAG: A Methodology for Aggregating Digital Twins Using the WoTDT Ontology

Abstract

The advancement of digital twins (DTws) has been instrumental in various scientific and industrial domains, facilitating real-time monitoring, analysis, and optimisation of complex systems. However, it remains difficult to describe precisely the architectural models and their characteristics of DTws and the aggregation of lower-level DTws to higher-level DTws. This article introduces two contributions with the goal of addressing challenges in describing DTws architectures and aggregating DTws. Firstly, it presents the development of “WoTDT” (WoT digital twin) ontology, an extension of the W3C Web of Things descriptions ontology, designed to semantically describe the five-dimensional model architecture of DTws. This ontology enhances data interoperability and accessibility across dimensions, promoting a deeper understanding of DTws. Secondly, it introduces the “DTAG” (digital twin aggregation) methodology for aggregating multiple DTws into an unified DTw aggregate (DTwA). This methodology considers whether the DTws contain semantics or not and employs the WoTDT ontology to conceptualise the architecture and features of the resulting DTwA. Finally, an example of WoTDT ontology together with the DTAG methodology is shown in the context of the European H2020 construction-related project COGITO.

1. Introduction

Current technological advancements and the increasing complexity of modern systems have driven the adoption of digital twins (DTws) as a powerful solution to address a variety of challenges [1], such as high-fidelity modelling, data acquisition and processing, and unified development platforms and tools. DTws offer a virtual representation of physical assets, processes, or systems, enabling real-time monitoring, simulation, and optimisation. This technology has become widely accepted in various domains due to its potential to help decision-making, improve operational efficiency, and increase overall performance [2].

DTws can be differentiated in multiple levels [2], such as DTw at the unit level (representing individual components or assets), DTw at the system level (modelling a collection of interconnected units), and DTw at the system-of-systems level (representing complex interconnected systems). Furthermore, these levels can be represented as a digital twin instance (DTwI) for the unit level and a digital twin aggregate (DTwA) for the system and system-of-systems level [3]. Although DTws offer many benefits, such as providing solutions to the challenges explained previously, a considerable challenge lies in the interoperability between different levels of DTws [4,5,6].

Furthermore, even though DTws can be represented on different levels, a challenging problem arises when trying to aggregate and connect lower-level DTws (DTwI) to create higher-level representations (DTwA). In many cases, these DTws are developed independently, using different data formats, architectures [7,8], modelling methodologies, and sometimes ontologies [2]. This results from a lack of interoperability between the data generated at each DTw level.

In this article, an extension of the W3C standard thing description (TD) ontology [9], proposed by the Web of Things (WoT) group, called the WoTDT ontology (WoTDT ontology v2: https://w3id.org/def/dtw, accessed on 18 May 2024) (WoT digital twin ontology) is presented. The goal of the WoTDT ontology is to provide formal semantics to represent the five-dimensional architecture model approach [8] and its features, allowing semantic discovery by reusing the TD ontology and a common approach to describe the capabilities of a DTw allocated by dimensions. Furthermore, this ontology was developed using the LOT methodology [10], following good practices in ontology engineering.

In addition, this article also includes an aggregation methodology called DTAG (digital twin aggregation methodology), used to aggregate DTws of different levels to obtain an aggregated DTw (DTwA), taking into consideration whether the DTws contain semantics or not. DTAG methodology follows dimensional aggregation according to the five-dimensional approach [8], where WoTDT ontology is applied to conceptualise the architecture and features of the resultant DTwA. Thus, this aggregation approach enables the aggregation of both metadata and data (whether semantic or not) from multiple DTws, resulting in a DTwA that contains all the metadata, centralised through the WoTDT ontology, and incorporates the data related to the DTws involved in the aggregation.

The rest of this article is structured as follows. Section 2 provides an overview of the literature and research proposals related to DTws in terms of architectures, different levels, aggregation, and ontologies. Section 3 includes the development of the WoTDT ontology using the LOT methodology. Section 4 provides the aggregation methodology based on the dimensions described in the WoTDT ontology and provides examples of aggregation by two DTws, which are aggregated into a DTwA extracted from the European H2020 COGITO (COGITO project: https://cogito-project.eu/, accessed on 18 May 2024. All the images presented in this article can be found in the repository used to publish and maintain the ontology presented: https://github.com/oeg-upm/WoT-DT-ontology-v2/tree/main/images/article_images, accessed on 18 May 2024) project. Section 5 introduces the different advantages and disadvantages of the presented aggregation method and recaps the conclusions of this research.

2. State of the Art

The concept of digital twin was introduced by Michael Grieves as a product lifecycle management (PLM) [7] for NASA in the aerospace field, defining it as a digital representation of a physical object or system that can be used to analyse its behaviour and effectiveness. The proposal models a three-dimensional architecture: the physical dimension, which represents the actual asset in the real world; the virtual dimension, which represents the software representation of the physical asset; connection parts, which exist between the physical and virtual dimensions.

Following the three-dimensional methodology, the researchers focused on refining aspects of these dimensions to address new challenges [3,11,12,13]. For instance, NASA [12] enhanced the current simulations conducted in the virtual dimension with the aim of better managing US Air Force aircraft over their operational lifetime through the development of customised structural management strategies and by integrating real-time data collection into the physical dimension.

Five-dimensional model approach: Subsequently, in 2017, Tao and Zhang [8] proposed a five-dimensional model of a DTw, extended from the three-dimensional approach. In this proposal, the physical dimension is referred to as the physical entity dimension, while the connections are termed the digital twin connection dimension. Instead, the virtual dimension is divided into three dimensions: the virtual entity dimension, which includes the description of the DTw models (such as rules, behavioural, physical, etc.), the data dimension of the digital twin, where all the data utilised by the DTw are stored, and the digital twin service dimension, which includes all the services used by the DTw.

DTw levels: Based on the five-dimensional model, three-level differentiation of DTws was proposed [14]: (i) unit level, which is the minimum unit that can be represented as a DTw (e.g., a robotic arm belonging to an assembly line); (ii) system level, it is considered as the integration of multiple DTws at unit level that cooperate with each other (e.g., the set of robotic arms belonging to the assembly line); (iii) system of systems level, which is the set of system-level DTws that need each other to perform more complex operations (e.g., the set of assembly lines in the factory where the assembly process is being carried out). This model of DTws divided into levels is also presented in other articles [2], where the existence of a world of interconnected twins is proposed, where the DTw of a system can be the composition of a system made up of interconnected DTws of a lower level.

DTw aggregation: Grieves and Vickers presented the idea of DTws aggregation in 2016 [3], outlining concepts such as a DTw prototype (DTwP), a DTw instance (DTwI), a DTw aggregate (DTwA), and a DTw environment (DTwE). A DTwP characterises a physical object to the extent that an object can be produced using the details provided in the DTwP. A DTwI represents an instance of a DTwP, which is linked to a specific physical object and persistently collects data about this object during its lifecycle. The DTwA aggregates all DTwIs of a specific category to create a larger and more complete dataset concerning the operation of a type of physical object. Finally, the DTwE serves as an integrated interdisciplinary physics application environment that uses the DTws for multiple purposes, such as the simulation of future system behaviour. Brangiu et al. [15] used aggregation to collect, process, and reduce data from multiple DTws to inform a control application. Karanjkar et al. [16] aggregated historical data (collected within DTws) to handle large amounts of historical data. Similarly, Pan et al. [17] employed hierarchical data format (HDF) data compression to aggregate large amounts of heterogeneous data, providing a more comprehensive and integrated data representation. Lutze [18] employed personal DTws to maintain patient medical records. Additionally, group DTws and system DTws, which are compilations of personal DTws organised by specific criteria, serve the purpose of training machine learning models. While personal DTws contain all relevant medical data of a patient, group and system DTws only gather the data necessary for the intended model, thereby excluding details like the patient’s name to maintain privacy and anonymity.

Furthermore, architectures for DTw aggregations have been proposed. Villalonga et al. [19] proposed a hierarchical aggregation approach, where local DTws focused on monitoring and diagnosing the health of assets, whereas global DTws focused on decision-making processes. Ciavotta et al. [20] introduced a framework in which data from various DTw are organised into layers. These layers are subsequently aggregated into different collections tailored to the user’s preferences and required level of detail. Finally, Redelinghuys et al. [21] proposed a six-layer architecture for DTw with aggregation called SLADTA (six-layer architecture for DTws with aggregation), which is an extension of the SLADT framework that allows multiple DTws to aggregate data for a system-level perspective.

DTw aggregation problems and possible solutions: From these aggregations between different DTws, numerous problems can be found. A complex system usually contains multiple subsystems and components that may have their own DTw models. These models may be created by various stakeholders based on different protocols and standards whose structures and data sources are often heterogeneous in terms of syntax, schema, and semantics. This makes the integration of DTw models a difficult task [4]. To solve this problem, in the literature, the use of semantic technologies has been used as key components in various DTws to obtain semantic interoperability in data and in heterogeneous information [5,6].

Semantics in DTw: The application of semantic web technologies in the development, management, and modelling of DTws has grown in recent years. Specifically, recommendations have been proposed on how to integrate ontologies and their advantages for DTw [22]. The ontologies of the DTws are used to (i) improve the visualisation and understanding of the DTw data [23] and (ii) describe the architecture model of a DTw [24].

In the literature, various studies have been conducted concerning the description of an architecture model of a DTw, which is the goal of WoTDT ontology. Charles Steinmetz et al. [24] explored the extension of IoT-Lite ontology [25] by adding classes related to the virtual aspect of the three-dimensional model, which enables external applications and systems to interact with the virtual dimension through a specific protocol. Following this approach, Sumit Singh et al. [26] introduced an ontology designed to encapsulate domain knowledge and preserve the semantic integrity of asset functionalities and fundamental properties throughout their operational period within the virtual aspect. Furthermore, Meijers of Microsoft Azure introduced the digital twins definition language (DTDL) [27], which uses an RDF metamodel to represent DTw virtual aspect metadata within their proprietary tools.

WoT in DTws: In the literature, the research conducted by Ricci et al. [28] outlines the development of a DTws ecosystem that employs semantic web technologies within the healthcare domain. In their research, the integration of DTw and WoT improves the accuracy of real-time asset monitoring and interoperability with different systems. A different proposal by Pittaras et al. explored the integration of the WoT standards with smart contracts to represent DTws of physical devices [29]. Furthermore, the study by Luca Bedogni and Federico Chiariotti [30] introduced an architecture based on the WoT standard to facilitate a DTw in a smart environment involving sensors implemented in a construction-related project. Finally, Xiaochen Zheng et al. [4] integrated these technologies, applying WoT in cognitive DTws (CDTws) to standardise and facilitate data interoperability.

In this article, an extension of WoT description ontology [9] is named WoTDT ontology. WoTDT ontology diverges from those previously presented ontologies in the literature by not only describing the virtual aspect but also integrating all five dimensions suggested by Tao and Zhang [8]. In addition, this ontology allows us to centralise all the metadata of the DTw, providing a unified point for accessing its features and data. Furthermore, it allows the aggregation of other metadata from DTws, which facilitates interaction with the DTwE introduced by Grieves and Vickers [3]. Since this ontology is based on WoT, it allows each DTw to (i) describe services of different dimensions [9], (ii) discover services across dimensions [31], (iii) define the security specification of each dimension [9], and (iv) facilitate the access of data of a specific dimension [9].

In addition to ontology, this article includes a methodology called DTAG for aggregating DTws, which considers whether the DTw contains semantics or not. This aggregation methodology follows dimensional aggregation according to Tao and Zhang’s five-dimensional model, where WoTDT ontology is applied. Therefore, this methodology, unlike the aggregations presented in the literature, allows the aggregation of the metadata and data (semantic or non-semantic) of different DTws that are in a DTwE, obtaining a DTwA that contains all the metadata, centralised thanks to the WoTDT ontology, and all the data regarding the DTwIs or DTwAs of the DTwE involved in the aggregation process.

3. WoTDT Ontology Development

In this article, a novel approach is presented to semantically represent the metadata of a digital twin (DTw) that follows the five-dimensional architecture model [8] with its characteristics and functionalities. To this end, this ontology was developed as an extension of thing description ontology (TD) [9], proposed by the W3C Web of Things group, which is a standard that allows the description of services, promoting interoperability, discoverability, accessibility, and security. This novel ontology, named WoTDT, provides an approach that describes the metadata of all the dimensions and internal capabilities of a DTw, allowing the centralisation of all the metadata of the DTw.

WoTDT ontology has been developed following the LOT (Linked Open Terms) methodology [10]. This methodology is based on the ontological engineering activities described in the NeOn methodology [32]. In addition, this methodology incorporates agile techniques in the ontology development process, allowing the division of development into sprints or iterations.

The LOT methodology outlines a process that includes the following activities: (i) specifying ontological requirements, (ii) implementing the ontology, (iii) publishing the ontology, and (iv) maintaining the ontology. The following subsections provide further details on these activities and their implementation to deliver WoTDT ontology.

3.1. WoTDT Requirements

The specification of ontology requirements is derived from the analysis of ontologies from the literature, the five-dimensional model approach, and the aggregation method proposed in this article, which was refined during its adoption and use in the COGITO H2020 project. In contrast to the ontologies found in the literature that are limited to the virtual aspects of a DTw, WoTDT ontology outlines the necessary requirements to conceptualise the five dimensions, as defined by Tao and Zhang [8]. Similarly, the virtual component discussed in WoTDT presents similarities to the ontologies described in the existing literature. From these inputs, a collection of ontological requirements was generated in the form of competency questions and sentences in natural language.

Table 1. Requirements for WoTDT ontology.

ID	Competency Question/Statement—Possible Answer
WOTDT-1	A digital twin is a thing.
WOTDT-2	A digital twin contains five dimensions.
WOTDT-3	Physical entity is a dimension that represents the real-world asset of the digital twin.
WOTDT-4	Digital entity is a dimension that represents the digital asset of the digital twin. Also, it contains the dimensions of the virtual entity, DTw data, and DTw services.
WOTDT-5	Virtual entity is a dimension that represents the different models used in the digital twin.
WOTDT-6	DTw data is a dimension where are stored all the data used in the digital twin.
WOTDT-7	Digital twin services is a dimension in which all services of the digital twin are described.
WOTDT-8	DTw connection is a dimension in which all the connections between other dimensions in the DTw and with other external DTw dimensions are described.
WOTDT-9	Virtual entity dimension can have models.
WOTDT-10	Which kind of models can be described in the virtual entity dimension? The models can be from rules, behavioral, physical and geometric models to semantic models like ontologies.
WOTDT-11	DTw data dimension can have resources that can be used to represent different types of data stored at the digital twin.
WOTDT-12	DTw service dimension can have interaction affordances from the WoT thing descriptions ontology to represent the different services used at the digital twin.
WOTDT-13	DTw connection dimension can have different connections.
WOTDT-14	Which type of connections can the digital twin connection dimension describe? The connections defined in the DTw connection dimension are described with the different existing elements of other dimensions of the DTw, such as models, resources, and interaction affordances, and the connections with external things such as other DTws.
WOTDT-15	Digital twin instance (DTwI) describes a specific corresponding physical product to which an individual DTw remains linked throughout the life of that physical product.
WOTDT-16	Digital twin aggregate (DTwA) describes the aggregation of DTwI and DTwA. Unlike the DTwI, the DTwA may not be an independent data structure. It may be a computing construct that has access to all DTwIs and queries them either ad-hoc or proactively.
WOTDT-17	Connections between DTws can be represented as external connection points.
WOTDT-18	Aggregations between data models metadata or the data resources metadata of the DTws can be represented in the resulting DTwA within the connections between them.

shows the new requirements obtained from the specification process.

3.2. WoTDT Implementation

To streamline the implementation process, a conceptualisation of the ontology was proposed using the requirements identified in the previous step as input. This conceptualisation incorporates the key concepts to represent the metadata of the five dimensions of the DTw and the aggregation of other DTws. Figure 1 shows an overview of the representation of this conceptualisation, which follows the Chowlk visual notation [33], which establishes a connection between the stereotypes used in the profile with OWL, RDF (S), and certain OWL2 constructs. The use of prefixes indicates the ontologies in which a concept or relation is defined. For example, dtw:DigitalTwin is defined under the “https://w3id.org/def/dtw”, accessed on 18 May 2024. Furthermore, this ontology reuses DCAT ontology (data catalogue vocabulary), such as dcat:Resource; HCTL ontology (WoT hypermedia controls ontology), such as hctl:hasTarget; apart from WoT thing description ontology, such as td:InteractionAffordance.

As shown in Figure 1, the dtw:DigitalTwin class is defined as a owl:subClassOf of the td:Thing class, enabling it to inherit the properties of the td:Thing class. In addition, the different dimensions detected in the requirements identification process are represented using the following classes: dtw:Entity, for the physical entity dimension; dtw:DigitalEntity, for the digital entity dimension; dtw:Model, for the virtual entity dimension; dcat:Resource, for the DTw data dimension; td:InteractionAffordance, for the DTw services dimension; dtw:Connection, for the DTw connection dimension. These dimension conceptualisations will be explained separately in the following subsections.

3.2.1. Physical Entity Dimension

In WoTDT ontology, the dtw:Entity class is a representation of the dimension of the physical entity. This class goes beyond only representing physical entities, such as sensors or actuators, and can also represent non-physical entities, such as processes or projects. It should be noted that this dimension is unique for every DTw because it represents the entity from which the DTw is being created.

3.2.2. Digital Entity Dimension

The dimension of the digital entity in WoTDT ontology is associated with the class dtw:DigitalEntity. This class allows for the representation of the digital entity of the DTw. Moreover, as this dimension is described, it allows us to represent the proposed three-dimensional model for a DTw [3]. This dimension also contains the dimensions of virtual entity, DTw data, and DTw services, allowing the representation of the five-dimensional approach [8].

3.2.3. Virtual Entity Dimension

The dimension of the virtual entity in the developed ontology is represented by the class dtw:Model. This class allows for representing the conceptualisation of data registered in the DTw. As can be shown in Figure 2, there are different subclasses under the dtw:Model class that allows for representing non-semantic models, such as the dtw:BehavioralModel or dtw:PhysicalModel, and semantic models, such as the dt:OntologyModel. Furthermore, as shown in Figure 1, each of these dtw:Model has a specific format, represented by the class dtw:Format, containing attributes represented as owl:DatatypeProperty, such as the route where the model is stored (hctl:hasTarget), and the extension of the model (dt:hasExtension), that can be, for example, the case of an dt:OntologyModel of the “ttl” extension that refers to turtle serialisation.

3.2.4. DTw Data Dimension

Once the previous dimensions have been explained, the dimension of the DTw data will follow. In WoTDT ontology, the dimension of DTw data is represented by the class dcat:Resource. In this case, the authors chose to adopt DCAT ontology over WoT TD ontology for data representation due to the comprehensiveness of DCAT and its ability to describe more extensive data volumes (as used in DTws) featuring a broader range of features, such as dcat:Dataset, dcat:DataService, or dcat:Catalog. This approach can be useful when dealing with diverse data volumes classified by both semantic and non-semantic categories.

3.2.5. DTw Services Dimension

The following dimension is the dimension of DTw services. This dimension is represented by the class td:InteractionAffordance. As explained previously, WoT enables the description of DTw services, which is why the class td:interactionAffordance is reused in this context to represent the various services within the DTw. Furthermore, this class demonstrates the options available to DTw consumers, indicating the ways in which they can interact with DTw services.

3.2.6. DTw Connections Dimension

The last dimension is the dimension of DTw connections, which is represented by the class dtw:Connection. This class represents the different connections that are available between DTw dimensions. This dimension, as well as the dimension of the physical entity, is unique for every DTw because it represents the connections of the DTw between the dimensions of the DTw itself or between these dimensions and the external dimensions of other DTws. Furthermore, a set of subclasses has been created under the dtw:Connection class to represent the different connections that can exist. These subclasses can be seen in Figure 3. In order to represent a particular endpoint of a dimension that functions as a provider (dtw:hasProvider) or consumer (dtw:hasConsumer) of information within the connection, the class dtw:ConnectionPoint has been created. The authors decided to introduce the class dtw:ConnectionPoint instead of reusing existing SEAS ontology [34] because SEAS ontology only considers connections between systems, whereas, in the context of DTws, connections may not always be limited to systems.

3.2.7. Aggregation Method Conceptualisation

In this section, the representation of the conceptualisation of the aggregation method introduced in this article is explained. This conceptualisation is focused on the last four identified requirements. In order to satisfy the requirements of representing a DTwI and a DTwA, the subclasses of dtw:DigitalTwinInstance and dtw:DigitalTwinAggregate have been added under the class dtw:DigitalTwin. Furthermore, there are two new types of owl:ObjectProperty that represent the aggregation connection between DTwAs and DTwIs or other DTwAs. These object properties are dtw:aggregateDTwI and dtw:aggregateDTwA.

Moreover, to conceptualise whether the connections are internal to the DTw or external to other DTw, two subclasses have been added under the class dtw:ConnectionPoint. On the one hand, dtw:InternalConnectionPoint represents if the existing connection point in the DTw is internal, and on the other hand, the class dtw:ExternalConnectionPoint represents if the connection point is external to the DTw. Therefore, the connection points depend on the viewpoint of the DTw. This conceptualisation can be found in Figure 4.

Finally, the last requirement, which refers to the aggregation representation between the data models or the data resources is conceptualised. This conceptualisation has been represented as a cyclic relation between owl:ObjectProperty, dtw:Model, and dcat:Resource classes. On the one hand, the owl:ObjectProperty defined for dtw:Model is dtw:modelAggregatedFrom, which represents the data models (e.g., ontology models) used in the aggregation to obtain the DTwA data model. On the other hand, the owl:ObjectProperty defined for dcat:Resource is dtw:resourceAggregatedFrom, which represents the data resources (e.g., knowledge graphs) used in the aggregation to obtain the DTwA data resource.

Once the conceptualisation of WoTDT ontology was defined, it was encoded in OWL using Chowlk [35] and Protégé (Protégé: https://protege.stanford.edu, accessed on 18 May 2024) and stored in a GitHub repository (GitHub repository: https://github.com/oeg-upm/WoT-DT-ontology-v2, accessed on 18 May 2024).

3.3. WoTDT Evaluation

The evaluation to identify typical errors during the ontology extension implementation was performed using the OOPS! tool [36]. This tool receives the ontology as input and detects possible pitfalls commonly found in the ontology implementation phase. This tool is independent of the ontology editor used and performs a greater number of automatic checks than the rest of the existing tools, with a detection catalogue of 41 pitfalls. Through the use of this tool, several minor pitfalls have been identified, but all were corrected accordingly.

Furthermore, the authors performed a systematic analysis to ensure that the extension of the ontology satisfies the requirements described in Table 1. To perform this verification, a set of tests (Themis tests: https://github.com/oeg-upm/WoT-DT-ontology-v2/blob/main/testsuite.ttl, accessed on 18 May 2024) was defined and executed using the Themis tool [37], which implements the testing methodology defined by Fernández-Izquierdo and García-Castro [38]. Upon execution of the tests, it was found that all tests passed successfully, suggesting that the developed ontology extension meets all specified requirements.

3.4. WoTDT Publication and Maintenance

After the development and evaluation activities, the ontology has to be published online. To achieve this goal, the Ontoology [39] tool is used. This tool is a web-based system that is designed to work seamlessly with Git-based environments and incorporates various pre-existing documentation tools. Furthermore, OnToology provides two methods for publishing via content negotiation techniques. The initial method involves the use of a permanent identifier to publish the ontology, facilitated by the services at “https://w3id.org”, accessed on 18 May 2024. Alternatively, the second option is to download a bundle containing all the necessary files to publish the ontology on a server. For WoTDT ontology, the permanent identifier method was chosen, which resulted in its publication within the URI “https://w3id.org/def/dtw”, accessed on 18 May 2024, making it accessible in both machine-readable and human-readable forms.

Finally, to support maintenance activity in the developed ontology, an issue tracker (https://github.com/oeg-upm/WoT-DT-ontology/issues, accessed on 18 May 2024) is used. This issue tracker enables the monitoring of all suggested issues, and once an issue is open, the ontology development team needs to discuss and make a decision on whether the submitted proposal should be implemented in the ontology or rejected.

4. DTw Aggregation Methodology

The DTw aggregation (DTAG) methodology is a lightweight methodology for developing aggregation between DTws to obtain an aggregated DTw (DTwA). The DTws involved in aggregation can be DTwI or DTwA, with the aggregation always producing a DTwA. In addition, this DTwA can also be used for future aggregation processes. This methodology follows WoTDT ontology for aggregating the different DTws according to the dimensions conceptualised in the ontology. Therefore, the various tasks involved in the aggregation process will be distinguished according to the five dimensions [8] conceptualised in the ontology, as explained in Section 3.

The DTAG methodology defines interactions on a basic workflow composed of the following activities, also represented in Figure 5:

• DTws instantiation, where the DTws involved in aggregation are instantiated using WoTDT ontology.
• DTws dimension aggregation development, where the information contained in the different dimensions of DTw involved are aggregated.
• DTwA maintenance, where the DTwA obtained from the aggregation process is updated according to the functionalities that will be performed.

Figure 5. DTAG methodology base workflow.

Figure 5. DTAG methodology base workflow.

Although numerous roles may participate in the aggregation of DTws, the DTAG methodology categorises them into the following groups:

• DTw developer: a DTw developer is part of the DTw development team and possesses extensive knowledge regarding the DTws used in the aggregation process.
• Domain expert: a domain expert possesses expertise in the fields addressed by the DTws used in the aggregation process.
• DTwA user: a DTwA user is the end user of the DTwA obtained from the aggregation process. This actor will also include DTw developers who will use and extend the DTwA knowledge and functions.

The subsequent sections provide comprehensive information on each activity, encompassing detailed tasks and workflows, intermediate results, and the tools used for support. In addition, for every activity performed, an example taken from the COGITO project will be explained; therefore, they will be limited to the constraints imposed on the project.

Furthermore, examples of aggregation involve two DTws. The first DTw refers to a construction pilot of a railway station in Munich (Germany), while the second DTw refers to a construction pilot of a railway station in Murcia (Spain). The desired result of the aggregation of these two DTws is to obtain a DTwA that defines a DTw of the entire COGITO project.

It is worth noting that this article focuses on the investigation of the description of an ontology that allows us to describe the metadata of a DTw in its totality and offers a functionality for the possible aggregation between DTws. In turn, the described aggregation methodology focuses on offering solutions to the possible types of aggregation between the existing components in the DTws. Therefore, in each of the activities of the methodology, tools or frameworks existing in the literature are proposed to allow the aggregation or integration of the different components of DTws.

Moreover, the aggregation methodology focuses, as the ontology, on aggregation by dimensions of the five-dimensional model. For this reason, unlike the aggregations presented in Section 2, this methodology allows the aggregation of metadata and data (semantic or non-semantic) belonging to different DTws within a DTwE, obtaining a single DTwA containing all the centralised metadata thanks to the WoTDT ontology, and all the data belonging to the DTwIs/DTwAs involved in the aggregation process.

4.1. DTws Instantiation

The DTws instantiation activity refers to the activity of obtaining prerequisites for the DTAG methodology. This activity of obtaining prerequisites focuses on collecting all metadata of all dimensions of the DTws involved in the aggregation and the instantiation of all of these metadata using the WoTDT ontology presented in Section 3.

As shown in Figure 5, this activity will be carried out by DTw developers and domain experts. The workflow proposed for the DTws instantiation activity is shown in Figure 6.

4.1.1. DTw Metadata Extraction by Dimension

The goal of DTw metadata extraction by dimension activity is to obtain all the metadata information of the DTw to instantiate and centralise it in a single place. This activity involves DTws developers and domain experts of DTws involved in the aggregation process. The output of the activity is a table that contains the metadata information that refers to the different dimensions of the DTws, which describes all the functionalities and accesses of DTws. The described table should contain the following columns:

• DTw: DTw where the metadata are extracted.

  –

  DTw Identifier: identifier that represents the DTw.

  –

  DTw Title: title that describes the DTw specifically.

• Entity: entity or asset that is represented by the DTw.

  –

  Entity Identifier: identifier of the entity or asset represented by the DTw.

  –

  Entity Title: title that specifically describes the entity or asset that is represented by the DTw.

• Models: models used by the DTw to model its data.

  –

  Model Type: type of model described as subclasses in the model class of WoTDT ontology.

  –

  Model Identifier: identifier of the model.

  –

  Model Title: title that describes specifically the model.

  –

  Model Description (optional): description that describes the model.

  –

  Model Formats: formats in which the model can be found.

  –

  Model Access URL: URL where the model can be accessed.

• Resources: data resources used by the DTw.

  –

  Resource Type: type of data resource described as subclasses in the resource class of the reused DCAT ontology in the WoTDT ontology.

  –

  Resource Identifier: identifier of the resource.

  –

  Resource Title: title that describes specifically the resource.

  –

  Resource Description (optional): description that describes the resource.

  –

  Resource Access URL: URL where the resource can be accessed.

  –

  Resource Download URL (optional): URL where the resource can be retrieved.

  –

  Related Resources Identifier (optional): relations with other data resources, such as distributions or data services where a dataset is stored.

• Services: services used by the DTw to execute processes.

  –

  Service Type: if it is a property, action, or event affordance from the thing description ontology.

  –

  Service Identifier: identifier of the service.

  –

  Service Title: title that describes the service specifically.

  –

  Service Description (optional): description that describes the service.

  –

  Service Access URL: URL where the service can be accessed.

  –

  Service Content Type (optional): content type that returns the service, such as “application/json”.

• Connections: existing connections between the different dimensions of the DTw.

  –

  Connection Type: type of connection described as subclasses in the connection class of WoTDT ontology.

  –

  Connection Identifier: identifier of the connection.

  –

  Connection Title: title that describes specifically the connection.

  –

  Connection Description (optional): description that describes the connection.

  –

  Connection Provider Identifier: identifier of the connection provider.

  –

  Connection Consumer Identifier: identifier of the connection consumer.

An example of the extraction of the DTw metadata from the COGITO Munich pilot is shown in

Table 2. DTw metadata extraction by dimension table (Part 1).

DTw		Entity		Model
ID	Title	ID	Title	Type	ID	Title	Description	Format	Access URL
b3fe643d-f9f2-4e14-bf3c-95343d63c850	Munich Pilot DTw	b3fe643d-f9f2-4e14-bf3c-95343d63c850	Munich Construction Site	Ontology Model	eac0b1bf	COGITO Facility Ontology.	The COGITO Facility ontology aims at modelling facilities in the construction domain.	JSON-LD	https://cogito.iot.linkeddata.es/def/facility/ontology.jsonld, accessed on 18 May 2024
								RDF/XML	https://cogito.iot.linkeddata.es/def/facility/ontology.owl, accessed on 18 May 2024
								N-Triples	https://cogito.iot.linkeddata.es/def/facility/ontology.nt, accessed on 18 May 2024
								Turtle	https://cogito.iot.linkeddata.es/def/facility/ontology.ttl, accessed on 18 May 2024
				Rules Model	ae463899	Geometric Quality Control Rules.	Geometric Quality Control Rules to analyse the geometry quality of the DTw.	JSON	https://dtp.cogito-project.com/file/9b5fe1ab-fec2-471c-93f2-eab17040cb2b/download, accessed on 18 May 2024
				…	…	…	…	…	…

,

Table 3. DTw metadata extraction by dimension table (Part 2).

Resources
Type	ID	Title	Description	Access URL	Download URL	Related Resources ID
Dataset	f50ea5d4	Knowledge Graph	Knowledge Graph of DTw b3fe643d-f9f2-4e14-bf3c-95343d63c850	https://triplestore.cogito.iot.linkeddata.es/resource?uri=https:%2F%2Fdata.cogito.iot.linkeddata.es%2Fdti_774bab16role=context, accessed on 18 May 2024	https://triplestore.cogito.iot.linkeddata.es/repositories/cogitotriplestore/statements?infer=falsecontext=%3Chttps%3A%2F%2F\data.cogito.iot.linkeddata.es%2F\dti_774bab16%3Elocation=Accept=text%2Fturtle, accessed on 18 May 2024	eeee1272
Data Service	eeee1272	Triplestore	SPARQL endpoint of the Triplestore where the Knowledge Graph is stored.	https://triplestore.cogito.iot.linkeddata.es/repositories/cogito-triplestore, accessed on 18 May 2024	/	f50ea5d4
Dataset	d00e4a90	IFC file	IFC file that contains DTw 774bab16 modelling information.	https://dtp.cogito-project.com/file/\1c28d21c-f5d7-4b84-8cb8-3b518dbb9581/download, accessed on 18 May 2024	https://dtp.cogito-project.com/file/\1c28d21c-f5d7-4b84-8cb8-3b518dbb9581/download, accessed on 18 May 2024	4d18ce76
Data Service	4d18ce76	DTP	COGITO Digital Twin Platform Graph	https://fuseki.openmetrics.eu/Munich, accessed on 18 May 2024	/	d00e4a90
…	…	…	…	…	…	…

and

Table 4. DTw metadata extraction by dimension table (Part 3).

Services						Connections
Type	ID	Title	Description	Access URL	Content Type	Type	ID	Title	Description	Provider ID	Consumer ID
Property Affordance	40629	validate_rdf	Validate RDF Data	https://data.cogito.iot.linkeddata.es/validation/api/file_shacl_validation/data, accessed on 18 May 2024	text/turtle	Model-Data Connection	ece55bb5	Connection of DTw455ed3a9	Connection between a model and a dataset	eac0b1bf	f50ea5d4
Action Affordance	04c26	register_shacl_model	Register SHACL Shapes	https://data.cogito.iot.linkeddata.es/validation/api/construction_shacl_validation/mapping, accessed on 18 May 2024	application/octet-stream
…	…	…	…	…	…	…	…	…	…	…	…

.

4.1.2. Metadata Instantiation Using WoTDT Ontology

The goal of metadata instantiation using WoTDT ontology activity is to provide the DTwA user with necessary information about the DTws involved in the aggregation process in a centralised and homogeneous format to perform the DTws dimension aggregation development activity. This activity involves DTws developers of the DTws involved in the aggregation process, who will be responsible for performing the instantiation of the metadata available in the table using WoTDT ontology. The output of the activity is an instantiation of the metadata extracted from the previous activity using WoTDT ontology. Since the data described in the table follow the modelling of WoTDT ontology, the instantiation of the information is straightforward. For the instantiation representation, a modification of Chowlk’s notation is used. Therefore, an excerpt of this instantiation can be seen in Figure 7, following the metadata extracted in Table 2, Table 3 and Table 4. Furthermore, an excerpt from the instantiation of the other DTw (Murcia pilot DTw) involved in the aggregation can be seen in Figure 8.

4.2. DTws Dimension Aggregation Development

The DTws dimension aggregation development activity refers to the activity of performing aggregation by dimensions of the DTws involved, obtaining a DTwA. This aggregation activity focuses on aggregating different information obtained from the dimensions of the DTws instantiated in Section 4.1 using WoTDT ontology.

As shown in Figure 5, this activity will be carried out by experts in the domain and DTwA users. The workflow proposed for the DTws instantiation activity is shown in Figure 9.

DTwA Entity Creation

As explained in Section 3.2.1, the entity in a DTw is unique; therefore, the objective of this activity is to provide an entity in the real world that describes the DTwA. This activity involves the DTwA user and domain experts, who will be responsible for selecting the entity that will describe the DTwA. Once the entity has been selected, it should be instantiated using WoTDT ontology, as was carried out in Section 4.1. Therefore, the output of this activity will be the selection and instantiation of the entity that represents the resulting DTwA.

In Figure 10, the instantiation of the entity belonging to the DTwA that refers to the aggregated DTw of the COGITO project can be observed, together with the reference to the DTws involved in the aggregation process.

4.3. Digital Entity Aggregation

In the “Digital Entity”, data models, data resources, and service interaction affordances can be found. Therefore, the goal of this activity is to provide the aggregation of data models, data resources, and the reference of the service interactions affordances from the DTws involved in the aggregation process and its instantiation.

As shown in Figure 9, this activity will be carried out by the DTw user and domain experts. Furthermore, the workflow proposed for the digital entity aggregation activity is shown in Figure 11.

4.3.1. Models Aggregation

Data models represent all data conceptualisations of the DTw [8]. The goal of this activity is to aggregate the models from the DTws involved in the aggregation to obtain the DTwA models. This activity involves the DTwA user performing aggregation between the models of DTws and obtaining DTwA models. Furthermore, this activity also involves domain experts in providing support for the model aggregation process. These models are divided into non-semantic and semantic models; therefore, an activity must be performed for each of them.

Non-Semantic Model Referenciation

The goal of the non-semantic models referenciation activity is to reference all non-semantic models of the DTws involved in the aggregation within DTwA instantiation using WoTDT ontology. This activity involves domain experts and the DTwA user to select which of the non-semantic models from the table developed in Section 4.1 can be useful for the resultant DTwA. Once the non-semantic models are selected, these are referenced in the instantiation of the DTwA models using WoTDT ontology. Therefore, the output of this activity will be the instantiation of the references to the non-semantic models that are of interest for the resultant DTwA.

Furthermore, in case new non-semantic models are needed for the DTwA, the DTwA user should reference them in DTwA model instantiation.

In Figure 12, a non-semantic model reference from the Munich pilot DTw is referenced in the instantiation of the DTwA.

Semantic Model Aggregation and Referenciation

In case the DTws involved in the aggregation process contain semantic models, a process different from the one described in Section “Non-Semantic Models Referenciation” shall be conducted. Semantic models can include the following: (i) ontologies, which contain all the conceptualisation of all the semantic data that are going to be used in the DTwA; (ii) mappings, which are based on the ontologies models and contain the rules that aim to materialise the DTw knowledge graph [40] using data resources as input; (iii) shapes models, such as SHACL shapes [41], which are going to be the shapes models used for this article, that are also based on the ontology, but their objective is to contain the validation rules (restrictions/constraints) to verify the knowledge graph materialised by the rules described in the mapping models.

The goal of semantic model aggregation and referenciation activity is to provide semantic models that are going to be used by the DTwA to conceptualise its semantic data. This activity involves the DTwA user and the domain experts to first select the semantic models that can be useful for the DTwA, and then in the case that two models of the same type belonging to different DTws are found (types described as subclasses of the model class in the WoTDT ontology), perform the aggregation process between them in order to be able to have links between both models. After selecting and aggregating the semantic models, they should be referenced in DTwA instantiation using WoTDT ontology. This includes both models originating from the DTws involved in aggregation and those derived from the aggregation process.

Sometimes, both models can be the same between different DTws involved in aggregation; therefore, if the DTwA user and domain experts select them to be used in the resulting DTwA, they should be referenced as in Section “Non-Semantic Models Referenciation”.

Consequently, the output of this activity is to acquire semantic models that will be used in the DTwA and referenced during the instantiation of the DTwA.

The following sections describe the aggregation that can be performed for each of the semantic models described.

• Ontology Aggregation

The goal of the ontology aggregation activity is to perform an aggregation between two ontologies to obtain a single ontology that contains the conceptualisation needed for the DTwA data. This activity involves the DTwA user performing the aggregation process and the domain experts providing information about the ontologies domain. The output of this activity is an ontology resulting from the aggregation of the ontologies of the DTws involved in the aggregation process and its reference in the instantiation of the DTwA using WoTDT ontology.

In the aggregation process of ontology models, multiple scenarios can be found. The scenarios depend on whether the ontology models of the DTws to be aggregated are (i) identical, (ii) partially overlapping, or (iii) completely distinct. For each of these scenarios, the aggregation steps are different.

Scenarios that involve identical or partially overlapping ontologies do not require operational aggregation because these ontologies are interconnected. In the first scenario, the ontologies are identical, whereas in the second scenario, they are linked to each other. Therefore, DTws ontologies must be referenced by DTwA instantiation using WoTDT ontology. Meanwhile, in the third scenario, a process called ontology alignment needs to be performed. In Figure 13, the workflow of this activity is presented depending on the particular aggregation scenario.

The ontology alignment process performed in the third scenario refers to the activity of identifying similarities between two or more ontologies and then exploiting or storing them [32,42]. For these ontology alignment activities, there is an organisation called the Ontology Alignment Evaluation Initiative (OAEI) (https://oaei.ontologymatching.org/2023/, accessed on 18 May 2024), which annually proposes challenges to perform better ontology alignment algorithms. The OAEI initiatives are as follows: (i) evaluation of the advantages and disadvantages of alignment/matching systems; (ii) comparison of the performance of techniques; (iii) improvement of the level of communication among algorithm developers; (iv) improvement of evaluation techniques; (v) assistance in improving ontology alignment and matching research.

In recent years, the Matcha and LogMap frameworks have been used the most for ontology alignment and matching in OAEI due to the fact that they offer the best results.

On the one hand, Matcha [43] is an innovative ontology matching system that seeks to address persistent issues in the field of ontology matching. It integrates the essential algorithms of AgreementMakeLight (AML) [44] into a new core framework that is specifically designed to handle the matching of multiple ontologies and complex ontology matching. Furthermore, its structure is more flexible and scalable compared to that of AML. Additionally, Matcha includes an extension known as Matcha-DL, which is a variation of Matcha designed for semi-supervised learning. It uses the scores generated by the multiple matching algorithms in Matcha to train a dense neural network for the purpose of distinguishing and ranking a group of candidates identified by Matcha. The results of this framework for the OAEI challenge of last year can be seen in [45].

On the other hand, LogMap [46] is an ontology matching system known for its high scalability, incorporating reasoning and inconsistency repair features to generate mappings between classes, properties, and instances. Additionally, LogMap stands out as one of the few matching systems that can effectively align complex ontologies with a large number of classes (tens and hundreds of thousands of classes), utilising advanced reasoning and repair methods to reduce logical inconsistencies and offering user support options throughout the matching procedure. The results of this framework for the OAEI challenge of last year can be seen in [47].

Furthermore, in addition to these frameworks, there is the research conducted by Inès Osman et al. [48], in which a review of the literature on ontology matching and ontology integration is performed, presenting approaches and possible errors that may occur in the implementation of these processes. Among the possible problems, the need for a repair and refinement process of the links obtained between the ontologies in the merging process due to the heterogeneity of the ontologies is explained. In order to solve these problems and considering an analysis of the existing literature, OIAR (ontology integration with alignment reuse) and AROM (alignments reuse for ontology merging) tools are presented as possible approaches to automatically build a simply merged and fully merged ontology, respectively, using refinement and repair techniques to ensure that input alignments are not disambiguous.

Hence, with the aim that the ontology obtained from the ontology merging process is consistent, coherent, and does not contain ambiguities, the DTwA user, in case the ontology merging tool does not have it, shall apply refinement and repair techniques between alignments. In turn, to ensure that the ontology obtained satisfies all the requirements obtained from its pre-implementation requirements specification activity and does not contain any pitfalls, the DTwA user shall use the tools used in Section 3.3 regarding the ontology evaluation activity.

Therefore, in the third scenario, it is necessary to implement one of these technologies to align the ontologies of different DTws. Moreover, there are instances where aligning ontologies is not feasible due to the substantial disparity that may be present in the conceptualisation of ontologies. As a result, an extension of the ontologies is required to perform the aggregation of the ontologies.

Once the DTwA ontology is obtained, it has to be referenced in the instantiation of the DTwA using WoTDT ontology and establish links from this ontology to the ontologies of the DTws involved in the aggregation process if the third scenario of the aggregation is performed.

Following the example shown in the previous sections, the process of aggregation of the ontologies described in the instantiation of the DTws involved in the aggregation is performed. Since both DTws belong to the COGITO project, both DTws contain the same ontology; therefore, the scenario shown in the proposed example follows the first scenario proposed in the aggregation method. As both ontologies are the same, the DTwA should reference them in its instantiation using WoTDT ontology. This example can be found in Figure 14.

• Mappings Aggregation

Mapping models allow us to represent the relationships between the data model in heterogeneous sources and an RDF version that follows the schema of an ontology; i.e., they define the rules on how to translate from non-RDF data into RDF [49].

The goal of the mappings aggregation activity is to perform an aggregation between two mapping models to obtain a single mapping model that follows the ontology obtained from the ontology aggregation activity and also contains all the transformation rules to materialise non-semantic data into semantic data (e.g., RDF). This activity involves the DTwA user performing the aggregation process and the domain experts providing information about the mapping rules that follow the ontology domain. The output of this activity is a mapping model resulting from the aggregation of the mapping models of the DTws involved in the aggregation process and its reference in the instantiation of the DTwA using WoTDT ontology.

Sometimes, in contrast to previous aggregations, this aggregation may not be necessary. This is because instead of aggregating the mapping models for the subsequent materialisation of the knowledge graph of the DTw, the aggregation of the knowledge graphs belonging to the DTws involved in the aggregation process is done directly. In this way, the knowledge graphs will be aggregated, obtaining the DTwA knowledge graph (scenario 2 of Section “Semantic Resources Aggregation”), and in the case of extension, it will be enough for the domain experts and the DTwA user to create new mapping models containing the rules for the materialisation of the new information to be incorporated into the DTwA knowledge graph. Regardless of this case, in this section, the aggregation of the mapping activity will be performed.

As mapping models are ontology-based, the same three scenarios explained earlier in the ontology model aggregation are of interest. In the first two scenarios, the mappings models do not have to be aligned/processed to make the aggregation because the ontologies are linked, and no alignment process has been performed in the ontology aggregation step. The difference is that instead of obtaining the data from a single data source, the mappings obtain it from two data sources, one from each DTw involved in the aggregation. Therefore, DTws mappings have to be referenced by DTwA instantiation using WoTDT ontology. Meanwhile, in the third scenario, a merging of these mapping models and an extension has to be performed, creating new rules in order to satisfy the newly created links between the ontologies obtained from the alignment process. In Figure 15, the workflow of this activity is presented depending on the particular aggregation scenario.

In order to perform the merging process, when dealing with mapping models, there is no literature on how two mapping models should be merged. Therefore, a possible solution could be the use of the instance matching method since mapping models are mostly written in RDF language. Instance matching is the problem of identifying pairs of entities (equivalently, instances) that refer to the same underlying entity [50]. For this purpose, numerous approaches have been proposed in the literature [50,51,52]. Furthermore, in the OAEI organisation mentioned above, there are challenges (OAEI Instance and schema matching 2023: https://oaei.ontologymatching.org/2023/, accessed on 18 May 2024) where instance matching tools are tested every year, proposing datasets for experimentation.

Once the instance matching process is performed, the DTwA user has to extend the mapping models with new rules to satisfy the new conceptualisation obtained from the ontology aggregation process. Moreover, between mapping models belonging to different DTws, there may be different naming practices of the URIs for the instances obtained from the materialisation process. Therefore, it is necessary to choose a naming practice for standard instances [53,54] so that in the materialisation process of the resulting DTwA obtained from the aggregation process, the URIs of the knowledge graph contain a specific naming pattern. Consequently, independently of the scenario in which the aggregation is involved, the rules that contain the mapping models have to be modified to contain the new naming strategy chosen for the URIs of the knowledge graph of the resultant DTwA. Finally, the resultant mapping from the aggregation process has to be referenced in the instantiation of the DTwA using WoTDT ontology and establish links from this mapping model to the mapping models of DTws involved in the aggregation process.

Building on the examples provided in earlier sections, the process of aggregation of the mappings described in the instantiation of the DTws involved in the aggregation is performed. Since both DTws belong to the COGITO project, both mappings contain the same translation rules; therefore, the only thing that needs to be added to these is the acquisition of data from the different data resources used by the different DTws involved in the aggregation. As both mappings are the same, but the data resources from where both DTws obtain their data have been added to the mapping used by the DTwA, in the instantiation of the DTwA shown in Figure 16, a new instance has been created for the DTwA mapping model incorporating the changes, and the reference to the mapping models of the DTws involved in the aggregation.

• Shapes Aggregation (SHACL Shapes)

As explained earlier in this article, the aggregation of the shape models uses SHACL shapes. The goal of the SHACL shape aggregation activity is to perform aggregation between two SHACL shape models to obtain a single SHACL shape model. This model has to follow the ontology obtained from the ontology aggregation activity and also contains all the restriction rules to validate the semantic data that are stored in the Knowledge Graph of the DTwA. This activity involves the DTwA user performing the aggregation process, and the domain experts providing information about the validation rules and constraints that are useful to validate the knowledge graph of the DTwA. Therefore, the output of this activity is a SHACL shape model that contains all the validation rules and constraints that allow for the validation of the knowledge graph of the resultant DTwA. Furthermore, this SHACL shape model should be referenced in the instantiation of the DTwA using WoTDT ontology.

In addition to mapping models, SHACL shape models are ontology-based; therefore, the three aggregation scenarios that are in the ontology model aggregation will also be in the shapes model aggregation. For the first and second scenarios, no merging process is needed because the aggregated ontologies are already aligned. Therefore, the DTws shapes have to be referenced by the DTwA instantiation using the WoTDT ontology. However, in the third scenario, a merge between the SHACL shapes models has to be performed since the ontologies have been aligned previously, as well as the generation of new restriction rules in the case that the ontologies have been extended. In Figure 17, the workflow of this activity is presented depending on the particular aggregation scenario.

With the goal of performing the merging process between SHACL shapes models, there is no literature on how two mapping models should be merged. However, a possible solution could be the use of the instance matching method, as well as in the mapping models aggregation section, since SHACL shape models are written in the RDF language.

Once the instance matching is performed, the DTwA user and the domain experts should analyse the constraints of each pair of related instances from the instance matching process and compare each of the constraints that each of them contains. After comparison, the DTwA user decides which constraints to keep to satisfy the needs to be covered by the DTwA. An example of this decision can be if there is a constraint for an instance of sh:minCount equal to “2”, and in the other shape model, there is a constraint for the same instance of “sh:maxCount” equal to “1”. For these instances, the user can select one of them or instead create a new constraint that may include the two constraints, like, for example, sh:minCount equals “1”.

Once this instance matching process has been performed, the DTwA user has to validate the SHACL shape obtained from the aggregation to ensure that their syntax is correct. For this purpose, the SHACL standard provides specific shapes (SHACL shapes validation: https://www.w3.org/TR/shacl/#shacl-shacl, accessed on 18 May 2024) to validate the syntax of the generated shape graphs.

Furthermore, since a specific naming pattern has been chosen for the URIs of the DTwA instances, as explained in the mapping model aggregation, the instances and their respective restrictions existing in the shapes should be modified to validate the instance URIs with the new naming strategy. Finally, the resultant SHACL shape model from the aggregation process has to be referenced in the instantiation of the DTwA using the WoTDT ontology and establish links from this SHACL shape model to the SHACL shape models of the DTws involved in the aggregation process.

Returning to the examples of the previous activities, the process of aggregation of the SHACL shape models described in the instantiation of the DTws involved in the aggregation is performed. In addition to previous aggregation activities, both DTws belong to the COGITO project; therefore, both SHACL shape models contain the same SHACL shape models. As both SHACL shape models are the same, in the instantiation of the DTwA shown in Figure 18, the reference to the SHACL shape model used by the DTws involved in the aggregation should be referenced in the DTwA using the WoTDT ontology.

4.3.2. Resource Aggregation

Data resources represent all data information stored in the DTw [8]. The goal of this activity is to aggregate the data resources from the DTws involved in the aggregation to obtain the DTwA data resources. This activity involves the DTwA user performing the aggregation between the data resources of the DTws and obtaining the DTwA data resources. Moreover, this activity also involves domain experts to provide support in the data resources aggregation process. These data resources are divided into non-semantic and semantic data resources; therefore, an activity has to be performed for each of them.

Non-Semantic Data Resource Referenciation

The goal of the non-semantic data resources referenciation activity is to reference all the non-semantic data resources of the DTws involved in the aggregation within the DTwA instantiation using WoTDT ontology. These data should be referenced so that the mapping models and the service in charge of the materialisation can be found with the aim of performing the materialisation process to obtain the semantic data. This activity involves the DTwA user and the domain experts selecting which of the non-semantic data resources from the table developed in Section 4.1 can be useful for the resultant DTwA. Once the non-semantic data sources are selected, these are referenced in the instantiation of the DTwA data resources using WoTDT ontology. Therefore, the output of this activity will be the instantiation of the references to the non-semantic data resources that are of interest for the resultant DTwA.

Furthermore, in case new non-semantic data resources are needed for the DTwA, the DTwA user should reference them in the DTwA data resources instantiation.

In Figure 19, a reference to non-semantic data resources from the DTw pilot in Munich is referenced in the instantiation of the DTwA.

Semantic Resource Aggregation

In case the DTws involved in the aggregation process contain semantic data resources, a process different frpm the one described in Section “Non-Semantic Data Resources Referenciation” shall be conducted. The semantic data resources of this dimension are represented by the knowledge graph (KG), which (i) follows the ontology model conceptualisation, (ii) is obtained from the materialisation process using the mapping models, and (iii) is validated with the shapes models.

The goal of applying the aggregation method to the semantic data resources is to obtain a single knowledge graph that contains all the information of the DTws involved for the correct performance of the new DTwA. The activity involves the DTwA user and the domain experts first selecting the KGs from the DTws involved in the aggregation that can be useful for the DTwA and then performing the aggregation process between them, to be able to have links between both KGs in a single KG. After selecting and aggregating the KGs, they should be referenced in the DTwA instantiation using the WoTDT ontology. This includes both KGs of the DTws involved in the aggregation and the KG derived from the aggregation activity. Therefore, the output of this activity is to acquire a KG for the DTwA obtained from the aggregation of the KGs of the DTws involved in the aggregation and referenced during the instantiation of the DTwA.

To perform the aggregation of the KGs of different DTw, there are two scenarios. The first scenario consists of applying instance matching, where in the literature, approaches such as the use of neural networks [55,56], genetic algorithms [51], or hybrid approaches [57]. Once the instance matching process has been performed, in contrast to earlier aggregation activities, a validation step can be performed to verify whether the aggregated KG is correct using the aggregated SHACL shapes models from the shapes model aggregation activity. In case the resultant KG is not valid, the instance matching process has to be performed again.

The second scenario involves the materialisation of the KG of the resultant DTwA. This materialisation process is performed by using the mapping models already aggregated from the mapping models’ aggregation step. Similarly to the initial scenario, the KG triples produced during the materialisation process undergo a validation phase, where the aggregated SHACL shapes are used to determine their validity.

Furthermore, the new KG obtained from the aggregation process has to follow the URI naming strategy chosen at the aggregation of the mapping models in such a way that when the validation process is performed, it does not detect any error in the URIs, and they can be published by the new DTwA.

Finally, the instantiation of the resultant DTwA shall reference the new KG obtained from this aggregation activity using the class of dtw:Resource.

In Figure 20, the workflow of this activity is presented depending on the particular aggregation scenario.

Following the examples of the previous activities, the process of aggregation of the KGs described in the instantiation of the DTws involved in the aggregation is performed. Once the aggregation activity is conducted, the instantiation of the new KG referencing the ones involved in the aggregation is represented in the DTwA instantiation using the WoTDT ontology. This instantiation can be seen in Figure 21.

Interaction Affordance (Service) Referenciation

The service interaction affordances describe all the services and functionalities used by the DTws that are aggregated [8]. These descriptions allow for the access and discovery of the different features that the services provide. The goal of the interaction affordances referenciation activity is to reference all the interaction affordances that describe the access to the services of the DTws involved in the aggregation activity, which are necessary to perform a specific process in the DTwA. This activity involves domain experts and the DTwA user to select which of the interaction affordances of the services from the table developed in Section 4.1 can be useful for the resultant DTwA. Once the interaction affordances are selected, these are referenced in the instantiation of the DTwA models using the WoTDT ontology.

Therefore, the output of this activity will be the instantiation of the references to the interaction affordances of the services of the DTws involved in the aggregation that are of interest to the resultant DTwA. Furthermore, if necessary, new references to the services deployed in the new DTwA have to be created to perform the particular processes of the DTwA.

In Figure 22, an instantiation result obtained from the referentiation of services interaction affordances activity can be shown. In this case, two interaction affordances from the Munich DTw that refer to the validation of a knowledge graph and the registration of a SHACL shape have been referenced.

4.4. Connections Creation

As explained in Section 3.2.6, the connections in a DTw are unique; therefore, the goal of this activity is to provide a new set of connections that represent the different relations between the other dimensions of DTw. These connections are divided into external and internal connections depending on the viewpoint of the DTw. This activity involved the DTwA user, who will be responsible for creating and registering the different connections that exist within the DTwA based on the existing connections in the tables described in Section 4.1 belonging to the DTw involved in the aggregation. Therefore, the output of this activity is the creation of the connections that exist between the different dimensions of the DTwA, internally and externally, to the DTwA, and the instantiation of these connections using the WoTDT ontology.

In Figure 23, an example of the instantiation of a connection is shown using the WoTDT ontology. In this case, a connection is created between the ontology model instantiated in Section 4.3.1 and the knowledge graph instantiated in Section 4.3.2. This connection represents that the conceptualisation of the data resource has been modelled according to the ontology.

Once all aggregation methods have been applied, the resulting DTwA metadata using WoTDT ontology is described as shown in Figure 24, where most of the aggregations performed are referenced.

4.5. DTwA Maintenance

The goal of DTwA maintenance activity is to update the DTwA during its lifecycle. During this lifecycle, potential situations may occur. These situations are bug detection, which also includes suggestions and improvements, and the addition of new information to the different dimensions of the DTwA, such as new models, new data sources, new services, or new connections. In both cases, this activity is carried out by the DTwA user, who is responsible for detecting the different bugs or new information added to the new DTwA to perform the respective solution by performing the activities corresponding to the workflow described in Figure 5.

5. Conclusions

DTws are a powerful solution that enhances the accuracy of needed predictions to be improved, making more logical decisions and developing well-informed plans. However, there is no standard architecture that provides a precise definition of a DTw and offers guidance for its development. In the literature, numerous research proposals describe their architecture using a three-dimensional model [7]. Subsequently, a new proposal introduced an expanded model of DTw in five dimensions [8], enhancing the comprehension of the DTws architectures. However, DTws lack formal semantics, hindering their interoperability with external third-party DTws or services.

To address this issue, the WoTDT ontology has been developed as an extension of the Thing Description ontology suggested by the W3C Web of Things group. This standard facilitates the description of services and enhances interoperability, discoverability, accessibility, security, and scalability. Consequently, this ontology will enable a more accurate understanding of DTws and will provide direct access to all system functionalities for the specified DTw.

Moreover, even though the examples used in the article focus on the DTw construction domain, since the model used to conceptualise the DTw architecture (five-dimensional model [8]) is applied for generic DTws, this conceptualisation can be applied to DTws from different domains. Therefore, thanks to the reuse of ontologies in WoTDT, such as DCAT and W3C WoT Thing Description, which have not been developed for a particular domain, the WoTDT ontology has the flexibility to conceptualise DTws belonging to different domains. This can be done by extending the ontology by incorporating new additional subclasses into classes related to different dimensions, e.g., the addition of subclasses to represent new non-semantic models, such as energy or simulation models. However, introducing these new requirements could lead to problems that might trigger changes in the ontology. Hence, an opportunity for future research lies in expanding the ontology to include diverse information from multiple domains.

Furthermore, when dealing with the aggregation of multiple DTws, in the literature, there are numerous approaches, such as Grieves’ [3] and Qi’s [14] proposals, but the method in which the authors propose an aggregation where multiple DTws are aggregated in a single one (DTwA) is not present. Therefore, this article presents, together with the WoTDT ontology, a novel approach in which the authors propose an aggregation methodology, called DTAG, for the aggregation of DTws, which considers whether the DTw contains semantics or not.

DTAG follows the dimensional aggregation according to the five-dimensional model of Tao and Zhang, where WoTDT ontology is applied. Therefore, this approach, distinct from those aggregations presented in the literature, allows the aggregation of both metadata and data (whether semantic or non-semantic) from various DTws within a DTwE. This results in the creation of a DTwA that contains all metadata, centralised thanks to the WoTDT ontology, along with all data related to the DTwIs or DTwAs of the DTwE involved in the aggregation process.

Furthermore, the aggregation method allows the creation of DTwE. In the case of Section 4, it shows the aggregation of two DTws of construction pilot sites in a DTwA of the construction-related project.

An additional advantage of using the WoTDT ontology in the DTAG aggregation methodology is the enhanced comprehension of the aggregation data itself, i.e., where each DTw comes from and how the DTwA has reached the aggregated state.

At the same time, there is no loss of specificity because DTws are not removed in the aggregation activity. Instead, a DTwA is created that includes them. Therefore, the DTws involved in the aggregation can still operate without the need to access them through the DTwA.

As a disadvantage, the aggregation process of a DTw that contains restrictions on access to its data might be performed partially in some cases, and in others, the aggregation cannot be performed directly.

Another disadvantage is that since the methodology has various roles involved in the aggregation of DTws, it cannot be automated; therefore, it always requires a user or developer to be involved in the aggregation activity.

For future research directions, the framework responsible for the aggregation process shall be implemented. Furthermore, the experimental application of the suggested aggregation methodology could be applied in settings where there is a need to perform the aggregation procedure for DTws encompassing diverse ontologies or even DTws from different domains. Finally, as future work, this ontology shall be applied to different domains in order to validate its flexibility in terms of its applicability to DTws belonging to domains other than the one proposed in the article.