The issue of inconsistent property namings and classifications during the export of building element properties from a design program is a common occurrence that significantly hampers the interoperability of created data models. We study this with a use scenario that involves the transportation of a steel beam, and the challenges of inconsistent property namings are highlighted. A generic method for unifying properties is proposed when IFC formatted building models are converted into semantic web and how to share the user-defined and software-specific property mappings. We also discuss the benefits of mapping the namings into buildingSMART Data Dictionary definitions and the limitations of this approach.
• How to handle and align user-defined and software-specific property sets? • How can we overcome inconsistent property namings between domain-specific software to enable generalised queries? In the context of linked data, alignment refers to the establishment of correspondences between entities. We establish correspondences between RDF properties so that IFC-to-LBD conversion can provide equivalent but standard properties in the produced graphs. This work analyses the general problem with a specific use scenario that stems from an intralogistics use case developed by domain experts in the EConoM research project1. The aim is to investigate how construction robots can automatically transport components on-site. As is generally the case for automated machines and robots, it is crucial to know the robot’s capabilities concerning physical limitations to ensure the safety of all involved and to protect the machines and their environment from damage. When it comes to material handling, such as lifting or carrying, a typical constraint is the maximum weight a machine or a robot can handle. While IFC, IfcQuantityWeight, serves as a standard way to express the weight of building elements; nonstandard properties are needed to express the extra weight of pallets, stretch wraps, tarpaulins, strappings, or crates. In this use case, a mobile robot platform is assigned to transport a building element from a delivery area to its designated storage, as illustrated in Figure 1. To check whether the autonomous robot can perform the transportation task safely, it must be checked if the cargo weight exceeds the machine limits. There are beams from two providers that have designed the beams in diferent programs. The robot needs to get the weight of the building element from the data models to know which beams to select. Assuming interoperable BIM-based construction planning, the weight of the building elements should be provided in the IFC. Here, the information is located in property or quantity sets, which can, in theory, be converted to Ressource Description Format (RDF) using the existing practices and ontologies of the LBD community. However, in practice, information is missing or inconsistently described in the resulting LBD graph, depending on the authoring software.
Section 2 provides an overview of related work in the field. In Section 3, we dive into a practical intralogistics use scenario, wherein a steel beam is modelled using two distinct software systems, presenting the issue of inconsistent property naming. Section 4 presents a novel solution to address this challenge, accompanied by a presentation of results. Finally, the article concludes with a discussion and conclusion of the findings and their implications. In this paper, we use the prefixes of the namespaces provided by the http://prefix.cc/ site and, in general, the namespaces are as in Listing 1 1 PREFIX beo: <https://pi.pauwel.be/voc/buildingelement#> 2 PREFIX inst: <https://www.econom.one/> 3 PREFIX props: <http://lbd.arch.rwth-aachen.de/props#> 4 PREFIX opm: <https://w3id.org/opm#> 5 PREFIX schema: <http://schema.org/> 6 PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> 7 PREFIX owl: <http://www.w3.org/2002/07/owl#>
Listing 1: Namespaces in the listings.
2. Related work
buildingSMART2 is a global organisation that develops standards to improve collaboration
and digital BIM workflows. The buildingSMART Data Dictionary (bSDD), provided by
buildingSMART International, is an online repository for BIM-related classes and properties. It
ofers a user-friendly search interface and a management portal that allow authors to publish
content, and it also allows integrated BIM software through APIs. Earlier work to integrate this
with Linked Data is presented in [
Following the scenario-based design [15], the described intralogistics use case is incorporated to develop our approach by modelling an IPE 240 steel beam as an element to be transported. In construction practice, it can be observed that subcontractors utilise a diverse range of specialised software tools. Unfortunately, many software solutions use diferent properties and names for the same information. Even if the same building element is modelled, this can occur. To simulate this, the steel beam is modelled in two diferent software, Tekla Structures 5 and Autodesk Revit 2024 6. Both are widely used in steel construction.
In this example, Tekla Structures annotates the value using the quantity set QTO_
BeamBaseQuantities and the property GrossWeight. In Revit, the weight information property is
in a custom property set called ElementWeight. Revit does not directly export weights, so custom
parameter sets are common. When the models were converted to RDF, the IFCtoLBD converter
[
After modifying IFCtoLBD to export element quantities, the weight values for both software can be found in the resulting graph. However, the naming conventions used in diferent software were not identical, resulting in diferent RDF object properties (see Figure 2 - red encircled). Practically, this means that a query for the weight written for the Tekla export (see Listing 2) will not return the same information when applied to the export from Revit, or more precisely, it will not return anything. Revit would require its own "dialect" or a "user-defined dialect" for the query to function correctly. When using Autodesk Revit, the naming can vary since custom property sets are used. This means that SPARQL queries are also customised. The example custom property ElementWeight cannot be queried with Listing 2.
We exported the data models to LBD using the Open BIM approach and Industry Foundation Classes (IFC). Since IFC is a buildingSMART standard, we searched for a solution to express the weight value in the use case into a bSDD equivalent value. They have published a namespace bsdd:http://bsdd.buildingsmart.org/def# and an unnamed namespace https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/. In the test, both ontologies were ofline. In this work, we can only recommend buildingSMART to use an addresses that are accessible online. In our test, we used Postman software to test the connections. The property can be accessed with the HTTP header Accept: text/turtle to get the machine-readable version. It defines :GrossWeight. Our recommendation is to add a statement “:GrossWeigh rdf:type rdf:Property .” and use it as a unified RDF property for the values, or “:GrossWeigh rdf:type owl:Class .” and property instances it as a type. The first one has the benefit that the descriptions for the used properties are from the best dictionary, a single source of truth, emphasising the idea of sharing a standard dictionary in the industry while maximising the gained amount of information in the name of an RDF property, that is, not using RDF properties like :hasPropery, or :hasPropertySet. The latter approach has the benefit of already having an ontology with an online existence. In the following, we present the latter approach. IFCtoLBD was modified to accept a JSON description of URI mappings as input. Internally, each instance of the description of a property set is associated with the given map. Then, in the phase, when the converter writes out the property set RDF assessments, that mapping is used if a match is found. The idea is that there would be published mappings for common software and users could have private ones for their custom mappings. Since the IFC-LBD output already implies that simple property replacement is insuficient, we suggest using SPARQL property paths in the mapping description. 1 2 3 4
Above, the handling was done using IFCtoLBD, showing that the mapping can be done so that the converter was instructed in a generic JSON description to replace specific property URIs with a given one. The implementation details of the unifying properties are described above and are found in the IFCtoLBD source code. In addition, the Java sample code for usage can be found in Example13.java9. To provide better insight, IFC.js-based IFC-LBD was also tested to show that RDF property creation is similar in independent implementations. It has a similar approach for property names but creates properties under https://example.com/resources/ namespace. It created the quantity sets but did not connect them to the building elements, so there were no comparable property URIs for the quantity sets. In this case, the implementation was not changed to include a generic RDF property mapping. Tekla_lbhack.ttl contains the analysed IFC-LBD output in the sample data repository (see Section 3.1). An insight is that a simple mapping rule cannot express a fix for the diferent ways of presenting the quantity sets in the converters, but the same logic can be implemented in both converters. The solution can be enhanced by providing mappings of company-specific or software-specific properties and commonly used ontology definitions online in JSON format, with frequently used mappings accessible through a public repository to encourage broader adoption. We have used the use scenario presented in the beginning of the article to evaluate the solution. In the scenario, we can use published mapping rules so that element descriptions of diferent providers can be queried using one query. By implementing the solution, we have shown that it is viable. However, analysing the possibility of standardising the RDF properties that correspond to IFC properties, e.g., using bSDD, revealed limitations in following Linked Data principles.
Inconsistent property namings and classifications during the export of building element properties from a design programme are common occurrences that significantly hamper the interoperability of created data models. The proposed solution ofers a way to share RDF property mapping of user-defined and software-specific properties to commonly agreed definitions. We recommend using the BuildingSMART Data Dictionary (bSDD) definitions. The solution has limitations. For example, we do not unify the IFC models, which afects programmes that do not use RDF. Therefore, the recommendation is also to follow buildingSMART specifications when available. Also, unifying measurement units, conflicting values, and more complex mappings, like aggregations, are left for future studies.
This work is part of the EConoM research project funded by the Federal Ministry for Digital and Transport of Germany within the initiative InnoNT (funding number 19Ol22009F). It was supported within the TARGET-X framework, a project funded by the Smart Networks and 9https://github.com/jyrkioraskari/IFCtoLBD/blob/master/IFCtoLBD/src/main/java/examples/Example13.java Services Joint Undertaking (SNS JU) under Horizon Europe (funding number 101096614). The authors are responsible for the content. Computing in Construction, European Council on Computing in Construction, 2019, pp. 341–350. [15] M. B. Rosson, J. Carroll, Scenario-based design, 2002, pp. 1032–1050. doi:10.1201/ b11963-56. [16] J. Oraskari, M. Bonduel, K. McGlinn, P. Pauwels, F. Priyatna, A. Wagner, V. Kukkonen, S. Steyskaland, J. Lehtonen, M. Lefrançois, Ifctolbd: Ifctolbd v 2.43.3, 2023. URL: https: //github.com/jyrkioraskari/IFCtoLBD.