# An Approach of Automatic SPARQL Generation for BIM Data Extraction
## Main Research Approach  
### Research Approach and Definitions  
Some basic principles should be introduced firstly. RDF is a standard model that can facilitate data merging on the Web, and the RDF model is a graph-based data model with a directed and labeled graph data format [44]. SPARQL is a graph-based query language for RDF and can be used to query data across different data sources [45]. A SPARQL query generally consists of two clauses: _SELECT_ and _WHERE_. The _SELECT_ clause specifies the searched target(s) and the _WHERE_ clause is a set of triples, in which each triple can be a query filter condition. In a knowledge base, the assertion box (ABox) and the terminological box (TBox) are generally used to describe two different types of statements: the TBox describes the statements about conceptual entities and the ABox describes the statements involving concrete entities [46]. In order to use semantic building data with semantic web technologies, we need to convert the IFC data into the RDF data format (based on the ifcOWL schema), as described in Section 2.2. Additionally, we introduce the path concept, which is the connected relationships between two specified nodes, including the linked nodes and properties. The common nodes in different paths are frequently referred to. Figure 1 shows our definitions and assumptions about the length of a path and the shortest path. The length of a path is the number of connected edges in a path. The shortest path connecting the nodes \"3\" and \"4\" is the path of minimum length among all paths that include the nodes \"3\" and \"4\", shown in Figure 0(c). A SPARQL query is a sub-graph of the whole data model, so in our approach, we should firstly acquire the structure of the SPARQL query desired in the BIM model, and then utilize the structure of the SPARQL query to generate the required SPARQL query. Considering that not all civil engineers have programming experience, we tried to avoid intricate programming, so we chose the Stardog 7 RDF graph data platform because Stardog 7 provides path queries that can traverse an RDF graph, return all intermediate nodes on each path, and allow arbitrary SPARQL graph patterns to be used in the query [47]. One can easily get a query path in the Stardog database without complex programming. The path query syntax provided in the Stardog RDF database is shown in Figure 2, in which _START_ and _END_ specify a start node and an end node, and _VIA_ assigns a graph pattern to match each edge in the path [47]. According to the query keywords provided by engineers/users, all paths that contain different query keywords can be found through the Stardog 7 database. Based on the found paths, simple programming is developed to find the common nodes in path files and to connect all query keywords through the shortest path. The structure of the shortest path is the structure of the SPARQLquery. After that, the nodes in the shortest path are replaced with SPARQL variables and the final SPARQL query is generated. To formalize the query keywords, a query tabulation was designed to record the query requirements and was then used as a query basis to produce the SPARQL query, listed in Table 1. The first line of this tabulation is the query target(s), and the column below a target can be filled with query filter conditions about the target(s). A query tabulation can be filled with several targets. When multiple targets are extracted in a SPARQL query, a semicolon is used to separate targets, and a dot indicates the dependency relation of targets. For example, wall.GlobalUniqueID means the GlobalUniqueID of a wall, shown in Table 1b. Table 1b expresses that the targets are the GlobalUniqueIDs of walls and walls with some query conditions. The number of filter conditions is not limited, and one can increase or reduce the number of query conditions based on different requirements. It should be noted that specific query targets and conditions are necessary and the basis for correct execution results in our approach.