BimSPARQL: Domain-specific functional SPARQL extensions for querying RDF building data

3.1. BIM query techniques

Many past developments have been aimed at the query and analysis of IFC instance data. Some commercial platforms such as Solibri Model Checker (SMC) provide functions for querying IFC data [47]. However, the semantics of query functions in these proprietary systems are not transparent and the usage of them is limited by the user interfaces provided to end users.

Some researchers attempt to have use the generic Structured Query Language (SQL) to query IFC data that has been mapped into relational databases [28,30]. These attempts either have severe performance and scalability issues due to the vast amount of tables, or are not intuitive enough for end users.

BimQL is among the first implemented and open source domain specific query language for querying IFC data [35]. It is implemented in the open source bimserver.org platform [4]. It provides create, retrieve, update and delete (CRUD) functionalities to manipulate IFC data. Besides using concepts in the IFC schema, BimQL also provides a few shortcut functions for handling common use cases such as deriving information from common modeling constructs in the IFC model referred to as property sets and quantity sets. However, these functions are very limited and BimQL has not been further developed.

Geometry and spatial information in building models is especially focused by a spatial query language introduced in [8]. This approach is further developed as a query language named QL4BIM for querying IFC data [11]. It has provided a few topological and spatial operators and use R-Tree [18] spatial indexes to optimize query performance.

There are also query languages tailored for specific use cases such as building code compliance checking. The Building Environment Rule and Analysis (BERA) Language is a domain-specific language dedicated to evaluate building circulation and spatial programs [33]. For this purpose, it has defined an internal data model containing a small subset of IFC with related concepts such as floor, space and door, etc. Path-finding algorithms are developed to generate circulation routes between spaces. As a language, however, BERA has limited expressive power and only supports some specific cases on building circulation rules. BIM Rule Language (BimRL) is a more recent research project [13]. It is a domain specific query language designed to facilitate accessing information for use cases of regulatory compliance checking. BimRL has provided a suite of components including a simplified data schema and a light-weight geometry engine. IFC building models are loaded through an Extract-Transform-Load (ETL) process into data warehouse. The language has an SQL-like syntax to check building models in terms of the defined data schema and implemented functions. It is currently implemented based on a relational database.

The above technologies have provided inspiring domain specific algorithms for querying building data. Currently, however, no query language has been standardized or widely adopted by the research community and AEC industry. We argue that this might be because these technologies are limited by the closed conventional data modeling approaches that are not sustainable in the AEC domain, which continuously needs changes, extensions and customizations according to different contexts and use cases. All these domain specific BIM query languages are designed based on fixed internal data models (usually an IFC equivalent or a simplified subset of it) and additional functions are hard-wired on top of them. Although some of them have provided programming interfaces for further extensions, the development work is usually limited by the data captured in its internal data model.

3.2. Applying Semantic Web technologies for querying BIM models

In recent years, Semantic Web and Linked Data technologies have received increasingly more attention as a knowledge modeling approach in the AEC industry and a number of research prototypes have been developed. A recent and comprehensive overview of them is provided in [42]. Here, we only briefly describe cases related to data query and knowledge reasoning tasks.

Regarding data query for use cases in the AEC domain, one of the early examples is described in [55]. Conformance constraints are interpreted and formalized as SPARQL queries in that paper. A similar method is developed in [9], which has introduced a semi-automatic process to transform regulatory texts to SPARQL queries. A limitation of both efforts is that they mainly focus on formalizing building regulations into a query language without specifying on how to map the used terminologies to building data models.

A number of researchers have applied Semantic Web technologies in different sub-domains in the context of the AEC industry to facilitate knowledge modeling and rule checking. In [41], a remarkable approach for facilitating regulatory compliance checking has been introduced based on N3Logic and EYE reasoning engine [5], and a test case of an acoustic performance checking is presented. In [34], an OWL ontology has been used for reasoning tasks in cost estimation cases. There are also cases regarding energy management and simulation, construction management, and job hazard analysis etc. [3,58,59]. All these examples have proved that different knowledge reasoning tasks in the AEC industry can be facilitated by properly using Semantic Web technologies.

Currently however, a systematic way to query data from building models using Semantic Web technologies is still missing. One of the possible reasons is that an authorized and stable standard ifcOWL ontology has only been established very recently and its adoption in suitable use cases will likely take a few more years. The most similar work that has overlaps with this research are the IfcWoD and SimpleBIM [36,39] ontologies. They both attempt to transform ifcOWL data to a more compact graph to ease query and improve runtime performance. The difference is that they mainly focus on developing a standard ontology as an alternative to ifcOWL to simplify the data graph, while this research is a framework that mainly considers the query functions with respect to semantics in common use cases and further extensions of them. A major enhancement of the approach introduced here is that functions related to geometry data are provided. To our knowledge, it is the first time to combine analyzing IFC geometry data with rule-based reasoning technologies.

3.3. Functional extensions of SPARQL

Extending SPARQL with additional functions has been proposed and implemented in other fields. The most inspiring ones are geospatial and geographical domains as they share many requirements, concepts and processes with the AEC industry. The stSPARQL in Strabon and the GeoSPARQL standard from Open Geospatial Consortium (OGC) have specified many topological and geospatial functions for 2D geometry data [32,43]. They have been implemented by spatial database systems including Strabon, Parliament and uSeekM [2,17]. Some other RDF APIs and triplestores like the Apache Jena framework, Allegrograph and OpenLink Virtuoso have also implemented some geospatial functions. To our knowledge, these vocabularies and functions developed in the Semantic Web world have mainly considered 2D geometry and cannot be directly reused for building models.

The AEC industry also has significant differences to e.g. the geospatial field. There are many disciplines and use cases in different contexts, in which the amounts of required properties and relationships are almost unlimited. There are much more sophisticated reasoning tasks related to 3D geometry. Therefore, the systems needed in the AEC domain must go beyond a fixed set of vocabularies but should rather provide a flexible framework that can reuse and extend functions more easily to process data and adapt with different situations.

From the implementation perspective, there are many technologies can be used to extend functions for SPARQL. Besides existing open source and commercial platforms (e.g. Apache Jena, OpenLink Virtuoso and Allegrograph) that support customizing functions by coding them with full fledged programming languages, there are some technologies that provide more transparent and portable methods for extending functions. For example, SPARQL Inferencing Notation (SPIN) can be used to define and execute functions by issuing SPARQL queries. A meta vocabulary is provided by SPIN to serialize SPARQL queries into RDF graphs to maintain implemented functions (see Section 5). The VOLT proxy provides a similar method that utilizes SPARQL fragments and graph patterns to define functions [44]. It has been applied on some geospatial cases and a plugin to include functions for spatial computation is provided based on the PostGIS API. Recently, an approach is presented in [12] to define functions by extending Triple Pattern Fragments (TPF) [54] on the client side, hence extended functions are compatible with any SPARQL server. As showed in [12], it however might have issues regarding performance and data traffics since additional functions are computed in web browsers and raw data needs to be retrieved to the client side. All these approaches can potentially be undertaken for implementing extended SPARQL functions for querying IFC building models and data in the AEC domain.

OPEN IN VIEWER

Fig. 3.

Conceptual relationships between vocabularies and IFC data.

Functions in this group are defined to wrap commonly used structures specified on the IFC schema level. They are identified with prefixes schm: in this paper. We model these functions mainly from the fundamental concepts and assumptions specified in the official IFC documentation [10]. These fundamental concepts describe recommended and commonly used structures in IFC instances as the general guideline for usage and implementation of IFC. Each of the fundamental concepts defines how a domain concept or relationship should be represented in IFC. Many of them have relatively complex structures to represent semantics. By reviewing these fundamental concepts and comparing them with use cases, shortcuts can be constructed to simplify writing queries and adapt to the high level abstractions in the AEC domain. They are defined for the following situations.

The most basic functions are related to objectified relationships. Many relationships in IFC data are realized by objectified relationships that are instances of IfcRelationship subtypes. An example is IfcRelContainedInSpatialStructure, which is used in Listing 1. Most of these objectified relationships and their usage are described by the fundamental concepts in IFC documentation. In general, each of the objectified relationships can be used to associate an object with another object or a set of objects. For example, an IfcRelContainedInSpatialStructure can be used to associate an IfcSpatialElement (e.g. storey, space) with a set of IfcElement instances (e.g. wall, door) to define a spatial containment relationship. In the current vocabulary, functions are defined as shortcuts to wrap such structures and create direct relationships between the objects that are associated. For example, the function schm:isContainedIn is created to retrieve the relationship between an IfcElement and the containing IfcSpatialElement instance (see Fig. 4). With the same approach, functions are created for all the fundamental concepts which describe semantic structures containing IfcRelationship subtypes (see another example schm:hasSpaceBoundary in Table 2). This type of shortcuts are also proposed in [36] and [39].

OPEN IN VIEWER

Fig. 4.

Example of shortcut functions for schema level semantics.

Another requirement is that some relationships need additional specification or generalization. For example, the spatial composition relationship between spatial objects (e.g. site, building, space) is semantically different from the aggregation relationship between building elements (e.g. wall, slab, stair). The former one only represents a hierarchical spatial relationship, while the latter one implies geometry compositional relationship. In IFC, however, they are represented using the same structure (IfcRelAggregates). These two structures are defined as two different functions (see one of them schm:isDecomposedByElement in Table 2). On the contrary, sometimes more generalized relationships are required for different structures. A typical example is the relationship of material association. There are several means to associate a material with a building object (e.g. single material, layered material), while in many use cases, it requires direct relationship between an object and its associated material. In this case, besides functions for each different structures, an additional function is created to retrieve a direct relationship between an object and its associated material regardless of which representation it is taken (see schm:hasMaterial in Table 2).

The third situation is functions for additional shortcuts. They are defined only based on experiences and referenced use cases. A typical example is the relationship between a filling element (e.g. doors, windows) and a voided element (e.g. walls that have openings). If we need to assert such relationship, it is realized in IFC with two objectified relationships and an opening element as illustrated in Fig. 4. As such relationship is frequently required, a function is created as a direct relationship between the filling element and voided element (see Fig. 4 and Listing 2).

Following these approaches, over 40 relationships are currently wrapped as functions (see Appendix A). Some frequently used examples are listed in Table 2. Listing 2 shows an example query to apply two functions for a use case from Statsbygg BIM Manual [50], which requires to check whether every window and the wall it is placed in are contained in the same building storey. This query uses the functions schm:isPlacedIn and schm:isContainedIn. A comparison with a query using plain SPARQL to realize this use case is presented in Section 6.

OPEN IN VIEWER

Listing 2.

Query to retrieve pairs of a window and a wall, with the condition that the window is placed in the wall but they are not contained in the same storey

Functions in this group are provided to represent IFC instance level semantics. As mentioned in Section 2, IFC instances can be semantically extended by property sets and quantity sets. These extended properties are modelled as instances of IfcProperty or IfcElementQuantity in IFC models, which are associated with IfcObject instances using certain structures. For example, Fig. 5 illustrates two common structures for associating IfcProperty with IfcObject [10]. An extended property that is modelled as an instance of IfcProperty with a related IfcPropertySet is associated with an IfcObject through either an IfcRelDefinesByProperties or an IfcTypeObject, which in turn is associated with the IfcObject through an IfcRelDefinesByType. The semantics of extended properties are identified by their names defined in external documentations. A property which is modelled using the former structure overrides a property modelled using the latter one if they have the same name.

OPEN IN VIEWER

Fig. 5.

Two common structures for associating IfcProperty with IfcObject.

This structure leads to complex declarations in SPARQL even for simple use cases. In this research, shortcut functions are defined to directly connect objects (IfcObject instances) with property values instead of using complex structures in IFC instances for writing queries. These functions are identified with prefixes pset: and qto: for property sets and quantity sets respectively. A typical example is illustrated in Fig. 6, where a wall that has a “LoadBearing” property is represented as an IfcWall associated with an IfcProperty instance in ifcOWL data. A shortcut property pset:loadBearing is defined to associate the wall and value of the property instance. All the properties of primary data types (instances of IfcPropertySingleValue and IfcPhysicalSimpleQuantity) can use the same mechanism to define functions. They are the majority in property sets and quantity sets and are also most frequently required in use cases. In our work, the property sets and quantity sets officially defined by buildingSMART are considered as examples. In total, there are 2519 properties and 257 quantities grouped within 415 property sets and 93 quantity sets in the official IFC 4 documentation [10]. Within them, 1471 properties and 257 quantities have the value range of primary data types and the domain of IfcObject subtypes. They are defined in our vocabulary.

OPEN IN VIEWER

Fig. 6.

Example of short cut functions for property sets. The schm:hasObjectProperty and schm:hasTypeProperty are two shortcut functions defined in the vocabulary schm: to wrap the two different structures (see Fig. 5) for associating an extended property with an object.

Functions are automatically extracted from the official ifcDoc document, which is a file in SPF format released by buildingSMART for storing IFC documentation. Additional, third-party property sets and quantity sets can be extended by processing e.g. simple XML or tabular structures with a trivial tool.

Listing 3 shows a query for a realistic quantity take off example, which is to count the load bearing walls on each building storey. By only using plain SPARQL, a query with the same semantics can also be written but with a much more complex structure (see the comparison in Section 6 and Listing 13).

OPEN IN VIEWER

Listing 3.

Query to count load bearing walls for each building storey

Functions in this category are introduced to derive properties based on the geometric representations of a single building product. The vocabulary is identified by the prefix pdt:. In IFC model instances, geometry data is represented by geometry objects associated with related building products. Large amounts of properties are implied in geometric representations of building products including e.g. height, area, length. Although many of these properties can be represented by property sets and quantity sets (see Section 4.2), they are not mandatory and are not always reliable in real building models [49] . In fact, a typical example of BIM requirement checking is to check the consistency between property sets (or quantity sets) and properties derived from geometric representations [47,50].

The IFC data model offers a number of means to represent geometry for building products. The most common way is the Body representation, which defines 3D volumetric shape of products. However, there are many geometry types to describe a Body geometry in IFC including e.g. Boundary Representation (Brep), Constructive Solid Geometry (CSG) or Non Uniform Rational B-Splines (NURBS). In our work so far, they are unified as triangulated boundary representation to ease developing analysis algorithms, but can be tailored to different representation forms in future. The 3D geometry representation of a product is either represented by a single triangulated surface, a collection of triangulated surfaces or represented by triangulated surfaces associated with its composing elements.

Based on the triangulated representation, many general geometry properties are derived using existing or simple algorithms (see Section 5), including axis-aligned bounding box, oriented minimum volume bounding box, basic dimensions (e.g. height, volume, area of surfaces) and partial geometry (e.g. surfaces facing to certain directions). These properties are defined as general product geometry functions that are applicable for all products which have 3D representations. Table 3 lists examples of them, their 3D showcases and semantics. Listing 4 shows a use case: search for inconsistencies between the geometric height of a wall with its height quantity [47].

OPEN IN VIEWER

Listing 4.

Query to retrieve walls that do not have height quantity or have inconsistent information between its height quantity and geometric representation

Combined with product types and some common assumptions (e.g. a wall length is greater than the wall thickness), many more specific product properties can be retrieved. These properties include some defined examples in Table 4. They can be applied for more domain related use cases such as design assessment. Listing 5 shows an example, which is defined to find out spaces which have too small window-to-floor area ratios. It is a common use case that can be additionally customized (e.g. add conditions for space types) to validate the design plan according to regulations or programmatic requirements.

OPEN IN VIEWER

Listing 5.

Query to retrieve spaces which have window-to-floor area ratios less than 0.3

Functions in this group are provided to derive information related to spatial reasoning, which needs geometric and location data of multiple building products. This vocabulary is identified by the prefix spt:. They are additionally classified and described in following sections.

4.4.1. Relationships between products

Functions in this category are used to derive relationships between two products. We have defined some general topological relationships that belong to this group, which are applicable for all building products. They are related to many use cases including e.g. geometric clash detection and quantity take-off. The OGC Simple Features are also used as a reference for defining these functions, as they have already established general topological relationships for geometric objects [21]. The aim of these defined functions is not to cover a full range of possible scenarios, but to provide a set of reference examples for other developers and a basis for extensions. For example, directional relationships like “above”, “under” or more domain specific relationships can also be defined with the same form in the future.

OPEN IN VIEWER

Table 5

Functions for relationships between products

Function	Simple Feature counterpart	Use case scenario
spt:touches	touches	Identify connection relationships between building elements
spt:disjoints	disjoints	Evaluate interferences between building elements
spt:intersects	overlaps	Detect clashes between building elements
spt:contains	contains	Identify containment relationships between e.g. space and elements
spt:within	within	Identify containment relationships between e.g. space and elements
spt:equals	equals	Detect duplicate building elements in coordination phases

OPEN IN VIEWER

Listing 6.

Query to retreive all walls intersect with slabs. The result of query is used to detect clashes between walls and slabs

Defined functions are listed in Table 5 with their counterparts defined in OGC Simple Features and example scenarios for using such functions. Each of these functions retrieve products that have such relationships, or evaluate the relationship between two products. In the GeoSPARQL standard, these topological relationships are defined to process 2D geometry data, while in our cases 3D geometry data is the focus.

Listing 6 shows an example to retrieve walls which intersect with slabs in order to detect clashes between walls and slabs.

4.4.2. Property for groups of products

Functions in this group are used to derive properties for groups of products. Querying the distance between products is a typical example. Many building codes and BIM requirement manuals constrain the minimal, maximal or exact distance between building components, such as interference between building elements, clearance before openings, heights of floors etc. The exact semantics of the notion “distance” can vary between contexts. We have currently defined the concepts provided in Table 6.

OPEN IN VIEWER

Table 6

Functions as properties for groups of products

Function	Description
spt:distance	Returns the shortest distance between two products in 3D space
spt:distanceZ	Returns the vertical shortest distance between bounding boxes of two products
spt:distanceXY	Returns the shortest distance between the projections of two products on a horizontal plane

An example query is provided in Listing 7 to detect suspended ceilings that are too close to the floor slab and may e.g. interfere mechanical, electrical, and plumbing components (MEP) by selecting ceilings which have the vertical distance shorter than 0.4 meter with floor slab in the above floor [50]. The function spt:distanceZ requires two products as the inputs for the computation.

OPEN IN VIEWER

Listing 7.

Query to retrieve ceilings that are too close to the floor slabs in the above floor

This vocabulary includes geometry related concepts that are materialized in RDF graphs. They are considered as general geometry concepts that provide additional layers independent from domain information. Similar with GeoSPARQL, we define the geom:Geometry as the class for geometry objects. As mentioned in Section 4.3, triangulated representations are used to represent Body geometry data. As geometry data for a product is usually processed as a whole, Well Known Text (WKT) string literals that have been defined in Simple Feature Access [21] are adopted to keep materialized triples in small size. The geometry data of an element (instances of IfcElement subtypes) that is decomposed by other elements is represented by geometry data of its composing elements. Figure 7 illustrates the basic structure for materializing product geometry data. Table 10 lists a comparison between triple count of building models in ifcOWL, geometry subsets of them and the triple count of geometry data represented in this format. It shows that geometry data represented in triples with WKT literals is much more compact and should be more efficiently processed by programs. Besides the triangulated representations that are by default always materialized, the axis aligned bounding boxes and minimum volume bounding boxes for products are also provided in this vocabulary. In future research, other types of geometry representations can also be extended if they are required.

OPEN IN VIEWER

Fig. 7.

SPARQL query with domain specific functional extensions.

OPEN IN VIEWER

Fig. 8.

Use case examples that require temporarily added or generated geometry objects to analyse properties and relationships of building objects: The first one requires “upper surface” and “lower surface” of walls and slabs to evaluate their topological relationships; The second one requires extruded boxes to evaluate clearance in front of windows.

OPEN IN VIEWER

Listing 8.

Query to select all walls which do not have bottom surface touching the upper surface of any floor slab on the same floor

Another requirement that can be addressed by WKT and this vocabulary is to represent and process temporarily generated geometry data at query runtime. In many tasks, analysis on IFC building models not only requires geometry data of building products, but also needs temporarily defined or derived geometry data. Figure 8 shows some use cases of them. Such geometry objects can be manually added or automatically derived in query runtime with the WKT literals, and expression functions used in e.g. FILTER expressions can be defined for additional manipulation on them. An initial set of expression functions for manipulating WKT data are defined. The query example in Listing 8 demonstrates an example of using them. In this example, the bottom surface and upper surface are derived at query runtime (see Table 3) as partial geometries of a wall and a slab, and they are additionally evaluated by the function geom:touches3D to identify their topological relationships.

Table 12 documents the results and average query execution times for Q1 to Q7 on models M1, M2 and M3. All queries except Q2 are used to address requirement checking use cases by retrieving building objects which violate defined constraints. Thus, in these cases returning zero results means no violation in the building model was detected.

Q1 and Q2 only depend on functions that are implemented based on the SPIN framework, which in turn is dependent on the Jena ARQ query engine, while Q3 to Q8 also depend on additional computations in external Java code. Q3 and Q4 are related to functions in the group introduced in Section 4.3 and their query execution time mainly depends on the algorithms used for deriving properties from the geometry data of a single product. For example, in Q3 when the function pdt:hasOverAllHeight is called, the underlying WKT representation of the product is processed to generate an axis-aligned bounding box on the fly in order to derive the overall height of a wall. In Q4, the most computationally expensive part is the function pdt:hasWindowArea, which needs to compute a minimum volume bounding box for each window object. These processes can be optimized by materializing additional geometry representations for building products. Q5, Q6 and Q7 have relatively longer execution times, especially for the largest model M3. This is expected since these three queries are all related to spatial reasoning functions, which involve geometry data of multiple building products. For example, the current procedural of the function spt:intersects, which is used in Q5, needs to compute the topological relationship for each combination of a wall and a slab. This procedure needs to run 750*19 times for the model M3, which contains 750 walls and 19 slabs. This can be optimized further by mechanisms like adding spatial indices to reduce computation time.

6.2. Comparison

We first compare the results with a procedural that only uses SPARQL to query ifcOWL data. The same query environment is set up with the exception that all the extended functions are not activated. By just using SPARQL and ifcOWL data, only the use cases that are addressed by Q1 and Q2 can be realized, hence the comparison is limited in these two queries. Queries with the same semantics of Q1 and Q2 are written in SPARQL and presented in Listing 12 and Listing 13 in Appendix B. They have complex query bodies that contain more triple patterns. They are documented as Q1* and Q2* in Table 13, which also compares them with Q1 and Q2 with respect to triple pattern count in WHERE clauses, query results and average query time. It shows that with significantly simplified query bodies, Q1 and Q2 have the same query results with Q1* and Q2* respectively without sacrificing much performance. This topic is further discussed in Section 8.3.

As mentioned in Section 3, there have been a few ontologies developed to simplify ifcOWL data including those introduced in [36] and [39]. All these existing efforts have not considered processing geometry data, hence only the use cases addressed by Q1 and Q2 can be addressed. Functions defined in Section 4.1 and 4.2 can be compared with those simplified ontologies. The difference is that those existing simplified ontologies tend to preprocess ifcOWL data (or IFC data) and transform it to a more compact data graph and improve query performance, while the approach presented in this paper treats simplified properties and relationships as functions, which are used in query runtime. An advantage of this approach is that simplified queries can run on any ifcOWL data without additional materializations (for functions defined in Section 4.1 and 4.2). This provides a more flexible paradigm that users do not have to adopt the entire vocabulary but can reuse a subset of them or extend them to adapt with more specific use cases. If some simplified IFC ontologies are standardized, this approach can also be compatible with them by defining additional mapping rules.

Regarding use cases addressed by Q3 to Q7, to our knowledge there is no open and off-the-shelf query system in the Semantic Web field can be compared with. Some of them might be supported by BIM query languages which support geometry features like those introduced in [11] and [13]. However, we argue that these query languages either have limited expressive power or do not have precisely defined or standardized semantics, while this approach is based on a standard and expressive query language [1,19]. More importantly, with this approach RDF and other Semantic Web technologies can be leveraged to facilitate knowledge reasoning and data integration and partition tasks. With these capabilities, defined functions can more easily be reused and extended for specific applications. An example is presented in Section 7.

8.1. Flexibility and portability

In comparison with domain specific query languages that are developed from scratch, the approach introduced in this paper leverages Semantic Web technologies and existing implementations to provide a more interoperable, modular and flexible mechanism to extend functionality in order to address a wide range of use cases for information extraction and validation of the AEC industry. As shown in Section 7, query functions for specific use cases can be extended by adding additional declarative rules based on procedural functionality. They are modular and flexible to adapt to the various possible forms to present facts in IFC datasets. For example, a protected opening in another building case, created by another author using a different BIM authoring tool might be different from how it is defined in Listing 14. It is easier to change or replace this rule without affecting other rules. External, linked datasets can be addressed using the same technology as long as they are captured as RDF or provide SPARQL endpoint services [6,20].

Declarative methods can also enable more portable implementations for functions. As many functions are defined using SPIN rules, they can be reused by query environments which have implemented SPIN (e.g. Topbraid SPIN API or Eclipse RDF4J) and potentially be reused by those which have implemented SPARQL. All the SPIN functions are stored in RDF which can be maintained in triplestores or shared as dereferencable resources on the Web. It is also possible for users to upload SPIN rules as RDF data to the server side to extend functions for their own cases without extending the source code of the server.

There are a few issues that affect the portability of this system. The main issue that limits portability here is functions implemented by procedural programming, which still needs geometry libraries to be integrated. This may not be addressed in a short term as geometric computation is a domain that usually requires specific methods and tools. Secondly, the portability also depends on the implementation of used declarative methods. With the implementation approach presented in Section 5, in order to implement a BimSPARQL-enabled endpoint and reuse some of the development work here, the server side must support SPIN by e.g. integrating SPIN engines. For specific applications that require extending additional functions using SPIN, users must have the access to upload SPIN rules to the server side.

8.2. Coverage

The full list of implemented functions are published in the link of Appendix A. They are defined based on referenced BIM requirement checking use cases. There are various use cases in the AEC industry and almost unlimited properties and relationships are required. IFC also provides rich methods to represent information to adapt with different contexts and projects. As stated in Section 4, it is not our aim to provide a complete set of functions, but to suggest a more bottom-up approach to define modular functions and then gradually extend to cover more use cases. In this approach, each function should be considered as a module to retrieve a view from IFC building models. A general classification of them is provided as a framework for further extending functions and a set of functions are provided as foundational examples.

Functions introduced in Section 4.1 and 4.2 cover all the commonly used semantic structures and all the simple data properties and quantities defined in the official IFC documentation. In real practices, these two groups of functions can be extended according to various application concepts in AEC sub-domains and third-party property sets and quantity sets.

Functions introduced in Section 4.3 and 4.4 mainly focus on triangulated boundary representation, which is a fundamental geometric representation that can be used to represent any 3D physical shapes. The WKT literals simplify the structure of IFC geometry data, which has a high degree of decompositions. This method enables many general geometry algorithms be reused for analyzing data (see Table 9). A set of general geometry and spatial reasoning functions that are applicable for all building products and some example functions related to specific product types are defined. This geometric representation is also related to further implementations including e.g. spatial indexation and use cases like efficient visualization, which is commonly required for many applications in the AEC industry. It is suggested that such representation should be accepted as the basis for other implementations to ensure interoperability and query results across them. There are indeed use cases that require particular geometry forms (e.g. deriving the flange thickness for a I-shape beam requires parametric I-shape profile objects), they can be extended by providing multiple representations for specific products. It can be envisioned that with efforts of research communities, a consensus of a set of geometry representations for query and analysis should be defined and accepted.

From the perspective of use cases, a current limitation of this approach is related to requirements of instantiating resources with additional triples based on procedural computations. For example, identifying the shortest path between two rooms usually needs to instantiate a path object, which might have geometric representations and relationships with e.g. passed spaces and doors. Even with procedural coding, extended functions are not suitable to create such additional dynamic data graphs in query runtime. WKT literals might be used to represent additional geometry objects in query time, but more investigations are still required to properly adapt this type of query functions in an RDF and Semantic Web environment.

8.3. Query performance

At present optimizing query performance is not in the main focus of the research presented here. Query performance depends on the implementation of used technologies and geometry analysis algorithms that are used. The prototype implementation has used the SPIN framework, which is based on the Jena ARQ query engine and Jena TDB triplestore. In Section 6, it is shown that for some cases, simplified queries can have similar performance with equivalent plain SPARQL queries. This implementation method has also taken part in a performance benchmark with comparisons to other rule languages and their implementations [38]. That research shows that this implementation method is a reliable approach, but there is still room for optimizing its performance in comparison with some commercial databases like Stardog. In the current SPIN framework, when a function is called in a triple pattern, it is considered as a separate query that is executed based on assigned arguments and then joints with the temporary results of outer query. It lacks a query rewriting mechanism to flatten queries and preferentially execute the most selective triple patterns regarding all the triple patterns defined in called functions.

As shown in Section 6, the current performance short-coming can be mainly attributed to geometry-related functions, especially spatial reasoning related functions. With a plain RDF triplestore like Jena TDB without additional optimization mechanisms, spatial reasoning functions have relatively long running time. In future developments, this process can be optimized by e.g. integrating spatial indices and caching mechanisms.

As RDF graphs are flexible, another direction for optimizing performance might be to materialize required triples into RDF graphs for specific applications. As described in Section 6, besides ifcOWL data only the triangulated boundary representation of products are currently materialized and all the functions are processed at query runtime. If some related functions are frequently required for specific applications, it is recommended to materialize them as properties. The effect of materialization has been discussed in [38]. Since it is usually a trade-off between storing and computing data, a dynamic approach to automatically materialize triples with regards of use cases, preprecessing, runtime performance and storage cost needs additional investigation and future research.

9.1. Performance optimization

Optimization for query performance is necessary as it is important for applications of this approach. As discussed in Section 6 and 8, some current performance shortcomings of the solutions introduced here are mainly related to the implementation issues. They seem specifically problematic for spatial reasoning functions, which require additional computations related to many-to-many relationships. In the future, spatial indexation mechanisms can be integrated to improve performance in this aspect, as they have been proved to have significant impact for spatial reasoning in the geospatial domain [37]. This might lead to creating specialized databases in the future. Additional development and testing work is required since this method might also cause the performance issue of preprocessing building models if building designs change frequently. Other general query optimization techniques such as query rewriting and additional materialization should also be investigated and applied.

9.2. Implementation approaches

As discussed in Section 8, the purpose of introducing a declarative language for implementing some of the functions is to improve the portability of development work. In practices, the portability is also affected by the implementation status of used declarative language. Other technologies especially standardized ones shall also be investigated in the future. It however requires evaluation and comparison regarding their expressiveness, implementation status and performance. A potential candidate is Shape Constraint Language (SHACL) [31], which is a newly standardized W3C Recommendation and has many functionalities in common with SPIN. Regarding geometry related functions, existing and commonly used 3D geometry libraries like e.g. CGAL [16] may also be integrated in the future to reuse algorithms, improve interoperability and performance of computations.

9.3. Knowledge engineering

The last direction that can be considered as a long-term objective is to simplify the knowledge engineering processes that are required for extending functions. As shown in Section 7 and Appendix C, SPIN rules can enable more flexible extensions for functions, but the knowledge engineering work required is still intensive for domain end users. How to enable them to effectively translate domain knowlege into processable rules is still an open question that needs to be addressed. Proper methods and tools for such knowledge engineering activities need to be developed to ease these processes and verify correctness.