dataesr/scientific-paragraphs-categorization huggingface dataset:
VIII. MODERN SOFTWARE ENGINEERING PRACTICES In this section, we describe a number of modern software engineering practices that are now part of the de- The provenance graph automatically generated by AiiDA when running a Wannier90 calculation for a diamond crystal using Quantum ESPRESSO as the DFT code. Rectangles represent executions of calculations, ellipses represent data nodes, and diamonds are code executables. Graph edges connect calculations to their inputs and outputs. In particular, the following calculations are visible: Quantum ESPRESSO pw. x SCF (dark blue) and NSCF (green), Quantum ESPRESSO pw2wannier90. x (brown), and Wannier90 pre-processing (yellow) and minimisation run (purple). The initial diamond structure (light blue) and the final interpolated band structure (dark grey) are also highlighted.
Second, nightly automatic tests are run on a Buildbot test-farm. The test-farm compiles and runs the code with a combination of compilers and libraries (current compilers include GFortran v6. 4. 0 and v7. 3. 0, Intel Fortran Compiler v17 and v18, and PGI compiler v18. 05; current MPI libraries include Open MPI v1. 10. 7 and v3. 1. 3, Intel MPI v17 and MVAPICH v2. 3b). This ensures that the code runs correctly on various highperformance computer (HPC) architectures. More information on the test-farm can be found on the Wannier90 GitHub wiki website. 113 n addition to these tests, we have implemented git pre-commit hooks to help keep the same code style in all source files. The current pre-commit hooks run Patrick Seewald's Fortran source code formatter fprettify 114 to remove trailing whitespaces at the end of a line and to enforce a consistent indentation style.
ACKNOWLEDGMENTS We acknowledge code contributions by  Daniel Aberg  (w90pov code),  Lampros Andrinopoulos  (w90vdw code),  Pablo Aguado Puente  (gyrotropic. F90 module),  Raffaello Bianco  (k-slice plotting),  Marco Buongiorno Nardelli  (dosqc v1. 0 subroutines upon which some of transport. F90 is based),  Stefano de Gironcoli  (pw2wannier90. xinterface to Quantum ESPRESSO),  Pablo Garcia Fernandez  (matrix elements of the position operator),  Nicholas Hine  (w90vdw code),  Young-Su Lee  (specialised Γ-point routines and transport),  Antoine Levitt  (preconditioning),  Graham Lopez  (extension of pw2wannier90. xto add terms needed for orbital magnetisation),  Radu Miron  (constrained centres),  Nicolas Poilvert  (transport routines),  Michel Posternak  (original plotting routines),  Rei Sakuma  (symmetry-adapted Wannier functions),  Gabriele Sclauzero  (disentanglement in spheres in k-space),  Matthew Shelley  (transport routines),  Christian Stieger  (routine to print the U matrices),  David Strubbe  (various bug fixes and improvements),  Timo Thonhauser  (extension of pw2wannier90.
Code 'wannier90. x' v3. 0 Wannier90Calculation Wannier90 (pre-processing) code Wannier90Calculation Wannier90 (main run) code SinglefileData. nnkp file Code 'pw2wannier90. x' v6. 3 code ParameterData parameters ParameterData parameters KpointsData Kpoints mesh: 4x4x4 kpoints ParameterData kpoint_path List projections Code 'pw. x' v6. 3 code code parent_calc_folder.
However, deleting the raw recordings eliminates the possibility of checking that the automatically generated data accurately capture the constructs of interest (e. g. ,  Weisleder & Fernald, 2013 ) and significantly limits the potential for future analyses. Similarly complex issues arise when deciding what type(s) of data will be extracted from the recordings, the constructs that will be analyzed, and the type(s) of data that will be shared with other researchers for purposes of verification or secondary analyses. In the sections below, we outline both benefits and risks from research with longform recordings with the goal of helping researchers approach these decisions. We anticipate benefits from this type of research at the level of individual participants and communities, individual researchers, and the scientific community.
Benefits to participants and communities Analyses of large-scale databases of audio recordings may permit a deeper understanding of what is effective in promoting better health and mental health outcomes across populations, with ensuing benefits for participants and communities. For example, in the area of language development, longform audio recordings have the potential to revolutionize public health approaches to promoting language and literacy in young children by providing quantitative measures of children's language environments that can be used both as feedback to caregivers and as a measure of the efficacy of various interventions  (Zhang et al. , 2015; Ferjan Ramirez et al. , 2018; Leung, Hernandez & Suskind, 2019). Parents in the United States report that receiving a variety of feedback from ambulatory recordings -from parenting advice to deviant behaviors -would increase their reported willingness to participate in mobile-sensing studies  (Levin, Egger, Johnson & de Barbaro, 2019) , suggesting this type of feedback is valued among U.
g. , moving institutions) or after researcher retirement. Furthermore, collaboration in research groups does not require that members openly share all of their longform recordings. For example, a recent multi-lab collaboration involved the large-scale annotation of small clips (~400 milliseconds extracted from day-long recordings) by citizen scientists  (Cychosz et al. , 2019). Through the collaboration, large amounts of data from diverse groups were included in the analysis. But the annotation methodology also protected participant privacy and confidentiality since the audio clips were so short. This is one example of collaborative data sharing that protects participants and does not involve sharing entire recordings. For the larger scientific community, research initiatives will be facilitated by the collection and analysis of larger samples that originate from diverse populations.
For example, research on highly sensitive topics such as drug use or crime often uses anonymous surveys to ensure that compromising information cannot be linked back to individual participants, thus minimizing any potential harm from sharing this information. At the other end, language acquisition researchers have created shared databases of audio and video corpora in which individuals are identifiable (e. g. , CHILDES, Databrary), but which typically showcase interactions that are relatively constrained and considered to be harmless (e. g. , video recordings of parent-child play), and thus carry minimal risk to participants. A recent survey of parents' willingness to collect and share mobile-sensing data of children's daily experiences showed that a representative sample of U. S. parents queried in 2018 (N = 210) were less comfortable collecting audio (and video) data than they were collecting motion and heart rate data when provided with a brief study description.
g. , YouTube, SoundCloud) from which the person can be uniquely identified. This means that for most research participants, the likelihood of identification through voice data alone is extremely low. However, the anonymity of voice recordings cannot be completely guaranteed. First, there is a possibility that the risk of identification will change in the future. For example, it is not impossible that a database of voice recordings (e. g. , collected via commercially available smart speakers) could be paired with identifying information (participant names) which could be used to "fingerprint" individuals. While we are unaware whether such a database exists at a truly large scale, using voice to uniquely identify a speaker appears technically feasible. Second, even if a given participant is not known by the research team collecting the data, they could ostensibly be known to researchers with access to the data in the future.
One future possibility for intelligently limiting identifiable data is combining algorithms that automatically detect the events or behaviors of interest and then launch recordings for short windows. After data collection, researchers can take several steps to remove/mask sensitive and identifying information from longform audio recordings. A first step that many researchers take is to vet the recordings, especially prior to sharing (semi-)publicly. A guide for vetting longform recordings can be found among the HomeBank Project's Resources (https://homebank. talkbank. org/; VanDam et al. , 2018). This cursory listen to a recording could involve flagging inappropriate language or elements of the recording that the participant would likely not want to be publicly released or, in the case of a child, might find embarrassing at a later date (e.
There are numerous options available for storage and sharing of data in various forms. Below is a partial list of repositories that are particularly well-suited for longform audio recordings. Databrary (https://nyu. databrary. org). Databrary is a data repository for developmental research geared primarily toward video footage, but which can also be used for audio-only recordings. At the time of writing, it is not well-designed for easy interfacing with batch usage of a large number of files, but it is well-designed for smaller-scale projects and includes embedded structure for participant and file metadata. Databrary requires an institution-to-institution legal contract. Once this is in place, authorized investigators can add research assistants as "affiliates" and manage different levels of access for affiliates and collaborators.
There are multiple levels of access available for data sharing. At the time of writing, these include "private" (shared only within the lab -a good option for long-term storage of highly sensitive files or short-term storage of unvetted files that may be released to a larger audience at a later stage), "authorized users" (available to all authorized Databrary users, but may not be further distributed), "learning audiences" (available to authorized Databrary users and brief sections may be used for illustration purposes -note that this may include redistribution in public forums), or fully public. HomeBank (https://homebank. talkbank. org/). HomeBank is a member of the TalkBank system. Contributors and users must have ethics training to apply for membership. After completing a brief phone interview, a contract is signed specifying terms of use.
HomeBank was originally designed specifically for longform child language audio recordings and contains audio files, derivative data files, and transcripts, but could be extended to similar data sets centered on adult participants. At the time of writing, corpora may be shared according to four levels of access: fully public, members-only, secure (which requires additional approval, for more sensitive corpora), and embargoed (temporarily unavailable to all researchers outside of the primary team). Additional restrictions on use may be specified by the data contributor. Institution-specific repositories. Many institutions now provide their own resources for data storage and sharing that may be used for longform audio recordings, sometimes through existing systems such as Dataverse  (Castro & Garnett, 2014).
These will often have different levels of sharing suitable for sensitive and confidential files. Institution-specific repositories may also be ideal for promoting connections with speech communities interested in documenting/revitalizing their language(s) (e. g. ,  AILLA, 2017; CLA, 2018). However, some institutional repositories may not have the user-vetting functions available through systems like Databrary or HomeBank. Longform audio recordings present unique challenges for obtaining informed consent. Following the principle of autonomy, participants need to understand what the recorders can capture as well as the myriad ways that the data can be used. Table  3  provides a summary of information that should be communicated to participants during the informed consent process. This includes details about the length and scope of the recording, the way in which the recording will be processed, and the types of data that will be extracted and analyzed (as overviewed in Fig.
Generally speaking, end-user applications, including IIoT applications, are provisioned in cloud settings using PaaS and offered as SaaS. The provisioning process consists of three phases: (a) Developing the end-user application sources; (b) deploying them on PaaS resources; and (c) managing (including executing) the applications to optimize its performance and the resources usage  [4]. Specifically, the PaaS provides the services that offer the resources needed to provision consumer-created or acquired applications implemented using programming languages, libraries and tools supported by its provider  [3]. These resources are deployed in the underlying IaaS. The interaction between the PaaS and IaaS is enabled through well-defined interfaces. Specifically, a PaaS abstracts the IaaS resources and offer a re-usable framework, which provides application platform components as-a-Service.
Examples of components are containers and DataBase Management Systems (DBMS). Containers are the service engines necessary for applications hosting and execution. DBMS handle and manage persistent data. An example of PaaS is Cloud Foundry(www. cloudfoundry. org). With Cloud Foundry, the applications could be implemented, for instance, with Java programming language, Java Spring library and services integration tools. The interactions between Cloud Foundry and IaaS could be done via Amazon Web Services (AWS). This manuscript is devoted to the PaaS for IIoT applications provisioning. It identifies evaluation criteria and rely on them to review and evaluate the proposed IIoT PaaS architectures in the relevant literature. It also discusses the research directions. The reader should note that this manuscript exclusively surveys IIoT PaaS architectures and excludes the regular IoT PaaS from its scope.
This explains why emerging IoT PaaS solutions (e. g. , Microsoft Azure IoT Suite, Google IoT Platform, IBM Watson IoT Platform, AWS IoT Platform and Cisco IoT Cloud Connect) are seldom used to host and execute IIoT applications. The suitable architectures for IIoT PaaS are still in their early development stages. In the literature, there are several papers that surveys the IoT cloud platforms (e. g. , see  [5] [6] [7] [8] [9] ). This manuscript exclusively surveys the literature on PaaS architectures for industrial Internet. It relies on a set of IIoT use cases and PaaS reference architecture to derive the evaluation criteria. The existing IIoT PaaS are reviewed and evaluated in the light of these criteria. The next section introduces IIoT use cases and derives architectural requirements for IIoT PaaS with respect to the PaaS reference architecture.
According to the authors, the control of the application is the process of activating and managing the PaaS resources it uses, such as security and scalability management, and the data it generates in the context of the virtual solution that it belongs to. End-user applications control is ensured by the "application context management" module. This module interacts with the objects through "gateways" and "mediators". The "gateways" allow for providing the drivers and protocol stacks for the communications with the objects. The "mediators" domain mediates the interfaces between different gateways in the same application domain to cover the diversity of all domain-specific data models. For the end-user application deployment (including driver installation and gateway configuration), the same authors propose in  [16]  to extend Topology and Orchestration Specification for Cloud Applications (TOSCA) specifications in order to support IoT end-user applications deployment and management in the same PaaS.
Services Compositions Approach In  [27] , the authors propose an open source PaaS for smart city end-user applications. The PaaS is designed as part of the COMPOSE EU FP7 project(https://compose-project. eu/) and provides features to discover and compose tools and services in order to build and deploy end-user applications upstream smart objects. The architecture of the COMPOSE PaaS consists of a marketplace, a runtime engine and an ingestion layer. The marketplace provides graphical user interfaces for developers to operate the reusable services. It allows to develop applications through IoT workflows and libraries by specifying the appropriate services discoverable from the PaaS. The services that are not supported by the PaaS can be provided and published by the developers. The runtime engine is the component that is responsible for deploying the end-user applications.
COMPOSE PaaS meets the requirement concerning the support of heterogeneous IoT applications(R1). Any IoT application could be modeled with elementary services that are composed together to implement the end-to-end target application. This work does not meet the requirement concerning the interaction with fog layer (R2). Similarly, it does not meet the requirement concerning the federation with other IoT clouds (R3). Indeed, COMPOSE PaaS is strongly coupled and designed to only communicate with COMPOSE infrastructure. This work meets the requirement concerning the control and security support (R4). Security modules, when required, can be provided by developers and published by COMPOSE through its marketplace to be used with IoT applications. This work meets the requirement concerning the support of the whole spectrum of IoT devices (R5).
The main components of this framework are the file repository, database module, resource configuration module and service module. The file repository is based on distributed Hadoop server to handle unstructured data. The authors extend Hadoop by adding the isolation of tenant's data support and enhance its performance by improving the file repository's ability to handle small files. The database module manages the structured data and aggregates several SQL and NoSQL database sources. The aggregation is performed through unified API and object-entity mapping for multiple databases. This considerably simplifies the development of data access modules and data exchanges for the end-user applications. The resources configuration module ensures the data management in terms of a predefined meta-model.
These services are accessed via the DAvinCi Server, which uses the distributed Robotic Operating system (ROS) as the messaging framework to talk to the robots. ROS proxies are used to communicate with robots that cannot run ROS software. This work does not meet the requirement concerning the support of IoT applications heterogeneity (R1). The DAvinCi framework is exclusive to map management. It also does not meet neither the requirement concerning the support of interaction with fog layer (R2) nor the requirement concerning the federation with other IoT clouds (R3) and the requirement concerning the control and security support (R4). Furthermore, the DAvinCi Server directly communicates with non-virtualized robots delivered from a specific infrastructure. Thus, it does not meet the requirement concerning the support of virtualized IoT services (R6).
In addition to DAvinCi, Rapyuta is yet another open-source robotics PaaS  [37]. It enables robots to offload heavy computations to customizable and elastic computing environments in the cloud. These computing environments are tightly interconnected to allow information and service sharing among the different robots. Rapyuta's computing environments are implemented using Linux containers that enable environments scaling up and down via the easy configuration of the computing resources assigned to each of them (e. g. , memory limits). The physical robots communicate with Rapyuta using the WebSockets protocol via a full duplex and a bidirectional communications channel, which enables the platform to push information to the Robots. The exchanged messages are JSON-based. Rapytua's internal processes intercommunicate over sockets, using the ROS inter-process communication and exchanging serialized ROS messages.
Rapyuta's processes, communicating with physical robots, convert data messages between the internal and the external communication formats (i. e. , JSON and serialized ROS formats). This work does not meet the requirement concerning the support of IoT applications heterogeneity (R1). Rapyuta focuses on offloading each robot's computation to the cloud and then providing access to the RoboEarth database, a worldwide database in which robots can share their knowledge about objects, environments and tasks execution. It also does not meet neither the requirement concerning the support of interaction with fog layer (R2) nor the requirement concerning the federation with other IoT clouds (R3) and the requirement concerning the control and security support (R4). Finally, Rapyuta only support interactions with physical robots.
Control and Security Management Existing IIoT systems are vulnerable to a variety of cyber-attacks  [39, 40]. This led to make protection against cyber-attacks a major design goal for IIoT systems  [41]. This concern is even more important when migrating such solutions to the cloud and provisioning them over dedicated IIoT PaaS. Indeed, achieving efficient and reliable security in IIoT PaaS is critical and mandatory to reassure and promote companies and factories to adopt and migrate their solutions to such environments. The review of the IIoT platforms highlighted that they either do not provide any security support or, when it is the case, this support is modeled as "pluggable" entity that could be transversally added to the platform like any other technical service. In addition, these "pluggable" entities often implement and adapt a classical security approach such as restoration measures of states and data (e.
Interactions with Fog Layer The integration of a fog layer would enable meeting the latency sensitivity requirement for IIoT applications when deployed in the cloud. For instance, given a distributed IIoT application, the latency-sensitive components could be provisioned over fog nodes that are close to data sources and/or actuators, and the compute-intensive components could be provisioned in the distant and more powerful IIoT PaaS  [42]. This stipulates that the IIoT PaaS is able to interact with a fog layer and both make up a common and aggregated ecosystem. The literature review shows that there is still lack today of such mature system. Obviously, there are several works today that propose solutions to deploy IoT applications in hybrid cloud/fog environment (e. g. ,  [43] [44] [45] ).
Reference  [46]  describes prospective attack models in an IoT-Fog architecture. Appropriate countermeasures using Bloom filters can be considered as possible solution to this issue. When it comes to the data plane, security needs to be addressed as this level as well (e. g. , encryption). furthermore, appropriate mechanisms are needed for gateways deployment and configuration. The gateways are useful to parse, convert and/or annotate the data, when needed, in between the IoT devices and the applications in hybrid cloud/fog. Besides the security issue, another challenge is the interaction framework between the IoT PaaS in the cloud and the fog. Two research venues are worth being explored: orchestration and choreography. In the orchestration approach, the IoT PaaS could act as the orchestrator since it has an overall view.