dataesr/scientific-paragraphs-categorization huggingface dataset:
, 2017). SGL proprietary software was used for AIRGrav data processing. As the Gordon and Betty Moore Foundation (GBMF) funded the survey, we refer to the gravity data as the GBMF gravity data. We refer to the gravity data as the GBMF gravity data. The GBMF gravity line data are processed with 20, 28, 36, and 42 s half-wavelength filters. These filters provide nearly identical gravity anomalies for the two glaciers, albeit with a reduced data noise for the longer filters. For the 3-D inversion, we use the 750 m gridded data, which offer the best compromise between data noise and spatial resolution. The precision of the AIRGrav data from an analysis of cross over is 0. 5 mGal. For comparison, Operation IceBridge gravity data has a spatial resolution of 4. 9 km (aircraft speed 262 knots or 135 m/s) using a 70 s full wavelength filter  (Cochran & Bell, 2010) , hence 1 order of magnitude coarser spatial resolution.
Geophysical Research Letters 10. 1002/2018GL077204 were acquired using the QINSy software and processed using the CARIS HIPS software. Calibration of sound speed in water was performed using conductivity temperature depth data obtained at regular intervals during the cruise. In 2016, we employed a SeaBat 577 sonar on board the "Ivila. " The MBES data were gridded at 25 m spacing with a nominal vertical precision of 2 m (Figure  1b ).
Gravity Inversion We form a 3-D model of AVA and KUJ using Geosoft GM-SYS 3-D software which implements the method of  Parker (1973). The model included three horizontal layers: (1) a solid ice layer with a density of 0. 917 g/cm 3 , (2) a sea water layer with a density of 1. 028 g/cm 3 , and (3) a rock/sediment substrate layer with a uniform density of 2. 60 g/cm 3 for AVA and 2. 69 g/cm 3 for KUJ. The model domain extends to the limit of the GBMF survey. We allow a 500 m wide transition at the boundary where the inversion is modulated by a factor varying linearly between 0 (no gravity inversion) to 1 (full gravity inversion) as a function of distance from the gravity data. We invert the gravity data inside the inversion domain, which includes land ice and portions of the ocean not surveyed by MBES (inversion factor > 0).
Acknowledgments This work was performed at the  University of California Irvine  under grant  3280  from the  Gordon and Betty Moore Foundation , funds from  UC Irvine  and  NASA  grant  NNX12AB86G ; and at  Caltech 's  Jet Propulsion Laboratory, Pasadena , under a contract with  NASA. Gravity data and inversion are available at https://faculty. sites. uci. edu/erignot and will be archived at the NSIDC,  Boulder Colorado.
If their virial mass estimates are accurate, number density constraints alone suggest that the quasars SDSS J1044-0125 and SDSS J010013. 02+280225. 8 likely have black hole mass -stellar mass ratios higher than the median z = 0 relation, confirming the expectation from Lauer bias. Finally, we present a public code to evaluate the probability of an apparently ΛCDM-inconsistent high-mass halo being detected given the combined effects of multiple surveys and observational errors.
METHODOLOGY We adopt cumulative halo mass functions (Φ h ) from  Behroozi et al. (2013)  and define a redshift-dependent maximum cumulative galaxy mass function: Φ ,ΛCDM (M , z) ≡ Φ h (M / f b , z) (1) Φ ,ΛCDM is the ΛCDM upper limit on the true stellar mass function-equivalently, it is the expected collapsed gas mass function for ΛCDM. In practice, a given survey volume may contain a higher number density due to sample variance or observational errors, especially when multiple surveys are conducted. Appendix A offers a simple method and code to test whether a given outlier is significantly discrepant from the ΛCDM prediction. Given that median stellar mass fractions already reach up to 40% at z > 4 (Fig. 1 ) with the assumption of a Salpeter (1955) IMF, and that measurements of scatter in stellar mass at fixed halo mass are typically ∼ 0.
ACKNOWLEDGEMENTS We thank  Robert Antonucci ,  Andrea Cimatti ,  Alister Graham ,  Ryan Trainor ,  Marta Volonteri , and the anonymous referee for many extremely helpful comments that greatly improved this paper. PB was partially supported by program number  HST-HF2-51353. 001-A , provided by  NASA  through a  Hubble Fellowship grant  from the  Space Telescope Science Institute , which is operated by the  Association of Universities for Research in Astronomy, Incorporated , under  NASA  contract  NAS5-26555. JS acknowledges support from  ERC  Project No. 267117  (DARK) hosted by  Pierre et Marie Curie University  (UPMC) -Paris 6, France.
SIMBAD is a bibliographic added-value database on astronomical objects, where the data on individual objects are cross-identified as far as possible. The data comes exclusively from what has been published by the scientific community. To treat large tables, the work is done semi-automatically with the help of a customized software. Since 2014, we are using a new one, called COSIM (Comparison of Objects for SIM-BAD). It meets the new requirements which is a consequence of the evolution of the available astronomical data. It has increased in number, accuracy and diversity. On the basis of the data presented in a published table, COSIM searches for objects that are already known in SIMBAD, by name or by coordinates. A combination of scores based on the available and comparable parameters, like the main object type, coordinates, velocity and magnitudes, suggests whether the candidate is good for cross-identification or not.
As soon as the result of the search is clear, indicating that there is either no matching candidate or only one good candidate, COSIM creates the commands necessary for updating the SIMBAD database. The documentalists can act on the method of calculation of each score, according to the nature of the objects in the table. Thus, with COSIM the documentalists manage to obtain a good cross-identification level with a minimum risk of omitted or false cross-identifications in a relatively short time compared to the treated data number.
The SIMBAD database The SIMBAD database 1 is a service offered by the Strasbourg astronomical Data Center (CDS) 2. It was created in 1979 and has been maintained since. It is a bibliographic added-value database on astronomical objects outside the solar system, searchable via the Internet. SIMBAD provides basic data, identifiers, bibliographic references and observational measurements on astronomical objects. All data comes from the scientific literature  [6]. SIMBAD now contains about 9 million objects and 24 million identifiers for 330,000 references. This research tool is complementary to VizieR, another database maintained at the CDS, containing long lists of objects and large surveys.
At the beginning of SIMBAD, the number of volumes was reasonable and the documentalists could afford to read the whole article, looking for astronomical objects in the text, the figures and the tables. We thus updated SIMBAD manually till the 90's  [3, 4]. Then a software was developed and from then on, long lists of objects have been treated in a semi-automatic manner. From that moment, the documentalist team has been specialized into two branches: one for identifying objects in text, and one for dealing with the long lists  [2]. Each of the two team branches has adapted itself to the evolution of the available astronomical data that have increased in number, accuracy and diversity: • For the processing of texts, a software was created in 2008, DJIN  [1, 5] , in order to assist the detection of object names.
The place of COSIM in the whole procedure It is first important to emphasize that before and in parallel with the automatic work, there is a lot of human work, too. That's why we generally speak about semi-automatic work. We present in figure  1  the complete COSIM team procedure. First, in a weekly meeting between astronomers and documentalists, a list of priorities is discussed and it is decided which data are likely to be put into SIMBAD. As a result, the documentalist gets a small notice (step 1), that allows her to extract the useful data for COSIM. It is in this phase generally that the Dictionary of Nomenclature is consulted, EPJ Web of Conferences 186, 02004 (2018) https://doi. org/10. 1051/epjconf/201818602004 LISA VIII to re-write identifiers if necessary. A file is given to COSIM (step 2).
COSIM consults SIMBAD to search for cross-identifications and returns an output file (step 3). This file is analyzed by the documentalist. This is an important part, which is sometimes long and difficult. Not only does the documentalist use whatever tool or database she has at her disposal, such as SIMBAD, VizieR, Aladin and others, but she also consults her colleagues (other documentalists, astronomers, sometimes the computer scientist) or authors. Sometimes some preliminary manual updates are necessary. The documentalist adjusts the parameters (step 4), until COSIM writes update commands for all objects of the list. The update in SIMBAD can be then automatically done (step 5).
The COSIM software overview COSIM searches SIMBAD for cross-identifications by identifier and/or around the coordinates. Then, each candidate found is compared to the entering object. To do this, a score is attributed to each comparable parameter, such as the object type, the coordinates, the velocity, the magnitude. Then all those scores are combined in order to evaluate the candidate (is it good for cross-identification or not?). According to the number of good candidates found, a decision is taken: to create a new object, or to update an existing one. Or, no automatic decision can be taken and the case is to be analyzed by the documentalist.
The update decision According to the number of good and bad candidates found and when an automatic decision can be taken, the software writes update commands. Here is the exhaustive list where the automatic decision can be taken: • No candidate has been found, neither by identifier nor around the coordinates. COSIM writes update commands to create a new object in SIMBAD. • No candidate has been found by identifier, and all candidates found around the coordinates have been labeled "bad". COSIM again writes update commands to create a new object in SIMBAD. • One or several candidates have been found, either by identifier or around the coordinates, but only one has been labeled "good". The others, found around the coordinates, have been labeled "undefined" or "bad", it does not matter. COSIM writes update commands to update the SIMBAD existing object.
Among the cases where no automatic decision can be taken, a few ones are notable: • the "Possible Merger": two (or more) candidates have been labeled "good". The software cannot choose and has not been programmed to do the update on several objects. Actually, even if the "possible mergers" put a break on the automatic update decision, they are interesting, because they allow us to "tidy" SIMBAD. Thanks to the great possibility of COSIM to refine the comparison parameters, we can really rely on COSIM for detecting those cases, and only a small portion are wrong. SIMBAD has been improved by a lot of mergers since the use of COSIM. • the "Conflict": the author has given several identifiers for one object, and they correspond to different objects in SIMBAD. Here again, the "conflict" puts a break on the software process: COSIM can't choose.
Conclusion The COSIM software is an essential part of the SIMBAD operations, with the main advantages being that: • all the parameters in the comparison are adjustable • statistics and sorted lists give a precious help • it is faster than the precedent software As a result we can rely on these automatic parts of the process, allowing us to use precious time on aspects that need human expertise. Also, by using COSIM we can treat more objects and have confidence in the quality of the cross-identifications. COSIM is thus an important update of CDS procedures that helps us to address the increasing volume of published data. It is also important to understand that while COSIM is a useful tool, the global process must be driven by real people with expertise in astronomy and documentation, which remains essential.
Pathways and network maps approached for molecular processes representation Using the aforementioned approaches of molecular processes representation, several pathway databases have emerged  (11). They serve as biological knowledge information resource and as computational analytical tools for systems-based interpretation of data. A significant number of pathway databases has been also developed in the private domain, but the majority of pathway collections are free and open source (Supplementary Table  S1 ). The most common way of knowledge representation, used in the majority of these resources, is depicting separate processes referring to 'signal transduction pathways'. However, drawing individual pathways precludes clear representation of cross-regulations among biological processes. The alternative solution is to create seamless maps of biological mechanisms covering multiple cell processes simultaneously, similar to geographical maps.
The suggested workflow is in line with the Findable, Accessible, Interoperable, Re-usable (FAIR) principles for data management and sharing  (23). The access to the detailed procedures is provided in the Supplementary material and available at https://github. com/sysbio-curie/ NaviCell. The terms and definitions used through the paper are listed in Table  1. The DNA repair map from ACSN resource is used as an example for map construction and annotation: https://acsn. curie. fr/navicell/maps/dnarepair/master/ index. html (20). Epithelial-mesenchymal transition (EMT) regulation map from NaviCell collection (9) is used for data visualization: https://navicell. curie. fr/pages/signalling_network_emt_ regulation_description. html.
Map construction tool, graphical standard and data model Signalling processes of DNA repair are represented as biochemical reactions in CellDesigner diagram editor based on the standard SBGN syntax  (10) , and the Systems Biology Markup Language (SBML), for further computational modelling of the map  (14). The data model used in our example is schematically depicted in Figure  2. It includes such molecular entities as proteins, genes, RNAs, antisense RNAs, simple molecules, ions, drugs, phenotypes and complexes. Edges on the map represent biochemical reactions or reaction regulations including post-translational modifications, translation, transcription, complex formation or dissociation, transport, degradation and so on. Reaction regulations are catalysis, inhibition, modulation, trigger and physical stimulation.
In our example, the boundaries and the content of the DNA repair map were defined in coordination with specialists in the corresponding fields. According to the seminal reviews and well-known databases, DNA repair machinery distinguishes 10 partially overlapping modes of repair, depending on the type of damage. The DNA damage types are depicted on the map as 'inputs' initiating the corresponding DNA repair mechanisms. In addition, the map covers four cell cycle phases and depicts regulatory circuits between cell cycle and DNA repair mechanisms coordinated by cell cycle checkpoints (24) (Figure  3A ).
In our example, the global map layout of the DNA repair map has been designed to emphasize the hierarchical organization of three major layers in the map: the DNA repair machinery layer and its connection to the cell cycle layer via the checkpoints layer. The upper layer depicts the cell cycle, the middle layer represents cell cycle checkpoints, receiving signals from the cell cycle and coordinating the crosstalk between the cell cycle and the DNA repair machinery, represented in the lower layer. This hierarchical organization of the map in layers reflects the current understanding of signal propagation in the cell. Further, the map can be divided into functional modules. Each functional module can exist as a part of the global map but also as an independent map. Exploring the module maps together within the global map can be supported by Google Maps-based map navigation (discussed in the Section 'Map generation and navigation in NaviCell').
This allows creating a layout where all entities of a single module map are closely located. This manipulation results in a different layout of the module, comparing its design at the comprehensive map, however it does not change the backbone structure of the module. An example of a module map with optimized individual layout is the homologous recombination (HR) from the DNA repair map, shown in Figure  3B. For modular map generation instructions see https://github. com/sysbiocurie/NaviCell. Similarly, it is possible to generate automatic layouts for global, module maps or even for maps of an individual entity. The maps of an individual entity can represent 'lifecycle' reflecting reactions where the entity participates and the regulators of these reactions. This can be performed in Cytoscape software using the BiNoM plugin using the modularization and automatic layout functions  (25).
Some details on cell signalling might be skipped or, on the contrary, represented rigorously, depending on the purpose of the map being drawn, and the opinion of the map creator. It is important to address the challenge of persistent homogeneity on how to present the information on the map. This is especially important for visualization and exploration of the map, because it will ensure a correct stepwise appearance of details at different zoom levels on the Google Maps-like map visualization platform (discussed in the Section 'Common exchange formats'). For efficient map construction, we suggest to perform a systematic literature revision. The hierarchical organization of the map, actually reflects a suggested approach for literature curation. First, we recommend to use seminal review papers in the field and the major pathway databases (Supplementary Table  S1 ), in order to define the boundaries and general contents of the map.
The information on canonical pathways retrieved from these sources, reflects the consensus view of the field and can serve as basis for drawing the backbone structure of the map. Thus, further details on molecular mechanisms can be compiled from the most recent studies and added to the map. The good practice is to comply with the requirement of supporting every interaction included in the map by at least two independent investigations. In addition, the interpretation of scientific text and translation of written information into the correct and meaningful diagram is not always obvious. For consistency from text to diagram translation, we developed major rules for standardized interpretation of statements, see https://github. com/sysbio-curie/NaviCell. Figure  4  represents an example of scientific text translation into the PD diagram type.
The HiPub approach translates PubMed and PMC texts to networks of knowledge  (29). The ANDSystem: an Associative Network Discovery System for automated literature mining, distinguishes and reconstructs in a form of networks several types of interactions as genetic, protein, metabolic and so on. (30). Finally, the Information Hyperlinked over Proteins system, uses genes and proteins as hyperlinks between sentences and abstracts and converts the information from PubMed into one navigable resource for scientific literature investigation  (31). Among others, there is an approach of formalized textbased intermediate language as Biological Expression Language that structures the statements in a way that can be mechanistically converted into a meaningful biological network  (32). Similarly, BiNoM, a Cytoscape plugin, provides a function that converts sentences formulated in the 'human' language, into a set of formal statements describing reactions that in turn can be automatically represented as graphical diagrams.
The section 'Identifiers' includes standard IDs and provides links to the corresponding pages in HGNC, UniProt, Entrez, SBO, GeneCards and cross-references in REACTOME  (33) , KEGG  (34) , Wiki Pathways (  35 ) and so on. Metabolites and small compounds are annotated by corresponding IDs and linked to ChEBI  (36) , PubChem Compound  (37)  and KEGG Compound  (38)  databases. The section 'Maps_Modules' includes links to modules of the map where the entity participates. Referring to our example, the DNA repair map is part of Atlas of Cancer Signalling Network (ACSN) resource, and multiple entities from the DNA repair map can participate in various maps in the resource. There is a challenge to demonstrate this multi-functionality of an entity and there is a need to provide links to all maps and modules of ACSN where an entity participates.
The scores in the BioGRID resource (39) (https:// thebiogrid. org) are calculated taking into account if it is an original publication describing the interaction following the principle of CompPASS score system that uses unbiased metrics to assign confidence measurements to interactions from parallel nonreciprocal proteomic data sets  (40). These scores are ranged from 0 to 1, with 1 being the most confident. The SIGNOR database (41) (SIGNOR http://si gnor. uniroma2. it) uses functional relevance of interactions provided in the form of a 'reliability score'. This score is defined by the probability that two partners in the interaction are cited together in the same paper. This co-citing probability is ranged from 0 to 1. In the RECON database (42) (https://vmh. uni. lu), each reaction in the network is associated with a confidence score ranging from 0 to 4.
For example, a reaction annotated by two reviews will obtain the highest reference score REF ¼ 5. The functional proximity score, marked by 'FUNC' is computed based on the external network of protein-protein interactions (PPI), Human Protein Reference Database (HPRD)  (43). The score reflects an average distance in the PPI graph between all proteins participating in the reaction as reactants, products or regulators. Therefore, if all the proteins participating in a reaction interact directly (functional distance 1) in the PPI network, then this reaction obtains the highest score (FUNC ¼ 5). If in the reaction where phosphorylation of protein A is catalyzed by protein B, and A and B are separated in PPI graph by 2 (or 3, or 4) edges, then the reaction obtains the functional proximity score FUNC ¼ 4 (or FUNC ¼ 3, or FUNC ¼ 2, respectively).
Map generation and navigation in NaviCell Generation of NaviCell map using NaviCell factory CellDesigner maps, as the DNA repair map, annotated in the NaviCell format or not, can be converted into a NaviCell web-based front-end, which represents a set of HTML pages with embedded JavaScript code. It can be launched in a web browser locally or located on a webserver. The NaviCell factory is currently embedded in the BiNoM Cytoscape plugin but will be soon available as a stand-alone command line package. The detailed guide to use the NaviCell factory is provided at https://github. com/ sysbio-curie/NaviCell.
This gradual detail appearance permits to explore the map contents from the top-level toward a detailed view. To prepare maps for this type of navigation, a map pruning is performed, eliminating hence non-essential information for each zoom level. Typically, it is recommended to generate three to four zoom levels, although the number of zoom levels is unlimited in NaviCell (Figure  5 ). In our example of the DNA repair map, the top-level zoom displays the modules of the map, depicted with a coloured background shapes with the backbone structure of the pathways (Figure  5A ). In the next zoom level, canonical cell signalling pathways are shown. These pathways are defined by intersecting the content of the map with the corresponding pathways in other databases (Figure  5B ), at the last zoom all map elements are present (Figure  5C ).