# An Approach of Automatic SPARQL Generation for BIM Data Extraction
## 4 Case Studies
### Case Study Two: A Single House in Norway  
We tested our approach using another BIM case, shown in Figure 10. Table 1b lists the query requirements to extract all external walls on the second floor and the Globally Unique Identifiers (GUIDs) of these walls in the BIM model. Because there are two properties to jointly express external walls in the IFC schema (IsExternal property and a Boolean value), the total three query conditions are \"Plan E2\", External, and TURE, listed in Table 1b. Table 3 lists the prefixes and IRI in this case. Figure 10: A single house project in Norway. Figure 9: The generated SPARQL query and query results. Similarly, we implemented the path queries in Stardog using five different query keywords, shown in Figure 11. When the results of a Stardog path query number more than 1000 paths, only 1000 results are shown in the Stardog database. However, when the path queries are exported through \"Run to File\", all query results can be stored in a csv file. In this case, the core keyword was \"wall\", related to all other query keywords, and the closest term to \"wall\" was \"_IfcWall_\" in the BIM knowledge base, so the path file of the keyword \"_IfcWall_\" was viewed as the main target. As the first iteration, we began to search the common node(s) between the path file for _\"IfcWall\"_ and the other path file, generating paths that connected the keyword _\"IfcWall\"_ and the other query keyword, and then stored the shortest path(s) into a shortest-path file. In the first iteration, we obtained four shortest-path files. The next iteration was to search for common node(s) between pairs of shortest-path files. Two paths were merged into a new path through the common node(s) and stored in a new shortest-path file for the next iteration. For example, Zone I in Figure 12 shows the shortest path connecting _\"IfcWall\"_ and _\"Plan E2\"_ obtained in the first iteration. The other shortest path in the other path file was merged into this path, and then a new shortest path was generated, shown in the combination of Zone I and Zone II in Figure 12. Nodes in the red dashed circle are common nodes between these two shortest paths, which connect the two paths. However, ifc:IfcGloballyUniqueID is a class, not a value. Actually, the GUID value of an instance has a same upper node as the node _\"ifc:IfcGloballyUniqueID\"_ of this instance. When finding the node of _\"ifc:IfcGloballyUniqueID\"_ of an instance, one also finds the position of the GUID value of an instance because they have a fixed structure in the ifcOWL schema. So, we can add the fixed structure in the shortest path to find the GUID value, shown in the red font in Zone II of Figure 12.  
Figure 11: The codes and results of path queries based on different query keywords. Figure 12: The structure of the shortest path of query requirements. In the third iteration, a path in the path file of the keyword _\"IsExternal\"_ was joined into the new shortest path through the common nodes(s) in the red dashed circle in Figure 12. The result of the third iteration is shown in the combination of Zones I, II, and III in Figure 12. In the last iteration, the path in the last shortest-path file was combined into the shortest path that was gained in the third iteration. The greed and red dashed circles cover all common nodes in this iteration; however, the common nodes were only added into the shortest path once. So, the whole of Figure 12 illustrates the final result of the shortest path connecting the five query keywords in this semantic BIM case. We used SPARQL variables to replace the node instances, shown in Figure 10:0 Figure 14 exhibits the generated SPARQL query and the query results of SPARQL codes. When compared with the external walls of the second floor in the Solibri Model Viewer tool  
We implemented our approach using the Python programming language to automatically search common nodes and generate the SPARQL query.