Analyzing Contextual Linking of Heterogeneous Information Models from the Domains BIM and UIM

Abstract

Information models from the domains Building Information Modeling (BIM) and Urban Information Modeling (UIM) are generally considered as information silos due to their heterogeneous character. These information silos can be bridged through linking where corresponding objects are identified and linked subsequently. However, whether two objects are considered as corresponding might depend on the scenario for which the links are created. The dependency of the link creation and the scenario refers to the term contextual linking and is analyzed in this paper with respect to building and city models. Therefore, different situational aspects influencing the link creation are discussed. Afterwards, the issue of contextual linking is demonstrated based on three different integration scenarios. In summary, this paper has three major outcomes: First, this paper introduces an application-oriented perspective on information integration and emphasize the role of the application when linking heterogeneous information models. Second, this paper shows that linking heterogeneous information models from the domains BIM and UIM at instance level depends on the scenario. Third, the results of the discourse about contextual linking serve as a framework supporting the design and development of artifacts for linking heterogeneous information models from the domains BIM and UIM.

1. Introduction

Integrating information models from the domains Building Information Modeling (BIM) and Urban Information Modeling (UIM) aims to bridge information silos caused by the heterogeneous character of these information models [1,2,3,4,5,6]. A significant reason for the heterogeneous character of information models from the domains BIM and UIM is the diversity of their underlying perspectives and purposes [3,4,5,7,8]. While the domain BIM primarily describes real-world objects such as buildings from prescriptive view for design and maintenance purposes, the domain UIM describes real-world objects such as cities from descriptive view for spatial analysis [3,4,5,7,8]. An integration method able to bridge information silos caused by the heterogeneity between information models from these domains is linking of information models at the instance-level.

The applicability of the integration method linking for integrating information models from the domains BIM and UIM was originally demonstrated more than a decade ago [9,10] and afterwards, several times confirmed for different integration scenarios [11,12,13,14,15,16]. For successfully linking two information models at instance-level, such as building and city models, corresponding objects from both models need to be identified and linked subsequently. The resulting set of links is called alignment. However, linking heterogeneous information models at instance-level is generally not straightforward since the corresponding objects often do not match exactly [4,12,17,18]. In other words, information represented by one object does not necessarily hold for the corresponding object. This drawback means that the alignment relating these information models might depend on the respective scenario: Is an alignment created for Use Case A also valid for Use Case B? Is an alignment relating two information models also valid after updating one information model? This dependency between alignment and its application scenarios understood as contextual linking and analyzed in this paper.

To the best of the authors’ knowledge, contextual linking is not considered in research literature about linking heterogeneous information models from the domains BIM and UIM. Instead, the respective integration solutions are generally developed for specific application scenarios without having other scenarios in mind [2]. This limited perspective on information integration causes isolated, partial integration solutions what is opposed to an ideal, holistic integration solution. Overall, this paper aims for three major outcomes: First, this paper aims to introduce an application-oriented perspective on information integration that serves as a basis for the subsequent discourse about contextual linking. Second, this paper aims to show that a purposeful alignment at the instance-level between heterogeneous information models from the domains BIM and UIM depends on the application scenario for which the alignment is created. Third, the results of the discourse about contextual linking shall serve as a framework supporting the design and development of artifacts for linking heterogeneous information models from the domains BIM and UIM.

The paper is organized as follows: In the next chapter, literature about contextual linking in the field of Semantic Web and information integration across the domains BIM and UIM are reviewed. Afterwards, a new perspective about integrating information models is introduced, called the application-oriented perspective. Following this application-oriented perspective, the application for which the information models are aligned is considered as being significant for the design of the alignment and serves as a basis for the discourse about contextual linking. In the next chapter, the concept of contextual linking is introduced and aspects influencing the alignment creation are analyzed. Afterwards, the validity of the developed concept of contextual linking is demonstrated using illustrative examples. In the last chapter, the outcome of this paper and future research investigations are discussed.

2. Related Literature

2.1. Contextual Linking

Linking information from different domains is the subject of several (mostly) independent research areas related to computer science such as database engineering, model-driven engineering, ontology engineering, or semantic web. These research areas refer to different kinds of integration subjects (like databases, ontologies, thesauri, information models) and use different terminologies for both the link creation (like record linkage, entity resolution, object identification, model weaving, instance-level matching) and the resulting set of links (like alignment, weaved model, link model) [7,19,20,21]. Similarly, the term context has no common meaning across and within these research fields. This ambiguity of terminologies makes the literature research about contextual linking complicated such that an exhaustive literature research across all related research areas is out of the scope of this research investigation. Instead, the literature research was limited to the research area Semantic Web which was chosen due to two aspects: first, contextual linking is a current research subject in the research area of Semantic Web [22,23,24]. Second, Semantic Web technologies are currently discussed for integrating information models across the domains BIM and UIM [7,11,12,25,26]. In the field of semantic web, corresponding information is linked through a link predicate. This correspondence is called triple and generally expressed using formal languages such as Resource Description Framework (RDF) [27] and Web Ontology Language (OWL) [28]. There are three different research directions referring to the term contextual linking in the research area semantic web: alternative link predicates, limited validity scope of an alignment, and enriching the alignment with meta-data.

• Alternative link predicates address the issue of the strict meaning of the link predicates provided by RDF/OWL. For instance, the link predicate such as owl:sameAs suggest that everything state about one object holds for the corresponding object. This suggestion is not always adequate which is why alternative link predicates are utilized. An example for alternative link predicates are vocabularies provided by Contextualized OWL (C-OWL) [24] which covers five different relation types, namely disjoint ($\perp$), equivalence ($\equiv$), related ($*$), more abstract ($\subseteq$), and more specific ($\supseteq$). Further alternative link predicates are provided by the simple knowledge organization system (SKOS) [29] and similarity ontology (SO) [30];
• There are two approaches for limiting the validity scope of an alignment. First, the alignment refers only to a subset of the original knowledge graphs. For instance, Raad et al. [31] and Beek et al. [31,32] limit the alignment to subgraphs such that the links become valid. Additionally, Idrissou et al. [33] categorize properties of corresponding entities which corresponds to the semantics of an identity relation. Second, the alignment refers to a specific application scenario such as some time period or perspective. As an example, the statement that Barack Obama is President of the United States is only true for a certain time period. In OWL^C [23], two-dimensional description logics are used to make this kind of validity scope explicit;
• The third direction enriches links or alignments with metadata. This kind of meta data is often called contextual information. C-OWL [24] and the alignment language Expressive and Declarative Ontology Alignment Language (EDOAL) [34] enable this kind of enrichment through patterns for correspondences (called bridge rules and cells respectively). The Vocabulary of Interlinked Datasets (VoID) [35] is designed to store a set of correspondences separated from the datasets such that data can be added describing this set of correspondences (called linkset). Besides these patterns, there are a variety of approaches aiming to syntactically enrich RDF statements with meta-data, such as SingletonProperty [36], named graphs [37], and RDF* [38]. As an example, Idrissou et al. [33] use singleton properties and VoID to enrich links with information about matching methods such that the links become more detailed.

In summary, these research directions about contextual linking have in common that they aim to avoid erroneous reasoning in a certain context, such as erroneous reasoning caused by wrong utilization of identity links (see alternative link predicates) or caused by missing information about the application scenario in which the alignment is valid (see limited validity scope). However, the literature following these research directions lack a detailed analysis of why some reasoning formulae are erroneous in a certain context. The following discourse about contextual linking is an approach aiming to fill this gap with respect to linking information models from the domains BIM and UIM.

2.2. BIM-GIS Integration

Building and geospatial data are generally represented in the computer-based information systems Computer Aided Design (CAD) and Geospatial Information Systems (GIS) respectively. The usage of building data in terms of digital representation of a building through the whole life-cycle is called Building Information Modeling (BIM) [39,40]. The establishment of BIM in the digital discourse of both industry and research about Architecture Engineering Construction (AEC) has led to the common keywords “BIM-GIS Integration” or “GeoBIM”. However, major issue of these keywords is that they do neither specify what is integrated (called integration subject). This issue is emphasized by the inhomogeneous comparison of BIM and GIS, since BIM rather refers to a method while GIS refers to an information system. Another issue of these keywords is that they do not specify how these subjects are integrated (called integration method) [1,2].

• Integration subjects: Exemplary integration subjects are processes, software products, or information models [1,2,41,42]. The most common integration subjects in the field of “BIM-GIS Integration” are two information models, namely Industry Foundation Classes (IFC) [43] and CityGML [44,45]. IFC is generally associated with the domain BIM and aims to support the information exchange between proprietary software products in the whole life cycle of a building project. On the other hand, CityGML is generally associated with the domain GIS and is an application schema of the Geographic Markup Language (GML) [46] aiming to support modeling, storage, and exchange of city models. Other related integration subjects are the Building Topology Ontology (BOT) [47] and internal information models of software products. The integration subjects addressed in this paper are information models following the Meta-Object Facility (MOF) [48] which is composed of four layers: M0, M1, M2, and M3. The M0 layer refers to concrete instances representing real-world objects, called instance-level or instance model respectively. The M1 layer refers to instantiated object models following a formal language such as unified modeling language, called schema-level or schema model respectively. The M1 layer refers to two types of models, namely instance models and schema models. The M2 and M3 layers are more abstract layers describing the structure of the layer below but are not further addressed in this paper.
• Integration method: Instance or schema models are integrated by means of an integration method. In the field of “BIM-GIS Integration”, the most common integration methods are converting, extending, merging, and linking [1,2,7] (Figure 1). This paper focuses on the integration method linking at instance-level. Remarkably, information integration through linking is a research topic in computer science since the late 1950s [49], called record linkage. Thus, the integration of data through linking is a rather long-established topic in the research field of computer science. More than a decade ago, the integration method linking was transferred for linking information models across the domains BIM and UIM [9,10].

To the best of the authors’ knowledge, there are no publications related to the term contextual linking in the research area referenced by the keywords “BIM-GIS Integration” or “GeoBIM”. Instead, three subjects relevant for this research investigation were reviewed in detail: use cases, heterogeneities, and instance-level alignments.

• Use cases: The literature research about use cases aims to provide an understanding of the role of the application in the information integration process. There are several different approaches to categorize use cases [42,50,51,52,53] whereby these approaches do not follow a certain structure. Common use cases are navigation scenarios where outdoor and indoor paths need to be combined [13,54], utility management where utility infrastructure at building and city scale is connected [55,56], environmental assessment where environmental data such as noise or water emissions are integrated with building information [57,58,59] and optimization of infrastructure alignments where topological and cadastral maps are related to the geometrical representation of an infrastructure alignment [9,15,60,61,62]. Conclusively, the reviewed use cases have in common that they all require information from two different information models but differ regarding the integration method and the perspective from which the information is integrated, such as integrating from BIM or GIS perspective;
• Heterogeneities: In research literature about “BIM-GIS Integration”, there are three different approaches describing the heterogeneity between information models. These approaches generally refer to the comparison of IFC and CityGML. First, accumulating differences from a general perspective [5,7,8,42,63,64,65]. Second, following defined structures and standards. As an example, Herle et al. refers to the conceptual interoperability model (LCIM) to discuss differences between respective information models [7]. Among others, the LCIM covers technic, syntactic and semantic layers. Third, comparing specific entities of the information models [11,66,67]. As an example, El-Mekawy et al. [66] considers window entities as full match while wall entities are called partial matches. Furthermore, Nagel et al. [4] emphasize instance-level differences caused by different modeling paradigms. For instance, while beams modeled in the design phase are represented in IFC using their true dimensions (i.e., including support length), beams created from photogrammetrically methods are represented in CityGML using the visible dimension (i.e., without support length). In summary, the scope of information models IFC and CityGML models overlap at building scale, whereby not all corresponding objects can be used interchangeably due to heterogeneities and instance-level differences;
• Instance-level alignments: Explicit alignments between information models from the domains BIM and GIS are expressed either formal through modeling languages such as Semantic Web technologies [11,12,62,68,69] and UML/EXPRESS-G [70,71,72] or informal, e.g. using tables [73,74,75,76] or text/figures [66]. These alignments either refer to schema- or instance-level of the information models whereby this paper primarily addresses instance-level alignments. As an example for instance-level alignments, Hijazi et al. [77] relate IFC and CityGML models utilizing a relation table in which GMLIDs of CityGML buildings are related to IFC models. Hor et al. [68] propose a method to link IFC and CityGML models using semantic web technologies and the concepts equivalent, as-is, and has an attribute. Huang et al. [78] use the concept skos:exactMatch from the SKOS vocabulary to relate window objects represented as ifcOWL or BOT and CityGML. Vilgertshofer et al. [16] map the globalID of IFC elements to the gml:id of CityGML element using semantic web technologies without specifying any link predicate. Stepien et al. [15] make use of topological relationships to link several different models such as city models and cadastral maps to an infrastructure alignment of a tunnel using semantic web technologies. Overall, alignments between instance models are expressed through several approaches such as tables or formal languages. Furthermore, instance-level alignments relating information models from the domains BIM and GIS differ regarding their link predicates and the connected objects.

In summary, linking heterogeneous information models at instance-level is part of current research investigations in the research field of “BIM-GIS Integration”. However, the influence of contextual variables such as use cases or heterogeneities on the alignment creation is not explicitly considered in these research investigations. Instead, the alignments are designed isolated from each other for specific integration problems such that the problem of contextual linking is not apparent in the research field of “BIM-GIS Integration”.

3. Application-Oriented Perspective

A decisive aspect for understanding contextual linking is a change in perspective regarding the alignment design, from the data-oriented to an application-oriented perspective. Roughly spoken, an application-oriented perspective means that the design of the alignment starts with the application in mind instead of with data. The application-oriented perspective emphasizes the role of the application on the alignment creation and is described through the following model. In this model, the need for information integration comes from the application scenario in which a function requires instance-level information represented in two different information models (Figure 2). An information model represents a set of instance-level information and is developed for a specific set of functions. A set of functions refers to the term application and represents some processes and their tasks from technological point of view. The subject’s application and information model refer to the technical layer while the subject process refers to the organizational layer of a computer-based information system [79].

In Figure 2, the left figure represents these subjects and their relationship while the right figure represents the technical layer through Venn diagrams. In the right figure, two information models are represented whereby both the set of functions for which they are developed and the set of information which they represent overlap. Following this figure, a function X demands information integration at instance-level when the required instance-level information is distributed over both instance models A.1 and B.1 (indicated by grey circles in the right figure). Remarkably, information integration at the schema-level generally supports information integration at the instance-level. For example, schema-level alignments often serve as matching criteria to create instance-level alignments. In total, there are three different constellations for which there is a need for information integration (Figure 3). In the following, these constellations are illustrated by examples and their correlation to the chosen integration methods is described.

• F$unction \in A \backslash B$ means that the function is part of A without B. All relevant information for such kind of function can be represented in A.1. The need for information integration comes from the circumstance when some of the relevant information is represented in instance Model B.1 (overlapping area). The most common integration method for these kinds of functions is converting information models, e.g., IFC to CityGML or GeoSPARQL [67,80,81,82,83] (see case Conversion in Figure 1). This is because all the relevant information can be represented in a single information model A.1. This has the key benefit that the functions being part of A can process the relevant information without additional effort. In contrast to that, the integration method linking is used when there are high requirements for data sovereignty or for the timeliness of information [84,85]. For instance, Hijazi et al. [77] link two building models represented in CityGML and IFC to avoid time-consuming preprocessing of files and prevail control about privacy rights on the data. As another example, McGlinn et al. [14] apply the linking for controlled sharing building data related to both BIM and GIS. Furthermore, Djuedja et al. [86] link information models to address the issue of simultaneous information accessibility concerning products and their environmental assessment;
• $Function \in {\left(A\cup B\right)}^C$ means that the function is neither part of application A nor B. Such kind of function might require information which lay in scope of both instance models and potentially additional external source (like information from a third information model). In other words, this kind of functions requires information that cannot be represented in a single information Model A.1 or B.1. An example refers to checking building projects against building codes provided by government agencies which require both building and geospatial information [87]. This is because some information required for compliance checking rules do not exist in CityGML (like “front yard” while others lack in IFC (like “setback distance”). Thus, compliance checking rule saying that the setback distance where there a front yard should be at least 5.00 m demands the integration of both IFC and CityGML models. There are three ways to deal with this kind of functions: First, one information model is extended to represent all information relevant for route finding [56,88,89,90] (see case extension in Figure 1). Second, the information models are merged such that all relevant information is represented in a third information model [87,91,92,93] (see case merging in Figure 1). Third, the information models are linked such that all relevant information can be accessed through an alignment connecting both information models. Examples for linking information models for this kind of function are evacuation scenarios [68,94] and supply chain management [95] for which information models representing indoor and outdoor environments need to be integrated. More examples are the calculation of performance indicators for energy analysis [96], route finding for highways [62], and the enrichment of IFC models with innovative energy façade components such as building-integrated solar thermal [11], or the “sniper example” from homeland security [89];
• $Function \in A\cap B$ means that the function refers to the overlapping area of application A and B. The relevant information here refers to the overlapping area of both instance models. This is because both information models are developed to represent the relevant information for these functions. This is applicable for the indoor navigation scenarios where the relevant indoor information can be represented by both IFC and CityGML [97,98]. Another example is checking the consistency of two information models to communicate model modifications. For instance, consistency checks after the handover of building information (e.g., IFC) to a city model (e.g., CityGML) [99] or in the field of railway infrastructure [100].

The application-oriented perspective on information integration based on the described categories corresponds to research in the field of “BIM-GIS Integration”. This correspondence is demonstrated by the following three examples:

• First, the need for information integration as described in the previous section corresponds to Hijazi et al. [2] who state that the information integration aims to support business processes that require information from both domains. Furthermore, some authors argue that there is a need for “BIM-GIS Integration” because both domains deal with similar information [2,6,101] while others argue that these domains deal with different information [2,51,52,101,102,103]. The former type of argumentation corresponds to the categories F$unction \in A \backslash B$ and $Function \in A\cap B$ while latter correspond to the category $Function \in {\left(A\cup B\right)}^C$. As an example for the latter type of argumentation, Rich and Davies [102] state that utility networks do not stop at the outside of the building such that the exterior and the interior need to be integrated;
• Second, the categories corresponding to the publications state that there is either one dominant domain in the integration process (e.g. BIM leads, GIS supports) or both domains are equally involved [53,89]. Here, one dominant domain in the integration process refers to the application scenario that a function implying information integration clearly refers to one domain either BIM or GIS (F$unction \in A \backslash B$). Two domains being equally involved mean that either the function does neither refer to the domain BIM nor GIS ($Function \in {\left(A\cup B\right)}^C$) or that the function refer to both domains ($Function \in A\cap B$);
• Third, the application-oriented perspective illustrates why the terms integration and interoperability are often synonymously used in research literature dealing with information models from the domains BIM and GIS [104]. As an example, the methods conversion, linking, and merging are called by some authors interoperability approaches [7] while others refer to integration approaches [2]. Roughly spoken, interoperability in the scope of information modeling means the ability of software products to exchange information and to process this exchanged information [105]. In more detail, interoperability is only required when a function of a software product demands information from the internal information model of another software product. These kinds of functions correspond to the categories F$unction \in A \backslash B$ and $Function \in A\cap B$. In other words, a function demanding interoperability between software products also demands the integration of their internal information models (Figure 4). The integration of internal models can be achieved directly or through one or more external models, whereby the data flow from one model (independent of external or internal) to another is considered as integration process itself. This circumstance leads to some unclearness: Are the information models linked to integrate information models or to achieve interoperability between the software products? As a remark, there are further aspects causing an ambiguous use of the terms interoperability and integration such as missing specification of the interoperability subject (like processes or software products) and the integration subject (like processes, information models, functions) [1,41,42].

In summary, the application-oriented perspective emphasizes the role of the application on the alignment creation. In more detail, the application-oriented perspective on information integration shows that instance-level alignments relating two information models aim to fulfill the requirements coming from the function for which the information models are integrated. Or the other way around, the functions of the applications determine the alignment creation. This dependency between application and alignment creation is relevant for the following discourse about contextual linking.

4. Contextual Linking

4.1. Conceptualization

The term context has different meanings across and within research fields related to information integration. In the field of semantic web technologies, context might be understood as locally created information models which encode a party’s view of a domain [24] or limited validity scope of an alignment [33]. Coming from a more general perspective, Abowd et al. [106] define context as “any information that can be used to characterize the situation of an entity, where an entity can be a person, place, or physical or computational object.” Here, this conceptualization is adopted while the entity of interest is the alignment relating two information models at the instance-level. Thus, context (or contextual information) refers to all kinds of information describing the application scenario of such an alignment such as meta-data about authorship or about matching algorithms.

In this regard, contextual linking refers to the alignment creation depending on the context. The created alignment is called contextual what means that it solely holds in the context for which it was created. For instance, different contexts might require different link predicates between corresponding objects. Conclusively, two contextual alignments differ from each other. This alignment difference can be expressed by arithmetic operations on these alignments, whereby the alignments are represented as bipartite graphs using adjacency matrices. According to the literature research about contextual linking in the research area semantic web, the explicit formalization of the context aims to avoid erroneous reasoning following misleading links. For instance, the explicit formalization of the context can partly be achieved by several methods such as enriching the link with meta-data or defining explicitly the validity scope of the alignment.

A necessary requirement for the occurrence of contextual linking is the misfit of the instance models. This requirement becomes clear by illustrating the opposite: when all corresponding instances of two information models would share full identity then there is a single, clear alignment between two information models. The mismatch of instance models is also considered as instance-level conflicts and instance-level heterogeneities [107] or contextual phenomena [108]. A significant reason for the mismatch of the instance models is the heterogeneity of their underlying information models (Figure 5). Apart from that, mismatches between instance models can be caused by aspects such as different types of data acquisition or modeling rules. For instance, the geometrical representation of a wall modeled based on photogrammetric data acquisition differs from a simplified geometrical representation of the same wall modeled in the design phase [4,15].

The alignment creation at instance-level is in the first place influenced by two types of contextual information: model-oriented aspects, and application-oriented aspects (Figure 6). Model-oriented aspects refer to information describing the aligned information models such as time of creation or type of data acquisition. On the other hand, application-oriented aspects refer to the requirements coming from the functions for which the alignment is created such as requirements for timeliness of the linked information. Contextual linking caused by application-oriented aspects is called application-driven contextual linking while contextual linking caused by model-oriented aspects is called model-driven contextual linking.

4.2. Application-Driven Contextual Linking

Application-driven contextual linking occurs when different functions require different alignments relating two instance models (Figure 7). These kinds of requirements can be categorized into information requirements and structural requirements. Information requirements refer to requirements for the information to process the function properly such as completeness, timeliness, or accuracy [109]. On the other hand, structural requirements address the structure of the alignment such as the alignment language, the syntactical representation, or the kind of correspondence. Here, the kind of correspondence refers to aspects such as the granularity level at which the correspondence is established or the required degree of similarity between the corresponding objects. In the following, four application-oriented aspects are described in more detail, namely timeliness, accuracy, granularity, and similarity.

• Timeliness: Contextual linking due to timeliness becomes relevant when dealing with static and dynamic data. For instance, the number of pillars of a bridge does not change over time while its damage symptoms do. Querying damage symptoms (Function 1) has higher requirements for the timeliness of the instance models than querying the number of pillars of a bridge (Function 2). Thus, an alignment relating two bridge models is prone to be misleading (Alignment 1) when querying damage symptoms but generally correct (Alignment 2) when querying the number of pillars of a bridge;
• Accuracy: Different functions might require different accuracies of information. In other words, some functions consider the integrated information as “close enough” while others do not. As an example, from research literature, information models created in the scope of BIM generally employ orthogonal coordinate systems, while information models created in the scope of GIS use different georeferencing systems taking the curved earth surface into account. Whether or not the discrepancies between both kinds of referencing systems can be knowingly neglected depends on the intended use and the geometric scale of the information [110]. For instance, the discrepancies for the dimensions of a railway curve insignificantly affect the driving dynamics (Function 1) but might violate a compulsory points margin such as a railways platform edge (Function 2) [110]. Linking information models for driving dynamics analysis is straightforward (Alignment 1), while linking for checking compulsory points of margin requires an evaluation of the discrepancies caused by the referencing systems (Alignment 2);
• Granularity: Contextual linking can be caused by linking at different granularity levels. As an example, some authors link IFC and CityGML models at building or project level (low granularity level) [77] with while others relate more granular objects such as specific windows to each other (high granularity level) [78]. The consequent alignment at the project level (Alignment 1) is sufficient for visualization purposes at which the IFC model replaces one whole building in a CityGML model (Function 1) [77]. On the other hand, linking of specific window objects (Alignment 2) is required for solar energy simulations (Function 2) [78];
• Similarity: Different functions might require different kinds of similarity. The specification of similarity is challenging but can be derived from Leibniz’s laws about the identity of indiscernible [111]. According to the law of indiscernible, two objects are identical when they share all of their properties. Following this understanding, two objects might be considered as highly similar when they share many of their properties, and low similar when they share few of their properties. Some functions require identity or high similarity between corresponding objects (Alignment 1) such as reasoning or consistency checks (Function 1) across several information models. On the other hand, some functions do not require this kind of similarity such as the identification of topological relation between spatial objects. As an example for the latter kind of functions, Stepien et al. [15] link an infrastructure alignment of a tunnel to cadastral maps (Alignment 2) to identify topological overlaps between buildings under historical preservation and the geometrical representation of the infrastructure alignment (Function 2).

4.3. Model-Driven Contextual Linking

Model-driven contextual linking occurs when a function applied to different variants or versions of an instance model causes different alignments (Figure 8). Notably, there is no common understanding of the terms variant and version [112]. In the field of CAD, the term variant often refers to instance models representing alternative solutions for a problem specification in the operative design process. On the other hand, the term version often means different instance models resulted from simultaneous, distributed modeling operations [113]. In this paper, variants are instance models representing the same real-world object in a different manner while versions are instance models representing the real-world object at different times in terms of temporal snapshots of the real-world object [99,114]. Different variants/versions are caused by instantiating different schema models (Figure 5) or instantiating one schema model differently (Figure 9). The former kind of variants/versions causes differences between instance models belonging different information Models A and B. On the other hand, the latter kind of variants/versions causes differences between instance models both belonging to one information model, here called B.1 and B.2. In more detail, model-driven contextual linking is caused by the latter kinds of variants/versions (instantiating one schema model differently).

• Variants: As an example, two different variants of a CityGML model are linked to an IFC model (A.1) created in the design phase. One CityGML model (B.1) was converted from the IFC model while the other CityGML model (B.2) was generated directly from photogrammetric methods or laser scans. The geometric dimensions of the IFC model correspond to those from the converted CityGML model (B.1) but deviate to those from the generated CityGML model (B.2). Thus, a function requiring accurate geometrical representations (Function 1) might consider the geometrical objects of A.1 and B.1 as equivalent (Alignment 1) but not of A.1 and B.2 (Alignment 2). Besides different types of data acquisitions, different variants of the same schema-model can be caused by instantiations at different detail levels [17,115,116], such as such as Level of Development (LoD) for IFC [117] or different Level of Detail (LOD) for CityGML [118]. For instance, Sun et al. [18] illustrate different variants of instance models based on CityGML whereby the variants are caused by both different data acquisition methods and different detail levels;
• Version: Different versions refer to different instance models caused by changes over time. For example, changes over time at instance-level occur due to changes to the respective real-world objects, maintenance operations (e.g., fixing geometrical errors), or new accessibility of information [82]. Differences between two versions generally raise the question if an object representing the real-world object at time t can be considered as equal to an object representing the same real-world object at time t+x [47]. Is the building before refurbishment measures the same as the building after these measures? As an example, both A.1 and B.2 represent a building after refurbishment measures, while B.1 represents the same building before these measures. A function that requires information affected by the refurbishment measure considers A.1 and B.2. as equivalent (Alignment 1) but not A.1 and B.1. (Alignment 2).

5. Demonstration

The previously developed concept about contextual linking is demonstrated through comparing the alignments of different integration scenarios. The compared integration scenarios differ regarding some model- (here: variants and versions) and/or application-oriented aspects (here: accuracy, timeliness, granularity, similarity) resulting in different alignments, called contextual linking. This kind of comparison between two integration scenarios is further called Demo. In total, there are three Demos that illustrate application-driven contextual linking (Demo 1), model-driven contextual linking (Demo 2), and their simultaneous occurrence (Demo 3). The difference regarding the model- and application-oriented aspects between two integration scenarios and the consequent alignment differences are summarized in

Table 1. Comparison of integration scenarios regarding model-oriented and application-oriented aspects.

		Demo 1		Demo 2		Demo 3
Aspects		Scenario A	Scenario B	Scenario A	Scenario B	Scenario A	Scenario B
Model-oriented	Variant	=		CityGML without door object (LOD2	) CityGML with door object (LOD3)	IFC model without tree objects	IFC model with tree objects
	Version	=		=		=
Application-oriented	Accuracy	=		=		=
	Timeliness	=		=		=
	Granularity	Querying stair steps of building	Querying stair steps on specific path	=		=
	Similarity	=		=		Querying number of trees in area	Checking consistency of similar objects
Alignment difference		Alignment at building level	Alignment of stair objects	Alignment of door to wall objects	Alignment of door objects	Alignment of building to tree objects	Alignment of tree objects
		“=” → aspect is similar

. All integration scenarios of the Demos link instance models representing parts of the campus of Technical University Munich (TUM) based on IFC and CityGML which are visualized in Figure 10 using the software tools FZKViewer [119] and 3DCityDB [120]. The instance models were syntactically translated to RDF/OWL using the IFCtoRDFConverter [121] and GMLImporter [122] respectively. One CityGML model (Model B) was created through converting the IFC Model (Model A) to CityGML and is based on Level of Detail 3 (LOD3). LOD3 means that detail information such as building installations are represented. In contrast to that, the other CityGML model (Model C) represents the whole building complex and surrounding information such as vegetation objects and is based on LOD 2. The corresponding objects were linked to each other through the link predicate skos:related [29]. Remarkably, the link predicate skos:related refers to an associative link between two SKOS concepts (here: two objects) and was chosen without a detailed comparison of available link predicates since such kind of comparison is not in the focus of this paper.

• Demo 1: Application-driven contextual linking. In Demo 1, the IFC model (Model A) and the converted CityGML model (Model B) representing the same building of TUM campus were linked (Figure 11). In both models, the stairs are represented but only the IFC model covers the number of stair steps of the respective stairs. In the first integration scenario (1.A), the total amount of all stair steps from a specific building of the building complex was queried. This query requires the linkage of the building represented in the IFC model to the respective building of the CityGML model. In the second integration scenario (1.B), the number of stair steps on a specific path in the building complex was queried what requires linking particular stair instances of the IFC and CityGML models located at the respective path. The integration scenarios refer to the same model-centric aspects since they query the same instance models. On the other hand, the integration scenarios differ regarding the application-oriented aspect granularity: While querying the total amount of stair steps requires the relationship between buildings, querying the number of stair steps of a single building requires relations between stair instances. The other application-oriented aspects are not affected: the timeliness does not matter since both queries demand static data, the similarity between the related objects does not significantly differ, and there is not a special requirement for the accuracy of the queried information.
• Demo 2: Model-driven contextual linking. In Demo 2, indoor information provided by the IFC model (Model A), and outdoor information provided by a CityGML model (Model C) were linked for navigation purposes (Figure 12). In the first integration scenario (2.A), the CityGML model is based on LOD2 what means that it does not cover openings such as doors. Thus, the exit doors represented in the IFC model were linked to the corresponding surface of the building represented in the CityGML model. In the second integration scenario (2.B), the CityGML model is based on LOD3 what means that the openings of the buildings are represented in the model. Therefore, the exit doors represented in the IFC model were linked to the respective doors in the CityGML model. The function for both integration scenarios is the same such that the application-oriented aspects do not differ between the integration scenarios. However, the integration scenarios are based on different variants of the CityGML model. While the first integration scenario refers to a CityGML model with LOD2, the second integration scenario refers to a CityGML model with LOD3. The change from LOD2 to LOD3 allows linking at a higher detail level to obtain more accurate results for the navigation scenario.
• Demo 3: Application-driven and model-driven contextual linking. In Demo 3, two integration scenarios are compared both differing regarding some application- and model-oriented aspects (Figure 13). In integration Scenario A, the IFC model (Model A) was enhanced with a planned building extension but does not cover environmental data such as trees, while the CityGML model (Model C) represents the existing building including the surrounding trees. For cost estimation purposes, the number of trees located in the area relevant for the building extension was queried. Therefore, the building extension represented in the IFC model was linked to the corresponding trees represented in the CityGML model (tree objects refer to the class SolitaryVegetationObject in CityGML). In the second integration scenario, the IFC model of integration scenario A was enriched through modeling the trees (tree objects are modeled through IfcProxy objects in this IFC model), while the same trees are also represented in the CityGML model (Model C). Here, the single trees of both information models were related for consistency checks. The integration scenarios are based on two different variants (IFC model with and without trees). Furthermore, their queries of the integration scenarios require different kinds of similarities. For the query of the number of trees in a specific area, the linking dissimilar objects such as an area and trees is allowed. However, the consistency check regarding the trees requires the linkage between trees of the IFC model and trees of the CityGML model. Therefore, the alignment in both integration scenarios differs due to both application-driven (different similarity) and model-driven contextual linking (different variants).

In summary, Demo 1 is based on application-driven contextual linking due to change of the application-oriented aspect granularity, and Demo 2 is based on model-driven contextual linking due to a change of the model-oriented aspect variant. Demo 3 is based on both application-driven contextual linking due to a change of the application-oriented aspect similarity and model-driven contextual linking due to a change of the model-oriented aspect variant. Overall, the demos show the suitability of the previously introduced concepts about contextual linking, application-driven, and model-driven contextual linking.

6. Discussion

The discourse about contextual linking of instance models from the domains BIM and UIM has three major outcomes:

• First, the discourse has introduced an application-oriented perspective in the integration of information models from the domains BIM and UIM: In contextual linking, the application for which the information is linked plays a major role. However, current research investigations about information integration see the bridging of heterogeneities between the information models as driving aspect for information integration rather than the applications. Because of that, an application-oriented perspective on information integration was introduced to emphasize the role of the application in the linking process. Following this application-oriented perspective, the need for information integration results from a function requiring information from two information models. Here, an information model is developed for a specific set of functions and represents a specific set of instance-level information. Hence, there are three different categories for which there is a need for information integration: (1) the function clearly refers to one information model; (2) to none of the two information models; (3) or to both information models. Subsequently, the validity of this application-oriented perspective on information integration was demonstrated through three exemplary correspondences in the research field of BIM-GIS integration. Conclusively, the application-oriented perspective on information integration across the domains BIM and GIS has the potential to improve the overall understanding in the research field of “BIM-GIS Integration” and served as a basis for the subsequent discourse about contextual linking.
• Second, the discourse has shown that a purposeful alignment between instance models from the domains BIM and UIM depends on the model- and application-oriented aspects describing the integration scenario, called contextual linking: as a first step, the term contextual linking itself was conceptualized, since there is no common understanding about this term within and across some field of discourse such as semantic web or “BIM-GIS Integration”. Here, the term contextual linking means the dependency of the alignment on some contextual information. These kinds of contextual information refer to application-oriented and model-oriented aspects. Thus, contextual linking caused by different application-oriented aspects is called application-driven contextual linking while contextual linking caused by different model-oriented aspects is called model-driven contextual linking. Furthermore, exemplary model-oriented (namely variants and versions) and application-oriented aspects (namely accuracy, timeliness, granularity, similarity) were described and illustrated through examples from literature research. Afterwards, the validity of the developed concept about contextual linking was demonstrated using some examples in the scope of “BIM-GIS Integration”. Conclusively, an alignment relating instance models from the domains BIM and UIM depends on both application-oriented and model-oriented aspects describing the application scenario of the alignment.
• Third, the results of the discourse serve as a framework supporting the design and development of artifacts for linking instance models from the domains BIM and UIM: The concept about contextual linking means that a general rule for aligning instance models from the domains BIM and UIM cannot exist. Instead, application-oriented and model-oriented aspects must be considered in the design and development of artifacts [123] aiming to align instance models from the domains BIM and GIS. Notably, both application-oriented and model-oriented aspects are often implicitly considered in the creation of alignments relating instance models from the domains BIM and GIS. Thus, the alignment is often created without explicitly having application-oriented and model-oriented aspects in mind. This paper made these kinds of aspects explicit such that they can be used in terms of a framework for the alignment between heterogeneous information models from the domains BIM and UIM.

The major limitation of this work refers to the limited scope of the demonstration. The demonstration aims to inductively support the deduced concept of contextual linking with respect to the information models IFC and CityGML. Therefore, the demonstration of the concept of contextual linking is not readily transferable to other kinds of information models or knowledge representation systems. For instance, ontologies following some truth conditional modeling approaches might only allow one alignment as the single source of truth. Thus, contextual linking as described in this paper is not relevant for these kinds of ontologies. As another example, the concept of contextual linking might be less relevant for two information models being very similar to each other (like two different versions of the same schema model).

This paper emphasizes three major directions for future research: first, the pro and cons of the information integration methods need to be investigated in more detail and subsequently correlated to the three categories of the application-oriented perspective on information integration. This kind of research investigation might result in a framework answering the question of when to use which information integration method. Second, application-oriented, and model-oriented aspects relevant for contextual linking were described, but not investigated in a holistic manner. Thus, future research investigations could address the holistic accumulation of these kinds of aspects that would support the deduced concept of contextual linking. Third, the demonstration examples were kept simple in order to show that already for such small examples contextual linking is required. The application of the framework on a more practical and complex use case and the assessment regarding the suitability and accuracy of the achievable integration will also be addressed in future work.