dataesr/scientific-paragraphs-categorization huggingface dataset:
| Methodological causes for the differences between data sets The majority of EVA-W plots have limited associated metadata except for plot location, plot size, crop and survey date. Therefore, we must make assumptions regarding the survey methodology of these data. In contrast, information on sampling methodology is available in detail from the publications associated with the AWME records (Appendix S2). The EVA-W collection consists mainly of data from a phytosociological background (EVA defines itself as a repository of 'records of plant-taxon co-occurrence at particular sites, also called phytosociological relevés'; http://eurov eg. org/eva-database; 10 Nov 2021). In this context, preferential sampling was and maybe still is the most commonly used sampling strategy because for research purposes such as vegetation classification, it aims to record typically developed, species-rich stands of a certain vegetation type  (Moore et al.
Arable land use has always had a history of spatial differences in disturbance and management  (Jansen et al. , 2009). Analysis of long-term trends in change of the European arable flora will then be facilitated by integrating all available data sources. Similar to the data sources made available by the efforts for the European Weed Vegetation Database  (Küzmič et al. , 2020) , many more studies exist in the weed science that can be included in the AWME collection, including resurvey studies, surveys from before 1996 and those from further European countries, especially from Scandinavia. The contrast in species richness at the field scale described in this study should be extended further to the landscape scale. It is known that more heterogeneous agricultural landscapes harbour higher species diversity than homogeneous agricultural landscapes with large field units and a low crop diversity  (Benton et al.
Acknowledgements P. d. A. acknowledges the support of  FET-Open  project  NARCISO  (ID:  828890 ) and of  Swiss National Science Foundation  (grant  ID 200021 172587 ). All authors acknowledge the assistance from  Faderico Pasotti  in performing the PIV experiment,  Silvia Guadagnini  in measuring the diffusivity of colloids and  Monica Bollani  for very useful discussions.
While patients operated in high-volume multidisciplinary sarcoma centers have better outcome  [16] , many patients are initially operated out of a sarcoma center and the question of systematic re-operation is still debated, considering the inconsistent impact of RE on overall survival across series. We used the French nationwide prospective database NETSARC to assess overall survival (OS), local and distant relapse free survival (RFS), and local control (LRFS) in patients with R1 margins who had been operated for a trunk wall and limb soft tissue sarcoma outside of a reference center who experienced reexcision (RE) or not (no-RE).
Objectives This study aims to assess the overall survival in patients with STS of the extremities or the trunk wall, who experienced initial surgery with R1-margins, performed outside of the French nationwide NETSARC reference centers, reexcised (RE) or not (No-RE). Secondary objectives included local and distant relapse free survival (RFS) and local recurrence free survival (LRFS). The data-collection and analysis received approval from the national Advisory Committee on Information Processing in Health Research (Comité consultatif sur le traitement de l'information en matière de recherche dans le domaine de la santé, CCTIRS) n°10. 403, September 16, 2010, and from the French data protection authority (Commission Nationale Informatique et Liberté, CNIL), n° 910390, July 15, 2013.
Patients' selection The study enrolled patients with localized STS of trunk and limbs prospectively registered in the NETSARC database between 07/2010 and 12/2017, with specified R1 margins after initial surgery performed outside a NETSARC reference center. Desmoid, well differentiated (atypical lipomatous tumors), dermato-fibrosarcoma protuberans were excluded because they are rarely lifethreatening diseases. Patients with metastasis at diagnosis or unknown initial metastatic status were also excluded (Fig. 1 ). The affiliation of the first surgeon was collected and categorized within or outside a NETSARC reference center; patients were considered as operated in a NET-SARC reference center if the surgeon was registered in NETSARC network (https:// NetSa rc. sarco mabcb. org), and conversely, as operated in a non-expert center if the surgeon was not referenced in the NETSARC network.
NETSARC network and database The French nationwide reference network for clinical and pathological sarcoma care NETSARC supported by the French Institute of Cancer (INCa) set up a nationwide database currently considered to be close to exhaustivity of all STS in France  [2]. All sarcoma including suspicion for sarcoma are presented and reviewed by a multidisciplinary tumor board (MDTB) involving the 26 French cancer centers and registered at first presentation in a database by a dedicated team of clinical research assistants, at any time of the disease course (before diagnosis, before any treatment, after primary surgery, before adjuvant therapy, at the date of oncologic event or/and clinical trial screening). In France, for each operated patient regardless of the institution, a centralized review with double-interpretation is deemed mandatory and pathological reports encourage the clinicians to present each case to MDTB.
Thus, data from patients operated in or outside of NET-SARC reference center network are collected in NET-SARC database. The database includes patient and tumor characteristics, surgery, relapse and survival. The wider tumor diameter defined tumor size. The National Federation of Cancer Centres (FNCLCC, Unicancer) specified 4 categories for histological grades: grade 1, 2, 3, and ungraded tumors. Sarcomas without grading resulted from histology grading failure or lack of critical elements to complete the diagnosis, as determined by experts. The quality of surgical resection used the definition of the Union Internationale Contre le Cancer (UICC)  [17] , and margin status determination is based on pathology and surgery reports when available: R0 referred to clear margins -in the present study R0 margins qualified a monobloc resection and clear margins specified on pathological report; R1 margins referred to (possible) microscopic residual disease, with visible tumor cells on resection margins (positive microscopic margins) -in the present study R1 margins indicated margins not confirmed as R0 or R2.
RE status was not available for 255 patients with R1 margins. Considering that all re-excision of R1 patients were carried out in NETSARC reference centers, missing data regarding RE status were considered as missing not at random. Characteristics of patients with no specified margin status are presented in Supplementary material S1 and a sensitivity analysis was performed considering these patients as not reoperated in Supplementary material S2. A propensity score matching analysis was carried out and presented in supplementary material S3. The cut-off date for data analysis was 2020, Novembre 9. Analyses were performed using SAS version 9. 4 software (SAS Institute Inc. , Cary, NC, USA) and significance for all statistical tests was evaluated using two-sided p values.
Discussion Our results issued from the French nationwide prospective database NETSARC registering all sarcoma and connective tissue tumors since 2010 show a significantly improved OS, RFS, and LRFS with a median follow-up of 31 months in patients with an initial R1 resection conducted outside of a reference center for a limb or trunk wall soft tissue sarcoma, and RE as part of adjuvant treatment. The benefit of RE on OS is observed in almost all subgroup of patients i. e. all other thing being equal, meaning regardless of age, tumor size (deep/superficial seated), location (lower/upper or trunk), grade (1/2 or 3), and histology. Our series is the first and largest so far to our knowledge, using direct comparison of prospectively registered patients with and without RE after a first surgery outside of a reference center, and prompt us to systematically consider RE in patients with potential microscopic margins (R1) initially operated outside a reference center.
Funding  NETSARC (INCA & DGOS)  and  RREPS (INCA & DGOS) ,  RESOS (INCA & DGOS)  and  LYRICAN (INCA-DGOS-INSERM 12563 ),  Association DAM's, Ensemble contre Le GIST ,  Eurosarc  ( FP7-278742 ), la  Fondation ARC, Infosarcome ,  InterSARC (INCA) ,  LabEx DEVweCAN  ( ANR-10-LABX-0061 ),  Ligue de l' Ain contre le Cancer, La Ligue contre le Cancer, EURACAN  ( EC 739521 ) funded the study. The funders had no role in the study design, data collection, data analysis, data interpretation, or writing of the report.
Introduction A multi-model DBMS (MMDBMS) is a data managing platform that supports different data models with a fully integrated backend, thus providing unified data governance, management, and access via a single query language, while still granting performance, scalability, and fault tolerance Lu and Holubová,  [28]. Using a single platform for multi-model data delivers several benefits to users besides that of providing a unified query interface; namely, it will reduce maintenance and data integration issues, speed up development, and eliminate migration problems Tsunakawa,  [40] , Lu and Holubová,  [28]. Examples of MMDBMSs are PostgreSQL, ArangoDB, Cosmos DB, and CouchBase. Specifically, PostgreSQL (www. postgresql. org/) is a relational DBMS that supports the row-oriented, column-oriented, key-value, and document-oriented data models, offering XML, hstore, JSON/JSONB data types for storage.
Polystores and multi-model databases Traditional DBMSs were conceived for handling a specific type of data; for example, relational DBMSs for structured data, document-based DBMSs for semi-structured data, etc. For applications that require the integration of different types of data, two solutions are possible: (i) integrate all data into a single DBMS, or (ii) use two or more DBMSs together. The obvious drawback of the former solution is that some types of data cannot be stored and analyzed (e. g. , the pure relational model does not support the storage of XML, arrays, etc. Shimura, Yoshikawa and Uemura,  [38] ). The latter approach (known as polyglot persistence Gadepally, Chen, Duggan, Elmore, Haynes, Kepner, Madden, Mattson and Stonebraker,  [19] ) presents drawbacks as well, namely, a difficulty in technically managing more DBMSs, a steep learning curve for developers, inadequate performance optimization, complex logic in applications, data inconsistency, etc.
Tsunakawa,  [40]. MMDBMSs have been proposed to overcome these issues (see the survey by Lu and Holubová  [28] ). MMDBMSs support different models using specific storage strategies; for example, PostgreSQL stores data using relational tables, text, or binary format, while ArangoDB uses a document storage technique. To enable queries on different data models, these DBMSs provide new query languages, namely, extended-SQL and AQL for PostgreSQL and ArangoDB, respectively. Besides, depending on the storage strategy, each DBMS implements a particular set of physical structures (indexes and partitions). The main cloud providers either support multi-model databases to some extent (e. g. , Azure's Cosmos DB supports all non-relational models) or offer cross-querying functionalities over multiple database systems (e.
g. , Amazon's standard data warehousing solution RedShift can be used to query semi-structured and unstructured data on S3). Among the topics currently investigated for MMDBMSs, we mention conceptual modeling of multi-model data Holubová, Contos and Svoboda,  [24] , inference of multi-model schemata, multi-model querying Holubová, Svoboda and Lu,  [26]  as well as evolution management Holubová, Klettke and Störl,  [25]. To the best of our knowledge, the only work dealing with multi-model logical design starting from a conceptual schema is the one by Svoboda, Contos and Holubová  [39] , which uses category theory to formalize the transformation from elements of an Entity/Relationship diagram to relational tables, documents, and graphs in an MMDBMS. The approach is devised for operational databases rather than for multidimensional data; besides, it is more focused on providing a uniform modeling framework than on supporting the designer in deciding which model to use for each piece of data.
In this case the multidimensional schema is not devised at design time and forced in a DW, but decided at querying time. Chouder, Rizzi and Chalal  [15]  describe a schema-on-read approach to automatically extract facts and hierarchies from document data stores and trigger OLAP queries. A similar approach is presented by Gallinucci, Golfarelli and Rizzi  [20] ; there, schema variety is explicitly taken into account by choosing not to design a single crisp schema where source fields are either included or absent, but rather to enable an OLAP experience on some sort of "soft" schema where each source field is present to some extent. In the same direction, Dehdouh  [17]  proposes a MapReduce-based algorithm to compute OLAP cubes on column stores, while the work by Castelltort and Laurent  [7]  aims at delivering the OLAP experience over a graph-based database.
The approaches mentioned above rely on a single-model database. Conversely, Gallinucci and Golfarelli  [23]  propose a pay-as-you-go approach which enables OLAP queries against a polystore supporting relational, document, and column data models by hiding heterogeneity behind a dataspace layer. Data integration is carried out on-the-fly using a set of mappings. Even this approach can be classified as schema-on-read; the focus is on query rewriting against heterogeneous databases and not on the performance of the approach. Bimonte et al. [2]  investigate the effectiveness and efficiency of MMDWs to store multidimensional data. Though one multi-model solution coping with variety is proposed with reference to a case study, there is no discussion and evaluation of all the single-and multimodel solutions made available for the different types of multidimensional elements when relying on a MMDBMS.
Case study UniBench is a benchmark for multi-model databases Zhang et al. [43] , Zhang and Lu,  [42]. It includes a retail dataset composed of relational, XML, JSON, key-value, and graph data, which makes it a good representative for variety. To investigate the pros and cons of MMDBMSs, in Bimonte et al. [2]  a multidimensional schema is derived from UniBench by adopting a classical data-driven approach based on the functional dependencies inferred from the data. Though that schema was good for a preliminary study, it is not sufficient in this paper because it is not representative of all the possible situations that may arise in multidimensional modeling. For this reason we had to extend it by adding new types of multidimensional elements, such as shared hierarchies and convergences Golfarelli and Rizzi,  [21].
g. , for the hierarchy rooted in a in Fig. 4. a, there could be a document for each value of c, each including an array of values of a). The denormalized and the shattered schemata obtained for the Order fact are shown in Figs. 5  and 6 , respectively. Noticeably, in PostgreSQL document-based data are actually supported only in terms of column data typed JSON in relational tables; for this reason the schemata show each document as embedded in a relational table. In the denormalized schema all levels are included within a single document, the only exception being Customer where a non-onto hierarchy is rooted. Conversely, in the shattered schema separate documents are created for the fact, for each dimension, for the shared hierarchy in City, for the cross-dimensional level Rating, and for the non-onto hierarchy in Customer (there is no need to create a document for tag since it has no children).
5 ± 2. 9 (minimum 1, maximum 10), the number of customers known by each customer is 7. 3 ± 2. 7 (minimum 1, maximum 21), and the number of tags per customer is 2 ± 1 (minimum 1, maximum 5). Finally, we assume that ratings are given for each product ordered by each customer. All tests have been run on a Core i7 with 8 CPUs @3. 6GHz server with 32 GB RAM running Ubuntu. PostgreSQL memory parameters have been set as follows: -Shared_buffers (i. e. , the number of shared memory buffers used by the server) is set to its default, 128MB; this avoids the entire database being stored in memory; -Effective_cache_size (i. e. , the estimate that the query planner makes of how much memory is available for disk caching by the operating system and within the database itself) is set to 4GB; -Work_mem (i. e.
Even for non-strict hierarchies we tried different combinations, to involve either Tag or ProductASIN either in the group-by set or in the selection predicate. Queries are formulated in the extended query language provided by PostgreSQL and Agensgraph to query JSON and graph data, respectively. In particular, as mentioned at the beginning of this section, AgensGraph supports Cypher to formulate queries over graph data and then rewrites them to SQL operations over the relational structures that implement the graph. The Cypher query language is integrated with SQL and hybrid queries (e. g. , over relational, JSON, and graph data) are allowed. A sample hybrid query (corresponding to an implementation of q22) is shown in Listing 1. Execution times are obtained by running a PostgreSQL procedure that runs each query of the workload in random order; the reported execution times are the average of five workload runs  4.
Document-based model The results for the performance tests made on document-based solutions are shown in Fig. 10. The shattered schema appears to perform better than the denormalized one in almost all situations. The main reason is that the fact table is significantly larger in the denormalized schema (1 KB per row on average, against the 670 B in the shattered schema), thus requiring longer execution times to operate on the data; for instance, a simple sequential scan of the fact table takes less than 100 ms in the shattered schema and almost 2 s in the denormalized one. A careful evaluation of the execution plans showed that JSON objects are carried out along the execution plans until the end (i. e. , fields are not efficiently projected out of JSON objects). This substantially increases the footprint of queries, putting much pressure not only on the main memory, but also on the disk (that is used when an external sort on a large amount of data is carried out).
e. , having lighter JSON objects in the fact table). -For queries on plain hierarchies, by far the most common, the performance of the three models is substantially the same (around 1 second in the average). -Queries on non-onto hierarchies are apparently the most challenging ones for the document-based and graph-based models, from both points of view of performance and formulation complexity. However, we remark that the average values shown on the chart do not consider query q24, which failed on both the relational and the document-based models. -In general, the shattered schema suffers the need to deal with JSON data, which require more storage and are more challenging to be analyzed efficiently (as discussed in the single-model comparison). Although aggregate data modeling allows to save explicit join operations (instead, the jsonb_array_elements function is used to "enter" arrays), PostgreSQL implements the unnesting of arrays as a Nested Loop between the Sequential Scan of the table and the Function Scan of the contents of the array.
Eventually, in our workload, the shattered schema performs a total of 113 joins (32 of which are due to the unnesting of arrays) against the 107 of the star schema. All these factors contribute to making the shattered schema generally less performing than the star schema. -The shortcut schema suffers from issues similar to the shattered one in terms of JSON data. Additionally, we remark that the Agensgraph's implementation of graph data relies on the relational data model, i. e. , all nodes of a certain class are stored in a different table, and a table is created for each type of edge (independently of the edge representing a one-to-one, one-to-many, or many-to-many relationship). This means that, against our expectations, the shortcut schema requires a larger number of joins than the star schema (184 against 107), because a join to an "edge table" is required even in presence of a -The formulation complexity on the star schema is not very different from the one on the shattered schema, being significantly smaller only for queries on non-onto hierarchies.
An ETL query reads a piece of data from the data source and transforms it so that it can be loaded onto the MMDW. Hence, its precise formulation depends on the model and schema of the data source, on the multidimensional schema, and on the solution adopted for logical design; thus, a huge number of combinations arise. Precisely counting the number of characters of each possible ETL query-as suggested by Jain et al. [27] -would require to write all of them. To avoid this, we introduce some rough approximation. Specifically, we proceed as follows: 123 Fig. 16  Modeling the many-to-one relationship between Category and Type in a normalized (left), nested (center), and flat (right) schema (i) We classify data sources, based on their type of schema, into normalized (e. g. , a relational database), nested (e.
g. , a JSON collection), and flat (e. g. , a wide-column database); Fig. 16  shows how the many-to-one relationship between Category and Type would be modeled according to the three schema types, respectively. The reason for not explicitly considering the model of the data source is that the formulation complexity of an ETL query is mainly driven by the need to nest/un-nest and normalize/denormalize the data. (ii) For each type of multidimensional element, each type of source schema, and each target logical design solution, we write a sample ETL query. Plain hierarchies are considered together with convergences, optional arcs, and non-covering hierarchies, since the corresponding query does not change significantly. (iii) We count the number of characters in each sample ETL query. We claim that the complexity is actually driven by the structure of the query, so we do not count the attribute names.
To discuss the complexity of ETL formulation for our Order fact we use Table  3  with reference to three different situations, in which the source data are stored in (i) a (normalized) relational database, (ii) a (nested) document-based database, and (iii) a (flat) graph-based database  6. The results are shown in Fig. 17  for each source model and target solution. The figure can be commented as follows: -For each source model, the ETL formulation complexity for the shortcut schema is more than double the one of the other schemata. Indeed, an extra effort is required to create different nodes for each level and to create transitive arcs from the fact nodes.
123 -The star and flat schemata are similar from the point of view of denormalization, thus their costs are mostly the same-except for shared hierarchies and cross-dimension levels, where more arcs need be created. -When the source data are normalized and relational, using star as the target schema is the best choice; for the denormalized, shattered, and flat schemata the costs are roughly the same. The larger effort here is in creating the JSON objects by joining and aggregating the data. -When the source is a nested document-based collection, using a document-based solution for logical design as well is the best option as data is already aggregated (indeed, most queries are very simple). Specifically, a denormalized schema is the cheapest solution, followed by a shattered (where some degree of normalization is required), a star, and a flat schema.