dataesr/scientific-paragraphs-categorization huggingface dataset:
FY Semi-Empirical Models In the present FY nuclear data library, such as JEFF-3. 1. 1, semi-empirical models are employed to calculate independent fission yields. Such models are used in a fitting procedure to interpolateextrapolate missing data, especially for those fissioning systems which have few available experimental data. Independent fission yields can be written as the product of three factors Y post (A, Z, M) = Y post (A) f (A, Z)R(A, Z, M) (2) EPJ Web of Conferences where f (A, Z) is the charge distribution giving the fractional independent yields and R(A, Z, M) is the isomeric ratio. In JEFF-3. 1. 1 evaluation mass yields interpolation and extrapolation are deduced performing a multi-Gaussian systematics calculation to fit chain yields  [3, 9]. Multiple Gaussians can in fact well represent the general trends of mass distributions, if the fluctuations due to prompt neutrons emission are ignored.
WONDER-2015 values y are available, provided with corresponding covariance matrices M prior and M y. f ( x) are the FY models just presented and G (n) their derivatives. We performed the adjustment using JEFF-3. 1. 1 evaluated FY data as pseudo-experimental values. Brosa fission mode characteristics, ν values, a single width for all the prompt neutron Gaussian probabilities, Wahl model parameters and the Madland England cut-off were simultaneously adjusted to achieve a satisfactory JEFF-3. 1. 1 representation. Such procedure was performed including extra experimental values concerning miscellaneous fission quantities, as the total prompt neutron emission probability distribution and the total average number of prompt neutrons emitted by the fissioning system. The parameter covariance matrix M x was finally deduced enabling a retroactive analysis fitting only Brosa, Wahl and Madland England parameters.
SMRT sequencing was performed on the Pacific Biosciences RS II System using the C4 sequencing kit (Pacific Biosciences), with magnetic bead loading and 240 min movies. Three SMRT cells were run per library type, providing a total of nine SMRT cells worth of data to be used for downstream analysis. Prior to data analysis, raw reads with a predicted polymerase read quality less than 0. 80 were filtered out.
The first step in RS_HGAP_Assembly. 3, i. e. preassembly, utilizes a directed acyclic graph-based consensus procedure to align shorter reads to the longest reads in the sequencing data, thus generating corrected, continuous preassembled reads. 29 Next, the preassembled reads are assembled into larger contigs with the AssembleUnitig algorithm (Pacific Biosciences; https://github. com/PacificBiosciences/SMRT-Analysis/wiki/SMRT-Pipe-Reference-Guide), which incorporates elements of Celera Assembler 36 for overlapping and layout. Finally, the filtered reads are mapped back to the contigs using Blasr,  37  error-corrected with Quiver 29 to generate a high-quality consensus (referred to here as the SMRT assembly), and then visualized using SMRT View 2. 3. 0 (Pacific Biosciences). To assemble the $32 kb P.
falciparum apicoplast genome, reads that did not align to contigs in the SMRT assembly (which comprised only the nuclear genome) were reanalysed in SMRT Analysis Portal 2. 3. 0. p2 resulting in an apicoplast contig. For the $6 kb P. falciparum mitochondrial genome, Blasr was used to align the raw sequencing data to the M76611 mitochondrial sequence (http://plasmodb. org/plasmo/showRecord. do?name=SequenceRecordClasses. SequenceRecordClass&project_id=PlasmoDB&primary_key= M76611) and assembly performed with reads that presented partial or full homology to M76611 mitochondrial DNA. Dot plots comparing the SMRT assembly to the P. falciparum reference genome, Pf3D7_v3. 0 (http://genedb. org), were rendered with Gepard  38  using default parameters and a word length of 30. To identify structural variations in the genome, we used our new algorithm Assemblytics.
Acknowledgements We are grateful to  Cameron Macpherson  and  Sebastian Baumgarten  for helpful scientific discussions and  Jonas Korlach  for critical reading of the manuscript. We also acknowledge PlasmoDB, a member of pathogen-databases that are housed under the  NIAID-funded EuPathDB Bioinformatics Resource Center (BRC) umbrella , for regular updates and ready access to P. falciparum genome information.
Availability of Supporting Data The raw data generated in this study have been deposited in the National Centre for Biotechnology Information (NCBI) Sequence Read Archive under the accession number SRA360189 (http://www. ncbi. nlm. nih. gov/sra/? term¼SRA360189; BioProject accession number ¼ PRJNA313199 and BioSample accession number ¼ SRS1315102 last accessed on June 8, 2016). The SMRT assembly has been deposited in the European Nucleotide Archive under the study accession number PRJEB11803 (http://www. ebi. ac. uk/ena/ data/view/PRJEB11803 last accessed on June 8, 2016). Note that in the fastq file for the final assembly, the term Unitig is used instead of Contig.
Simulated samples For the modelling of the background we use the MADGRAPH v5. 1. 3. 30 [29]  event generator to simulate the production of W boson and Drell-Yan events in association with jets, the POWHEG 1. 0 r1380  [30] [31] [32] [33] [34] [35]  package to generate tt and single top quark events, and PYTHIA v6. 424  [36]  for diboson (WW, WZ, and ZZ) processes. All simulated event samples are generated using the CTEQ6L1  [37]  parton distribution functions (PDF) set, except for the POWHEG tt sample, for which the CT10 PDF set  [38]  is used. All the samples are then processed further by PYTHIA, using the Z2* tune  [39, 40]  for simulation of parton showering and subsequent hadronization, and for simulation of the underlying event. The passage of the particles through the CMS detector is simulated using the GEANT4 package  [41].
Jets and missing transverse momentum reconstruction Hadronic jets are identified by clustering PF candidates, using the FASTJET v3. 0. 1 software package  [54]. In the jet-clustering procedure, charged PF candiates associated with pileup vertices are excluded, to reduce contamination from pileup. In order to identify a Higgs boson decaying into bottom quarks, jets are clustered using the Cambridge-Aachen algorithm  [55]  with a distance parameter of 0. 8 ("CA8 jets"). Only the highest p T CA8 jet is used. Jets in the event are also identified using the anti-k T jet-clustering algorithm  [56]  with a distance parameter of 0. 5 ("AK5 jets"). AK5 jets are required to be separated from the CA8 jet by ∆R > 0. 8. An event-by-event correction based on the projected area of the jet on the front face of the calorimeter is used to remove the extra energy deposited in jets by neutral particles coming from pileup.
N BKGD SR (M WH ) = C W+jets SR F W+jets DATA,SB (M WH ) α MC (M WH ) + ∑ k C k SR F k MC,SR (M WH ), (2) where the index k runs over the list of minor backgrounds, and C W+jets SR and C k SR represent the normalizations of the yields of the dominant W+jets background and of the different minor background contributions. The C W+jets SR parameter is determined from the fit to the m jet distribution as described above, while each C k SR is determined from simulation. The ratio α MC accounts for the small kinematic differences between signal and sideband regions, and is largely independent of the assumptions on the overall cross section. The validity and robustness of this method have been studied in data using a lower m jet sideband of  [40, 80]  GeV to predict an alternate signal region with m jet in the range  [80, 110]  GeV.
Acknowledgments We congratulate our colleagues in the CERN accelerator departments for the excellent performance of the LHC and thank the technical and administrative staffs at  CERN  and at other  CMS institutes  for their contributions to the success of the CMS effort. In addition, we gratefully acknowledge the computing centres and personnel of the Worldwide LHC Computing Grid for delivering so effectively the computing infrastructure essential to our analyses. Finally, we acknowledge the enduring support for the construction and operation of the LHC and the CMS detector provided by the following funding agencies:  BMWFW  and  FWF (Austria) ;  FNRS  and.
Dynamic deployment of security policies The negotiated security policies are analysed and interpreted by the Policy Engine and the Policy Interpreter modules. These modules are responsible for identifying changes in the security policies that require the security concerns deployed inside the application to be adapted. Security policies are dynamically deployed, and/or adapted at runtime using the Aspect Generation and the Aspect Weaver modules, which are in charge of receiving the information generated by the Policy Interpreter module and of incorporating or eliminating the corresponding security aspects in the application. Security aspects can be developed in any Java-based AOP language such as AspectJ, Spring AOP, CaesarJ, or JBoss. The detailed design of these modules is beyond the scope of this paper but can be consulted in Fig.
Monitoring (test and operation phases) Negotiated security policies are also sent to the Monitoring Tool in order to activate/deactivate the associated security properties that control the fulfillment of the security policies by the deployed aspects. Security properties are formally described as conditions in sequences of events  (Morales et al. , 2010)  based on Linear Temporal Logic (LTL)  (Clarke et al. , 1999)  to define security rules (i. e. , rules that should be respected) or attacks and misbehaviours  (Mallouli et al. , 2012). The Monitoring Tool relies on an adaptation of the Montimage Monitoring Tool (MMT)  (Wehbi et al. , 2012)  which is an online monitoring solution that allows a real-time network traffic, application, flow and user level visibility to be provided. The Notification and Context Awareness modules notify the Monitoring Tool about application's internal events and changes in the application context, e.
Testing for vulnerabilities detection Different fuzz  (Howard and Lipner, 2003)  and active  (Cavalli et al. , 2008)  testing techniques are also provided as part of the framework (Fuzz Testing Tool and Active Testing Tool modules) in order to test the application's security and robustness. In order to do that, during the testing phase the MMT tool monitors the traces automatically generated by the fuzz testing and active testing tools in order to simulate the application behaviour. Note that the INTER-TRUST framework is a modular solution with complementary functionalities that can be partially or completely deployed according to the developer's needs. This modular framework has several benefits for the following reasons: (1) the modules in charge of specifying, negotiating and interpreting the security policies are unaware of the use of AOP to enforce them.
Similarly, the decryption aspect (line 19) has associated with it an advice (line 11) to decrypt messages (lines 12 and 13) and the associated pointcut (line 3) that indicates where messages will be decrypted. Both advices are implemented in the same AspectJ file (see Listing 3) of the INTER-TRUST aspect repository. This is indicated by the url attribute (lines 7 and 11) defined for each advice. The Aspect Generation module performs a mapping between the required security functionalities and the aspects that provide these functionalities. The output of this mapping is a new configuration that is analysed to: (1) obtain the differences between the new and the current configurations of the aspects deployed within the application, and (2) generate a security adaptation plan with the list of actions that must be performed over the aspects: weave, unweave, or reconfigure.
Listing 2 shows an example of a security adaptation plan where we indicate that the encryption and decryption aspects need to be deployed inside the application (lines 1-5) and configured with parameters such as the encryption algorithm or the key values (lines 9-18). Also, we indicate the aspects that need to be undeployed (lines 6-8). The security adaptation plan generated by the Aspect Generation module is sent to the Aspect Weaver module that Listing 1 -Aspectual Knowledge. Listing 2 -Security Adaptation Plan. is in charge of executing the actions by interacting directly with the aspects (activity labelled 3 in Fig. B3 ). The Aspect Weaver module is a wrapper that translates the list of actions received as input (which is specified independently of a particular AOP language/framework) to the particular syntax of the AOP weaver being used.
This means that we provide different instantiations of the Aspect Weaver module for using different AOP weavers, since the use of a unique AOP solution does not cover all the dynamicity, expressiveness, and performance requirements that the applications may need. For instance, AspectJ allows dynamically activating/deactivating at runtime the aspects woven when deploying the application, while Spring AOP allows directly weaving/unweaving new aspects at runtime. However, Spring AOP only supports interceptions of method executions, in contrast to AspectJ that can intercept any point in the execution of the application (e. g. , calls and executions of methods and constructors, references and assignments of fields, handler of exceptions, etc. ). Listing 3 shows an example of an encryption aspect using the AspectJ language.
The aspect defines two main pointcuts: encrypt (line 5) and decrypt (line 6). Each pointcut defines the points where the messages will be encrypted (line 2) or decrypted (line 3). To control the activation of the pointcuts we use the if() pointcut constructor that AspectJ provides to define a conditional pointcut expression which will be evaluated at runtime for each candidate join point. 1 This mechanism increases the degree of dynamicity by coding patterns that can dynamically support enabling and disabling advice in aspects  (Andrade et al. , 2013). In our example, the AspectsStatus class contains the configurations and status (enabled/disabled) of the aspects that are changed at runtime by the Aspect Weaver module. The aspect defines two advice associated with the encrypt and decrypt pointcuts: one for encrypting (line 8) and one for decrypting (line 14) CAM messages.
The advice use a CypheringModule object that provides the functionality for encryption and decryption and is configured with the algorithm and parameters indicated in the AspectsStatus class (lines 9 and 15). Once the aspects have been adapted, the Aspect Weaver module notifies the Monitoring Tool in order to inform about the status of the deployment (activity labelled 5 in Fig. B3 ). That is, to notify whether or not the deployment was successfully carried out and which aspects were deployed/deployed/ reconfigured.
Dynamic monitoring of security policies In order to maintain the correlation between the security policies, the aspects, and the security properties, the application and the aspects are monitored at runtime by the Notification module. The Notification module reports the application's internal events (e. g. , traces with state changes, error conditions, timestamps, method status, etc. ) to a monitoring server (the Monitoring Tool) (activity labelled 7 in Fig. B3 ). To operate at runtime, the Notification module is introduced into the target application as an aspect in the instantiation phase. The target source code is annotated, using standard Java annotations, to specify the measurement points (or meters) that generate the monitored data. These annotations are also incorporated using AOP without manually modifying the source code of the application, e.
Furthermore, the Context Awareness module notifies the Monitoring Tool but, in contrast to the Notification module, the Context Awareness monitors changes in the environment (activity labelled 8 in Fig. B3 ), i. e. , contextual changes that are external to the application such as packets over the communication network, battery status of the device, CPU consumption, etc. Both traces and context changes are sent to the Monitoring Tool that interprets them (activity labelled 8 in Fig. B3 ) so it can react to changes or adapt the security rules with the negotiation of a new security policy. The right-hand side of Fig. B3  shows an excerpt of a sample trace received by the Monitoring Tool with three events generated from the Notification module. For instance, the first event (event with name Pursuing_DCL) provides the values of the attributes captured by the monitoring annotation.
Evaluation and discussion In this section we quantitatively evaluate the performance overhead of the dynamic deployment of security policies and the dynamic monitoring of the application. Also, as part of our participation in the INTER-TRUST project, the deployment modules (the Aspect Generation 3  and the Aspect Weaver 4  ), the monitoring modules (Notification and Context Awareness) 5  as well as the MMT tool 6  presented in this paper have been used to implement a demonstrator of the project that provides dynamic adaptation of security policies for two real case studies: the ITS case study presented in this paper and an online electronic voting (e-voting) case study. This demonstrator has been evaluated both quantitatively, by controlled tests performed for the implementation of the modules, and qualitatively, by collecting the opinion of software developers with different Listing 4 -MMT-security property.
Performance of deployment The performance overhead of the deployment process considers the time from the reception of a security deployment specification in the Aspect Generation module to the execution of the adaptation plan by the Aspect Weaver. This time includes the generation of the adaptation plan by the Aspect Generation and the interaction with the aspects in order to weave, unweave, and/or reconfigure them. We consider the number of aspects that need to be dynamically adapted (i. e. , woven, unwoven, or reconfigured) in order to fulfill the required functionality specified in the security policy. The results are summarized in Fig. B4  where the performance presents a linear increment of the overhead over the number of aspects. We observe that the overhead introduced by the adaptation process is lower than the one initially expected.
The attack model We have identified a set of vulnerabilities that can break the correlation in our approach. Table  B2  shows examples of attacks based on the identified vulnerabilities. For each attack, we present the result of the effectiveness in detecting the attack by the Monitoring Tool. According to the vulnerabilities identified, we assume that an attacker is able to access and corrupt sensitive information that is interchanged and managed by the INTER-TRUST framework modules. This kind of attack would be possible due to vulnerabilities V1-V4 and V6-V7. By exploiting these vulnerabilities, the attackers can follow a deceptive attack model  (Ajay, 2012) , where deception can be defined as an interaction between two parties, a deceiver and a target, in which the deceiver successfully causes the target to accept as true a specific incorrect version of reality, with the intent of causing the target to act in a way that benefits the deceiver  (Teixeira et al.
Finally, a rule in the security policy may be maliciously deactivated by omitting the information about that rule in the security deployment specification that is received by the Aspect Generation module. This will avoid the weaving of the corresponding aspect. The same benefit can also be obtained by exploiting the security vulnerability introduced by the Spring AOP runtime weaver (vulnerability V5), or any other AOP solution offering runtime weaving. Here the attack model is different because the attacker does not modify the information interchanged by the modules and instead directly injects new code into the running application by means of aspects. However, the consequence is the same: the security level of the application is altered (the same examples illustrated before apply here). There is a particular situation in which the false-data injection attack can cause a denial-of-service attack, understanding that the service that is denied is the application security.
Undetectable attacks The knowledge that the attackers have regarding how the INTER-TRUST framework works can make some of the attacks undetectable. Some of the situations have already been mentioned. For instance, the attacker is undetectable if the security policy is simultaneously altered in both the Aspect Generation module and the Monitoring Tool (vulnerability V2). Also if the attacker knows that the process of adapting a security policy at runtime is transactional and in consequence any error deploying the security policy (e. g. , a required aspect is not described in the aspectual knowledge or no implementation class is found in the aspect repository for a required aspect) leaves the system in the previous stable state, vulnerability V3 could be used to perform a denial-of-service attack by avoiding the correct deployment of the negotiated security policy.
This paper describes an ontology evolution activity designed for a data integration system called ONDINE (Ontology based Data INtegration) which proposes a complete workflow to acquire, annotate and query experimental data extracted from scientific documents. The core element of the ONDINE system is an ontology which allows experimental data annotation and querying. In order to adapt to domain changes, new usages and new annotated data, the ontology may change. This paper presents our a priori ontology evolution activity, which takes as input an ontology in a consistent state, defines and applies some changes and manages all the consequences of those changes by producing an ontology in a consistent state. The implementation and evaluation of the evolution activity are presented. Our work is illustrated through an ONDINE system's use case, the annotation of experimental data in the domain of matter transfer.
(2006). The conceptual component of naRyQ is divided into two subcomponents: a core conceptual component to represent n-ary relations between experimental data and a domain conceptual component to represent specific concepts of a given application domain. naRyQ can therefore be reused for different application domains: only the specific part of the OTR, which is at the heart of the scientific experimental data integration, must be redefined to use naRyQ for another domain. The first version of the ONDINE system, containing the annotation and querying subsystems, were presented in  Buche et al. (2013)  with results in three distinct domains: microbial risk, chemical risk and aeronautics. Relying on these successful experiences of using ONDINE for different application domains, three new projects were developed.
Mahfoudh et al. (2015)  propose a framework based on graph rewriting rules that maintains a set of constraints. In our work, we have combined, adapted and extented these existing approaches on ontology evolution in order to propose a naRyQ a priori evolution activity taking into account its main originality that is its inter dependent concepts to manage experimental data. Our approach was implemented in a plug-in, called DynarOnto, designed to assist domain experts in the naRyQ evolution activity. The extended version of ONDINE presented in this paper where the OTR evolution is taken into account is given in Figure  1. ONDINE system is composed of three subsystems: (1) the annotation subsystem of experimental data extracted from scientific documents using concepts from naRyQ; (2) the querying subsystem designed to query the annotation knowledge base using naRyQ, (3) the new subsystem, detailled in this paper, designed to manage naRyQ evolution in a consistent way.