dataesr/scientific-paragraphs-categorization huggingface dataset:
Resource Requirements The popularity of deep learning methods is to a large extent due to the possibility of training these models in a reasonable amount of time with large scale parallelism. In particular, the training stage requires repeated simultaneous access to many data elements and specialized hardware has been developed for training deep learning models. In contrast, inference can be an operation applied to a single data element at a time and needs to be performed only once. Inference has less demands on I/O and is limited only by the computing power and model complexity. Because inference has real-time applications in high-energy physics, latency and throughput constraints are the main challenges. A typical HEP application can require up to 1 GPU-week to train a single model. To obtain the best results and understand the performance of the model, an average of 100 hyper-parameter points optimization is typically performed.
Opportunistic Resources The current HEP computing model is based on a tiered structure where computing resources are mostly large data centers providing CPU resources for collaboration. Although existing resources are gradually moving towards supporting GPUs, it is unlikely to reach all HEP computing centers in the near future. Therefore opportunistic resources are a possible option for training machine learning applications. Currently, cloud solutions provided by the industry run ML workflows on dedicated hardware and offer interfaces for training machine learning models. The scientific community should work closely with cloud providers to harmonize our analysis computing needs and data access patterns with their business models. Costs of the cloud resources should be compared with the costs of procuring these resources independently.
Training the community The CWP on training  [77]  discusses the training needs of the HEP community in detail. In order to address the communication barrier and to speak the same language, training in machine learning concepts and terminology have to be part of a standard curriculum. In addition to lectures also hands-on tutorials on specific tools are necessary. Being able to apply machine learning to practical HEP problems requires the understanding of basic machine learning concepts and algorithms. For this, regular data science lecture series and seminars, like  [78] , are very useful. Also university level courses dedicated to machine learning applications in physics research are an excellent way to train undergraduate and graduate students. Experimental collaborations currently have training activities for newcomers that focus on analysis software and introduction to domain knowledge  [79].
2. Feasibility and demonstration: Given a dataset, appropriate machine learning algorithms need to be investigated and evaluated for their suitability to solve the problem. 3. First application: An application of the solution to one or a few specific physics analysis examples where the ML technique significantly improves the result. The incorporation of the technique into the computing work-flow will likely be very specific to the application and require significant manual intervention. 4. Scaling and optimization: Evolving from a demonstration to a general solution requires the use of realistic data sets with full detector simulation. Furthermore, the solution will also require optimization to achieve nominal physics and computing performance. This stage will likely require significant computing resources to scale solutions to the full detector and data sets.
In reference to point (2), a clever technique to re-map the phase space in order to reduce the sharpness of integrate in that space in an automated way (MADWEIGHT  [37] ) is often used in conjunction with a matrix element calculation package (MADGRAPH aMCNLO  [80] ). In practice, evaluation of definite integrals by the ME approach invokes techniques such as importance sampling (see VEGAS  [42, 43]  and FOAM  [44] ) or recursive stratified sampling (see MISER  [81] ) Monte Carlo integration. Acceleration of some of these techniques on modern computing architectures has been achieved, for example concurrent phase space sampling in VEGAS on GPUs.
e. fulfilling requirements from different application domains). Thus, it is deemed necessary to set-up IoT experimentation infrastructures that have the appropriate scale, experimentation realism, heterogeneity, interoperability and openness to facilitate the development of innovative solutions that can actually realize this paradigm of instrumented, interconnected and intelligent scenarios. This paper presents a platform that has been implemented for enabling Experimentation as a Service (EaaS) over multiple IoT testbeds. In this sense, the key advance with respect to the state of the art brought by the IoT EaaS Platform, which this paper is describing, is twofold. On the one hand, the tools and services underpinning the EaaS concept across federated IoT data sources that reduce the effort to build and run experiments.
Experimenters assessing their research on top of this IoT Platform are able to get data from any of the underlying testbeds using a unique set of tools and Application Programming Interfaces (APIs). On the other hand, the interfaces and models provide IoT testbed semantic alignment and interoperability so that the resulting platform increases scale, heterogeneity, experimentation realism and cross-domain innovation. These testbeds federate through the semantic web platform allowing the interoperability and seamless testbed-agnostic access to the services and data that they provide. The paper describes the overall system architecture as well as the tools implemented to support the EaaS paradigm. In addition to the description of the design principles and the specification of the different building blocks, another contribution of the paper is the validation and evaluation of 1 http://fiesta-iot.
The integrated IoT EaaS Platform low-level architecture and the different components that are part of it are presented in Section III. In Section IV the workflow for federating IoT testbeds and making their resources available through the Platform is described. Section V summarizes the tools and procedures that experimenters have at hand to access the underlying testbeds datasets in a testbed-agnostic manner and, thus, carry out their experiments. In Section VI, the results of the validation and evaluation of the Platform instantiation are presented. Finally, Section VII contains some concluding remarks and discussion on the scenarios enabled.
A. KEY DESIGN CONSIDERATIONS The main aim of the Platform described in this paper is to enable an EaaS paradigm for IoT experiments. However, instead of deploying yet another physical IoT infrastructure it enables experimenters to use a single EaaS API for executing experiments over multiple existing IoT testbeds that are federated in a testbed agnostic way. Testbed agnostic implies in this case the ability to expose a single testbed that virtualizes the access to the underlying physical IoT testbeds. Experimenters learn once and accordingly use the EaaS API to access data from any of the underlying testbeds. To this end, the testbeds that aim to participate in the federation have to implement common standardized semantics and the interfaces that have been defined. This enables the meta-platform to access the data that their devices produce as well as the descriptions of their devices and the services that these devices might expose.
In this sense, the first main design decision is the use of semantic technologies to support the interoperability between heterogeneous IoT platforms and testbeds. Using a common ontology makes it possible to seamlessly deal with data from different sources. Federated testbeds have to implement their own Semantic Annotators to transform the data they handle internally to the common semantic ontology defined by FIESTA-IoT. Different RDF representation formats (e. g. RDF/XML, JSON-LD, Turtle, etc. ) are supported as long as the common ontology is used. The second major design decision is to take as reference the IoT ARM as defined in the IoT-A project  [30]. This decision has brought out, within the IoT EaaS Platform context, the need to comply with the Domain and Information Models defined in the ARM.
Thus, the architecture focus on defining a canonical set of concepts which all IoT platforms, which can be part of the federated IoT EaaS Platform can easily adopt. The adoption of these essential concepts only require from underlaying testbeds a straightforward tuning of the models that they handle internally. In this sense, independently of which internal model the testbeds uses, whether it is proprietary or based on existing standards  [31] ,  [32] , they should be able to find in a straightforward manner how to map the internal modelling to the canonical concepts managed within the IoT-related ontology used as a basis for the Platform. The aforementioned tuning of models basically consist on mapping the internal structure of information to the one that uses the ontology as a basis. The less number of concepts to map and the more fundamental these concepts are, the less the chances to have existing IoT platforms that are unable to perform the mapping between their internal data model and the IoT-related ontology that is employed to enable interoperability among the federated IoT infrastructures.
Analytics data retrieval Experiment execution underlying testbeds IoT devices and the observations that they generate. Moreover, it exposes the interfaces necessary to access this data. On top of the IoT-Registry, the architecture consists of the additional set of tools and APIs underpinning the EaaS concept. They allow experimenters assessing their research on top of the IoT EaaS Platform to get data in a testbed-agnostic manner. Moreover, several experiment management components, namely Experiment Execution Engine (EEE), Experiment Registry Module (ERM), Experiment Management Console (EMC) and Experiment Result Storage (ERS) ease the experiment creation and management and the result extraction. They allow the experimenter to define an experiment in an XML-based document, schedule its execution in an unattended manner and store the results for later retrieval.
ERM and EMC are available via the Platform Portal, a web-based UI open to the experimenters and testbed providers (represented in Fig. 2  with browser icons). In addition to these components, added-value services are also provided as part of the Platform experimentation tools portfolio. Through the Analytics and Reasoning modules experimenters can easily get added-value data without the need to implement the algorithms themselves. These modules can be used within the workflow of the experiment to get the raw data from the IoT-Registry and generate already processed data that fits with the experimenter needs. Below the IoT-Registry the IoT EaaS Platform is focused on the interfaces and models supporting IoT testbed semantic alignment and interoperability so that the resulting platform has increased scale, heterogeneity, experimentation realism and cross-domain innovation.
Still at the testbed side, two components must be implemented. The Semantic Annotator and the Testbed Provider Services (TPS) respectively transforms the data model used internally at the testbed into semantically annotated data (based on the IoT-related ontology defined for the specific instance of the IoT EaaS Platform) and exposes the interfaces for the Platform to access that data. The TPS interacts with the Data Management Services (DMS) already at the Platform side of the architecture. The DMS proxies the observations that arrives at the IoT EaaS Platform towards the IoT-Registry, where they are stored indefinitely. Since the Platform does not only manage information related to observations generated by underlying testbeds only but also the descriptions of the actual IoT devices (i. e.
sensors, actuators and tags), the Testbed and Resource Registration (TRR) module exposes the necessary interfaces to register the descriptions of the testbeds' resources. This registration is done either via the Platform Portal or through the TRR API. Before any RDF document is stored in the IoT-Registry, its compliance with the IoT-related ontology employed as baseline for interoperability has to be validated. Otherwise, the data inserted into the repository could be flawed and cause issues while querying afterwards. The Semantic Validator is in charge of this assessment both for the observations and the resource descriptions. Finally, all the interfaces exposed by the IoT EaaS Platform are secured using HTTPS and the corresponding authentication and authorization filters. Every query received has to pass through a Policy Enforcement Point (PEP) which checks if it contains a valid security token and if that token actually belongs to a user authorized to make such query.
C. IOT-REGISTRY IoT-Registry's main function is to store all the (semantic) resource descriptions and observations that the underlying testbeds provide. On top of this "collector" behaviour, it implements a fully-fledged REST API that allows the interplay between users and the stored information. Fig. 3  shows the internal architecture of the IoT-Registry. At the core of the IoT-Registry is the Triplestore Database (TDB) that provides the storage capacity for aggregating the Resource Descriptions from the devices belonging to the federated testbeds as well as the Observations that these devices are constantly producing. In this sense, the TDB internal structure follows the canonical concepts defined by the ARM information model. By using these concepts as a basis for its internal structure, it is able to adapt to different IoT-related ontologies.
For example, the resulting transformed URI for one of the testbeds original URI: http://api. smartsantander. eu#SmartSantande rTestbed becomes: https://platform. fiesta-iot. eu/iotregistry/api/testbeds/a1yp9GcKEPw37Bx5rslg RI4QLSNCwEwBatCIOe_W0dHZCmzj2WmkExz3qoNuvW g1pueAXn1Li0JrNjvBiQwV3Q== Therefore, all the semantically annotated descriptions generated by the testbeds are stored in the Triplestore Database following the testbed-agnostic paradigm adopted for the design of the IoT EaaS Platform. Once the necessary adaptations to the resource descriptions have been done and internally recorded for future use by the RB, the RM stores them into the TDB. While the communication interface between the RM and the TDB is based on semantic requests, the interface with the testbeds is based on standard HTTP encapsulating semantic documents.
D. EXPERIMENT DEVELOPMENT, DEPLOYMENT AND MANAGEMENT An experiment is defined as "a test under controlled conditions that is made to demonstrate a known truth, examine the validity of a hypothesis, or determine the efficacy of something previously untried"  3. Nevertheless, our EaaS Platform focus on data-oriented experimentation where experimenation can be performed on the stored IoT data. The modules that address all the steps in the execution of an experiment (i. e. development, deployment and management) are shown in Fig. 2. The core of the experimentation support subsystem is the Experiment Execution Engine (EEE). This module essentially schedules or deploys the experiment based on the provided experiment specifications. The EEE exposes APIs that are broadly divided into 5 categories: scheduling, polling, subscription, monitoring and accounting.
Scheduling API enable creating a recurrent job that executes the query included as part of the experiment specification. It also provides information (general description and status) about the created job, API to change the execution status of the job (start, stop, and resume job), change schedule parameters, and API to delete the job. The polling API provides a way to execute the experiment once and not to schedule it. The subscription API let experimenter subscribe or unsubscribe the public experiments. On the other hand, the accounting and monitoring APIs provides log information and status information about the execution of the experiments. EEE fetches from the Experiment Registry Module (ERM) the information about the experiments that is to be executed. ERM basically stores the experiments' specifications and provides the interfaces to handle the storage process (e.
g. saving, deleting, sharing, etc. ). EEE is accompanied by an experiment controlling and management user interface (Experiment Management Console or EMC) that enables experimenters to view an execution summary and control the execution of their experiment. Once an experiment is executed by the EEE, the results are sent to experimenters. The experimenters need to enable a Receiver on their side to receive the results. In case the results are not delivered to the experimenter, the results are stored in an Experiment Result Storage (ERS) repository where experimenters can download the results at will. Dedicated APIs, which can be used by experimenters to develop their own experiment workflow, complement the above tools. In the case where experimenters do not want to use the graphical interfaces of these tools, they can use the APIs of these modules or perform querying directly on IoT-Registry using the public IoT-Registry APIs.
Reasoning Engine Rule • If (temperature) > (25degrees) then (notify_hot) • If (temperature) < (19degrees) and (humidity) > (60%) then (notify_unhealthy). The architecture of the reasoning module is shown in Fig. 7. It provides three APIs for creating a rule template, registering a new rule for a sensor or a set of sensors and executing the rule. The rules are stored in a MySQL database. The engine is connected to the IoT-Registry for getting the sensors' descriptions and observations. The end users (experimenters) can access the reasoning module's functionalities either through a simplified graphical interface or through the APIs, which facilitates the way they can integrate the reasoning engine in their applications.
Apache Jena Open Source framework. https://jena. apache. org/index. html necessary to map the data format managed internally by the testbed to RDF documents complying with the selected reference ontology. The Annotator as a Service (AaaS) module lowers the burden for the TPs as they do not have to implement this mapping completely but just take, from their information models, the pieces of information that map into the desired reference ontology's classes. AaaS receives as input a JSON object with that pieces of information (organized using a pre-defined JSON Schema) and generates the corresponding RDF document. This way, the integration effort for the TP is significantly reduced.
e. not specifying execution to happen every second, writing queries that are not generic, or writing queries that result in huge datasets), providing the correct location where the data should be sent, and respecting the ontology structure in the SPARQL query. The above-described workflow is one way of executing the experiments using the tools provided by the EaaS Platform. However, an experimenter can create their own EEE like tool using the APIs of the EEE, ERM, ERS and Analytics tool and execute that component on their side. Nonetheless, if an 7 https://www. graylog. org/ experimenter does not want to use the related APIs, they can create their own tools to call the IoT-Registry API and retrieve IoT data. As experimenters then can define their own workflow, describing them is out of the scope of this paper.
B. CASE STUDY EVALUATION To evaluate the FIESTA-IoT platform, we use a case-study based methodology. That is, we consider particular use cases where FIESTA-IoT has been applied and observe the extent to which these cases show the following hypotheses. 1. The FIESTA-IoT platform can be used to perform IoT experiments atop semantically interoperable data; thus facilitating the testing of solutions with a horizontal approach 2. The FIESTA-IoT platform supports both experimentation and technology maturation under realistic conditions in real world experimental deployments as part of the innovation lifecycle. 9 https://github. com/fiesta-iot/testbed. tpi.
Throughout the paper, the experimentation workflow is described together with the platform's components that enables it. In this sense, the EaaS paradigm enabled by the IoT EaaS Platform described in the paper ranges from plain access to raw data and/or services offered by any of the underlying testbeds to autonomous scheduling and execution of experiments involving added-value analytics and/or reasoning techniques. Taking advantage of the actual instantiation of the Platform design and the integration of real IoT testbeds, the design has been refined together with the interfaces and models supporting IoT testbeds semantic alignment and interoperability. The resulting platform increases scale, heterogeneity, experimentation realism and cross-domain innovation as more testbeds are joining the federation.
An OCCI Configuration defines a running system. It represents an instantiation of one or several OCCI extensions. In addition, OCCIWARE METAMODEL introduces the Constraint notion allowing the cloud architect to express business constraints related to each cloud computing domain. The constraints can be expressed on OCCI kinds and mixins. Finally, OCCI- WARE METAMODEL provides the FSM mechanism. This later allows to describe the behavior of each OCCI kind/mixin as a Finite State Machine (FSM). To resolve the second issue, a model-driven tool chain for OCCI, named OCCIWARE STUDIO, has been proposed  (Zalila et al. , 2017). It is built based on the OCCIWARE METAMODEL and proposed as a set of plugins for the Eclipse IDE. OCCIWARE STUDIO allows both cloud architects and users to encode OCCI extensions and configurations, respectively, graphically via the OCCI Designer tool, and textually via the OCCI Editor tool.
Enhanced OCCI Platform Lifecycle Experimenting with the OCCI Platform extension in real use-cases shows several hidden lacks. The OCCI Platform extension provides only inactive, active, and error states with two actions: start and stop. This design assumes that a component is already installed and configured which might not be the case. For instance, an application component, e. g. , a software component, like a database or an application server, will first be installed ("deployed"), and configured, prior to managing it (start/stop etc. ). Therefore, we argue that the lifecycle of the Component and Application kinds is not expressive enough and does not define all possible states of a resource (compare P1). To resolve it, we propose an enhancement of the OCCI Platform extension as shown in Figure  3.
Case Studies As case studies, we selected a distributed MongoDB database 5  , the popular LAMP web-application stack 6  , a distributed Cassandra database 7  and an Apache Spark cluster 8. Due to space constraints, we focus on the description of the defined MongoDB extension of MoDMaCAO, and we provide a configuration model that is conform to this extension. For the other use cases, we give only a brief overview of the defined extensions. Full-sized configuration models using each of these three remaining extensions can be found in the supplemental material 9.
MongoDB MongoDB is a NoSQL database that can be highly scaled and is often used in cloud environments. To achieve scalability, it supports the concept of sharding, i. e. , the decomposition of and distributed storage of a data collection to several machines. Furthermore, replication sets can be used, to provide redundancy and high availability in case a machine experiences a failure. • The ReplicableMongoDBComponent mixin type defines the base type for components that can be replicated. It defines the attribute mongodb. replication. set. name that is used to assign a component to a certain replication set. MongoDB components belonging to the same replication set are synchronized copies of each other. • The Router mixin type abstracts the notion of a router in the MongoDB cluster. A router implements the component to which the user connects.