dataesr/scientific-paragraphs-categorization huggingface dataset:
However, these overheads are negligible with respect to component response, startup and shutdown time. The CameraReader component creates one image object per frame, while ImageWindow destroys them, so, for the sequential processing of video frames, the overhead introduced by the CM only involves invoking each component in order with a reference to the image frame objects. For parallel processing, we expected an overhead due to the synchronization of threads on the FIFO queues. On the other hand, reconfiguration requires to iterate and parse a list of operations instructed by the Configuration Adapter module. These overhead times are not considered in the experiment model, since they are orders of magnitude lower than performance properties values in Table  2. The reason for these deviations are feature interactions  (Siegmund et al.
However, we consider that it can be tailored to different component assemblies by providing a more sophisticated Component Manager implementation. In this respect, we plan to further analyze approach limitations and extend its applicability to other architectural styles. This would probably require to analyze more complex mappings among features and software elements. In addition, we should note that the approach requires an extra engineering effort at development time for designing the model, mapping it to system elements, and specifying attribute values, metrics and weights for the optimization step. Along this line, we expect to further develop the tooling support for system developers. The configuration selection is supported by a heuristic search algorithm that ensures correctness and completeness while addressing time efficiency and scalability for large scale instances of the problem.
Introduction Cloud computing is an evolving technology that is adopted progressively by companies and users creating a vast market. Still, there are issues and uncertainties surrounding its adoption, such as security and how users data is dealt with that require attention from developers, researchers, providers and users. It is essential that there are tools and mechanisms available that can help providing trust in the cloud. According to the definition provided by the A4Cloud project  [3] , Accountability consists of defining governance to comply in a responsible manner with internal and external criteria, ensuring implementation of appropriate actions, explaining and justifying those actions and remedying any failure to act properly. The A4Cloud project will then provide the tools and mechanisms needed in order to achieve accountability for cloud providers and users.
These tools cover different aspects that include regulatory aspects, socio-economical or legal aspects. In this paper we will concentrate on two specific tools within the toolset of A4Cloud: the Data Track Tool (DTT) and the Cloud Offering Advisory Tool (COAT). The DTT aims to provide information to the users about how their personal data is dealt with. The COAT tool helps users deciding about the best cloud service provider to use by reconciling the users' requirements on transparency, legal terms, privacy or security with those offered by the providers. The structure of the paper is as follows. In Section 2 we introduce the problem of accountability and how the project A4Cloud can help solving it. Thus, Section 3 describes how defining metrics can be useful for aiding achieving accountability.
The Objectives of the A4Cloud Project A4Cloud's goal, among others, is to understand what users need to trust a cloud provider with their personal data. A4Cloud focuses on the accountability for cloud and other future internet services as the most critical prerequisite for effective governance and control of corporate and private data processed by cloud-based IT services. The project goal is to increase trust in cloud computing by devising methods and tools, through which cloud stakeholders can be made accountable for the privacy and confidentiality of information held in the cloud. These methods and tools will combine risk analysis, policy enforcement, monitoring and compliance auditing. They will contribute to the governance of cloud activities, providing transparency and assisting legal, regulatory and socio-economic policy enforcement.
The A4Cloud project has four interlocking objectives to bring users, providers, and regulators together in chains of accountability for data in the cloud, clarifying liability and providing greater transparency overall to 5 : 1. Enable cloud service providers to give their users appropriate control and transparency over how their data is used. 2. Enable users to make choices about how cloud service providers may use and will protect data in the cloud. 3. Monitor and check compliance with users' expectations enforce business policies and regulations. 4. Implement accountability ethically and effectively.
An Overview of the A4Cloud Tools The A4Cloud project has developed a conceptual model for accountability in  [9] , which defines accountability attributes, practices and mechanisms and how they relate to each other. The accountability mechanisms incorporate legal, regulatory, socio-economic and technical approaches, which are integrated into a framework to support an accountability -based cloud approach to cloud data governance and are functionally classified into preventive, detective and corrective. In this paper, we focus on the A4Cloud toolset, which provides implementations for these mechanisms. The tools comprising this toolset are designed considering the existing gaps in accountability practices, thus, they aim to implement those functions of the accountability mechanisms, for which little or no support was found to exist out there to complement current privacy and security mechanisms.
The Architecture of the A4Cloud Tools The definition and the design principles of the toolset are based on the fact that each A4Cloud tool addresses different elements of accountability, and may operate over different time scales, while interacting with data at different stages of its life cycle. In that respect, the tools implementing preventive mechanisms investigate the potential risks in cloud data governance in order to form policies and decide on relevant mechanisms that should be enacted. The tools implementing detective mechanisms put in place detection and traceability measures to monitor misbehaviours, such as policy violations, in the normal operation of cloud processes. Finally, the tools implementing corrective mechanisms provide notification and remediation, as a response to detected abnormalities of the cloud service chains.
The evaluation of cloud offerings and contract terms complements this mechanism, which is performed through the Cloud Offerings Advisory Tool (COAT), with the goal of enabling a more educated decision making on which service to select. The Policy Definition and Enforcement area hosts two tools that supplement the tools in the previous area as preventive mechanisms to support accountability. In this category, we introduce the Accountability Lab (AccLab), as a tool, which translates human readable accountability obligations expressed in Abstract Accountability Language (AAL)  [8]  into an A4Cloud specific lower level machine-readable accountability policy language, called Accountable PrimeLife Policy Language (A-PPL) language. On top of it, we provide the Accountable PrimeLife Policy Engine (A-PPL Engine), which enforces data handling policies and actions, as they are specified in A-PPL, which takes the form of a sticky policy that travels with the data downstream  [8].
Moving to the implementation of the detective mechanisms, the Evidence and Validation category of tools offers accountability by implementing mechanisms for the monitoring of the appropriate software resources to control and verify the accountability policy-based operations occurred in complex cloud service provision chains. This is enabled through the Audit Agent System (AAS), which enables the automated audit of multi-tenant and multi-layer cloud applications and respective infrastructures for compliance with accountability policies, using software agents. Furthermore, we automate the collection of evidence, describing how data transfers comply with data handling policies within a cloud infrastructure through the Data Transfer Monitoring Tool (DTMT). In this category, we, also, include the Assertion Tool (AT) that ensures the validation of the A4Cloud tools through a test case-based methodology, during the development and deployment of accountability mechanisms.
In A4Cloud, we put particular emphasis on enabling individuals, whose personal data are collected and/or processed by cloud service providers, to take control over how these data are exploited along cloud service chains. To this direction, we introduce Data Track (DT), which is used by data subjects to get a user-friendly visualisation of all personal data they have disclosed to cloud service providers, with the additional capability to rectify data if necessary. DT embeds a Plug-in for Assessment of Policy Violation (PAPV) that provides an assessment on the criticality of previously detected policy violations. In order to secure the communication between these subjects and the cloud providers, the A4Cloud toolset offer the Transparency Log (TL), as a privacypreserving channel to facilitate offline data exchange as well.
Tools Collaboration for Accountability Support In this section, we describe the accountability information flow, depicting the tools dependencies and their interaction for implementing accountability along the three phases. Thus, the tools in the A4Cloud toolset generate accountability specific data objects, which are shared among them to accomplish the respective functions laid on the preventive, detective and corrective mechanisms. The flow of the accountability information among the tools is depicted in Figure  3 , which is achieved in a semi-automatic way along the implementation of the accountability lifecycle processes. As shown in Figure  3 , the type of data that are collected from the data subjects drives the definition of specific accountability obligations identified for the respective cloud providers processing such data, which are analysed along with the privacy and security requirements of the end users and the organisational level policies for providing security in their services, such as access control and encryption.
In parallel, the A4Cloud toolset enables verification of the followed data handling processes by the cloud providers, through a set of tools used to control the cloud subjects data disclosure in the cloud. As part of the European FP6 and FP7 research projects PRIME  6  and PrimeLife 7  , the Data Track tool was developed  [11, 14]. The PRIME Data Track tool was initially a history function for keeping log records for each transaction in which a user discloses personal data. Each log record included information for the user about which personal data were disclosed to whom, for which purposes, which credentials and/or pseudonyms have been used in the context of the disclosure as well as the details of the agreed-upon privacy policy. These transaction records were stored at the user side in a safe manner (protected by the PRIME core).
The follow-up PrimeLife and A4Cloud projects have extended the Data Tack to allow users to exercise their data subjects' rights pursuant to Art. 12 EU Data Protection Directive 95/46/EC to access their data at the remote (cloud) services sides online and to correct or delete their data online if the service provider allows it. In its backend, the architecture of the Data Track consists of four high-level components. First, the user interface component, which displays different visualizations of the data provided by the Data Track's core. Second, the core component is a backend to the UI with local encrypted storage. Through a RESTful API, the core is able to provide a uniform view to the UI of all users' data obtained from a service provider via plugins. Third, the plugin component provides the means for acquiring data disclosures from a source and parsing them into the internal format readable by the core.
By clicking on one (or many) of the services at the bottom of the interface, the interface shows a trace from the service to the user, and then from the user to the data items that she has disclosed to that specific service. If the user clicks instead on a data item at the top panel, the trace shows which online services have that particular data items. The traces are coloured allowing the users to easily differentiate between them. Each service in the bottom panel contains a button with a cloud icon from which users can also access the data about them stored on the services' sides (as seen in Figure  5 ). Clicking on this cloud icon opens a modal dialog where users can review their personal data that the selected service has stored in their databases (Figure  6 ). Contrasting colours, an explicit headline and adequate spacing are used to differentiate between the personal data that was explicitly disclosed by the user from the personal data that has been implicitly collected or derived by the service provider.
In this view, users also Fig. 5. A node representing a service provider, from where users can also access their data located at the services' side by clicking on the cloud icon. have the possibility to exercise their rights to correct or remove their personal data if the respective service provider allows it. Evaluation The Data Track trace view was evaluated in two iteration cycles with 14 and 17 volunteering test participants between 19 and 40 years, which were recruited from the region of Karlstad in Sweden. 16 of them were students and 15 had other professional background. For the evaluations, the test participants were first introduced to an eShopping scenario, where they had to conduct a purchase transaction for an eBook with fictitious personal data that was claimed to be send to an online bookshop.
Then, they were asked to used the Data Track tool to complete different tasks in regard to tracking the data that they previously released. Both test rounds confirmed that participants easily understood and appreciated having an overview of the data that they have sent to different service providers using coloured tracing lines. However, the test of the first design iteration showed that the controls to access their personal data remotely on the services side did not provide enough affordance. Besides, it was still hard for them to grasp the distinction between data logged locally by the Data Track program and data about them stored remotely in the services' databases. Therefore we included an introduction tour in the second design iteration that illustrated the different aspects of the user interface and explained the distinction of the views showing personal data stored by the Data Track under the user's control and the dialog that showed personal data stored remotely at the service provider.
The main internal processes are: Matching offers to requirements, Assessment of a cloud service provider offering from a privacy and security perspective, Comparison of offerings (from a data protection compliance and provider accountability point of view), Guidance on the meaning of the comparison attributes and education of users on security, and Logging of the offered advice and the user's decision. The tool connects to a database of predefined questions regarding the user's requirements and a database of service offerings (MySQL). The server-side application and the webservice layer that provide access to the questionnaire management and matchmaker are written in Java. The Matchmaker component along with the Questionnaire management (logic) are implemented in Java as well. The client-side application is implemented using HTML5 and JavaScript and is backed by Backbone 9 for a clientside MVC structure.
The offers management and associated webservices are written in Python 10. The Search Index used to find the matched service offerings is done by SOLR. We use RESTful API as a transport layer and JSON 11 as the data-interchange format. We evaluated the tool by testing it in two workshops: one for cloud service providers and one for cloud customers. The overall feedback was positive. One of the feedback resulted in creating a new service-types page for the customer (figure  9 , right handside) to make it simpler for the non-expert users to select the type of services they want. Another feedback was a concern that some cloud service providers will not cooperate in entering their contract details in the tool service-offerings side (populating the tool with offers). However, our argument is that the tool provides good exposure for them and more specifically an exposure to the unique terms that they can offer to their users; this would give small(er) businesses a competitive advantage over large cloud providers.
Conclusion In this paper, we have provided a general description of the A4Cloud project, which aims to address the problem of accountability in the cloud. This project tackles the problem of accountability from different perspectives: technical, legal, regulatory or socio-economic. The project has provided mechanisms for accountability that are introduced in the conceptual way and later on implemented through a toolset that can be used for the different cloud actors. We have concentrated here in accountability metrics that are developed from the conceptual point of view. We have also given an overview on the accountability tools and have emphasized in two of them in particular: the Data Track Tool (DTT) and Cloud Offering Advisory Tool (COAT). In the future we will continue working on the development of the A4Cloud tools and will start the validation of the DTT, COAT and the other tools.
In this study, we have two main objectives: our first goal is to evaluate the robustness degree in terms of sensitivity and selectivity changes via the decrease of SNR. Mainly, we have used two approaches that have been previously used for the automatic detection of epileptiform spikes, based respectively on: Discrete Wavelet Transform (DWT)  [6, 10]  and Continuous Wavelet Transform (CWT)  [3, 11]. The robustness degree was evaluated via an epileptic SEEG data mixed with different noise levels range from 10 dB up to -10dB. Our second purpose is to elaborate an overall comparison between the two approaches. The structure of the paper is ordered as follows: Section 1 presents the Introduction. Section 2 describes the materials and methods. Section 3 concerns our results and discussion. The last section presents the conclusion, and also the directions for future research.
Intracerebral EEG Data & Preprocessing The EEG data used in this study was recorded by semirigid multi-lead electrodes that were stereotactically implanted in the patient's brain. The stereotactic-EEG (SEEG) electrodes have a diameter of 0. 8 mm and generally consist of 10 to 15 contact leads, 2 mm wide and 1. 5 mm apart (DIXI Medical, Besançon, France). The intracerebral recordings were conducted at the Lyon Neurological Hospital (Lyon, France) using a video-SEEG monitoring system (Micromed, Treviso, Italy), which allowed the simultaneous data recording from up to 128 depth-EEG electrode sites. The data were sampled at 256 Hz. At the time of acquisition the data is recorded using a reference electrode located in white matter, each electrode trace is re-referenced with respect to its direct neighbor (bipolar derivations).
This bipolar montage helps eliminate signal artifacts common to adjacent electrode contacts (such as the 50 Hz power supply artifact) and achieves a high local specificity by canceling out effects of distant sources that are equally spread to both adjacent sites through volume conduction. The spatial resolution achieved by the bipolar SEEG is on the order of 3 mm. Our methods were tested on 2-minute segments of SEEG data containing only epileptic spikes. Visual marking of spikes was performed by one expert trained in electrophysiology and spikes analysis. All the marked events were immediately saved numerically in a database. That would serve subsequently as a gold standard for the evaluation and the measurement of the performance detection. Then, the chosen data were mixed with the Gaussian noise using six SNR values (10 dB, 3 dB, 0 dB, -3 dB and -10dB), associated with 10 trials for each SNR.
The variation of SNR values in human scalp EEG is comprised approximately between 10 dB and -10 dB  [12, 13]. Therefore, only this range was taken into consideration in our study. Subsequently, the obtained data were approximated as scalp EEG recordings and considered as a consistent gold-standard data set. The gold standard will be needed to test the stability of various test methods against the noise. The visual marking of epileptic spikes was performed via the signal visualization tools available in the EEGLAB [14] and ELAN  [15]  toolboxes. The processing and analysis of all signals were performed with custom codes which were implemented using MATLAB 2012a software.
Where , where a=2 and b=1. The original signal can be expressed as a linear combination of the wavelet functions weighted by the wavelet coefficients. The wavelet transformation analyses the signal at different frequency bands, with different resolutions by decomposing the signal into a coarse approximation and detail information. The selection of suitable wavelet and the number of decomposition levels is very important in the analysis of signals using DWT wavelet transformation. The Daubechies wavelet (Db4) has been previously chosen for automatic EEG spike detection  [6, 10] , because it yields the highest correlation coefficients with the epileptic spike among the wavelet bases available in the MATLAB Toolbox and it best matches the shape and frequency characteristics of epileptic spikes  [6, 10].
01% and 79. 10%. Our simulations have been carried out using a DELL-PC with Intel(R) Core (TM) i3 CPUM2350 2. 30GHz and 4-GB RAM by MATLABR2012. The CPU times were assessed  for one minute EEG data; it is 5. 473 s for DWT approach and 5. 117 s for CWT method. Overall, CWT based method seems to be more robust than DWT method in terms of performance. In the current paragraph, we aim to provide some examples of spikes detection using respectively DWT approach and CWT approach. The left side of Fig. It may be much more interesting and challengeable to compare our methods with different other algorithms. However, the comparison between spikes detectors is not an easy task. The following reasons can be considered as difficulties in assessing or comparing the performances of automatic spikes detection methods: varying EEG recording techniques, different electrode locations and pathologies across patients, different definitions for spikes (i.
The emerging picture from these studies is that the classical approach of using linear regression with a small number of expert-selected structural features can be strongly improved by a machine-learning approach based on nonlinear regression allied with comprehensive data-driven feature selection. Furthermore, the performance of classical SFs does not grow with larger training datasets and hence this performance gap is expected to widen as more training data becomes available in the future. Other topics covered in this review include predicting the reliability of a SF on a particular target class, generating synthetic data to improve predictive performance and modeling guidelines for SF development.