Linked Data and Ontologies for Semantic Interoperability

Abstract

The purpose of Linked Data and ontologies is to achieve semantic interoperability across different systems and agents. As a concrete implementation, Digital Construction Ontologies (DiCon) are meant to provide efficient information sharing and utilization between the tools in the BIM4EEB toolkit. This section explains the motivations, design principles, and organization of DiCon ontologies.

2.1 The Role of Linked Data and Ontologies

Construction and renovation industry is nowadays filled with digital solutions to support numerous tasks in design, planning, quantity estimation, procurement, logistics, site management, quality inspections, sensor data gathering, and so on. However, due to their specific origins and history, different solutions manage and represent data in an incompatible manner. The result is a fragmented systems landscape and the consequent need for repeated manual work to transfer information from one system to another or for costly integrations between pairs of systems.

Linked Data and ontologies provide a generic solution that enables systems to interoperate; that is, share information and act on the information shared. The need for manual information exchange is reduced or even removed since the interaction between systems can be automatized.

The following levels of interoperability can be identified (Singh and Huhns 2005):

• 1. Technical interoperability: At the lowest level there must be a connection between the systems, and an interface through which bits and bytes can be transferred from one system to another. This can be achieved if the systems are connected to a common communication network and if they have application programming interfaces.

• 2. Syntactical interoperability: There should be common understanding regarding the format of transferred data, so that the recipient can parse the structure of the data. This can be solved by using standard data formats (e.g., JSON, XML, CSV, or STEP Physical File Format).

• 3. Semantic interoperability: The terms used in the data (types of entities, their properties, datatypes, and identifiers) should be understood in a sufficiently similar manner by the systems to make their practical operations successful. The solutions for semantic interoperability are still in development with approaches based on standards, ontologies, wrappers, and mediators (Abukwaik, 2014). In the construction domain also classification systems can address some aspects of semantic interoperability.

• 4. Pragmatic interoperability: There are several issues related to processes, security, adaptation to dynamic changes, organizational arrangements, and even legal considerations where the systems may need to be in an agreement to successfully work together. Occasionally some of these aspects are regarded as additional layers of interoperability (EIF, 2017) (Abukwaik, 2014).

The solutions to tackle technical and syntactic interoperability, at least in ordinary domains, are already available, and to achieve interoperation at those levels is generally a matter of willingness and effort of implementation. Semantic interoperation is still an area of active development, with promising technologies and initial results. However, even after the problems of semantic interoperability have been tackled, challenges of the pragmatic level remain to be solved to make systems work seamlessly together.

In the case of the BIM4EEB toolkit, the Digital Construction Ontologies and the Linked Data principles take care of the semantic interoperability but as of now the solutions for the problems arising at the pragmatic level must still be separately agreed among the tools.

2.2 The Need to Supplement BIM with Ontologies

While in the future the design in renovation projects will be based on building information modelling (BIM), the information contained in the models will not be sufficient to comprehensive planning and modelling of different aspects of a renovation. Rather, BIM models will be related to multiple other areas as shown in Fig. 2.1: built assets, agents, legal roles, products and materials, classifications, information entities, plans, activities, sensor data, and so on. The entities in these areas need to be linked with the entities in BIM models but the different origin, lifecycle, and rate of change of the data in those domains imply that they are best managed separately from BIM models. That is, interlinked but separately managed.

Fig. 2.1

Examples of domains relevant for renovation management

There are several areas where comprehensive renovation management requires supplementary representational agreements:

• 1. Occupancy and ownership. In renovations, information about ownership, occupancy, and use of spaces of the building to be renovated require the concepts for built assets, including their division into individual residential and non-residential units in buildings. This is used in the early stages of renovation planning to organise the information about occupancy profiles, and requirements and preferences of stakeholders. In the execution phase it is used to coordinate the renovation activities with the stakeholders.

• 2. Information models of assets and projects. All construction projects are characterized by numerous information entities: BIM models, breakdown structures, quantity take-offs, operational plans (e.g., master plans, lookahead plans, week plans), drawings, and so on. The processes of creation and versioning of these needs to be supported. A specific concern is the linking of appropriate parts of project information model to the asset information model of the building.

• 3. Renovation scenarios and renovation measures. In the early planning, different renovation scenarios can be explored, each consisting of a set of renovation measures. Renovation measures are activities that are often repeated to different parts of a building identifiable from BIM models: for example, for each bathroom, window, part of facade, and so on.

• 4. Construction management. The concepts of lean construction can be modelled as activity flows, that is, relations of activities to building objects (from BIM), locations (partly from BIM), labour crew, equipment, materials, information, and external conditions (from IoT). These are needed to support methods such as Location-Based Management and Takt Time Planning (Seppänen, 2014), or practices like the Last Planner™ (Ballard, 2000).

• 5. Sensor data. Sensor observations can be organised by relating them to objects in the BIM models, such as spaces or building elements, the resources at the construction site (people, equipment, materials), or entities in the supply chain (shipments, products). Through the connections of activities to these entities, the progress of execution can be derived from sensor data.

• 6. Energy efficiency. An important contemporary motivation of renovations is the improvement of energy efficiency of a building over its remaining lifecycle. The models of life-cycle assessment and life cycle costing need to be integrated with BIM models and projects management.

• 7. Products and materials. The ability to promote low-carbon construction and facility maintenance, the information about materials, layers, and products should be represented in a detailed manner.

The representation of these areas has been addressed at least partially by many

• standards: e.g., BIM-based Information Management (ISO19650, 2018), Information Container for Linked Document Delivery (ISO 21597, 2020), and Basic Formal Ontology (ISO/IEC 21838, 2021) for fundamental categories, and

• established ontologies: e.g., OWL-Time for temporal concepts (Cox, 2017), QUDT for units of measure (QUDT, 2022), SSN/SOSA for sensor observations and systems (Haller, 2019), PROV-O for origin of information (Lebo, 2013), FIBO for financial and legal concepts (Bennet, 2013), or Brick Schema for building automation systems (Balaji, 2016).

The previous work on ontologies needs to be considered in any subsequent ontology development, and new ontologies should be aligned with existing ones.

2.3 Tool Interoperation Using Ontologies

The applications that utilize ontologies can originally be standalone tools. It is expected that future solutions for renovation management are likely to be implemented as systems of systems (Maier, 1998). There will be independently developed and used systems serving their specific purposes that will produce and consume information. The overall information system environment in any specific renovation project will be built from the existing systems of the parties involved. The essential goal is to have interoperability between different systems because it allows to connect them together to serve the goals of the project.

The constituent systems must relate to each other for the duration of a renovation project to act in complementary roles in the project. Detailed data remains inside each system, but the systems can share the relevant part of their data with others. To achieve interoperability, the constituent systems must have interfaces for the required interactions and semantic interoperability relevant to the renovation domain.

Figure 2.2 illustrates the role of the ontologies with a high-level architectural diagram as realized in the BIM4EEB project. There is a set of renovation tools that interoperate by sharing data through a common data sharing platform. The tools do not interact with each other directly; all interactions happen through shared data.

Fig. 2.2

An architectural overview ontology-based toolkit of BIM4EEB

Data sharing is based on the Linked Data principles and the use of ontologies that enable the semantic interoperability among tools. Both the tools and the data sharing platform access the ontologies either by downloading whole ontology modules or through URI lookup of individual terms. Downloading of whole ontologies is needed for performance reasons and to support reasoning functionalities.

The data sharing platform stores data in files and in databases. There is both a relational database (SQL) and a graph database (RDF) between which the data contents are synchronized.

The tools can access the data sharing platform in several different ways: by downloading IFC files and through SPAQRL queries, URI lookup and ordinary REST interface. Finally, the ontology modules are aligned with external ontologies through the alignment modules that import both the external and internal ontologies and connect the terms across them with alignment axioms.

A high-level example of the kind of data sharing that can happen between different tools in the workflow of BIM4EEB toolkit is shown in Fig. 2.3. The tools are shown in the middle level of the figure. The tasks that are performed with the aid of the tools are indicated at the top of the figure. At the bottom is the data sharing platform. The arrows between the tools and the data sharing platform describe the kinds of data that is exchanged between the tools and platform. It should be noted that there can be also other data that is directly loaded on the platform. The main message to take away from the figure is that there are various kinds of data that is exchanged, and that the data produced by one tool can later be utilized, enriched or modified by other tools. The interoperation is based on shared data, and it can support different kinds of processes, depending on the companies involved in projects and the tools utilized by them.

Fig. 2.3

High-level example of data sharing between tools in a workflow

2.4 The Design of Digital Construction Ontologies

The main principles that have driven the design of Digital Construction Ontologies (DiCon) are compliance with relevant standards, compatibility with a standard top-level ontology to provide fundamental categories and therefore increase conceptual integration, support for information evolution which is a crucial phenomenon in renovation and construction projects, the flexible mechanism to connect the entities with different identifier schemes and classification systems.

2.4.1 Standards Compliance

An important objective in the design of Digital Construction Ontologies was to support relevant standards in the AEC domain. Most important standard is IFC (Industry Foundation Classes) (ISO16739, 2018) that has also been converted into an ontology ifcOWL (Pauwels, 2016). The BIM models created by designers can be exported into IFC, and the IFC model contains all spatial and physical entities as well as building systems of a buildings. Another important standard is ISO 19650 that specifies the principles of BIM-based information management. DiCon provides a formalization of the central concepts of ISO 19650 standard (ISO19650, 2018) ranging from built assets, appointments and project teams to information models consisting of a federation of information containers. Finally, the information-related concepts of DiCon are compatible with the Container ontology of Information Container for Linked Document Delivery (ISO 21597, 2020) that enables the exchange of packages of interlinked datasets across parties.

2.4.2 Top-level Ontology for Fundamental Categories

Since DiCon covers a wide range of concepts—physical entities, spatial entities, information entities, events, processes, properties, roles, capabilities, etc.—there is a need for generalized concepts or higher-level categories as one method to interrelate different domains of information. Instead of ad hoc generalizations, a standard and widely used top-level ontology Basic Formal Ontology (ISO/IEC 21838, 2021) is used as the source of fundamental categories. BFO is a compact ontology based on ontological realism—according to which ontology represents entities in the world—that better promotes interoperability than ontologies that allow cultural or mental concepts with more diverse interpretations.

2.4.3 Support for Information Evolution

In renovation and construction projects it is crucial to support the evolution of information. Information will be accumulated, refined, and changed during the project execution. DiCon supports the evolution of information with two different mechanisms. Firstly, objectification of properties is used for the small-scale evolution, e.g., for values changing over time because of sensor observations. Objectification also enables the representation of other metadata about properties: quantity kinds, units of measure, and property definition entities. Secondly, the large-scale evolution is based on the ISO 19650 information containers. This enables the storage and management of alternative renovation scenarios, different versions of BIM models, releases of operational plans, and entity organizations such as breakdown structures.

2.4.4 Flexible Labelling of Entities

All DiCon entities can be labelled with identifiers and classifications. Every independent entity has a URI as its main and retrievable identifier but, in addition, the entity can have additional identifiers in different information systems and other scopes. Identifiers can be globally unambiguous such as a GUID, or locally unambiguous, such as a room number in a building (where the building defines the scope of the identifier). Likewise, since different classification systems in the construction sector are used in different geographical regions and organizations, DiCon supports the flexible labelling of entities with categories based on the needs of a project. The goal of DiCon is to avoid duplicating information that is already in classification systems; after all, classifications are complementary to ontologies in the sense that they capture the variety in the domain with an extensive set of detailed classes (possibly with class-specific attributes), while ontologies represent the complexity in it with a compact set of essential classes, each with a distinct set of constraints and relations to other classes.

2.4.5 Modularization and Alignment Using Vertical/horizontal Segmentation

DiCon is modularized using the vertical and horizontal segmentation approach of the Semantic Sensor Network Ontology (Haller, 2019). In the vertical dimension, a new module imports the previous one and deepens the representation of the underlying domain by defining additional subclasses, properties, restrictions, or alignments (therefore, alignment is always vertical segmentation). In the horizontal dimension, a new module broadens the domain by defining classes complementary to the previous ontology as well as properties to connect them to the previous concepts.

In the vertical dimension, the new module should support selected use cases better, having perhaps a narrower user base when compared to the previous module, while horizontal segmentation should extend the set of supported use cases, therefore broadening the potential user base.

In accordance with vertical segmentation, the approach to integrate DiCon ontologies with external ontologies is based on the use of alignment modules. It should be noted that there are several alternative ways to promote integration: (1) direct imports of external ontologies, (2) references to terms of external ontologies without importing them, and (3) utilization of SHACL to create application profiles as graph templates that incorporate terms from several ontologies. The resulting integration is different in each case; for instance, the consistency checking with ontology reasoning works in a different manner.

In the alignment approach the ontology modules to be aligned do not reference each other at all. Instead, a separate alignment module first imports the ontologies to be aligned and, second, provides additional alignment axioms that establish relationships between the terms in the imported ontologies. The alignment module can then be checked for consistency to reveal whether the alignments are compatible with the definition of the terms in the aligned ontologies.

According to the alignment approach all the references from DiCon ontologies to classes and properties defined in external ontologies are made explicit in the alignment modules; that is, the DiCon ontologies do not refer to any external classes or properties. However, it is still possible that they have references to individuals defined in external vocabularies. This applies especially to individuals representing quantity kinds and units of measure.

2.5 Definition of DiCon

The overall DiCon ontology is divided into a set of modules shown in Fig. 2.4. The arrows indicate the import relationships (owl:imports) between the modules.

Fig. 2.4

DiCon ontology modules and their import relations (owl:imports)

Contexts—The DiCon Contexts (dicc) ontology defines the basic concepts to manage data in different alternative realms, such as planned or actual data, models at different levels of detail, different renovation scenarios, versions of construction plans, and so on. The main concept is dicc:Context, each of whose data is contained in its own named graph of an RDF dataset.

Variables—The DiCon Variables (dicv) defines an enriched representation of the properties. It uses the objectification of properties as the basic mechanism. The properties of entities can be associated with additional objects to represent quantity types or units. Moreover, the value can be represented with property states that enable the values at different time points or levels of detail. The ontology is aligned with QUDT, SOSA, and Saref Core. It allows to associate, for instance, series of sensor values to the properties of entities.

Entities—DiCon Entities (dice) defines the basic entities of renovation and construction processes, ranging from building objects, real estate, devices, equipment, locations, roles, and capabilities to spatial regions and time intervals. The ontology observes the general structure of the Basic Formal Ontology (BFO) and is aligned with it.

Processes—DiCon Processes (dicp) defines the concepts for activities (intentional processes with start and end), activity flows and resources. An activity can have any number of sub activity layers, and it can represent anything from projects to tasks. The activity flows are relations that activity can have to different other entities: the object to transform, agents, locations, equipment, material batches, information entities, and to external conditions such as temperature or humidity. Resource is treated as a role that any entity can have with respect to an activity and activity may require different kinds of resources to appear in different activity flows.

Agents—DiCon Agents (dica) represents the concepts for actors and stakeholders, persons, organizations, and legal persons, as well as the basic organization concepts from ISO19650. The legal persons can have specific roles with respect to assets, for instance, as an owner or tenant.

Information—DiCon Information (dici) defines concepts of information content entities such as information containers, information models, designs, plans, messages, and so on. The concept of a project information model is defined based on the description in ISO19650.

Materials—DiCon Materials (dicm) ontology defines the layer structures of building objects, and different kinds of properties of materials from carbon content to thermal and dynamic properties.

Energy—DiCon Energy (dices) defined the concepts for life cycle assessment, energy efficiency and energy systems, including the related information content entities, processes, and objects.

Occupancy—DiCon Occupancy (dicob) covers the occupancy profiles of inhabitants, and acoustic performance and indoor air quality of building units.

Lifecycle—DiCon Lifecycle (dicl) addresses the representation of information specific to LOD levels and building lifecycle stages.

The overview of how the concepts in the different DiCon modules are related with each other through the upper-level categories is shown in Fig. 2.5. In the interest of legibility, not all the modules are presented in the figure.

Fig. 2.5

Overview of central concepts of DiCon