dataesr/scientific-paragraphs-categorization huggingface dataset:
This paper describes the process we followed and how we structured the plan. large-scale facility repositories for synchrotron data, and the project partners' repositories for electrochemical measurements. Gradually, as the BIG-MAP infrastructure develops, the data will also be made available for the project partners via this shared infrastructure. This article comprises four main parts: i) an overview of BIG-MAP and its link with the BATTERY 2030+ family of European battery projects, ii) the strategy and process we have followed when working out the DMP, iii) an overall description of the research data generated in the project and iv) a description of how the project methodologies and open-data policy facilitate the storage of data of high FAIR-ness. The detailed description of the data generated within each work package (WP) is reported in the Supplementary Information (SI).
All these should be open and accessible for reuse well beyond the duration of the specific project, if there is no passable reason for restricting the openness. With the integration of automated workflows  [1] [2] [3]  and Artificial Intelligence (AI) in our everyday research,  4  streamlined access to data becomes even more needed than before as AI models depend on the availability of large quantities of scientific data typically not found in a single publication, a single dataset or produced by an individual research group or institution. In support of this trend, several databases designed for curation and easy sharing of experimental and computational research data have been established. Examples from the world of materials research are: Inorganic Crystal Structure Database (ICSD),  5  Springer Materials,  6  the Cambridge Crystallographic Data Centre, 7 Materials Project, 8,9 Materials Cloud,  10  Open Quantum Materials Database (OQMD), 11 the AFLOW consortium, 12 the Open Materials Database,  13  and the Novel Materials Discovery Laboratory (NOMAD).
14 Another initiative designed for increasing awareness on research data (store, share, reuse), which is requested by many grant authorities and academic institutions, is the mandatory submission of a Data Management Plan (DMP). An example is the European Commission, who requests submission of a DMP within the first six months for their ERC (European Research Council) and H2020 projects. The purpose of the DMP is to promote curation, storage, and sharing of the generated data by describing the research data generated within the project, by stating for whom these data might be useful and by unfolding how the project ensures that the storing, sharing, publication and preservation of the generated data comply with the FAIR (Findable, Accessible, Interoperable, Reusable) principles  15  to the greatest possible extent.
To achieve this goal, it is necessary to develop a modular, closed-loop platform able to bridge physical insights and data-driven approaches. The BIG-MAP strategy is to cohesively integrate machine learning, computer simulations and AI-orchestrated experiments covering materials synthesis plus characterization and testing of materials and components, in order to accelerate the discovery and optimisation of battery materials. Optimal utilization of research data is crucial for achieving this goal and, in broader terms, to set a standard for future large-scale, data-centric projects aiming at accelerated discovery of materials for use in clean-energy technologies. Pivotal for this is the implementation of the BIG-MAP shared infrastructure, designed to support interoperability of the generated data, the BIG-MAP code repository 18 for shared development of computational tools and the BIG-MAP App Store 19 designed for easy public access to user-friendly versions of the developed tools.
Following a chemistry neutral approach, BATTERY 2030+ and its member projects aim at "reinventing the way we invent batteries" by generating a toolbox of versatile infrastructures, common data frameworks and transferable knowledge that can be translated into design principles for discovering and developing new battery materials, as described in the BATTERY 2030+ Roadmap. 25 The vision of BIG-MAP is fully aligned with the goals of BATTERY 2030+. BIG-MAP focuses specifically on the challenge of accelerating the discovery of new battery materials and interfaces that can only be achieved by understanding and predicting how the battery interfaces evolve in time and space, which is a theme shared by all projects under the BATTERY 2030+ umbrella. In BIG-MAP, this will be achieved by creating an autonomous infrastructure able to design, synthesize, and test new materials across all domains of the battery development cycle, as well as orchestrate experiments and simulations on-the-fly.
Our strategy and process for working out an operational and consistent DMP Our ambition has been to layout a DMP that serves multiple purposes: -An operational tool promoting the interaction and flow of data between the 10 scientific WPs of the project. -A practical guide for the project partners for how to fulfil the obligation set by the H2020 Open Research Data Pilot. -A demonstrator for how a DMP can facilitate active interaction with related R&D projects, here with the BATTERY 2030+ projects as a case. We have chosen to work out the DMP in a collaborative effort crossing the entire project. The template we used follows to a large extent the standard DMP template for H2020 projects. This consists of two sections: a data summary describing the generated data and the FAIR section describing the incentives taken for making the data FAIR.
The DMP Data Summary and the Highway of Data The research data generated in BIG-MAP is essential for creating a modular platform that future large-scale battery projects can build upon. The data originate from multiple sources: from physical experiments, simulations, and artificial intelligence. The data comes in many different forms: data can be processed or unprocessed, and data can be structured (e. g. , files holding labelled rows and columns with numbers) but also unstructured (e. g. , models, metadata, code, documents in natural language). Efficient exploitation of such heterogeneous datasets calls for the project-wide guidelines for generating, storing and querying of data described in a DMP. BIG-MAP is organized in one management work package (WP1) and ten scientific work packages, spanning from the generation of data describing battery materials by means of computational methods and experiments (WP2-WP6), to the design and development of data management tools facilitating data exchange within the WPs (WP7, WP8, WP9), and to the development of AI-accelerated materials discovery and deep learning models for inverse materials design (WP10-WP11), trained using the data generated in WP2-WP6.
An outline of the generation and flow of research data within the project is shown in Fig. 1. The starting point of the work is the knowledge and data already generated by the project partners combined with any relevant open data, i. e. data available in the research literature and in public repositories, e. g. topical repositories such as Inorganic Crystal Structure Database (ICSD), 5 Materials Cloud, 10 Materials Project, 8,9 and the Computational Materials Repository, 26 as well as general purpose repositories such as GitHub, Zenodo and FigShare. Following the flow of the data within the project is crucial. This does not only allow keeping track of how the work progresses, but also minimizes redundant research activities and, when needed, enables requests for new data across the WPs. Fig.
2  shows the data and information flow in the project in more details than Fig. 1. The developed infrastructure (WP9) is the hub that will ensure interoperable communication and transfer of data across the project. Included in the infrastructure will be a shared data storage and processing facility accessible for all BIG-MAP partners. The infrastructure will manage automated requests for data across the project, typically requests from AI-based models (WP10-11) for new data and the reporting back of the requested data to the models. The infrastructure will also include apps that can perform autonomously analyses of datasets on-the-fly, e. g. , for spectroscopic or structural datasets. The tools supporting interoperability of the data and automation of the request-replay system are the battery interface ontology BattINFO (WP7) and the standards and protocols for data acquisition, for data processing and for reporting data and metadata (WP8).
FAIR-ification of the BIG-MAP Data In addition to the description of the generated research data given in the Data Summary section, the DMP shall also describe how the project ensures that the generated research data is FAIR, and thereby giving the highest possible value for use within the project and reuse outside the project. BIG-MAP is part of the H2020 Open Research Data Pilot Programme of the European Commission. This programme provides Guidelines for FAIR Data Management, which serve therefore as guidelines for BIG-MAP's handling of data. BIG-MAP will utilize the Open Research Data Pilot opening for restricting the access to specific data. For BIG-MAP this applies for specific data underpinning business secrets, data for which disclosure can obstruct protection of intellectual property, data collected from propriety databases and some data generated by propriety software.
Transfer to the shared storage facility shall happen as soon as practically possible after data generation. The basic data shall appear findable, accessible, interoperable and reusable for the project partners as soon as it becomes available via the consortium-wide storage facility. This serves as a test in a restricted forum of how FAIR the data is. Passing the test means that the datasets and their documentation are in form that allows them to be indexed in a data repository and subsequently published provided that there are no restrictions on the data openness. An exception from this standard data handling procedure applies for datasets generated at large-scale synchrotron or neutron facilities, as such datasets are typically in the TB scale. Due to their size, such data will remain in their raw form in the repositories of large-scale facilities, and only processed datasets of manageable size will be transferred from there and made directly available for a broader audience.
The preferred site for publishing basic data will be repositories that are recognized within the battery research community, e. g. , the ones from which BIG-MAP also harvests open data, and the institutional data repositories of the partners. All basic data shall, to the largest degree possible, be made available in open, non-propriety formats. The software used should ideally be open source. If not possible, the software and tools needed for accessing the data shall be named. Published data shall be licensed in the least restrictive manner, e. g. , Creative Commons Attribution (CC BY 4. 0). Upon publication a persistent identifier (a DOI or handle) is assigned to the dataset. In addition to the basic data, computational tools supporting the development of novel battery chemistries are highly valuable research outputs.
e. , apps, via standard web browsers, and the apps are equipped with APIs (Application Programming Interfaces) allowing software-independent communication and usage of the app, see Fig. 3. The App Store is interlinked with both the BIG-MAP GitHub organization where the related source codes are deposited and with data storage facilities (the shared BIG-MAP data storage and public repositories) where the code/apps can access the data needed for performing their tasks. This architecture ensures maximum exploitation of all datasets, while complying with the legal constraints attached to the use of sensitive data.
Conclusions In this work, we have highlighted the importance of data management in large and multi-domain datacentric research projects, where interoperability of data is fundamental for connecting many different tasks reliant on effective interactions between WPs and scientific disciplines. Our take-home message is that a well worked-through DMP, holding concrete information on how to structure and handle the data, will serve as a valuable tool for guiding the project work towards trustworthy data that can be readily accessed and used also from outside the project. Another important point is that it takes efforts to concisely describe the data generated in large multi-disciplinary projects like BIG-MAP, however the effort pays back as a clear picture of how the many different datasets generated can and shall play together for maximizing the project output.
This is not only valuable for managing the project, but also for providing a map that will give the project members an understanding of how their data fits into to the overall puzzle -an understanding that is essential for targeting the data generation to the precise need of the destination WPs. We have also learned that the process used for working out the DMP is important. By working out the plan in a collaborative effort crossing the entire project, the DMP will appear not only as a document describing the generated data and how these are stored, documented and shared, but will also appear as an effective tool for planning and execution of the project and for keeping track of the work done by various partners in different WPs and their role within the overall project. The collaborative process itself is also important, as it raises the awareness in the team members of consistent data management and facilitates the project development of methodologies that support FAIR data handling.
The DMP is thus a living document, which will evolve during the project and be constantly updated. In this respect, the DMP will benefit from a deeper use of the developed ontology, from the general implementation, which would help in better organizing the data tables into more operational categories, to the tools, such as Protégé, 29 which will contribute to visualize the connections between data in a more dynamic way. With these updates, we aim at increasing the connectivity between the data, not only of the BIG-MAP project, but, more ambitiously, among the whole BATTERY 2030+ community, establishing for the first time a common platform for sharing battery data. Thanks to its connection with the BATTERY 2030+ initiative, BIG-MAP is defining new standards for data management across the whole battery community.
BIG-MAP's overall data structure The multi-disciplinarity of the BIG-MAP project makes research data one of its central components. The generated research data is essential for creating a platform that future large-scale battery projects can build upon. This might be projects targeted at discovery and optimization of new battery materials and battery technologies, projects within the BATTERY 2030+ family and projects serving the European battery community. BIG-MAP's research data is generated from different sources (multi-sourced): experiments, simulations, testing and artificial intelligence and comes in many different forms: files holding rows and columns with numbers, i. e. what we normally consider as data, but also in the forms of models, code, scripts, samples, etc. The priming and aggregation of data into a larger interoperable datasets and the flow of data between the work packages (WPs) are fundamental for the success of the project.
Such data, in particular from lower scales (atomistic, electronic structure) is then passed to higher scales or vice versa. This data is reported in tables below with the tag (intermediate data in the column datasets) and is not the primary output of the workflow, but required for completeness, according to our data standards. Types and formats of the data that will be generated by WP3 are shown in Table  WP  1. 4. The flow of data between WP3 and its tasks and to the other WPs is shown in.
Explain the relation to the objectives of the project The ontology will be used to support the interoperability of data across multiple scales, techniques, and domains in the battery discovery process. Applying the ontology will help BIG-MAP create a database utilizing a descriptive, formalized scheme to improve the reproducibility of experiments and simulations. From D7. 1: BIG-MAP links together the main European actors contributing to the development of new battery materials. This include both experimental and theoretical actors working at many different scales, from electronic via atomistic and discrete mesoscopic to continuum scale. To support the efficient reuse and interoperability of research data between all these actors, it is essential to have a common way to describe the real world entities constituting batteries and their interfaces, their associated physical properties, and how these properties are measured and/or modelled.
This common representational framework should be easy to read and understand by humans. At the same time, it must be highly formalized and accurate to be consumed by machines supporting flexible automated workflows that connect different domains and provide rich content to descriptors used for artificial intelligence. Another application of such a common representational framework is to enable semantic search across multiple databases. The battery interface ontology will serve exactly this purpose of being a highly formalized common language for describing battery interfaces. BattINFO will rely on other WPs to provide domain knowledge that will be incorporated into the ontology (e. g. by filling out questionnaires, tables, process diagrams, etc. ). BattINFO can then be utilized by users and AI platforms in BIG-MAP to identify data links and support interoperability.
Specify the types and formats of data generated/collected The developments within WP9 will be essentially delivered as workflow algorithms (Python code managing data generation/flow), apps (Jupyter Notebooks rendering interactive graphical user interfaces) and infrastructural software (code managing the deployment of the infrastructure in servers and databases). These are summarized in Table  WP  1. 23. 1. 9. 5 Specify the origin of the data WP2 will primarily generate atomic-scale and spectroscopic (computational) data, while WP3 is concerned with multi-scale modelling. Both WPs will be heavily reliant on infrastructure and interoperability formats from this WP. WP5 is primarily experimental in nature and will also depend on this WP for providing solutions and standards on how to couple experimental data and simulation, while WP4 and WP6 would be able to access and handshake with data and workflows produced.
As outlined in the Table above, some of the simulations in other work packages will be managed using AiiDA (Automated Interactive Infrastructure and Database for Computational Science), a python framework for high throughput calculations and provenance tracking (www. aiida. net). AiiDA automatically stores all information required to reproduce the result of each calculation. On the output side, AiiDA is designed to strike a balance between the cost of storage and the cost of recomputing a piece of data. For example, by default in a SCF calculation quantities like total energies, electronic band structures and log files are stored, while Kohn-Sham wave functions and charge densities are not. Before submitting a calculation through AiiDA, all inputs (+ metadata) are automatically stored in a local database.
Development and validation of multiscale modelling frameworks (PDT, DTU, UU, KIT, CNRS, CEA, NIC, CNR, CID, FZJ): electronic structure method, atomistic modelling, coarse grained & mesoscopic models, continuum models, PxD, workflow systems (AiiDA, ASE, Simstack) Verification and validation of scale-bridging protocols for SEI/CEI (ALL): workflows developed in task 3. AI enhanced models (KIT, DTU, UU, CNRS, CEA, PDT): AI-frameworks, workflows developed in task 3. 1 and 3. Verification and validation of models for HTS experiments (WWU, DTU, NIC, KIT, SAFT): workflows developed in Task 3. 1 and 3. 2, ontologies, databases, access protocol to robotic experiments Task 3. 5: Workflow demonstrators (KIT, DTU, UU, CNRS, NIC, PDT, CNR, CID, FZJ), AiiDA, ASE, Simstack): workflows developed in Task 3.
Acknowledgements This project has received funding from the  European Union 's  Horizon 2020 research and innovation programme  under grants agreement No  957189  ( BIG-MAP ) and No  957213  ( BATTERY 2030+ ). Sandrine Lyonnard would like to acknowledge Poul Norby,  Aleksandar Matic ,  Marnix Wagemaker ,  Ennio Capria ,  Duncan Atkins , and  Stéphanie Belin  for the fruitful discussions during the preparation of the section describing WP5.
Task 3. 1 :Task 3. 2 : 1 Task 3. 3 : 2 Task 3. 4 : 2 1. 3. 6 3132133234236 Development and validation of multiscale modelling frameworks (PDT, DTU, UU, KIT, CNRS, CEA, NIC, CNR, CID, FZJ): electronic structure method, atomistic modelling, coarse grained & mesoscopic models, continuum models, PxD, workflow systems (AiiDA, ASE, Simstack) Verification and validation of scale-bridging protocols for SEI/CEI (ALL): workflows developed in task 3. AI enhanced models (KIT, DTU, UU, CNRS, CEA, PDT): AI-frameworks, workflows developed in task 3. 1 and 3. Verification and validation of models for HTS experiments (WWU, DTU, NIC, KIT, SAFT): workflows developed in Task 3. 1 and 3. 2, ontologies, databases, access protocol to robotic experiments Task 3. 5: Workflow demonstrators (KIT, DTU, UU, CNRS, NIC, PDT, CNR, CID, FZJ), AiiDA, ASE, Simstack): workflows developed in Task 3.
2. WP2 will collect data to the following WPs. ML models exploration 1. 2. 4 Specify type Tarball As above Suggested format As above size MB WP3 WP WP4 WP3 Top-down data and knowledge What Experimental data (materials, input parameters for models) Parameters from structural Atomic-scale structures, energetics and transport coefficients required for bottom-up multiscale models Decomposition rates, and more pathways and reaction Multiscale modelling Model refinement and validation Usable for Model refinement and validation Model refinement, files can be created with post-processed data and parameters of interest As above Tarball. tar. gz (with Suggested type format databases and reproducible-data sheets) GB As above MB of interest files can. tar. gz (with be created databases with post-parameters data sheets) data and reproducible-processed and size GB and chemical Computational cross-analysis, WP5 characterizations at the local predictions for validation, and design As above As above MB Datatype scale, including e.
the data utility: to whom will it be useful - Curated reference data for repositories or interactive databases. Useful for the consortium and wider. - New interatomic potentials. Useful for wide modelling communities. - Alchemical data sets. Useful for the consortium and wider. - MD trajectories. Useful for the consortium and wider. - Property and spectral predictions. Useful for wide experimental and computational communities. - Computational protocols and workflows. Useful for wide modelling communities. Table WP 1. 1). 1. 2. 7 Outline.
(Engines): LAMMPS, SCM, SCIPY, NUMPY, MATLAB, in More details about the workflows and calculation platforms mentioned in the table above can be found in Description Data sets Type Format Size Computational protocols for workflows and data access AiiDA, ASE, CLEASE and SimStack Apps and their components Uncompres sed raw data GitHub MB Description of the meso-structure of electrodes Trajectories, structures, engines: LAMMPS, LIGGGTHS Structure, energies, wave function, electronic properties, spectra Intermediate Data in Workflows sed raw data, tarball, database. tar,gz. Databas e TB Structures, energies, trajectories, spectra Intermediate Data in Workflows Uncompres sed raw data, tarball, Curated data Access protocols, ontology components Database, semantic access, web Text GB Force field models for battery materials and compositions SOAP/ACE + GAP Parameters Uncompres sed raw data, tarball Databas (i.