dataesr/scientific-paragraphs-categorization huggingface dataset:
Statistical analysis The methodological quality of all included RCTs was based on Cochrane's criteria, which include random sequence generation, allocation concealment, blinding of participants and personnel, blinding of outcome assessment, incomplete outcome data, selective reporting, and differences in baseline characteristics  [5]. Statistical analysis was conducted using the STATA software (version 15, Stata Corp LP, College Station, TX, USA) and the Review Manager 5. 3 software (Cochrane Collaboration, Oxford, England). Heterogeneity was assessed using the I 2 test, and cut-off values of 25%, 50%, and 75% were considered of low, moderate, and high heterogeneity, respectively  [6]. Where heterogeneity occurred, both fixed-and random-effects models were generated, and the conclusions compared, with the latter used where there were discrepancies.
PRISMA 2009 Flow Diagram Hernia (2019) 23:1093-1103 IdenƟficaƟon Records idenƟfied through database searching (n =366) AddiƟonal records idenƟfied through other sources (n =4) Records aŌer duplicates removed (n =370) Screening Records screened Records excluded (n =370) (n =345) Full-text arƟcles assessed Full-text arƟcles excluded, Eligibility for eligibility (n =25) with reasons (n =4) see text Studies included in qualitaƟve synthesis (n =21) Included Studies included in quanƟtaƟve synthesis (meta-analysis) (n =21) 1 3.
Introduction During the last decade, NoSQL databases and schemaless data modelling have emerged as mainstream alternatives to relational modelling for addressing the substantive requirements of current data-intensive applications  [1] , e. g. ,  5  IoT, web, social media and logs. Document stores hold data in collections of documents (most often JSON objects); they do not require the definition of any formal structure before loading data, and any data structure can be used when updating data. The main advantage of this is being able 10 to store documents in transparent and efficient ways  [2, 3]. Nevertheless, it is possible to store a set of heterogeneous documents inside the same collection, and for the purposes of this paper, documents have heterogeneous structures. This is a major drawback, and issues arise when querying such data because the underlying heterogeneity has to somehow be resolved in the query formulation in order to provide relevant results.
Querying Issues To retrieve information from a document attribute in most existing document stores, it is necessary to build 110 queries using the absolute path from the document root down to the attribute of interest. If a user formulates a projection query using only the absolute path title, any document store engine ignores the information related to this attribute in documents (c) and (d), despite the fact 115 it is present in those documents. As a result, document stores return only {" id":1, "title":"Million Dollar Baby"}, {" id":2, "title":"Gran Torino"}. This result is closely related to the paths expressed in the query. Because the majority of NoSQL document stores require the use of 120 absolute paths, when a user makes a query, native query engines expect this user to explicitly include all existing paths from the database to target the relevant data.
(c) { "_id":4, "description":{ "title":"The Good, the Bad and the Ugly", "year":1966, "link":"goo. gl/qEFfUB", "country":"Italy", "director":{ "first_name":"Sergio", "last_name":"Leone" }, "stars":{ "lead_actor":{ "first_name":"Clint", "last_name":"Eastwood" }, "actors":["Clint Eastwood", "Eli Wallach", "Lee Van Cleef"] } }, "classification":{ "ranking":{"score":7. 2 }, "genres":["Western"] } } (d)  Contexts such as data-lake  [14] , federated database  [19] , data integration, schema matching  [5] , and recently, schemaless data support in NoSQL systems  [20]  have highlighted the importance of building transparent mechanisms that use the underlying data in a transparent way. In addition 170 to large volumes of data, there is a need to overcome the heterogeneity of the collected data. Different sources generate data under different structures, versions and languages.
The problem of querying multi-structured data has pushed the database community to rethink how information is 175 accessed with regards to the underlying data structure heterogeneity  [21]. We classify state-of-the-art research work based on the solutions proposed for querying multi-structured documents. The first family of work examines methods of Schema integration. The schema integration process is performed as an intermediary step to facilitate a query execution process. In their survey paper  [5] , the authors presented the state-of-the-art techniques used to automate the schema integration process. Matching techniques can cover schemas  [22]  or even instances  [23]. Traditionally, lexical matches are used to handle syntactic heterogeneity  [24]. Furthermore, thesauruses and dictionaries are used to perform semantic matching  [25].
Generally, this work recommends flattening XML or JSON data into a relational form  [12, 6, 13]. SQL queries are formulated based on relational views built on top of the inferred data structures. This strategy implies that several physical 215 re-factorizations should be performed which will affect scalability. Hence, this process is time-consuming, and it requires additional resources, such as an external relational database and more effort from the user to learn the unified inferred relational schema. Users of these systems have to 220 learn new schemas every time they change the workload or when new data are inserted (or updated) in the collection, as this is necessary to regenerate the relational views and stored columns after every change.
The limitation with such a logical view is that it requires a manual process in order to build the desired queries by including the desired attributes and all their possible navigational paths. In such approaches, the user is aware of data structures but is required to manage 245 the heterogeneity. Querying techniques. Other work recommends resolving the heterogeneity problem by focusing on the query side. Query rewriting  [28]  is a strategy for reformulating an input query into several derivations to overcome heterogeneity. The majority of research work is designed in the context of the relational database, where heterogeneity is usually restricted to the lexical level. When it comes to the hierarchical nature of semi-structured data (XML, JSON documents), the problem of identifying similar nodes is insufficient to resolve the problem of querying documents with structural heterogeneity.
In addition, we can see the same limitations with JSONiq  [8] , the extension to XQuery designed to deal with large-scale semi-structured data. In Table  1  we present the state-of-the-art research work intended to resolve the problem of querying multistructured data. We compare this work according to the following criteria: • The type of heterogeneity examined in each type of work: structural, syntactic or semantic; • The level of heterogeneity. For each type of work we consider whether the contribution is designed to resolve heterogeneity at schema level or instance level; • The querying mechanism. We examine if the type of work recommends a new query language, reuses existing systems or does not offer any querying support; • The underlying store. We indicate if each type of work is limited to one store or several stores; • The solution proposed for the heterogeneity problem.
We describe the nature of the solution for each type of work, for instance, does it perform physical refactorization and change the original schemas, does it focus only on inferring underlying schemas or does it offer a new query language? • The data models. We classify work according to the data models it supports: documents, key-value, relational, etc. ; • Schema evolution support. We indicate how each type of work handles the arrival of new data structures in the database (insert/update/delete documents). Do they offer transparent and native support to handle these new structures? Are manual changes needed to support this change? Similarly to our work, the majority of the state-of-theart research concentrates on managing heterogeneity at 305 a structural level. If we take into account schema evolution support, to the best of our knowledge our work is the first contribution that manages automatic support to overcome structural heterogeneity without regenerating relational views or re-executing schema inference techniques.
Experiments In this section we present a series of experiments to evaluate EasyQ and validate its ability for enabling schema-independent querying for NoSQL documentoriented databases. We conducted all our experiments on an Intel I5 i5-4670 processor with a clock speed of 3. 4 GHz and 4 cores per socket. The machine had 16GB of RAM and a 1TB SSD drive. We ran all the experiments in singlethreaded mode. We chose MongoDB as the underlying document store for our experiments. We focused on the measurement of the execution time for each executed query. We implemented the Algorithm 1 using the Python programming language. We used PyMongo, which is a Python distribution containing tools for working with Mon-goDB. EasyQ takes as input the collection name, the query representing a combination of operators and the set of parameters.
Using the reformulation algorithm, EasyQ automatically reformulates the input query and executes it directly on MongoDB. Results are automatically displayed to the user in the raw format as the MongoDB query engine returns them. In addition to EasyQ, we developed a module to build the dictionary. The dictionary construction module runs a recursive algorithm that goes through all documents trees starting from the root down to each leaf node before going up to collect all the absolute paths, partial paths and leaf rewritten queries when the size of the collection is varied and is this cost acceptable or not? • Is the time to build the dictionary acceptable, and is the size of the dictionary affected by the number of structures in the collection?.
Datasets In order to analyse the behaviour of EasyQ on varying collection sizes and structures, we generated customized synthetic datasets. First we collected a CSV document with information relating to 5,000 movies. Then we started generating an initial homogeneous dataset that we called Baseline where documents within the different collections are composed of 10 attributes (4 primitive type attributes, 1 https://www. irit. fr/recherches/SIG/SDD/EASY-QUERY/ 3 array type attributes and 3 complex attributes of an 1810 object type in which we nested additional primitive attributes). All documents within the different collections in the Baseline dataset share the same structure as document (a) in Figure  1. We intentionally chose to work with attributes that may be absent from some documents, e.
g. , 1815 awards in collection (C) in Figure  1. Moreover, we may have some attributes with null values, e. g. , link. Figure  4a  illustrates a document from the Baseline dataset. We used the Baseline dataset as baseline for our experiments. It helped us to compare our schema-independent querying 1820 mechanism with the normal execution of queries on collections that have a unique homogeneous structure. The Baseline dataset was composed of five collections of 1M, 10M, 25M, 50M, 100M and 500M documents for a total disk space ranging from 500MB to more than 250GB.
1825 In addition to the Baseline dataset, we then injected heterogeneity into the structure of documents from the Baseline dataset. We opted to introduce structural heterogeneity by changing the location of the attributes of the documents from the Baseline dataset. We introduced new 1830 absolute paths with variable lengths. The process of generating the heterogeneous collection took several parameters into account: the number of structures, the depth of the absolute paths and the number of new attributes of an object type. We randomly nested a subset of attributes, 1835 e. g. , up to 10 attributes, under these complex attributes at pre-defined depths. The complex attributes are unique in each structure, which enables unique absolute paths for each attribute in each structure. Figure  4b  describes a sample of a generated document 1840 along with the parameters used to generate it.
1845 • A Heterogeneous dataset to evaluate the execution time of the reformulated query on varying collection sizes. This dataset was composed of five collections of 1M, 10M, 25M, 50M, 100M and 500M documents for a total disk space ranging from 500MB to more than 1850 250GB and each collection contained 10 schemas; • A Schemas dataset to evaluate the time required to reformulate a query for a varying number of schemas and to study the consequences on the dictionary size. This dataset was composed of five collections 1855 of 100M documents with 10, 100, 1,000, 3,000 and 5,000 schemas respectively; • A Structures dataset to evaluate the time required to execute a query for a varying number of schemas. This dataset was composed of five collections of 10M 1860 documents with 10, 20, 50, 100 and 200 schemas respectively; • A Loaded dataset to evaluate the dictionary construction time on an existing collections.
This dataset was • An Adhoc dataset to evaluate the dictionary construction time for the loading collections phase. This dataset was composed of five collections of 1GB containing 2, 4, 6, 8 and 10 schemas respectively. In Table  2    In order to have the same results when executing queries across baseline and heterogeneous collections, we carried on using the same values for leaf nodes. The same results imply: (i) the same number of documents, and (ii) the same values for their attributes (leaf nodes). This is why the evaluation did not target result relevance, as the same results will be retrieved by all queries: either homogeneous documents or heterogeneous documents built from 1880 homogeneous documents.
Also, we represented the paths in several ways, e. g. , absolute paths, array entries, relative paths and leaf node. Table  4  gives the number of documents to be retrieved for each query. The query reformulation process replaces each element 1970 with its 10 corresponding paths. For instance, the query Q 1,ext contains 60 absolute paths for its 6 initial paths, 10 in query Q 4,ext etc. We present the details of the three evaluation contexts as follows: • Q Base is the name of the query that refers to the 1985 initial user query (one of the queries from above): it was executed across the Baseline dataset. The purpose of this first context was to study the native behaviour of the document store. We used this first context as a baseline for our experimentation; • Q Ext refers to the query Q Base reformulated by our approach.
It was executed across the Heterogeneous dataset; • Q Accumulated refers to distinct queries where each query is formulated for a single schema found in 1995 the collection. In our case we needed 10 separated queries as we were dealing with collections with ten schemas. These queries were built manually without any additional tools. We did not consider the time required to merge the results of each query as we were 2000 more interested in measuring the time required to retrieve relevant documents. We executed each of the Q Accumulated across the Heterogeneous dataset. The result was therefore the accumulated time required to process the 10 queries.
Queries evaluation results As shown in Figure  5 , we can see that our reformulated query, Q Ext , outperforms the accumulated query, Q Accumulated , for all queries. The difference between the two execution scenarios comes from the ability of our query 2010 to automatically include all corresponding absolute paths for the different query elements. Hence, the query is executed only once when the accumulated query requires several passes through the collection (10 passes). This solution requires more CPU loads and more intensive disk 2015 I/O operations. We now examine the efficiency of the reformulated query when compared to the baseline query Q Base. We can see that the overhead of our solution is up to three times more, e. g. , projection, selection and unnest when compared to the native execution of the baseline query 2020 on the Baseline dataset.
Moreover, we score an overhead that does not exceed a multiple of two in the evaluation of the aggregation operator. We believe that this overhead is acceptable as we can bypass the costs needed for refactoring the underlying data structures, similarly to other 2025 state-of-the-art research work. Unlike the baseline, our Heterogeneous dataset contains different grouping objects with varying nesting levels. Therefore, the rewritten query includes several navigational paths which were processed by the native query engine, MongoDB, to find matches for 2030 each visited document among the collection. Finally, we must emphasize that the execution time for the lookup operators is very similar between Q Base and our reformulated query Q Ext. We do not present the Q Accumulated evaluation for the 2035 query Q 5 from the operator evaluation workload and the operator combination evaluation workload due to the complexity and the considerable number of accessed collections required to evaluate the Q Accumulated context.
2055 The same behaviour for the native query occurs when studying the effects of the scalability on the query evaluation. Furthermore, the overhead induced by the evaluation of our reformulated query is not affected by the number of documents or the combination of operators. 2060 Furthermore, we executed the query Q 6 from the operator combination evaluation workload over the Structures dataset: we present the time needed to execute the reformulated query in Table  6. This experiment helps us to study the effect of executing our reformulated query on 2065 the varying number of schemas. It is notable that the time evolves linearly rather than exponentially as more heterogeneity is added. This is due also to the important number of comparison required waiting for the one query. For instance, the execution of the query Q 6 over the col-2070 lection having 200 schemas requires 200 possible paths for each attribute.
Query Reformulation Evaluation For this experiment we only executed the query Q 6 from the operator combination evaluation workload over 2075 the Schemas dataset: we present the time needed to build the reformulated query in   time to generate the reformulated query is less than two seconds, which is very low. Also, it is possible to construct a dictionary that covers a collection of heterogeneous docu-2080 ments. Here our dictionary can support up to 5,000 distinct schemas, which is the limit for the number of schemas we decided on for the purpose of this experiment. The resulting size of the materialized dictionary is very promising because it does not require significant storage space. Furthermore, 2085 we also believe that the time required to reformulate the query is of great interest and represents another advan-tage of our solution.
In this series of experiments we have tried to find distinct navigational paths for eight predicates. Each rewritten query is composed of numerous disjunctive 2090 forms for each predicate. Table  5  shows 80 disjunctive forms for datasets containing 10 schemas, 800 disjunctive forms for 100 schemas, 8,000 for 1,000 schemas, 24,000 for 3,000 schemas and 40,000 for 5,000 schemas. We believe that the dictionary and the query rewriting engine 2095 scale effectively when handling heterogeneous collections which contain a high number of schemas. We succeeded in executing all the reformulated queries on MongoDB. We noticed a limitation in terms of performance: the execution time can be 50 times more than the execution of similar 2100 queries on the Baseline dataset. This limitation is due to the considerable number of comparisons per document.
Dictionary Construction Time In this part we focus on the dictionary construction process. EasyQ offers the possibility of building the dictionary from existing collections or during the data loading phase. We studied both configurations. First we evaluated 2110 the time required to build the dictionary for collections from the Loaded dataset. We can see from the results in Table  7  that the time taken to build the dictionary increases when we start to deal with collections which have more heterogeneity. When 2115 a collection has 10 structures, the time does not exceed 40% when we compare it to a collection with 2 structures. In Table  7  we can again see the negligible size of the generated dictionaries when compared to the 100GB of the collection. Afterwards we wanted to evaluate the overhead 2120 that causes the generation of the dictionary at loading time using the Adhoc dataset.
2145 In this paper we have presented EasyQ, an automatic mechanism which enables schema-independent querying for multi-structured document stores. To the best of our knowledge, EasyQ is the first mechanism of its kind to offer schema-independent querying without the need to 2150 learn new querying languages and new structures, or to perform heavy transformation on the underlying document structures. Our contribution is based on a constructed dictionary which matches each possible partial path, leaf node and 2155 absolute path with its corresponding absolute paths among the different document structures inside the collection. Using this dictionary, we can apply reformulation rules to rewrite the user query and find relevant results. The query reformulation can be applied to most document store oper-2160 ators based on formal foundations that are stated in the paper.
In our experiments we compared the execution time cost of basic MongoDB queries and rewritten queries proposed by our approach. We conducted a set of tests by 2165 changing the size of the dataset and the structural heterogeneity inside a collection (number of grouping levels and nesting levels). Results show that the cost of executing the rewritten queries proposed in this paper is higher when compared to the execution of basic user queries, but al-2170 ways less than a multiple of three. Nevertheless, this time overhead is acceptable when compared to the execution of separated (manually built) queries for each schema while heterogeneity issues are automatically managed. Our approach is a syntactic manipulation of queries, so 2175 it is based on an important assumption: the collection describes homogeneous entities, i.
This paper contrasts with classical documents stores in that we offer users the ability to query documents using partial paths and thus EasyQ manages to find all information regardless of the document structures. Furthermore, 2195 by using specific dictionaries we extend the native querying capabilities of document stores, even when querying homogeneous documents. the collection. Indeed, the query is reformulated each time it is evaluated. If new heterogeneous documents have been added to the collection, their schemas are integrated into the dictionary and the reformulated query will cover these new structures too. Future research work will cover the different aspects presented in this paper. Initial research will focus on testing EasyQ on more complex queries and ever larger datasets. We also plan to employ our mechanism on real data-intensive applications.
we represent the characteristics of documents in the Heterogenous dataset. Setting Value # of schemas 10 # of grouping objects per schema (width heterogeneity) {5,6,1,3,4,2,7,2,1,3} Nesting levels per schema (depth heterogeneity) {4,2,6,1,5,7,2,8,3,4} Avg. percentage of schema presence 10% # of leaf nodes per schema 9 or 10 # of attributes per grouping objects [1. 10].