Open data movement is a worldwide movement that data are published online with FAIR principle 1 . Linked Open Data (LOD) [4] started by Sir Tim Berners-Lee is best aligned with this principle. In LOD, factual records are represented by a set of triples consisting of subject, predicate and object in the form of a standardized representation framework, RDF (Resource Description Framework) [5] . Each element in RDF is represented by network-accessible identifier called URI (Uniform Resource Identifier). SPARQL [15] is a standard query language for RDF data, and its basic structure is a graph pattern which consists of triple patterns being matched with triples in RDF data.
Although LOD has been proliferated its population over various domains, there are still lots of data which require large effort on converting into LOD. In particular, documents such as manuals and minute books are in this line. To convert document structure into RDF is one choice, however, the converted RDF schema and its data are not semantically meaningful. To utilize contents of documents, extracting facts from documents in the form of triples is another choice. To this end, sophisticated techniques (information extraction, ontology This is a full version of the poster paper in ISWC 2020. 1 FAIR stands for findability, accessibility, interoperability and reusability design, ontology mapping, and more) have been studied, but they still require human efforts on error-pruning.
In this paper, the way to utilize document open data which are linked from entities in LOD is explored. A naïve approach is a step-by-step approach. It first process SPARQL instance to obtain entities with links to documents. Second, these documents are processed on the basis of users' purpose such as filtering and analysis. In most cases, full-length documents are not necessary but only parts of documents are required. If these documents are structured (e.g., XML or JSON) and stored in dedicated databases (e.g., XML DB or document DB), their queryable interface allows users to extract parts of documents.
Consider the following example scenario. A user attempts to survey the proliferation of country-wise warnings about a virus with respect to county populations. Suppose that national safety information are published in XML and county information are available on LOD such as DBpedia. She first searches on the national safety information by using XQuery for countries that warnings about the virus are announced in a specified period. For each country in the XQuery results, she searches DBpedia for finding its population by using SPARQL. At last, she analyses these results for finding relationships between population and warning proliferation. In summary, this user is required three processes, namely, XQuery processing, SPARQL processing and merging results of different formats (i.e., XML and tuple). This example indicates that utilizing entities in LOD with documents is laborious that communication with different interfaces and merging results of various formats are required.
In this paper, to realize efficient query processing over LOD with documents, a SPARQL-based seamless access method is proposed. In particular, XML is assumed as the format of documents, therefore, the proposed method combines XQuery into SPARQL. For the first attempt, the usage of XQuery in SPARQL is limited for filtering. To this end, a dedicated filtering expression, XQueryFILTER, for SPARQL is proposed in this paper. This expression enables XQuery-based filtering by accessing underlying XML data. There are basically three query execution plans with XQueryFILTER as follows. Parallel plan is a plan that SPARQL and XQuery are performed in parallel and their results are joined afterward. SPARQL first plan is a plan that SPARQL is performed first, bindings of SPARQL variables are pushed into XQuery, and XQuery is performed. XQuery first plan is a plan that XQuery is first performed with modification to return document identifiers and SPARQL with these identifiers is performed. To explore the optimal plans, in this paper, database theory-based query optimization [16] which utilizes statistics of selectivity of SPARQL and XQuery as well as performance of SPARQL endpoint and XML DB is proposed.
The contributions of this paper are summarized as follows.
-Novel Filtering on LOD: In this paper, to utilize documents connected from entities in LOD, SPARQL is extended to enable document-based filtering. In particular, the proposed method assumes XML documents as the underlying documents which are stored in XML DB in which XQuery can be performed. The proposed extension, XQueryFILTER, is a filtering expression in SPARQL that contains an XQuery instance as filtering condition. This XQuery instance contains a SPARQL variable which bindings are links to XML documents in XML DB. -Query Optimization: SPARQL with XQueryFILTER contains both SPARQL and XQuery instances and they can be performed separately, therefore, three possible plans can be considered, namely, parallel plan, SPARQL first plan and XQuery first plan. On the basis of query optimization in database theory, the cost models of these plans are designed and the optimal query plan is explored by using selectivity estimation and database performance statistics. -Real-world Scenario-based Experiment: To demonstrate the usability of XQueryFILTER, three real-world scenarios are examined in experimental evaluation. The first one is country search from DBpedia using safety information XML data in external database. The second one is law search based on law body that laws are entities in law history LOD [11] and law bodies are XML documents. The third one is discussion search with minute book that discussions are associated with laws in the law history LOD and minute books are XML documents. On these scenarios, the experiment showcases that the query optimization can discover the optimal plans. The rest of this paper is organized as follows. First, related work to the proposed method is introduced in Section 2. In Section 3, definition of XQueryFILTER and basic architecture for XQueryFILTER are explained. The proposed method for realizing XQueryFILTER including query plans and optimization are discussed in Section 4. In Section 5, real-world scenario-based experiments are introduced to showcase characteristics of these plans and effects of the optimization. Finally, conclusion and future directions are described in Section 6.
In this paper, SPARQL with XQuery-based filtering is proposed, and, there are few work on combining queries for XML (like XPath, XSLT and XQuery) into SPARQL query except [6] . Droop et al. [6] have proposed a translation-based XPath embedding for SPARQL in order to enable XPath processing in SPARQL query processor. To this end, they have proposed translation model from XML to RDF and from XPath to SPARQL. There are three major differences from their work to the proposed filtering in this paper. One is query type for XML, namely, XQuery and XPath. In general, XQuery is more expressive than XPath. Another difference is that, in the proposed approach, no preprocessing is applied to XML data, while [6] requires translation into RDF. The other difference is that, the proposed approach fully utilizes the dedicated query processing technique in XML DB, but [6] translates an XPath instance into a complicated SPARQL query and processes it on a SPARQL query processor.
The related context is to query XML and RDF which can be translated each other. So-called data-centric XML data [19] are designed for representing objects with hierarchical attributes, while document-centric (a.k.a. contentoriented) XML data preserve document structures where the data are still un-derstandable without XML tags. Therefore, data-centric XML data are easy to convert to RDF, while document-centric XML data require large efforts on designing ontologies and mappings. The existing approaches basically assume data-centric XML data and RDF data as their translation. These approaches can be roughly classified into the following three categories. (1) to use XQuery to query on RDF data, (2) to use SPARQL to query on XML data, and (3) query translation between XQuery and SPARQL.
In the first category, there are two basic approaches. One is to integrate SPARQL into XQuery and the other is to convert RDF into XML. One early work [8] is the former approach, which aims at reshaping the output of SPARQL queries into XML for subsequent applications. It embeds SPARQL query into XQuery/XSLT for reconstructing SPARQL query results into XML. A more recent work [2] is the latter approach, which aims to integrate Open Street Map (OSM) in XML and Linked Geo Open Data (LGOD). To this end, this work has proposed XOSM (XQuery for OSM) framework which enables XQuery over LGOD and OSM by transforming LGOD data into OSM format. Therefore, this work does not handle RDF data directly.
In the second category, XSPARQL [1] is a representative approach, which is an extension of XQuery for enabling querying to either XML data or RDF data by switching query expressions. The motivation of this work is that translating XML data into RDF data is a tedious and error-prone task. To deal with this situation, XSPARQL enables to query XML data to produce RDF data (lifting) and to query RDF data to produce XML data (lowering). Note that, in XS-PARQL, users can perform query on either XML data or RDF data, meaning that they cannot perform query both of them at the same time.
In the last category, translating from one query language to another has been studied [12] to enable universal access to data in any format. In the users' perspective, learning different query languages is troublesome. Query translation aims to reduce this learning cost. SPARQL2XQuery [3] is the only work on the last category for translating SPARQL to XQuery. It transforms XML schema into OWL ontology to generate mapping between XML data and this ontology, and on the basis of this ontology, SPARQL query is translated into XQuery.
In this section, the proposed extension of SPARQL is defined. In the first sections, XQuery and SPARQL with examples are briefly overviewed. In the following sections the definition of the proposed extension and a basic architecture of mixed databases (SPARQL endpoint and XML database) are introduced.
The following gives a brief review of XQuery, and the full definition of XQuery is referred to [17] . The core of XQuery is FLWR expression, each of which character refers to keywords FOR, LET, WHERE and RETURN, respectively. FOR and LET clauses are used for binding XML elements to variables, WHERE clause serves a filter for the bindings, and RETURN clause reshapes the bindings in arbitrary XML format.
Listing 1 is an XQuery example. The target XML data are obtained from Overseas Travel Safety Information Open Data by Ministry of Foreign Affairs (MOFA) of Japan 2 . The data contain safety information (e.g., risk levels and announcements) for each foreign countries. The mail tag in the XML data correspond to announcements from MOFA. The XQuery in Listing 1 is a query to search for mail tags about a country (each XML file corresponds to a country) produced after March, 2020 talking about COVID-19 (i.e., coronavirus). 
The following gives a brief review of SPARQL, and the full definition of SPARQL should be referred to [15] . The core of SPARQL is basic graph pattern which consists of a set of triple patterns. A triple pattern is represented by triplet (s, p, o). s and o can be variable, URI or literal, and p can be either variable or URI. Main keywords in SPARQL are SELECT and WHERE. WHERE clause includes basic graph pattern and filtering conditions. SELECT returns bindings of specified list of variables in WHERE clause. SERVICE clause is an extension in SPARQL 1.1 [18] , which supports queries that merge data distributed across the Web.
Listing 2 is a SPARQL example using SERVICE clause on DBpedia 3 . The local SPARQL endpoint includes a mapping table between countries in the safety information by MOFA and those in DBpedia. The SPARQL instance in Listing 2 is a query to search for countries in the local SPARQL endpoint which population is more than 10 million using external knowledge about countries in DBpedia. Country identifiers in the local endpoint are explored in the WHERE clause, and external information in DBpedia to explore countries with more than 10 million population is used in the query by using the SERVICE clause.
XQuery-based filtering aims to filter bindings of basic graph pattern in SPARQL that XML documents specified in the bindings satisfy conditions in XQuery. To this end, this XQuery instance is required to return boolean value. In the extended query, XQueryFILTER expression is added to the SPARQL definition, that imitates FILTER expressions. Argument of XQueryFILTER is XQuery expression including a single variable used in basic graph pattern in SPARQL. Note that Figure 1 represents a basic architecture for realizing SPARQL with XQuerybased filtering. A basic assumption is that RDF and XML data are separately stored in SPARQL EP (endpoint) and XML DB, respectively. Dedicated query processors are associated to communicate with the databases, namely, SPARQL processor and XQuery processor. Query manager handles user query, decomposes it into SPARQL and XQuery instances, explores optimal query plans, executes In this architecture, the query manager is responsible for query optimization. In the parser module, it first parses input query into SPARQL and XQuery instances. In the optimizer module, it explores optimal query execution plan of the basis of statistics and selectivity estimation by using the catalog manager. The catalog manager is responsible to mange supplemental information for query optimization by communicating to the databases. At last, the executor module executes the decomposed queries and reshapes their results.
To realize efficient SPARQL with XQuery-based filtering, the query manger in Figure 1 is a core component of query processing. This component has three subcomponents, namely, parser, optimizer and executor. Since RDF data and XML data are separately managed, the role of the parser is to decompose a user query into a SPARQL instance and an XQuery instance, and, besides, to extract SPARQL variable in XQueryFILTER for joining results of these queries.
In the optimizer, there are three possible plans to execute SPARQL with XQuery-based filtering as shown in Figure 2. 1. Parallel: Execute SPARQL and XQuery in parallel and join these results afterward (Figure 2 (a) ). 2. SPARQL First: Execute SPARQL first, push its bindings down into XQuery, and evaluate the bindings with XQuery results (Figure 2 (b) ). 3. XQuery First: Execute XQuery first and push its results down into SPARQL (Figure 2 (c) ).
Subsequent sections introduce how to realize these query execution plans followed by a section describing optimal query plan exploration. 
Basic idea of this query plan is that SPARQL endpoint and XML DB are independent systems, therefore, executing SPARQL and XQuery in parallel can fully utilize their capabilities. In this plan, SPARQL and XQuery instances after decomposition requires query rewriting in order to execute correctly and join process afterward. In SPARQL instance, To join results of SPARQL and XQuery, variables for join keys are required, thus, in SPARQL instance, the SPARQL variable appearing in XQuery instance is ensured to exist in SELECT clause. In XQuery instance, a SPARQL variable within it leads syntax error. Therefore, for XQuery execution, XQuery instance is rewritten to another instance which finds XML documents satisfying the all conditions in the queries.
In this paper, rule-based rewriting is applied to rewrite an XQuery instance. First, enumeration of XML documents in XML DB is added, that is, FOR clause for this purpose is added at the front of this instance. Second, document loading function doc(·) is replaced to the variable in the added FOR clause. Third, boolean condition in RETURN is moved to WHERE clause. If WHERE clause does not exist in this instance, it is appended, otherwise this condition is added to WHERE clause with conjunction keyword (i.e., and). At last, expression in RETURN clause is replaced to base-uri (·) 4 for returning identifiers of XML documents. For instance, XQuery in Listing 3 is rewritten as Listing 4 (red-colored parts are changed by the rules above). The first line is added by the first rule where 'safety_info' is a name of collection in XML DB, variable $doc in the second line is replaced from doc(?doc) by the second rule. WHERE clause is added with the condition in RETURN clause by the third rule, and the expression in RETURN clause is replaced with base-uri ($doc) which returns identifiers of XML documents bound to $doc variable by the last rule.
To generate query result of SPARQL with XQuery-based filtering, respective results of SPARQL and XQuery are joined in an equi-join manner, since these results contain XML document identifiers in common. Variable corresponding with these identifiers is used as join key to find bindings of SPARQL variables that satisfy XQuery conditions. Since the join process is done on memory, hash join is a reasonable option of join algorithm. If the results do not fit in memory, sort-merge join or other algorithms can be considered 5 .
Basic idea of this query plan is that, when the number of binding in SPARQL instance is small, only the bindings are necessary to be examined in XQuery evaluation, therefore, the cost for XQuery processing can be reduced. To this end, similar to the parallel plan, SPARQL instance is rewritten to add the SPARQL variable in XQuery instance into its SELECT clause.
To push the bindings down to XQuery instance, this instance is rewritten by a similar rule to one in the parallel plan. In this rule, first, document enumeration on the basis of the bindings is added, that is, FOR clause including a list of XML documents in the bindings is added at the front of this instance. Second, document loading function doc(·) is replaced to the variable in the added FOR clause in the same way as the parallel query plan. At last, the expression in RETURN clause is modified to represent tuples of XML document identifier and boolean value of whether the document satisfies condition. Listing 5 showcases an example of rewritten XQuery instance of the query in Listing 3. The first line is added by the first rule and the second line is modified in accordance with the second rule. The RETURN clause is changed as the third to forth lines for pairing document ID and boolean value. To generate query result of SPARQL with XQuery-based filtering, bindings of SPARQL variables is filtered by the results of XQuery. This process can also be a join processing, and again this join processing is equi-join, therefore, hash join is performed. In contrast to the parallel plan, the size of XQuery results is much smaller, thus, join cost is also much smaller than that in the parallel plan.
Basic idea of this query plan is similar to that of the SPARQL first plan, that is, when the number of bindings in XQuery instance is small, only the bindings are necessary to be examined in SPARQL evaluation, therefore, the cost for SPARQL processing can be reduced. This is effective when SPARQL instance includes SERVICE clause for accessing remote SPARQL endpoints, which requires higher query processing cost. Since XQuery is used to enumerate XML documents which satisfy the conditions in XQuery, rewriting XQuery in this plan is exactly same way as that in the parallel plan.
To push results of XQuery instance down to SPARQL instance, the SPARQL instance is modified as a sequence of UNION operators over graph patterns corresponding with the XQuery results. Each graph pattern is a replica of WHERE clause of the original SPARQL instance, except replacing the variable appearing also in XQuery instance to one of these results. Listing 6 displays a rewriting example of SPARQL with XQuery-based filtering in Listing 3. WHERE clause in the original SPARQL instance is replicated for graph patterns, and these graph patterns are concatenated UNION operators. Variable ?doc is replace with identifier for XML document. Result set of the rewritten SPARQL instance is equivalent to that of the original query of SPARQL with XQuery-based filtering, therefore, no post-processing is required in this plan.
Basic idea of query optimization is to chose a query plan with the least cost for execution. To this end, execution costs of query plans are necessary to be modeled. Execution cost of the parallel plan depends on the worst performance of SPARQL endpoint or XML DB and on the join cost of post-processing. Execution cost of the SPARQL first plan is summation of SPARQL query processing cost, reduced XQuery cost by SPARQL result pushdown and the join cost. Similarly, execution cost of the XQuery first plan is summation of XQuery processing cost, reduced SPARQL cost by XQuery result pushdown.
Let C (p) , C (s) and C (x) denote costs of the parallel, SPARQL first and XQuery first plans, C SPARQL and C XQuery respectively denote the solo processing costs of SPARQL and XQuery, and C (p) Join and C (s) Join respectively denote the join costs in the parallel plan and in the SPARQL first plan. On the basis of these notations, the costs of the three plans are formalized as Equations 1, 2 and 3. The amount of cost reduction on the subsequent query processing in the SPARQL first and XQuery first plans are represented by selectivity ratios, ρ SPARQL and ρ XQuery , of preceding SPARQL and XQuery instances.
To explore the optimal plan, in this paper, these individual costs and selectivity ratios in these equations are estimated using statics from query execution history and conventional selectivity estimation techniques for SPARQL (e.g., [13, 20] ) and XQuery (e.g., [21, 22] ). The main objective of this paper in this optimization is to model the costs of query plans, and estimating these costs and selectivity ratios are out of scope. Therefore, in this paper, the costs and selectivity ratios are assumed to be ideally estimated.
In this paper, experimental evaluation to show efficiency of the proposed SPARQL with XQuery-based filtering technique and query optimization is conducted. In this experiment, three real-world scenarios are prepared. These scenarios have different settings of databases in terms of network latency and data size. Datasets and queries are explained in the subsequent section. For XML data, local XML database is prepared and XML data are stored in it. For RDF data, local and external SPARQL endpoints are used. For the local databases, eXist-db (version 5.2.0) 6 and Apache Jena Fuseki (version 3.14.0) 7 are used for XML DB and SPARQL endpoint, respectively. In this experiment, query execution time is used for efficiency measurements of query processing.
In this experiment, three scenarios are prepared in order to observe query performances over different performances of underlying databases as summarized in Table 1 . The first scenario (C.S. scenario) is to search countries with governmental safety information messages. This scenario is the case that cost of querying to SPARQL endpoint is high and that of querying to XML DB is low. This case is realized by using external SPARQL endpoint via SERVICE clause and small number of XML documents. The second scenario (L.S. scenario) is to search acts with their body texts. This scenario is the case that costs of querying SPARQL and XQuery are comparable. This case is realized by local SPARQL endpoint and moderate number of XML documents. The third scenario (D.S. scenario) is to search discussions with minute books about law enactment. This scenario is the case that cost of querying SPARQL is low and that of querying XQuery is high. This case is realized by local SPARQL endpoint and large number of XML documents. The following summarize datasets and queries in these scenarios, and Table 2 showcases dataset sizes. Queries are generated by using templates to control the selectivities of SPARQL and XQuery instances 8 . Scenario (C.S.) -Country Search with Safety Information: XML data in this scenario is Overseas Travel Safety Information Open Data 9 by Ministry of Foreign Affairs (MOFA) of Japan. Each XML document corresponds to a country and consists of a bunch of past messages about safety information of the corresponding country with dates. For RDF data, DBpedia 10 is used for referring to country information (e.g., population), and to connect these XML data with country entities in DBpedia, mapping relations between safety information XML data and corresponding countries in DBpedia are prepared as a local SPARQL endpoint. On the basis of these data, queries are designed to search countries having more population than specified and there are warning messages about a particular keyword before specified date. Query template is shown in Listing 7. In the following query templates, '_pop_' and '_date_' are placeholders for conditions in order to control selectivity.
Scenario (L.S.) -Law Search with Body Text: XML data in this scenario is law body texts from e-Gov 11 , a portal site for administrative information, by Ministry of Internal Affairs and Communications of Japan. Each XML document corresponds with a law. For RDF, Japanese law history LOD [11] Listing 7: C.S. Query Template -Countries with more than '_pop_' people and with at least one announcement about coronavirus before '_date_' documents of their body text. Using these data, queries are designed to analyze sizes of laws in different era.
Scenario (D.S.) -Discussion Search with Minute Book: XML data in this scenario is minute books about law enactments from a minute book search service 12 provided by National Diet Library (NDL) of Japan. The XML data includes 107,193 minute books. For LOD, Japanese law history LOD [11] is again used in this scenario, and it contains 317,552 links to minute books. On these data, queries are designed to search laws with minute books that a particular person speaks and their conference is held before specified date. Figure 3 represent execution times over SPARQL selectivity (i.e., the number of results of solo SPARQL instance). There are three lines for each query plan (query plans are colored in different styles, that is, red solid for SPARQL first, blue dashed for XQuery first and black dotted for Parallel), which correspond with high, middle and low XQuery selectivities, respectively. They are represented by circle, triangle and square markers, respectively. The common observation from Figure 3 is as follows. First, the SPARQL first plan (resp. XQuery first plan) is linearly performed in terms of selectivity of SPARQL (resp. XQuery) query and it is scarcely affected by selectivity of XQuery (resp. SPARQL) query. Second, the parallel plan is nearly constant in terms of both selectivities of SPARQL and XQuery instances when their execution performances have a large gap like C.S. and D.S. scenarios. If these performances are comparable (as the L.S. scenario), this plan depends on both selectivities of SPARQL and XQuery as shown in Figure 3 (b).
As summarized in Table 1 , query performances on these scenarios are expected varying, and figure 3 demonstrates different query execution behaviors as expected in the cost models in Section 4.4. When SPARQL endpoint has low performance (i.e., C.S. scenario in Figure 3 (a)), the XQuery first plan is clearly superior to other plans, especially when XQuery selectivity is low. On the contrary, when XML DB has low performance (i.e., D.S. scenario in Figure 3 (c)), the SPARQL first plan is always superior to the other plans. For the comparable scenario (i.e., L.S. scenario in Figure 3 (b)), the parallel and the SPARQL first plans are comparable. Figure 4 shows a breakdown of execution time for each module in query plans ( Figure 2 ). This figure is a stacked bar graph of execution times of SPARQL, XQuery and Join, which are illustrated with blue, orange and green colors. Theses figures are about a particular condition in the L.S. scenario where XQuery selectivity is 660 (triangular marker in Figure 3 (b)). One basic fact in Figure 4 is that join times in both the parallel and SPARQL first plans have few effect on their overall performances.
In Figure 3 (b), the optimal plan for XQuery selectivity of 660 is switched from the SPARQL first plan to the parallel plan around SPARQL selectivity of 1,000. Figure 4 indicate a reason for this switching. Basically, in this SPARQL with XQuery-based filtering query, SPARQL instance is executable relatively faster than XQuery (this can be seen from SPARQL execution time in Figure 4 (b) and XQuery execution time in Figure 4 (c)). Therefore, SPARQL first plan is better plan as far as the number of XML documents being queried afterward is small. In this scenario, the number of queried XML documents more than 1,000 is a turning point that the parallel plan overcomes the SPARQL first plan.
This experiment indicates that XQueryFILTER is useful when XML data is associated with entities in LOD. The users who are knowledgable to both SPARQL and XQuery can easily use SPARQL with XQuery-based filtering. Furthermore, the three query plans modeling in this paper reasonably reflect the pros and cons of underlying databases, namely, SPARQL endpoint and XML DB. On the basis of settings of these databases (e.g., network latency and data size), these plans have best-performing conditions. When SPARQL endpoint (resp. XML DB) performs far better than XML DB (resp. SPARQL endpoint), the SPARQL first plan (resp. XQuery first plan) is preferred because results of SPARQL (resp. XQuery) can reduce the processing cost of the subsequent XQuery (resp. SPARQL) query processing. For the intermediate case when performances of SPARQL endpoint and XML DB are comparable, the parallel plan can perform better on average, however, when selectivities of SPARQL and XQuery instances are both smaller, the SPARQL first plan is preferred. The proposed optimization technique captures these characteristics of plans by the cost equations in Equation 1, 2 and 3 and can successfully discover the best plan if statistics of database performances and selectivity estimations of SPARQL and XQuery are accurate.
Conclusion: In this paper, an extension of SPARQL which incorporates XQuery as a filtering mechanism, XQueryFILTER, to handle XML documents connected with entities in Linked Open Data is proposed. In contrast to data-centric XML data, document-centric XML data needs effort to construct LOD, therefore, it is preferable to handle XML data intact. To realize XQueryFILTER, in this paper, three query plans are proposed and a database theory-based query optimization is proposed on the basis of selectivity estimations on SPARQL and XQuery. The cost models for these query plans reflect their behaviors based on the query execution costs of SPARQL endpoint and XML DB as well as selectivity ratios of SPARQL and XQuery instance. In the experimental evaluation on real-world scenarios, the optimization strategy successfully chose the optimal strategy. Future Directions: There are three promising future directions. First, the proposed filter can be extended to deal with other types of structured documents like JSON by applying similar idea. Second, the proposed filter can be relaxed for general-purpose XQuery processing such as simultaneously querying LOD and XML documents. Last, to improve usability, user-friendly queries are preferable such as keyword search and faceted search, which are extensively studied solely on RDF data and XML data (keyword search on RDF data [7] and XML data [9] , and faceted search on RDF data [14] and XML data [10] ).