## 2 Related Work  
In ref. [39], [PERSON] and [PERSON] proposed a distributed SPARQL query processing scheme in a distributed grid environment. A SPARQL query was divided based on the WHERE clause, and a single atom was created for each condition and transferred to a few nodes according to the query performing plan. For each atom, the weight of each (S, P), (S, O), and (P, O) was calculated, and the lowest value was chosen as the atomic weight in the calculation. Once the weight was calculated, a query path, in which atoms that are able to connect to each of the atoms are combined, was created. The created query path was then divided into many query paths (as many as the number of the nodes uniformly based on the weight of the atoms). The divided query paths were then transferred to the nodes randomly to process the query. In ref. [41], [PERSON] et al. proposed a query processing scheme when RDF graphs were stored in a distributed manner in P2P environments. A SPARQL query was divided based on the WHERE clause, and a single subquery was created for each condition. Each of the subqueries searches to see whether it is connected to the node that stores the data through the index starting from the SPARQL query-requested node. Each of the subqueries verifies whether query processing can be conducted in a node through the index, and the index is searched using the hash function based on the values of constants that propose a triple pattern variable of the subquery. The node that stores the data is verified through the index, and a query is transferred to the data node to process a query of preferred data. It then receives the query result to complete the query processing. If no index information of the subqueries is found in the node, subqueries are transferred to the neighboring node in the clockwise direction. In ref. [42], [PERSON] et al. proposed a SPARQL query processing scheme while a large amount of RDF graph was replicated in each of the slaves in the master-slave environment. It proposed a distributed SPARQL query processing scheme in the replicated distributed environment to reduce the join and communication costs that occur in a distributed environment. It was performed assuming that all RDF graphs can be stored in a single node. All RDF graphs were stored in a single node, and a single node can perform a more efficient query processing scheme if SPARQL queries are processed through replication. In ref. [43], [PERSON] et al. proposed a distributed SPARQL query processing scheme in a Spark environment. Apache Spark is a general-purpose high-performance distributed platform [44; 43; 45]. As with other functions, Spark can process MapReduce tasks and streaming processing. The existing platforms that provide analysis functions on big data have degraded performance because they are run on a disk basis during query processing. However, Spark enables faster analysis on big data as query processing can be conducted on a faster memory basis. All tasks in Spark are performed through resilient distributed datasets (RDDs). An RDD is a set of distributed data (objects) that cannot be modified [46; 47]. All tasks inside Spark are processed by creating a new RDD, modifying existing RDDs, or calling operations (functions or methods) in RDDs to calculate the results [48]. The requested SPARQL query excludes the conditions that include predicates such as type and class, which are unnecessary query types, during query processing and is transformed to TR-SPARQL. It is then divided into a few subqueries based on the WHERE clause of SPARQL. The divided subqueries create all connectable query paths. The data parsing cost, join cost, and communication cost is calculated for each of all the created query paths, and the least-cost query path is selected. Query processing is performed in the Spark distributed memory environment through the selected query path, and subqueries are transformed to a Resilient Directed SubGraph (RDSG) format to perform a join action with other RDSGs.