On this page we provide supplemental material to the paper “Semantic Integration for Big Open BIM”.

Abstract

Building Information Modeling (BIM) is a data exchange and management method developed for the architecture, engineering and construction industries and for facility management. Its most advanced form, Big Open BIM, requires seamless information flow among an arbitrary number of applications by means of an open data exchange standard. However, fulfilling this fundamental requirement includes overcoming technological as well as semantic gaps and conflicts between data models and their implementations. In this work, we introduce a method for integrating the semantics of independent applications at run-time. This integration utilizes techniques of model-driven engineering and involves automatic discovery of functionalities, data models and user-guided translations between them. We present a case study involving the domains of architecture, building physics and structural engineering for evaluating our approach in object- as well as data-oriented programming environments. The results produce, for each scenario, a single semantics that facilitates a traceable as well as reproducible data flow between all of the involved applications. Thus, we successfully prove that our framework enables a seamless information flow among an arbitrary number of applications, which is the fundamental requirement for Big Open BIM, as stated at the very beginning.

Class Person and Model Person

Figure 1 shows the example of class Person, we discussed in Section 3.2.1. On the language level, both the target application (on the right) and the modeling framework (on the left) store their syntactic containers. Instantiating those containers and filling them with semantic information leads us to the next level below. This level is occupied by the type system of the target application (see class Person) on the right and by the first model level of the modeling framework (see component Person) on the left. A C# class can contain, among others, fields, properties and methods. Our focus in this example is on data exchange and Challenge 1: Exposing the semantics. Therefore, we will, for the moment, disregard the methods. Class Person has an attribute FirstName of type string. The corresponding model, component Person, contains an instance of Parameter named FistName. Further instantiation leads us to the lowest level, of the run-time instances. The target application carries a specific instance of type Person, p1 with a specific FistName, “Alice”. The corresponding elements in the modeling framework reside in the second model level. There is an instance of component Person, component Person Instance, and a Parameter instance named FirstName Instance, which carries the specific value, “Alice”.

Correlation between a class-object paradigm and a model
Figure 1: The syntactic correspondence between our modeling framework and an object oriented type system.

Workflow 1 and Logic Programming

In Section 2.6 we presented our approach to extracting a data model from an existing application as Workflow 1. The definition of this workflow as well as its evaluation in Section 4.6.1 used a target application relying on an object-oriented programming paradigm. Here we demonstrate the same workflow, but this time applied to a logic programming paradigm. We use the logic programming language Prolog as an example. Figure 2 shows its syntax. A Prolog application consists of a collection of Predicate definitions. Each predicate is a function that takes an arbitrary number of input arguments and returns a Boolean value, and is defined by a collection of Clauses. A clause has a head and an optional body, both of syntactic type Term. Number, Variable, Atom and Compound Term are all specializations of Term.

The syntax of a Prolog application.
Figure 2: The syntax of a Prolog application

A small Prolog application conforming to this syntax is shown as text below and as an UML object diagram in Figure 3.

Material Of (vs1, "concrete").
Vertical Slab (vs1).
Slab (x):- Vertical Slab (x); Horizontal Slab (x).

?- Slab (vs1).
Yes
Object diagram of a Prolog application. It defines the predicates Material Of, Vertical Slab and Slab.
Figure 3: The Prolog application as an instance of its syntax. It defines the predicates Material Of, Vertical Slab and Slab.

The application defines three predicates: Material Of, Vertical Slab and Slab. Material Of is defined by a clause consisting only of a head, i.e., a fact (see top of Figure 3). It states that Atom vs1 is of material concrete, represented by Atom“concrete“. Predicate Vertical Slab is also defined by a fact. It states that Atom vs1 is a Vertical Slab. From a MDE perspective, this fact defines vs1 as an element of the extension of the concept vertical slab. The object-oriented representation of this fact would be that vs1 is an ontological instance of type Vertical Slab (Kuehne, 2006). The predicate Slab is defined by a clause with a head and a body, i.e., by a rule. This rule’s body uses a pre-defined Prolog predicate ;/2, which is a logical OR operation that takes two Boolean arguments. This rule postulates that a Slab is either a Vertical Slab or a Horizontal Slab. The use of a Variable x instead of an Atom means that this rule is valid for all atoms.

In order to translate this application’s data model from the Prolog syntax to the object-oriented syntax of the modeling framework (i.e., into Component and Parameter instances), we define the following rules:

  1. predicate of arity 1: relationship OfType between the functor (see the definition of Compound Term in Figure 2) and the argument
  2. predicate of arity n, where n > 1: relationship ref. Components, carrying the semantics of the functor, between the first argument and all other arguments
  3. pre-defined predicate ;/2 (or): inheritance (the arguments inherit from the functor)
  4. pre-defined predicate ,/2 (and): composition (the arguments compose the functor)

The result from this mapping when applied to the example Prolog application is demonstrated in Figure 4 (a). The syntax of this model is the language of the modeling framework we presented in Figure 2 in our paper. Applying translation rule (1) to predicate Vertical Slab results in a model of type Vertical Slab and a model of its instance, vs1. Applying translation rule (2) to predicate Material Of results in another instance, “concrete“, and in a relationship Material Of between vs1 and “concrete“, instantiated from ref. Components. Finally, applying translation rule (3) to predicate Slab results in relationships specialization of, also instantiated from ref. Components, indicating inheritance. The equivalent class and object diagram in UML notation is shown in Figure 4(b).

Prolog app model: (a) The resulting model of the Prolog application in Figure 2 in the syntax of our modeling framework. (b) The equivalent object-oriented data model.
Figure 4: (a) The resulting model of the Prolog application in Figure 2 in the syntax of our modeling framework. (b) The equivalent object-oriented data model.