dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgements. We thank the  EURODELTA-III modelling community, especially INERIS  for providing various model input data. We are grateful to ENVIRON for providing the CAMx-VBS code before its public release. Calculations of land-use data were performed with the  Swiss National Supercomputing Centre (CSCS). We thank  D. Oderbolz  for developing the CAMxRunner framework to ensure reproducibility and data quality among the simulations and sensitivity tests. We thank  M. Tinguely  for the visualization software. We also thank  G. Pirovano  for helping with the pre-processing of AirBase data. This study was financially supported by the  Swiss Federal Office of Environment (FOEN). J. L. Jimenez  was supported by  NSF   AGS-1360834  and  EPA STAR 83587701-0. We thank  D. A. Day  for analysis on the DAURE dataset,  Erik Swietlicki  for the Vavihill dataset,  A.
We present a data set on the biodiversity of Italian freshwaters, including lakeshores and riverbanks of natural (N=379: springs, streams and lakes) and artificial (N=11: fountains) sites. The data set belongs partly to the Italian Long Term Ecological Research network (LTER-Italy) and partly to LifeWatch, the European e-Science infrastructure for biodiversity and ecosystem research. The data included cover a time period corresponding to the last fifty years. They span a large number of taxa from prokaryotes and unicellular eukaryotes to vertebrates and plants, including taxa linked to the aquatic habitat in at least part of their life cycles (like immature stages of insects, amphibians, birds and vascular plants). The data set consists of 6463 occurrence data and distribution records for 1738 species.
BACKGROUND & SCOPE Many freshwater and taxonomic data sets exist at both European and National levels, such as the Freshwater Biodiversity Data Portal -BioFresh (http://data. freshwaterbiodiversity. eu/metadb/metaDBfts/index. php), the National Network of  Biodiversity (http://193. 206. 192. 106/portalino/home_it/dati. php), and Nature 2000 (http://www. minambiente. it/pagina/rete-natura-2000). Further web-links exist that are data portals to locations along the Italian peninsula where information pertaining to the distribution of freshwater biodiversity is available (e. g. , Checklist of the Italian Fauna, AQEM-STAR invertebrate database, Alpine GIG lakes phytoplankton, macrophytes and macroinvertebrates data, European Trichoptera, etc. ). Of all of these websites and portals, no one site combines the simultaneous presence of different taxonomic groups.
There is a clear need to collate different data sets based on broad-scale and longterm monitoring projects. Hence, we have compiled a data set that represents one of the most comprehensive and thorough collection nationwide, which is part of a larger LifeWatch data set including also coastal lagoons, littoral marine waters and terrestrial habitats. This vast data set was created under the umbrella of a case study on Alien Species (AS) that was proposed and coordinated by LifeWatch Italy at the European level. The case study is designed using species occurrence data to assess the vulnerability of different Italian ecosystems to AS arrival  (Boggero et al. 2014 , Corriero et al. 2016). The taxonomic resolution adopted in the data set is at the species level for all the included taxonomic groups across different phyla.
lteritalia. it) (Bertoni 2012 ) and to the LifeWatch network (http://www. lifewatch. eu, http://www. servicecentrelifewatch. eu)  (Basset and Los 2012, Basset 2016). The data set spans over a temporal period of about fifty years  across the Alpine, Continental and Mediterranean biogeographic zones of Italy  (EEA 2002). This data set is of particular interest as it aims to make biodiversity information available to future research that focuses on the occurrence and distribution of freshwater species at the national level. Data may also be relevant to policy makers, public authorities and enterprises involved in protection, management and sustainable use of freshwater ecosystems and their biodiversity. The analysis of this extensive survey of freshwater biodiversity in continental Italy will provide a basis for setting conservation priorities, developing monitoring programs and enforcing regulation  (Boggero et al.
Reported data include species occurrence from 390 sites (Fig. 1 ) and taxa from 11 different EUNIS groups ("algae", "amphibians", "birds", "cyanobacteria", "ferns", "fishes", "flowering plants", "invertebrates", "mosses and liverworts", "protists", "reptiles") spanning 24 phyla (Table  2 ). All of the records were verified by experts belonging to the different LifeWatch nodes. The LifeWatch nodes are represented by different Institutions (Universities, Research Centres, Museums, Environmental Agencies, National Forest Service, etc. ) that gathered and managed species occurrence data from the different sites. The sites represent only freshwater habitats. Update policy: following update policy rules of LifeWatch. Language: English. License of use: if used by researchers, administrators, managers, teachers, amateurs, general public, and others, the access is free and the use is based upon request.
MANAGEMENT DETAILS Project title: Vulnerability of ecosystems to Alien Species invasion. Database managers: Angela Boggero, Cataldo Pierri. Temporal coverage: the present data set refers to the last 52 years. Record basis: Mainly preserved specimens. Sometimes sample collection was based on field observation without specimen collection and preservation. Sampling methods: The data set was created by collating different data sets managed by several research institutions. The data is shared within the context of the Alien Species Showcase of the LifeWatch infrastructure. The definition of alien species that is adopted for the data set is very general, and is defined and available in the Alien Species Thesaurus produced by LifeWatch Italy (http://thesauri. lifewatchitaly. eu/alienspecies/index.
php): where species are considered alien if deliberately or inadvertently introduced to Italy by human activities after the discovery of the New World by Columbus in 1492  (Boggero et al. 2014). This definition is similar to what plant invasion biologists call "neophytes"  (Pyšek, 1998). IT specialist: Nicola Fiore. Funding grants: Data were obtained within the framework of several European and Italian projects, and thanks to the LifeWatch support. LifeWatch Italy is funded by Ministero dell'Istruzione, dell'Università e della Ricerca (MIUR) and managed by the National Research Council of Italy.
GEOGRAPHIC COVERAGE Study area: Sites are distributed along the Italian peninsula. The five main geographical areas are North-West, North-East, North, Centre, and South (Fig. 1 ). The data were georeferenced by each LifeWatch node according to WGS 84 datum. Bounding box: min Longitude: 7. 39 -min Latitude 39. 38 -max Longitude: 17. 95 -max Latitude: 46. 98.
Sampling design: The general strategy developed within LifeWatch was to try to cover most of the territory and many different freshwater habitats. However, the data set covers only a minor part of Italy. It is anticipated that in the near future the data set will increase exponentially. The sampling design was intended to compile the information necessary for assessing Italian freshwater biodiversity and, in particular, the impacts of alien species on ecosystems. The idea is to design adequate management strategies to minimize the impacts of alien species and enable stakeholders to adapt the developed services to their particular needs (local, regional, or national scales). Habitat type: Four habitat types (Fig. 2 ) were covered by the different sites belonging to the LifeWatch network according to the EUropean Nature Information System (EUNIS; http://eunis.
eea. europa. eu/) hierarchical protocol of habitat identification considering only the first-level option. The EUNIS habitat type classification is a pan-European system that aims to facilitate the harmonized description and collection of data across Europe. Thus, the EUNIS classification is a reference framework for the development of indicators and environmental reporting at the administrative and political level, and is particularly suitable for a study focusing on alien species impact. Following The EUNIS system, the sites were classified as: C1 -Surface standing waters; C2 -Surface running waters; C3 -Littoral zone of inland surface waterbodies; J5 -Highly artificial man-made waters and associated structures. Biogeographic region: Alpine, Continental and Mediterranean  (EEA 2002). Country: Italy.
LITERATURE SEARCH General description: The information on species presence at each site comes from published papers on surveys directly conducted by the authors and their collaborators from 1962 to 2014. Moreover, it includes additional papers and reports from universities and research institutions, as well as notes in technical reports from local authorities. Literature search methods: All relevant literature (Supplementary file S1) was obtained using data from published papers on national and international journals directly supplied by data providers. Moreover, for each site, all the published grey literature (papers internal to public organizations, master thesis, reports, research deliverables, books, monographs) was screened. Quality control for literature data: The data collated was property of most of the authors and coauthors of this paper, and since the same researchers are experts in their disciplines at National and International levels, they were involved as experts of the LifeWatch nodes.
Therefore, the published data are considered reliable and simply checked for nomenclatorial consistency. General description: The data set covers a wide spectrum of taxonomic groups inhabiting freshwater habitats and their surroundings. The inclusion of a species as aquatic or its exclusion as not aquatic was carried out considering its life cycle, linked or not to the aquatic habitat in at least part of its life. Thus, we included truly aquatic organisms, together with those that have immature stages in water, nest in or on water, and have roots in water. Taxonomic ranks: All living freshwater biota or organisms related to waters in at least part of their life were considered. In particular, we gathered data from 24 phyla. Taxonomic methods: These include revision of names, synonymizing, delimitation of genera and higher taxa, both conducted manually and through online tools supplied by the LifeWatch infrastructure (http://www.
servicecentrelifewatch. eu). Taxon specialists: Each LifeWatch node was responsible for data management from specific geographical areas and for the taxonomic control. Taxonomists from each node screened the data set for taxonomic reliability, potential problems in taxonomic identification, consistency and homogeneity of taxonomic coverage, and temporal coverage of repeated sampling for each site. Quality control for taxonomic data: Record validation and cleaning were based on several steps and divided into: a) data standardization (considering the same time-span length, check of nomenclatural changes or synonyms); b) data cleaning and validation for taxonomic reliability and taxonomic consistency using different large zoological and botanical taxonomic indexes and databases known at European level following Pan-European Species directories Infrastructure (PESI), World Register of Marine Species -WoRMS, and Catalogue of Life; and c) final semi-automatic data cleaning, through the tools available on the LifeWatch portal.
ACKNOWLEDGEMENTS All the Authors would like to express their sincere gratitude to technicians, students, and colleagues offering their unconditional support during the different sampling campaign and the laboratory activities during all these years of hard work. Without their cooperation, this data set could never have been created. Authors are also in debt with  Mattia Menchetti  and an anonymous reviewer for their comments improving an earlier version of the manuscript, with  Ester Eckert  ( CNR, Institute of Ecosystem Study, Italy ) and  Marnie Campbel  ( Univ. of Waikato, New Zealand ) for their helpful suggestions and for the English correction of the text.
The need to store and manipulate large volume of (unstructured) data has led to the development of several NoSQL databases for better scalability. Graph databases are a particular kind of NoSQL databases that have proven their efficiency to store and query highly interconnected data, and have become a promising solution for multiple applications. While the mapping of conceptual schemas to relational databases is a well-studied field of research, there are only few solutions that target conceptual modeling for NoSQL databases and even less focusing on graph databases. This is specially true when dealing with the mapping of business rules and constraints in the conceptual schema. In this article we describe a mapping from UML/OCL conceptual schemas to Blueprints, an abstraction layer on top of a variety of graph databases, and Gremlin, a graph traversal language, via an intermediate Graph metamodel.
Introduction NoSQL databases have become a promising solution to enhance scalability, availability, and query performance of data intensive applications. They often rely on a schemaless infrastructure, meaning that their schemas are implicitly defined by the stored data and not formally described. This approach offers great flexibility since it is possible to use different representations of a same concept (non-uniform data), but client applications still need to know (at least partially) how conceptual elements are stored in the database in order to access and manipulate them. Acquiring this implicit knowledge of the underlying schema can be an important issue, for example in data integration processes, where each data source has to be inspected to find its underlying structure  [13]. Graph databases are a particular type of NoSQL databases that represent data as a set of vertices linked together by edges where both vertices and edges can be labeled with a number of property values.
Graph databases often provide advanced and expressive query languages that are particularly optimized to compute traversals of highly interconnected data. Recently, the graph database ecosystem is gaining popularity in several engineering fields such as social network  [11]  or data provenance  [1]  analysis, and the leading graph database vendor Neo4j 4  is used in production by several companies  [16]. In order to take full benefit of NoSQL solutions, designers must be able to integrate them in current code-generation architectures to use them as target persistence backend for their conceptual schemas. Unfortunately, while several solutions provide transformations from ER and UML models to relational database schemas, the same is not true for NoSQL databases as discussed in detail in the related work.
Moreover, NoSQL databases present an additional challenge: data consistency is a big problem since the vast majority of NoSQL approaches lack any advanced mechanism for integrity constraint checking  [21]. To overcome this situation, we propose the UMLtoGraphDB framework, that translates conceptual schemas expressed using the Unified Modeling Language (UML)  [24]  into a graph representation, and generates database-level queries from business rules and invariants defined using the Object Constraint Language (OCL)  [23]. The framework relies on a new GraphDB metamodel, as an intermediate representation to facilitate the integration of several kinds of graph databases. Enforcement of (both OCL and structural) constraints is delegated to an intermediate software component (middleware) in charge of maintaining the underlying database consistent with the conceptual schema.
External applications can then use this middleware to safely access the database. This is illustrated in Figure  1. The rest of the paper is structured as follows: Section 2 presents the UMLtoGraphDB framework and its core components, Section 3 introduces the GraphDB metamodel and details the model-to-model transformation which creates an instance of it from a UML model. Section 4 presents the transformation that creates graph database queries from OCL expressions, and Section 5 introduces the code generator. Finally, Section 6 describes our tool support, Section 7 presents the related works and Section 8 ends up with the conclusions and future work.
UMLtoGraphDB Approach UMLtoGraphDB is aligned with the OMG's MDA standard  [22] , proposing a structured methodology to systems development that promotes the separation between a specifi-cation defined in a platform independent way (Platform Independent Model, PIM), and the refinement of that specification adapted to the technical constraints of the implementation platform (Platform Specific Model, PSM). A model-to-model transformation (M2M) generates PSM models from PIMs while a model-to-text transformation typically takes care of producing the final code out of the PSM models. This PIM-to-PSM phased architecture brings two important benefits: (i) the PIM level focuses on the specification of the structure and functions, raising the level of abstraction and postponing technical details to the PSM level.
(ii) Multiple PSMs can be generated from one PIM, improving portability and reusability. Moreover, using an intermediate PSM model instead of a direct PIM-to-code approach allows designers to tune the generation when needed and simplify the transformations by reducing the semantic gap between their input and output artefacts. In our scenario, the initial UML and OCL models would conform to the PIM level. UMLtoGraphDB takes care of generating the PSM and code from them. Figure  2  presents the different component of the UMLtoGraphDB framework (light-grey box). In particular, Class2GraphDB (1) is the first M2M of the UMLtoGraphDB framework. It is in charge of the creation of a low-level graph representation (PSM) from the input UML class diagram (PIM). The output of the Class2GraphDB transformation is a GraphDB Model (2), conforming to the GraphDB metamodel (Section 3).
This metamodel is defined at the PSM level, and describes data structures in terms of graph primitives, such as vertices or edges. The OCL2Gremlin transformation (3) is the second M2M in the UMLtoGraphDB framework. It is in charge of the translation of the OCL constraints, queries, and business rules defined at the PIM level into graph-level queries. It produces a Gremlin Model, conforming to the Gremlin language metamodel that complements the previous GraphDB one. The last step in MDA processes is a PSM-to-code transformation, which generates the software artifacts (database schema, code, configuration files. ) in the target platform. In our approach, this final step is handled by the Graph2Code (5) transformation (Section 5) that processes the generated GraphDB and Gremlin models to create a set of Java Classes wrapping the structure of the database, the associated constraints, and the business rules.
These Java classes compose the Middleware layer (6) presented in Figure  1 , and contain the generated code to access the physical Graph Database  (7). To illustrate the different transformation steps of our framework we introduce as a running example the conceptual schema presented in Figure  3  representing a simple excerpt of an e-commerce application. This schema is specified using the UML notation, and describes Client, Orders, and Products concepts. A Client is an abstract class defined by a name and an address. PrivateCustomers and CorporateCustomers are subclasses of Client. They contain respectively a cardNumber and a contractRef attribute. Clients own Orders, that are defined by a reference, a shipmentDate, and a delivery-Date. In addition, an Order maintains a paid attribute, that is set to true if the Order has been paid.
GraphDB Metamodel The GraphDB metamodel defines the possible structure of all GraphDB models. It is compliant with the Blueprints  [26]  specification, which is an interface designed to unify NoSQL database access under a common API. Initially developed for graph stores, Blueprints has been implemented by a large number of databases such as Neo4j, Ori-entDB, and MongoDB. The Blueprints API is, to our knowledge, the only interface unifying several NoSQL databases  5. Blueprints is the base of the Tinkerpop stack: a set of tools to store, serialize, manipulate, and query graph databases. Among other features, it provides Gremlin  [27] , a traversal query language designed to query Blueprints databases. Figure  4  presents the GraphDB metamodel. A GraphSpecification element represents the top-level container that owns all the objects.
It has a baseDB attribute, that defines the concrete database to instantiate under the Blueprints API. In our prototype, the baseDB can be either Neo4j or OrientDB, two well known graph databases. Graph-Specification contains all the VertexDefinitions and EdgeDefinitions through the associations vertices and edges. A VertexDefinition can be unique, meaning that there is only one vertex in the database that conforms to it. VertexDefinitions and EdgeDefinitions can be linked together using outEdges and inEdges associations, meaning respectively that a VertexDefinition has outgoing edges and incoming edges. In addition, VertexDefinition and EdgeDefinition are both subtypes of GraphElement, which can define a set of labels that describe the type of the element, and a set of PropertiesDefinition through its properties reference.
Translating OCL Expressions to Gremlin Once the GraphDB model has been created, another transformation is performed to translate the OCL expressions defined in the conceptual schema into a Gremlin query model. The mapping presented in this Section is adapted from the one presented in  [8]  dedicated to OCL query evaluation on NeoEMF, a scalable model persistence framework designed to store models into graph databases  [2]. In this Section, we present the Gremlin language and describe how OCL expressions are transformed into Gremlin queries according to the UML to GraphDB mapping.
The Gremlin Query Language Gremlin is a Groovy domain-specific language built over Pipes, a data-flow framework on top of Blueprints. We have chosen Gremlin as the target query language for UML-toGraphDB due to its adoption in several graph databases. Gremlin is based on the concept of process graphs. A process graph is composed of vertices representing computational units and communication edges which can be combined to create a complex processing flow. In the Gremlin terminology, these complex processing flows are called traversals, and are composed of a chain of simple computational units named steps. Gremlin defines four types of steps: Transform steps that map inputs of a given type to outputs of another type, Filter steps, selecting or rejecting input elements according to a given condition, Branch steps, which split the computation into several parallel sub-traversals, and side-effect steps that perform operations like edge or vertex creation, property update, or variable definition or assignment.
Note that generated expressions are queries that return a boolean value. These queries are embedded in checking methods during the generation phase (Section 5). v. p r o p e r t y ( " p r i c e " ) > 0 ; / / v a l i d P r i c e v. p r o p e r t y ( " s h i p m e n t D a t e " ) < s e l f. p r o p e r t y ( " d e l i v e r y D a t e " ) ; / / v a l i d O r d e r v. o u t E ( " o r d e r s " ). inV. f i l t e r { i t. p r o p e r t y ( " p a i d " ) == f a l s e }. c o u n t ( ) < 3 ; / / m a x U n p a i d O r d e r s Listing 3. Generated Gremlin Queries Our code-generator relies on the Blueprints API for interacting with the graph database in a vendor neutral way. We first briefly review this API and then we show how we leverage it to enforce that any application aiming to query/store data through the created middleware does it so according to the its initial UML/OCL conceptual schema.