dataesr/scientific-paragraphs-categorization huggingface dataset:
-D. Gravel, Univ. du Québec à Rimouski, Dépt de Biologie, 300  Allées des Ursulines, Rimouski, QC G5L 3A1, Canada. DG and TP also at: Québec Centre for Biodiversity Sciences, Montréal, QC, Canada. The study of ecological networks is severely limited by 1) the difficulty to access data, 2) the lack of a standardized way to link meta-data with interactions, and 3) the disparity of formats in which ecological networks themselves are stored and represented. To overcome these limitations, we have designed a data specification for ecological networks. We implemented a database respecting this standard, and released an R package (rmangal) allowing users to programmatically access, curate, and deposit data on ecological interactions. In this article, we show how these tools, in conjunction with other frameworks for the programmatic manipulation of open ecological data, streamlines the analysis process and improves replicability and reproducibility of ecological network studies.
In both cases, making a programmatic link between interaction data and relevant meta-data is difficult and, more importantly, error-prone. By contrast, a data specification (i. e. a set of precise instructions detailing how each object should be represented) provides a common language for network ecologists to interact, and ensures that, regardless of their source, data can be used in a shared workflow. Most importantly, a data specification describes how data are exchanged. Each group retains the ability to store the data in the format that is most convenient for in-house use, and only needs to provide export options (e. g. through an API, i. e. a programmatic interface running on a web server, returning data in response to queries in a pre-determined language) respecting the data specification.
This approach ensures that all data can be used in meta-analyses, and increases the impact of data  (Piwowar and Vision 2013). Data archival also offers additional advantages for ecology. The aggregation of local observations can reveal large-scale phenomena  (Reichman et al. 2011 ), which would be unattainable in the absence of a collaborative effort. Data archival in databases also prevents data rot and data loss  (Vines et al. 2014) , thus ensuring that data on interaction networks -which are typically hard and costly to produce -continue to be available and usable.
Elements of the data specification The data specification introduced here (Fig. 1 ) is built around the idea that (ecological) networks are collections of relation-ships between ecological objects, and each element has particular meta-data associated with it. In this section, we detail the way networks are represented in the mangal specification. An interactive webpage with the elements of the data specification can be found online at  http://mangal. io/doc/spec/ . The data specification is available either at the API root (e. g.  http://mangal. io/api/v1/?format=json >), or can be viewed using the whatIs function from the rmangal package. Rather than giving an exhaustive list of the data specification (which is available online at the aforementioned URL), this section serves as an overview of each element, and how they interact.
We propose JSON, a user-friendly format equivalent to XML, as an efficient way to standardise data representation for two main reasons. First, it has emerged as a de facto standard for web platform serving data, and accepting data from users. Second, it allows strict validation of the data: a JSON file can be matched against a scheme, and one can verify that it is correctly formatted (this includes the possibility that not all fields are filled, as will depend on available data). Finally, JSON objects are easily and cheaply (memory-wise) parsed in the most commonly-used programming languages, notably R (equivalent to list) and python (equivalent to dict). For most users, the format in which data are transmitted is unimportant, as the interaction happens within R -as such, knowing how JSON objects are organized is only useful for those who want to interact with the API directly.
As such, the rmangal package takes care of converting the data into the correct JSON format to upload them in the database. Functions in the rmangal package are names after elements of the data specification, in the following way: verb  Element. verb can be one of list, get, or patch; for example, the function to get a particular network is getNetwork. The function to modify (patch) a taxon is patchTaxa. All of these functions return a list object, which means that chaining them together using, e. g. the plyr package, is time-efficient. There are examples of this in the use-cases.
Taxa Taxa are a taxonomic entity of any level, identified by their name, vernacular name, and their identifiers in a variety of taxonomic services. Associating the identifiers of each taxa allows using the new generation of open data tools, such as taxize  (Chamberlain and Szöcs 2013) , in addition to protecting the database against taxonomic revisions. The data specification currently has fields for NCBI (National Center for Biotechnology Information), GBIF (Global Biodiversity Information Facility), TSN (Taxonomic Serial Number, used by the Integrated Taxonomic Information System), EOL (Encyclopedia of Life) and BOLD (Barcode of Life) identifiers. We also provide the taxonomic status, i. e. whether the taxon is a true taxonomic entity, a 'trophic species', or a morphospecies. Taxonomic identifiers can either be added by the contributors, or will be automatically retrieved during the automated curation routine.
Use cases In this section, we present use-cases using the rmangal package for R, to interact with a database implementing this data specification, and to serve data through an API ( http://mangal. io/api/v1/ ). It is possible for users to deposit data into this database through the R package. Note that data are made available under a CC-0 Waiver  (Poisot et al. 2013a). Detailed information about how to upload data are given in the vignettes and manual of the rmangal package. In addition, the rmangal package comes with vignettes explaining how users can upload their data into the database through R. The data we use for this example come from  Ricciardi et al. (2010). These data were previously available on the InteractionWeb DataBase as a single xls file. We uploaded them in the mangal database at < http://mangal.
Create taxa and add an interaction In the first use-case, we will create an interaction between two taxa. We ask of readers not to execute this code as it which  Martinez (1992)  proposed to be linear (in food webs). Getting the data to produce Fig. 2  requires less than 10 lines of code. The only information needed is the identifier of the network or dataset, which we suggest should be reported in publications as: 'these data were deposited in the mangal format at  URL  /api/v1/dataset/  ID ' (where  URL  and  ID  are replaced by the corresponding values), preferably in the methods, possibly in the acknowledgements. To encourage data sharing and its recognition, we encourage users of the database to always cite the original datasets or publications.
Network beta-diversity In the second example, we use the framework of network b-diversity  (Poisot et al. 2012)  to measure the extent to is, but rather to use it as a template for their own analyses. A complete, step-by-step guide to upload is given in the vignettes of the rmangal package. Uploading anything requires an username and API key, which can be obtained at the following URL: < http://mangal. io/dashboard/login >. Your API key be generated automatically after registration. You can use it to connect to the database securely: api_secure <-mangalapi("http://mangal. io", usr="MyUserName", key="AbcDefIjkL1234") The first step is to create two taxa objects, with the species that we observed interacting: Figure  2. Relationship between the number of species and number of interactions in the anemonefish-fish dataset.
Constant connectance refers to the hypothesis that there is a quadratic relationship between these two quantities. Now, we will send these two objects to the remote database: seal <-addTaxa(api_secure, seal) cod <-addTaxa(api_secure, cod) Note that it is suggested to overwrite the local copy of the object, because the database will always send back the remote copy. This makes the syntax of further addition considerably easier, as we show below. Once the two objects are created, we can create an interaction between them: seal_eats_cod <-list( taxa_from = seal, taxa_to = cod, int_type = "predation", obs_type = "observed" ) Then using the same approach, we can send this information in the remote database: To create networks, datasets, etc, one needs to follow the same procedure, as is explained in the online guide for data contributors, available at  http://mangal.
Link-species relationships In the first example, we visualize the relationship between the number of species and the number of interactions, which networks that are far apart in space have different interactions. Each network in the dataset has a latitude and longitude, meaning that it is possible to measure the geographic distance between two networks. For each pair of networks, we measure the geographic distance (in km), the species dissimilarity (b s ), the network dissimilarity when all species are present (b WN ), and finally, the network dissimilarity when only shared species are considered (b os ).
Conclusions The mangal data format will allow researchers to put together datasets with species interactions and rich metadata that are needed to address emerging questions about the structure of ecological networks. We deployed an online database with an associated API relying on this data specification. Finally, we introduced rmangal, an R package designed to interact with APIs using the mangal format. We expect that the data specification will evolve based on the needs and feedback of the community. At the moment, users are welcome to propose such changes on As shown in Fig. 3 , while species dissimilarity and overall network dissimilarity increase when two networks are far apart, this is not the case for the way common species interact. This suggests that in this system, network dissimilarity over space is primarily driven by species turnover.
The ease to gather both raw interaction data and associated meta-data make conducting this analysis extremely straightforward. Bascompte (2009)  uses an interesting visualization for spatial networks, in which each species is laid out on a map at the center of mass of its distribution; interactions are then drawn between species to show how species distribution determines biotic interactions. In this final use case, we propose to reproduce a similar figure (Fig. 4 ). the project issue page: < https://github. com/mangal-wg/ mangal-schemes/issues >. A python wrapper for the API is also available at < http://github. com/mangal-wg/pymangal/ >. Additionally, there are plans to integrate this database with GLOBI, so that data can be accessed from multiple sources  (Poelen et al. 2014).
Retrieve the dataset of interest dataset <-getDataset(api, 2) # Get each network in the dataset as a graph object graphs <-alply(dataset$networks, 1, function(x) toIgraph(api, x)) # Make a data. frame with the number of links and species ls <-ldply(graphs, function(x) c(S = length(V(x)), L = length(E(x)))) ls$X1 <-aaply(as. numeric(as. vector(dataset$networks)), 1, function(x) getNetwork(api, x)$name) colnames(ls)[1] <-'Network' # Now plot this dataset source("suppmat/usecase_ls. r").
# Retrieve the dataset of interest dataset <-getDataset(api, 2) # Get each network in the dataset as a graph object graphs <-alply(dataset$networks, 1, function(x) toIgraph(api, x)) # Make a data. frame with the number of links and species ls <-ldply(graphs, function(x) c(S = length(V(x)), L = length(E(x)))) ls$X1 <-aaply(as. numeric(as. vector(dataset$networks)), 1, function(x) getNetwork(api, x)$name) colnames(ls)[1] <-'Network' # Now plot this dataset source("suppmat/usecase_ls. r").
On the other hand, improvements leading to lower detection limits for known bioactive compounds are also needed as for some of the newly established water priority substances (Table  1 ) it is currently virtually impossible to analytically determine compounds at the very low EQS concentrations set for them in the WFD. It is therefore the goal of the SOLUTIONS project to improve chemical analytics both with respect to capabilities to screen for more compounds and to improve present detection limits. Subsequently, the data from case studies will be utilised to investigate the co-occurrence of components. To identify mixtures of priority, two data evaluation strategies will be pursued. Firstly, we will try to identify patterns of co-occurring compounds and correlate them to site characteristics, land use or specific contamination sources.
To address this issue a focus on priority mixtures that might be derived from chemical analytical information is a promising approach. Priority mixtures identification based on the analytical data is, in our perspective, not limited to sets of defined chemicals at specified concentrations but rather an analysis of patterns is needed as described above. SOLUTIONS looks for answers regarding better coverage of detectable and unidentified compounds by establishing non-target screening workflows and a set of interacting compound identification tools which integrate GC-MS/MS and LC-HRMS/MS technology with computer tools for retention, fragmentation, hydrogen-deuterium exchange and toxicity prediction and database for mass spectra. More details concerning the roads taken are summarised in Table  2.
The task is to operationalise the required mixture assessment, i. e. to tailor the available tools for the specific tasks laid out above. The SOLUTIONS project as a whole sets out to not only provide advanced methodologies for water quality monitoring, but also to deliver suggestions for testing requirements and data needs for carrying out mixture risk assessment and management in the context of the WFD. The last step will be performed in collaboration with the modelling, case studies and conceptual framework activities  (Brack et al. 2014). The NORMAN network (http://www. norman-network. net/) has recently proposed a novel risk assessment-based approach for prioritisation of water pollutants for improving water monitoring (Dulio and von der Ohe 2013,  Brack et al. 2012). It suggests a strategy to cope with scarce data for individual compounds and to account for different management action categories.
Assessment of the impact of CeNGEPS CeNGEPS developed and implemented follow-up tools in April 2007 to evaluate the impact of the combined actions. Using these tools, reliable data have been collected since 2008 to measure the impact. One of these tools, implemented on the CeNGEPS extranet, enables real-time follow-up and analyses of the CRTs' activity, as well as financial surveillance of attributed funds. The second tool, not on the CeNGEPS extranet, enables information on the overall activity of industry-sponsored clinical research in the inter-regions to be collected using an Excel spreadsheet; the inter-region point of contact is responsible for collecting the data from the various sites in their region. The sites are classified as 'new' or 'closed'. New sites are those that have signed a contract with an industrial sponsor during the year being assessed and closed sites are those that are closed to recruitment and have invoiced the sponsor in the year being assessed.
Assessment of the impact of CeNGEPS-funded clinical research technicians In 2013, 58 % of sites with a CeNGEPS-CRT included >80 % of the number of patients targeted compared with 47. 0 % of sites without a CeNGEPS-CRT. Only 9. 0 % of sites with a CeNGEPS-CRT closed with no patients included, compared with 26. 0 % of those without a CeNGEPS-CRT. The median inclusion rate was higher in the sites with a CeNGEPS-CRT: 80 vs 50 %. Data from the CeNGEPS extranet showed that, in sites with a CeNGEPS-CRT, there were 873 trials closed to recruitment in 2013 compared with 670 in 2011 (+30 %). There was an increase in the median recruitment rate, from 71. 4 to 89. 0 %, and the percentage of sites that recruited >80 % of their target slightly increased from 58. 7 to 58. 9 %. There were fewer sites closed with no patients recruited (17.
Automatic tool to assess the patient database to prevent study sites closing with no patients included (estimated to cost sponsors about €12 000/centre) through feasibility surveys iii. Aid for the development of potential investigators and access to patients in non-teaching hospitals/clinics iv. National programmes for professionalization and training in clinical research to guarantee quality v. Increasing public awareness about clinical research and its importance in society via a website (www. notre-recherche-clinique. fr) which went live in April 2010; 329 760 visits and 1 346 883 pages seen up to August 2013.
This paper presents an overview of the capabilities of a new open-source pre-and post-processing tool for Computational Fluid Dynamics simulations, called Cassiopee. Its architecture, which is basically a set of Python modules, and the handled data, which is based on CGNS standard, are described. Some examples of workflows that can be built with Cassiopee functions are provided. Finally, some applications of Cassiopee functions to realistic CFD configurations are briefly presented.
Introduction In 2008, ONERA started a project to gather pre-and post-processing tools in a single software, called Cassiopee, following other initiatives as Salome  [1]  or gmsh  [2]. At that time, pre-and post-processing tools were spread among scientists, each one generally having its file formats and data representations. Thus, it seemed clear that capitalizing all the knowledge in a single software environment and making it interoperable was worth the effort. However, this effort pays off only if the common data representation is well accepted and easily accessible to users. For this reason, the Python language was chosen as a high level interface, since it is very fast to start with, easy to use and is spread in the scientific community (scipy, matplotlib,. ). To simplify the use of Cassiopee, two interfaces are provided: the first one, that we call the "array" interface, is directly based on numpy arrays.
In this way, Cassiopee functions can be easily mixed with functions using the numpy library. The second interface is based on the Python representation of the CFD General Notation System (CGNS) of data  [3]. The data handled by Cassiopee functions is then an imbricated set of lists describing a computation tree, compliant with the CGNS standard, as described by  Poinot [4]. We call this interface the "pyTree" interface. Functions are classified in thematic Python modules, according to their features. Each Python module is independent and can be compiled and installed separately from the others. Currently, among all the available functionalities, one can for example perform minor mesh modifications, mesh improvements (e. g. mesh smoothing), preprocessing of a CFD computation (e. g. connectivity computation or mesh splitting), code coupling or solution post-processing.
Design choices As previously presented, the pyTree is one of the two choices of data representations available in Cassiopee. From now on, we will focus on this interface only. A pyTree is a hierarchical data set where each node is a Python list of this type: ['name', v, [], 'Type'] (1) The string 'name' is simply the name of the node, v is a numpy array defining the value of the node (for instance, for the first component of the grid coordinates, say 'CoordinateX', the numpy array stores all the x-coordinate values for the corresponding zone), the string 'Type' is a CGNS-compliant name and describes the node type (e. g. 'Zone t' for a zone node). The third element of the Python list is [] and define the list of nodes that are the current node's children. This structure enables to store the mesh coordinates (in a node named 'GridCoordinates'), the flow solution (located at nodes and at centers), bound- ary conditions (in a node of name 'ZoneBC' for each zone) or the grid connectivity.
An example of a representation of a pyTree is displayed in figure  1. This data structure is common to all the modules of Cassiopee. In addition, the philosophy of Cassiopee modules is purely functional, hence a Cassiopee function can be written as: b = f (a) or f (a) (2) where a and b are pyTrees. Function f returns a copy b of the pyTree, whereas function prefixed with a " " results in an in-place modification of the pyTree (the given pyTree is directly modified by the function f ). For the sake of generality, we try (as far as possible) to make all the Cassiopee functions deal with all mesh types: structured meshes, unstructured meshes with basic elements, and polyhedral meshes, as displayed in figure  2. Element names are also defined according to the CGNS standard: for instance a 'NGON/NFACES'-type mesh describes a general polyhedral mesh.
Converter module Converter module enables input/output between the in-memory data representation and various file formats of discrete data, such as Tecplot, plot3d, mesh, STL, OBJ. and of course CGNS/ADF and CGNS/HDF5 formats. Converter module also provides low-level functions to handle pyTrees, such as pyTree node creation/removal or specific nodes search. Basic functions are also implemented to add boundary conditions to a zone, to initialize a solution, to convert a solution from centers to nodes and vice versa.
Transform module The Transform module gathers functions that operate on mesh coordinates such as translation, rotation, homothety. Some split functions are implemented for structured grids in this module. They can be used for parallel load balancing of a CFD computation or for post-processing purposes. Figure  10  displays a 2D mesh around a NACA0012 profile that is split according to the maximum number of points required in each zone. For this case, if the initial pyTree contains boundary conditions, flow solution or connectivities, they are also subzoned by the split function. Reverse algorithms enable to join pairs of structured grids or to merge all grids automatically in a minimum number of blocks, according to the algorithm of Rigby  [14]  (figure  11 ). Finally, structured or unstructured meshes can be smoothed by functions using Laplace/umbrella operators or Taubin smoothing  [15].
The algorithm is based on the one developed in  [18]. In Connector module, it is further split into two functions: -first, Connector. optimizeOverlap results in marking points that can be removed in overlapping regions as interpolated, depending on a quality criterion between donor and receptor points. -then, Connector. maximizeBlankedCells maintains d layers of interpolated points, the other points marked initially as interpolated are marked as blanked points. The computation of the overset grid connectivity is achieved by the function Connector. setInterpData: receptor and donor points, interpolation coefficients, interpolation method and the location of interpolated points are stored in the pyTree as a ZoneSubRegion t-type node for each pair of donorreceptor zones. Different interpolation methods are available: -the 2 nd -order interpolation works for structured and Tetra donor grids.