dataesr/scientific-paragraphs-categorization huggingface dataset:
Through this graphical interface, users can interact with the MESOCOSM database more flexibly and intuitively. It is also expected that this application could encourage users to use the MESOCOSM database and make it evolve. There are currently 5200 entities in the MESOCOSM database related to tens of unique experiments investigating CeO 2 , CuO, T iO 2 -based ENMs, and nano-enabled products. But we hope that with collaborative efforts, this number of entities could quickly evolve. Indeed, the database website invites the large nanotechnology and nanoscience communities to submit additional data that could contribute to the enrichment of the MESOCOSM database, as well as to address suggestions to improve the database. The MESOCOSM database provides experimental data of interest to a wide range of users, including manufacturers, researchers, and government agencies.
Link NanoE-Tox included in the database. Raw data collected from analytical instruments are manually refined, validated, and organized before being stored in the MESOCOSM database. The free access to the content of the MESOCOSM database and its integration into important databases such as eNanoMapper, NanoInformaTIX,. is expected to provide a vast collection of environmental nanosafety data to support governments and regulators in developing legislation and recommendations regarding the use of ENMs. Furthermore, in a safer-by-design perspective, using the MESOCOSM database, manufacturers could better understand and assess the environmental exposure and toxic potential of ENMs at each stage of their life cycle.
MESOCOSM database content The MESOCOSM database contains all the information collected during the contamination of an ecosystem by ENMs  [3]. The simulation in the lab of this ecosystem is ensured by mesocosm testing, that offer a means of providing meaningful environmental exposure and hazard data to inform about environmental risk  [11]. As described in Figure  1 , this meaningful data can be divided into six groups: • The mesocosm testing information: this group of information includes a general description of the conditions and the design of the experiment, such as the Digital Object Identifier (DOI) of the publication in which the results of the experiment were published, the total duration of the experiment, the type of ecosystem to be studied, the primary and secondary consumers, the benthic and planctonic primary producers representing the food chain of the mimicked ecosystem.
MESOCOSM database development The MESOCOSM database system is implemented using JAVA programming language with MySQL. It has been developed into two levels, the back-end and the front-end layers. The back-end layer consists of the database server implementation, and the front-end layer consists of the graphical user interface. The backend layer was firstly built on an Apache HTTP Server 2. 4. 4. 1 with MySQL server. It was then hosted on an external server to be accessible to all users. The relational database was developed using the Structured Query Language (SQL) through the relational database management MySQL version 8. 0. The interface component (front-end layer) is designed and implemented in JAVA programming language (Java SE 13. 0. 1). It allows users to access and manipulate data and services hosted by MESOCOSM database server.
In addition, a web page has been developed especially for the MESOCOSM database system. This website provides a thorough description of MESOCOSM, its data, structure, some help documents, and links to download its user interface and its source files. This web page is implemented in HTML, CSS, JavaScript, and PHP languages, and is hosted on the GitHub repository. The methodological steps followed during the implementation of the MESOCOSM database system are presented in Figure  2. In the following sections, each part of the methodology is described in detail.
• Step 2: Data integrity and standardization Collected files were pre-processed to ensure their reliability, availability, maintainability, and efficiency. The experts propose a consistent data structure that is as general as possible without losing or affecting the quality of the data. This standard file prescribes the format that the team members must absolutely respect, and by which their collected information can be imported and stored in the MESOCOSM database. Accordingly, raw data collected from analytical instruments are manually processed and organized in this file before being stored in the MESOCOSM database. The standard file mainly focuses on the ENMs properties, environmental exposure and hazard endpoints.
• Step 3: The conceptual data model As illustrated by Figure  3 , the conceptual data model represents the schema of the database, i. e. the most important entities and their relationships. An entity is a real-world object, while a relationship is an association or a dependency between two entities. Based on entity-relationship diagrams, the objective of the conceptual model is to communicate contextual knowledge to any individuals who are unfamiliar to the domain. The conceptual data model presents also some detail about the entities such as their attributes (the properties that characterize an entity set), their cardinality (the relationships between tables), and their constraints (the conditions forced on the columns of the table to meet the data integrity).
• Step 4: The logical data model As opposed to a conceptual data model, which may have very general terms, the logical data model includes a further level of detail, supporting both the architecture of the application and data requirements. It defines the primary keys, foreign keys, alternate keys, and inversion entities of the database. Table  2  presents the optimized logical data model of the MESOCOSM database which consists of nine tables. This logical data model uses indexes (primary keys) and foreign keys to represent data relationships, but these are defined in a generic database context independent of any specific database management system tool. For example, the user number (userID) represents the index of the USERS table and can uniquely identify a user. To distinguish foreign keys, a prefix consists of the sharp sign ( ) is added to the beginning of the attribute(s) that represent(s) them.
MESOCOSM database interface The MESOCOSM user interface allows users to access and add new data in the MESOCOSM database system. This proposed interface provides a logical interface to the MESOCOSM database management  The main classes of our application are: • Users class contains all the users of the application. • Standard user class includes all the activities handled by the internal user, such as Adding / Modifying / Removing / Searching bibliographies, publications, experiments, sampling, and measures. • Administrator class includes all the methods supported by the administrator, such as manage users, bibliographies, publications, affiliations, authors, experiments, sampling, and measures. • Bibliography class contains information on the peer-reviewed publications associated with the data (i.
e. DOI, authors, and affiliation). • Sampling class includes precise measurements on the experimental conditions of the mesocosm experiments (the sampling time, total duration of the experiment, type of ecosystem to be studied), and the physicochemical properties related to their contaminants (their size, surface,. ). • Measures class contains the measurements related to the experiments such as the environmental, exposure and hazard endpoints. The MESOCOSM database management system is accessible via a user interface presented in Figure  5. Using this interface users can have access to the whole or part of the dataset depending on their needs. For instance, in their recent paper Nassar et al. [52]  extracted from the database exposure and hazard data obtained in indoor aquatic mesocosms mimicking a pond ecosystem contaminated to CeO 2 ENMs.
How fair is MESOCOSM ? MESOCOSM was designed from the outset with maximum adherence to the FAIR principles that promote finding, accessing, interoperating, and reusing shared data  [53]. From the beginning, the MESOCOSM database system for environmental nanosafety was designed following the FAIR data vision to optimize environmental exposure data sharing and reuse by humans and machines. The proposed database system considers also the principles of linked data mentioned in the works of Bizer et al. [54, 55]  demonstrating that each entity must be correctly identified with a unique identifier, described in a semantic format, and linked with other resources. The idea from the beginning was to identify all the records with a persistent and unique identifier (PID) so that they can be located unambiguously by machines, and easily findable by humans through the richness of the metadata used to describe them.
Moreover, the database content is registered and archived in different websites (the CEREGE website, GitHub repository 1  , and Perma web archiving service 2  ) so that it can be easily found and accessible. Regardless of what may happen to the original source, the archived record will always be available through the cited websites. Similarly, all datasets have been published and are identified with unique DOI identifiers. To make the MESOCOSM database content interoperable and FAIRness for machines, we have adopted a semantic format, the Resource Description Framework (RDF). This semantic format is used directly as the primary medium for linked data in MESOCOSM. Indeed, all the entities in the database are linked to other resources with permanent unique URI identifiers through an ontology especially designed to support the development of the MESOCOSM database system for environmental nanosafety.
These identifiers can be considered unique across the World Wide Web and therefore provide a solid basis for linking the MESOCOSM datasets. Indeed, each data or entry in the database is associated with an ontological concept that defines its meaning. Indeed, each data or entry in the database is associated with an ontological concept that defines its meaning so that the datasets can be sufficiently understood by humans and can be reused appropriately. In addition, the RDF format makes the MESOCOSM data accessible in the semantic web through the powerful SPARQL query mechanism and rich metadata indexing. The reusability of the MESOCOSM database system is also ensured by the use of an open source license. The default license of MESOCOSM is Creative Commons (CC-BY 4) which allows users to download, modify and reuse the data without restriction, but attribution of the source must accompany the reuse.
Conclusion and perspectives In this paper, we present MESOCOSM, a mesocosm database management system for environmental nanosafety, developed to provide a collection of exposure and impact data to ENMs experimentally measured using aquatic mesocosms. The database can be used in many different applications aiming to assess and predict the ENMs behavior and fate in different ecosystems as well as their potential impacts on the environment at different stages of the nanoproducts lifecycle. The data provided by MESOCOSM will actively participate in optimizing the risk/benefit ratio over the entire life cycle of ENMs, from the manufacture of an industrial product to its end of life, and, therefore support the "safer by design" approach which aims to minimize the environmental exposure or hazards of ENMs.
Currently, all the entries stored in the MESOCOSM are published data obtained in mesocosms by the SERENADE consortium. The MESOCOSM database will be frequently populated with new data obtained in mesocosms facilities provided by groups working on nanosafety (as the CEINT center) but also, with other literature data. Indeed, we are focusing on the exploration and use of text mining techniques for enriching the MESOCOSM database. As such, we already proposed an ontology-based Natural Language Processing (NLP) approach to automatically extract and transfer data from text sources (typically scientific articles and expert reports)  [56]. The proposed system, firstly, exploits the NLP techniques to intelligently analyze textual documents and identify pertinent information from document  [57] , and secondly, uses a domain ontology to semantically classify and categorize the extracted information according to its concepts, thus associating the information with their corresponding attributes within the database.
We demonstrated how the automatic extraction system can extract environmental exposure to ENMs information from text sources, classify them according to the ontology concepts, and automatically enrich the database. This will significantly strengthen the MESOCOSM database by data coming from others groups using other mesocosm designs. Short-term perspectives would be the incorporation of additional user-friendly tools such as data analytics tools based on some innovative algorithms for predicting the potential impact of ENMs on the environmental on the long term or for categorizing the ENMs based on the potential risk for the environment. Based on the relational model of the MESOCOSM database, an ontology is currently under development. This ontology will provide the definition of vocabulary and specifies the meaning (semantics) of the MESOCOSM database entries.
Acknowledgments This work is a contribution to the  Labex Serenade  (No. ANR-11-LABX-0064 ) funded by the " Investissements d'Avenir" French Government program  of the  French National Research Agency (ANR)  through the A  MIDEX  project (No. ANR-11-IDEX-0001-02 ), and a contribution to the European project  NanoInfor-maTIX ,  H2020-NMBPTO-IND-2018-2020-814426. This work is also a contribution to the  OSU-Institut Pythéas. The authors acknowledge the  CNRS  for the funding of the IRP iNOVE, and the  Sustainable Environment Group  of the CEREGE for helpful discussions and valuable feedback.
The inflection point in Fig. 2b (C ) corresponds to a local maxima in restoring force, i. e. between point B and C the force required to decrease the gap distance also decreases with gap distance. At this point (C) the non-linearity between the external acceleration and the proof mass displacement will significantly increase. The concept has been implemented and numerically evaluated in the FEM simulation tool COMSOL. A 2D axisymmetric model is used, with a cylindrical geometry (see Fig. 1 ). The radius of the EMEH in the COM-SOL model is 18. 5 mm and the height is approx. 18 mm (including proof mass displacement). COMSOL modules "Magnetic Fields" and "Electrical Circuit" are used to calculate the magnetic flux, resulting magnetic forces and the EMEH power output over time. An ordinary differential equation (eq.
(  1 )) is used in COMSOL to model the change in air gap distance (or equivalently, proof mass displacement) resulting from an external force (F Ext ), linear spring force (k(βx)) and magnetic force (F mag ). M ẍ + F mag + C ẋ -k(β -x) + F Ext = 0 (1) The velocity and position of the proof mass are denoted as ẋ and x. Mass, mechanical damping and spring coefficient are respectively denoted as M, C and k. F mag is numerically determined by the Magnetic Fields module within COMSOL and includes the effect of electrical damping from the coil and damping from eddy currents in the core. As the spring is assumed to act only in the linear regime, all non-linear characteristics of the EMEH are contained in F mag. The external force is denoted by F Ext. Both a prescribed harmonic force and a stochastic external acceleration have been used (F Ext = Mÿ).
The corresponding free body diagram is shown in Fig. 3. The Electrical Circuit module in COMSOL uses a simple resistive load, matched to the resistance of the coil. Rectification and power storage are not included in the model. The electrical module includes both the resistance and inductance of the coil. The COMSOL model uses event handling to account for collision with a stopper. For simplicity, the collisions are assumed to be completely inelastic. For a stiff stopper this assumption is likely realistic. However, an elastic stopper (or spring) would be preferable in order to preserve and harvest more energy. Magnetic hysteresis is included in the model even though it is neglected in the above concept description. This is a necessary inclusion to be able to compare the COMSOL model with a non-ideal prototype.
The flux guiding core therefore uses a 5-parameter Jiles-Atherton (J-A) model  [25, 26]  for magnetic flux calculations, which includes a hysteretic effect when magnetizing and demagnetizing the core. The J-A model accounts for an impedance to magnetic domain wall movement and rotations, which in turn leads to a hysteretic effect. The considered impedance arises from "pinning sites" in the magnetic material, i. e. areas of decreased permeability for the magnetic domain walls due to imperfections in the magnetic material  [25, 26]. The J-A parameters are defined in Table  2  below. A number of in situ measured vibrational acceleration datasets, acquired in automotive settings, have been available during simulation  [27]. We import a set of measured data to COMSOL and use it to determine F Ext in eq  (1).
The driving current to the shaker is adjusted until a force amplitude of roughly 0. 3 N measured. The EMEH load voltage is continuously sampled at 51. 6 kb/s via a digital-to-analog converter (DAC) using MATLAB software. The load voltage is measured over a 300 Ω resistor (closely matching the measured resistance of the coil used in the lab prototype). The frequency response of the EMEH was measured by sweeping the shaker frequency from 40 Hz to 130 Hz. During the frequency sweep the DAC continuously samples the load voltage with a sampling time of 1 s. The frequency of the signal driving the shaker is not known in the DAC sampling software and must be extrapolated from measured data. MATLAB is used to extract the load voltage RMS value and frequency for each time-resolved data set. The frequency corresponding to each data set is determined from the frequency spectra of the data set.
Built in MATLAB functions for the Fast Fourier Transform (FFT) are used to generate the spectra. The frequency of the measured data set is then taken to be the largest component in the frequency spectrum for the data set. A separate test-rig was built to measure the gap force for varying gap distance (Fig. 7b ). From the diagram in Fig. 6 , only the magnet and core components were used. The spring is not included and thus only the force resulting from magnetic flux in the air gap is measured. Magnet and one core component were mounted statically. The second core component was mounted on a rod passing through the center of the magnet and resting on a vertically adjustable base. The force was measured by placing a FlexiForce TM sensor between rod and base. A second rod was used to limit horizontal movement with minimal friction.
A set of power spectra were acquired with varying spring offset β (in the case of the measurement setup, the position of the offset plate, see Fig. 6 , was varied and measured). The hysteresis is the same as shown in Fig. 8. Fig. 9  shows the set of simulated power and the measured power. Due to the limited precision of the spring offset in the measurement prototype (0. 1 mm) we could not match exactly the spring offset used in simulation. The applied force amplitude used in the simulations is 0. 3 N and is measured to be approximately the same in the lab. The minimum spring offset used in the lab measurements is 1. 95 mm. At 1. 85 mm the EH would get stuck in a closed state (as described in Section 2. 2). Both measured and simulated data follow the same pattern for increasing spring offset, i.
3 N. For a given excitation force there is likely an optimum spring offset and vice versa. The shaker will experience some force feedback from the EMEH. How the shaker responds to this has not been accounted for in the The spring offset used in measurements is set to match the simulation model parameters as closely as possible. The full set of model parameters values are found in Table  1  and Table  3. In both simulation and lab prototype, a further decrease in spring offset put the system in a permanently closed state. (For interpretation of the references to colour in this figure legend, the reader is referred to the web version of this article. ) measured dataset above. The relationship between spring offset and resonance frequency of the EMEH (with a resistive load only) has not been rigorously established in this work.
For instance, Overbeck et al. [1]  present a system for capturing and rendering light field image datasets at VR-compatible speeds, demonstrating its view-dependent capabilities on several sample scenes and sharing the results by way of a complementary VR application. Similarly, de Dinechin and Paljic  [6]  present an open-source toolkit and interface for transforming photographs into virtual environments that can be rendered with view-dependent highlights in VR. As another example, Broxton et al. [5]  also demonstrate that these approaches can also be extended to dynamic scenes, using a hemispherical setup to capture light field videos that they then render using a deep learning network.
Therefore, we selected as a practical backdrop for our study the recreation of a mineralogy collection in VR. We thus partnered with the MINES ParisTech Mineralogy Museum in order to capture the data required for our study, and were thereby kindly given access to the museum to take photographs of the main gallery using our capture rig. The museum staff also provided us with photographs of individual minerals in the collection, based on which we created 3D replicas of these items.
Hardware Setup For reasons of availability, size, weight, cost, and ease of use, we chose to build the system using 40 Raspberry Pi portable computers connected to the corresponding 8 Megapixel v2 camera modules. To simulate different possible camera layouts using these modules, we then virtually captured sample 3D scenes in the Unity game engine using various outside-in and inside-out setups, taking into account the fields of view of our selected cameras. We then led alignment and reconstruction tests in Reality Capture, a commercial photogrammetry software, to rapidly evaluate each design based on the quality and completeness of the reconstructed 3D models. As a result of this virtual prototyping phase, we ultimately selected a layout with 5 circular levels of 8 outward-facing cameras arranged in a uniform manner.
Software Implementation We decided to use a fixed addressing of cameras to get information on the location of each camera taking the photographs. We thus defined an address nomenclature and reserved the corresponding IP addresses in the router: level 1 was 192. 168. 0. 11x, level 2 was 192. 168. 0. 12x, and so on, the last digit being the camera index on the corresponding level. Each Raspberry Pi ran a Python backend, including a TCP/IP server that waits for incoming commands to set the white balance and shutter time. This server also enables launching the capture, with the image data then being transferred over the same network TCP/IP connection. A semi-automatic procedure was developed that allowed the easy installation of a fresh Raspberry Pi running Raspbian, in command line and over the network (SSH), with minimum manual intervention.
We developed the remote/client software in Unity, and tested it on both Windows and Mac OS X. The remote software implements 40 TCP/IP clients and displays a user interface allowing the operator to set capture parameters and remotely trigger cameras in synchronization. After the capture process is launched, the images are gradually displayed side-by-side on the screen for easy monitoring. Each image is then saved on disk with a file naming nomenclature that includes a timestamp and a camera index. Launching this process via WiFi allows the user to carry the laptop during capture, so as to be able to move outside of the rig's field of view.