dataesr/scientific-paragraphs-categorization huggingface dataset:
Preliminaries Document stores, aka document-oriented databases, are one of the four families of NoSQL stores. A document (cf. , Definition 1) is the basic concept of document stores. A document has a schemaless nature: it does not have up-front constraints or a strictly predefined schema. For instance, some attributes in documents can be missed entirely, have null values, or have different data types. To elucidate the basic concepts, we briefly present, in Table  1 , the terminology related to document stores and their associated concepts in relational databases. JavaScript Object Notation (JSON 2  ) is currently the most commonly adopted format that we will use in the remainder. Syntactically, Keys and values are separated by colons, while commas separate key-value pairs. Objects and arrays can be embedded inside a document.
Definition 1 (Document and Collection). A document  is an object. Each object contains an unordered set of key-value pairs (keys are also called names  [10] ); a key is a string, while a value can be a primitive value (i. e. , Number, String, or Boolean), an object, an array of values, or null. A collection  is an array of documents. In our work, we consider scattered data over several collections. Since in documents it is common to nest one object into another object  [11] , we regard the different cases of nesting objects: • The document-related objects are represented separately from the original document (i. e. , in another collection) and are referenced using identifiers. • All the document-related objects are nested in the original document with different nesting depths. After presenting the basic concepts related to document stores, we provide, in the remainder, a motivating example that throws light on the noteworthy challenges of detecting the join keys in the context of document stores.
The key fields that join  1 and  2 are orderID as an identifier in  1 and orderCode as a reference in  2. If we use existing algorithms dedicated to relational databases in order to automatically detect join keys, it would be unfitting. In fact, the orderID in  1 has a null value in the third document and is absent in the fourth one. Additionally, the set of orderCode values: {Amazon_Bosch1, eBay_Bosch1, Cdiscount_Bosch1} is not included in the set of orderID values: {Amazon_Moulinex1, Amazon_Bosch1, Amazon_KenWood1}. By and large, document stores have different aspects of heterogeneity that could be: • Intra-document: the variety is mainly related to heterogeneous structures within a document. For instance, a JSON array can hold objects with different fields. As shown in Fig. 1  (document 1 of  1 ), the product field is a JSON array that contains different objects in terms of fields number and types.
The first object comprises three fields, while the second one contains an array of simple values (i. e. ,  [17. 4, 17. 4, 22. 1] ). • Inter-documents: the variety is mainly related to documents with different fields. Fields can be present in some documents and absent in others. For instance, the product field in the first document of  1 does not contain the same fields as in the second document. Moreover, fields do not have the same order (e. g. , orderDate), which is an intrinsic characteristic of an object. • Inter-collections: the variety lies in having different schemas with different knowledge domains. In document stores, joining two collections is a thriving challenge because of their clueless schemaless nature. In fact, (i) unlike the primary key which is unique and not null, identifier as all the other fields, can be missing in some documents or can, normally and not exceptionally, have null values; (ii) document stores do not have ''precise'' join keys beforehand due to the absence of integrity constraints; and (iii) unlike a relational database, reference values are not included in the identifiers' values, so it is impossible to use the inclusion dependencies in order to automatically detect identifiers and references.
Related work Our primary objective is to identify ''joinable'' key fields, i. e. , identifier and reference fields, to perform a join operation between two different document stores. We survey, in this section, existing works that paid attention to this issue. We identify three major streams of approaches: (i) dealt with the ETL process over NoSQL stores, where we focus on the works addressing the join operation in the context of NoSQL stores; (ii) dealt with joinable tables discovery; and (iii) proposed contributions for the primary key and foreign key detection in the context of relational databases.
This step is followed by an advanced discovery that infers the global schema of a set of JSON documents. Baazizi et al. [19]  were interested in schema inference of massive JSON datasets. The distinguishing feature of their approach is that it is parametric and allows the user to specify the degree of preciseness and conciseness of the inferred schema. Besides, Gallinucci et al. [20]  have extended the level of schema extraction of a collection of JSON documents, with schema profiling techniques, to capture the hidden rules explaining schema variants. Although many authors have conducted schema extraction, this problem is still insufficiently explored. The major downside in their approaches is that they do not try to find the hidden type of each field while extracting the schema. Although most of the above approaches have only focused on the first phase of the ETL process, i.
In addition, the framework allows for the user to declare modifications for altering join keys during query time to make data joinable. In  [22] , Kondylakis et al. have proposed a data management solution allowing joins over NoSQL Cassandra databases where the primary keys are considered as partition keys. The approach proposed in  [23]  inputs two sets of values from join columns and produces a predicted join relationship using an extensive table corpus. The previous works have all addressed the join operation in NoSQL stores. However, we note that they all rely on a strong assumption: having the join keys beforehand. It is worth mentioning that, in NoSQL stores, no prior works have proposed a method to find the pairs of join keys, i. e. , both identifiers and their respective references.
Similarly, in  [26] ,  Fernandez et al. propose an approach that aims to find objects that are semantically related. However, to identify semantic links, their approach requires domain-specific knowledge encoded in an ontology, which is not always available. These works aim to identify relatedness between tables when explicit relationships between them are missing. The relatedness can be for joinability or unionability. Given a set of tables, they search significant datasets to populate a target table. The results generated by these approaches are in the form of similar tables or similar attributes regardless of whether among these attributes there are primary/foreign keys or not. However, our objective is to determine identifiers and references among several attributes that can be similar between two collections.
Primary key and foreign key discovery in relational databases This subsection presents the contributions that have dealt with detecting primary keys and foreign keys in relational databases. The authors in  [27] [28] [29]  have paid attention to foreign keys detection, assuming the presence of primary keys. Quite freshly, Jiang and Naumann  [30]  have proposed an approach to discover both primary keys and foreign keys automatically for a given relational database. The approach is based on the functional dependencies that describe the characteristics of a table or relationships between tables, namely unique column combinations and inclusion dependencies. Both types of dependencies have been used to detect primary keys and foreign keys in relational databases. A unique column combination is the set of attributes whose projection contains only the column combinations having unique and non-null values.
In document stores, fields can easily be missing in some documents or have null values usually and not exceptionally. Their work is based on the set of inclusion dependencies given as input. However, this assumption could not pertain to the context of document stores as described in our motivating example. Even if this previous work  [30]  is the closest one to our problem, we cannot apply it out of the context of relational databases. Thus, we have undergone a rethinking of the problem by using alternative methods adapted to document stores' schemaless nature.
• Rule 3: Semantic similarity based pruning: using only the syntactic similarity between two fields is not sufficient to cover all cases, e. g. , customer and client. It indeed leads to generate some false-positive and false-negative results. To this end, we propose a filtering step based on semantic similarity. To do so, we use the Wup semantic similarity measure (cf. , Definition 8), which is based on the lexical database Wordnet. 6 Similar to the syntactic measure, we use tokenization to divide the attached words into meaningful separated words. Given two fields  1 and  2 , we split each of them into a set of tokens,  1 and  2 respectively. We consider  1 and  2 semantically similar if exists at least a semantic similarity between elements of a pair ( 1 ,  2 ), where  1 ∈ { 1 ⧵  } and  2 ∈ { 2 ⧵  }.
By performing the node2vec algorithm, we get the most similar fields for each identifier with the corresponding probabilities, which approximate the similarities between nodes. Regarding probabilities values, we keep the highest ones to identify the candidate pairs of key fields. We hosted the python code samples that are used in this step in a GitHub repository. 10 As a result, we obtain [$. customer. NATIONKEY] as the most similar field to the candidate identifier [$. COUNTRYKEY] with a probability measure in the region of 0. 994.
Experimental study In this section, we report our experimental findings after describing the considered data collections. We base our experimental study on two benchmarks and two real-world datasets: • TPC-H: a benchmark for decision support systems. It represents the activity of any industry that must manage, sell or distribute a product worldwide. • TPC-E: a benchmark was offering a set of flat files that models a brokerage firm with customers who start transactions concerning trades, account inquiries, and market research. • Twitter: these datasets, which comprise users and their related tweets, are scraped from Twitter's API. We consider two collections: Tweets and Users. Each document of the Tweets collection contains nested objects such as the coordinates object that gives the geographic location.
These datasets are initially in JSON format. They are heterogeneous in terms of schema variety, different nesting levels (i. e. , field's depth), missing values, different types, etc. • Musicians: are datasets extracted from Wikidata, 11  a real-world data source. These datasets are implemented in Valentine  [41]  where the authors proposed a well-thought-out dataset creation process that is tailored to the scope of matching techniques. The datasets represent data about American singers. It contains around 11k tabular data that we converted into JSON documents. To resemble a real-life scenario, authors in  [41]  have varied the names of the attributes in the source and the target sources included in Valentine. In addition, they provide with the source and the target dataset a JSON file containing the possible matching that we used as ground truth to check the accuracy of our results as shown in Fig.
Data collection Since our approach deals with document stores, we carried out a data preparation phase to use the two benchmarks in our experimental process. We have implemented a transformation phase to convert TPC-H and TPC-E generated flat files to JSON ones. We consider each record in the flat file as a document in the JSON collection. We perform the data preparation stage regarding the document-oriented model characteristics, e. g. , randomly assigning null or missing values. Furthermore, in order to have different storage models, we have denormalised data in both benchmarks: (i) TPC-H, we have denormalised the Orders collection by embedding documents from Customer. Similarly, we have denormalised the Nation collection by embedding documents from Region; and (ii) TPC-E, we have denormalised the Trade collection by embedding documents from TradeType.
Experimental setup and results As proof of the concept of our approach, we have developed java prototypes to support the main phases and tested them under macOS High Sierra machine, Processor Intel Core i5, 2. 7 GHz, and 8 GB of DDR3 RAM. We store the used collections of JSON documents on MongoDB as a document-oriented DBMS. We used the python Wordninja library  14  to split the attached words into tokens. We also used the Python 3 implementation of the node2vec algorithm. As shown in Tables  3  and 5 , we compare the output sets of both candidate identifiers and candidate pairs (reference, identifier) with the gold standard of the Twitter collections, Musicians collections, TPC-H benchmark, and TPC-E benchmark, and we report the precision, recall, accuracy, and the percentage decrease. The results show that our approach reaches a high precision and accuracy without diminishing the recall.
Furthermore, the percentage decrease metric yields increasingly excellent results by reducing the number of candidates proposed to the end-user. We note that in Table  3 , our algorithm shows a decrease in the precision to 0. 25 when detecting the identifier in the Financial collection. This decrease is because of the existence of several non-composite unique fields, which generate false-positive results. However, this error accounts for only a tiny portion of the used collections, and fortunately, the percentage decrease is still high. Although our approach is dedicated to heterogeneous document stores (consisting of diverse data contents), we have also used as a part of our experimental study the two Musicians datasets, which encompass homogeneous data devoted to evaluating matching techniques.
For instance, the depth feature is intrinsic to document stores since collections' fields have different depths due to the embedding of objects inside documents. Thus, as shown in Table  4 , by omitting this feature while computing the score for the CustomersAccounts collection, we realize the remarkable decrease in the precision, accuracy, and percentage decrease. Similarly, we remark a significant difference between their absence and presence for the data type and field name prefix features while computing scores and discovering candidate identifiers. Since our approach considers several collections, we apply key pair discovery on every two collections. Indeed, there is at least one pair of collections that are not joinable so that they did not have a relationship (reference, identifier).
In a NoSQL context, a document may have hundreds of fields, making it tricky to fetch the identifier of a given collection manually. • Querying tasks: the join is mandatory for querying tasks. Hence, it is compulsory to have the join keys beforehand. For instance, MongoDB uses the MQL (MongoDB Query Language) to query stored data in document databases using different operators. Furthermore, since developers know well that join operations among collections are essential  [7] , MongoDB, the open-source community, has recently introduced the $lookup operator in version 3. 2. This operator performs a left join between two collections using a localField and a foreignField that the user specifies. • Database design: identifying the interrelationships in legacy databases certainly requires discovering join keys.
Conclusion and future work Document stores have a variable schema, where fields can be missing in some documents or have null values. Because of integrity constraints and inclusion dependencies, a document store is the furthest from having an exact join key. For this, detecting join key pairs between two document stores is a tricky task. In the literature, existing works have provided dedicated solutions to relational databases. For NoSQL data stores, current contributions rely on a strong assumption: having the join keys pairs beforehand. We seldom know the pair of identifier and reference in document stores. To this end, we have proposed, in this paper, an alternative approach for identifiers and references' discovery based on several document stores. We have introduced the IRIS-DS algorithm that discovers candidate identifiers for each collection, and then identifies the candidate pairs of identifier and reference for every two collections.
We use scoring features and pruning rules to discover actual candidate identifiers from many initial ones efficiently. To find candidate pairs between several document stores, we put into practice node2vec as a graph embedding technique, which yields significant advantages while using syntactic and semantic similarity measures for pruning pointless candidates. The carried out experiments on the TPC-H and the TPC-E benchmarks, and the Twitter dataset underscore that our approach fulfills the accuracy of the generated results. We claim that our findings might be useful for.
Model evaluation We evaluated CROCO-BioEBUS by comparing chlorophyll concentration and large zooplankton against observations (see Section 3. 1. 1). Simulated phytoplankton concentration was converted to chlorophyll using function get_chla. m of the croco_tools package  (Penven, 2019)  and compared against MODIS remotely sensed chlorophyll concentration  (NASA, 2018). A previous version of the model  (José et al. , 2017)  strongly overestimated zooplankton in comparison to observations  (Hill Cruz et al. , 2021). Therefore, for the present study, we tuned the model to better match observed concentrations. After tuning the model, large zooplankton model concentrations were compared against mesozooplankton observations by  Moriarty and O'Brien (2013)  and O'Brien and  Moriarty (2012) , which are provided in carbon units.
However, compared to satellite data (see Section 3. 1. 1), the surface chlorophyll in the model displays a similar variability (around 20% of the mean, see Section 3. 1. 1). A second reason may be that the link between the biogeochemical model CROCO-BioEBUS and the HTL model OSMOSE is too weak. This link is done only through plankton food forcing for juvenile and adult fish. Other possible links may include the effect of oxygen, temperature and food availability on larval survival and through interannuallyvarying distribution maps. Temperature and oxygen are some of the variables that were considered when developing the distribution maps for constraining the habitat of the fish (see  Oliveros-Ramos, 2014). In Appendix A. 5, we provide an alternative configuration where additional interannual variability is introduced by applying interannual distribution maps instead of climatological ones.
Species provided by  Dahlberg (1979) : Anchovy, Engraulis japonica  (Nakai et al. , 1955) ; Jack mackerel, Trachurus symmetricus  (Farris, 1961) ; sardine, Pacific sardine  (Murphy, 1961, scientific name not provided). The relationship between the daily larval mortality (LM/15 days = ) and survival () in OSMOSE is given by  =  (+)  () =  - (using the exponential approach provided in OSMOSE source code: https://github. com/osmose-model/osmose/tree/master/java [Accessed: 2021-10-28]). central value. In our study, we found that OSMOSE is very sensitive to the value of LM, with only a 10% change decreasing the biomass of anchovy by more than half. The impact is much stronger than the effect caused by a 10% decrease in available food. This suggests that the key to reproduce the interannual variability of the fisheries in the NHCS may not be in the food provided to adults but rather on the survival of larvae.
Acknowledgements This study was funded by the  Bundesministerium für Bildung und Forschung (BMBF) ,  Germany  through the projects: Coastal Upwelling System in a Changing Ocean CUSCO (03F0813 A) and  Humboldt-Tipping  ( 01LC1823B ). In addition, JG received funancial support by the  BMBF  funded project  CO2Meso  ( 03F0876A ) and TX by the  China Scholarship Council  (  201808460055 ). Simulations and model calibration were carried out using the computing facilities of the  Norddeutscher Verbund zur Förderung des Hoch-und Höchstleistungsrechnens -HLRN. We thank  Ricardo Oliveros-Ramos  and  Criscely Luján-Paredes  for providing the OSMOSE Humboldt interannual configuration and distribution maps. We also thank  Ricardo Oliveros-Ramos  for providing scientific advice and technical support to this project.
Methods: The LaRDR was established in 2016 as a multicentre, collaborative project at sites across Australia with a secure online database which collects prospective data on patients with a new diagnosis of lymphoma or chronic lymphocytic leukaemia (CLL). LaRDR development required multidisciplinary participation including specialist haematology, information technology, and biostatistical support, as well as secure funding. Here we describe the database development, data entry, ethics approval process, registry governance and support for participating sites and the coordinating centre. Results: To date more than 5,300 patients have been enrolled from 28 sites in Australia and New Zealand. Multiple challenges arose during the development, which we describe, along with approaches used to overcome them.
The value of clinical registries Clinical quality registries (CQR) are now well established internationally, and endorsed as integral to continuous improvement in healthcare through supporting delivery of and monitoring evidence-based practice  [1]. Key features of CQRs and their value, including for blood cancers, are reviewed in detail elsewhere  [2] [3] [4]. By collecting a standard minimum dataset, which increasingly includes patient-reported outcomes, registries are also very valuable for uncommon diseases or interventions where clinical trials are challenging, and even large referral centres may see few patients. In this context registries can provide a mechanism to identify variation in practice. They also and serve as efficient platforms to conduct observational studies and interventional trials to establish optimal management and conduct health economics analyses using 'real world' data  [2] [3] [4].
LaRDR utilises an "opt out" consent model, an approach approved by the Australian National Health and Medical Research Council and New Zealand National Ethics Advisory Committee if the public interest in a research study sufficiently outweighs the potential impingement on individual privacy. This model enables maximum participation and thereby reduces bias; it is widely used for registry activities in Australia. Clinicians at participating sites are responsible for identifying potential participants, explaining the study to them, inviting them to participate, and providing them the approved LaRDR information brochure, which describes the registry aims, data being collected and LaRDR contact details. This process is documented in the patient's file in the registry. No written consent is required.
Patients may opt out at any time from initial invitation or in the future, at which point any of that person's data will be deleted centrally. The consent also provides for centralised review of laboratory results and histology slides. Registry analyses by approved investigators using existing LaRDR data can be conducted without additional HREC approval. Sub-studies requesting additional data typically require additional approval. The project is registered on the Australian and New Zealand Clinical Trials Registry (ACTRN12617000050358).