dataesr/scientific-paragraphs-categorization huggingface dataset:
Control at run-time It can not be foreseen at compilation time if two different rules with different events and contradictory actions will be activated at the same time instant at run-time. Coordination or control techniques have to applied in that case. Heptagon/BZR is designed to provide this kind of run-time control. Inconsistency at run-time is controlled with the already described code generated for the devices. Contradictory signals can be discarded or delayed depending on the chosen policy. This provides more control on the execution of rules than avoiding the rules. In case that one rule has more than one action, only the inconsistent actions will be discarded or delayed, allowing the rest of actions to be performed. In this case, inconsistency is not only detected, as in the compilation time, but solved using the order priority to discard or delay signals.
In case of the absence of the tick signal, the oscillation is considered as undesired. To avoid this situation, besides the automaton, a contract is included in the Heptagon/BZR code. This contract indicates that the Error state must not be reached. The use DCS in Heptagon/BZR can control the avoidance of this oscillation at run-time using the delaying automata. Application-specific issues can be considered additionally to the above generic ECA rule-based system issues, for specific scenarios with specific requirements. These requirements can also be expressed in Heptagon/BZR, to provide more control on the ECA rule set execution. These requirements are also difficult to express in ECA rules, because of the lack of language support to describe them, but their violation would cause inconsistencies during the execution.
Our work offers users with a combination of a high-level ECA rules language with the compiler and formal tool support of Heptagon/BZR, which can seen in both ways: formal support of ECA rules, and user-friendly language above Heptagon/BZR. We are presently working on the integration of the generated controller, using the executable code in C or Java, in an experimental embedded platform for small or home environments where users could introduce ECA rules in the system to control home sensors and actuators using the automatically generated safe controller. We are also working on the possibility to automatically provide device models representing their behavior. This allows specifying, at the same level as ECA rules rather than in Heptagon/BZR, safety properties for applicationspecific scenarios as the one described in last section.
The reconstruction theorem For an arbitrary wave vector η = (η 1 , η 2 ) t ∈ R 2 , consider the source terms F (x, t) = η ⊥ × ne iη•x-i|η|t , E 0 (x) = η ⊥ e iη•x , and E 1 (x) = -i|η|E 0 (x), (2. 1) where the vector η ⊥ is the unit vector orthogonal to η. Assume that the boundary measurements curl E and curl E α on Γ 0 × (0, T ), ( have been recorded from the data (2. 1). Notice that the corresponding exact background solution E, solution to the unperturbed problem (1. 3) for the source terms (2. 1), is the plane wave E(x, t) = η ⊥ e iη•x-i|η|t. (2. 3) The reconstruction method, based on the knowledge of the boundary measurements (2. 2), requires the resolution of an exact boundary controllability problem. Therefore, we assume that the part of the boundary Γ 0 where the measurements have been recorded, and the final time T geometrically control Ω in the sense of  [14].
Acknowledgments The authors thank  Marc Miskin ,  John Bush ,  Ruben Rosales  and  Anand Oza  for useful discussions. This research is supported by the  AXA Research Fund  and the  french Agence Nationale de la Recherche , through  the project  " ANR Freeflow", LABEX WIFI (Laboratory of Excellence   ANR-10-LABX-24 ) within the  French Program Investments  for the  Future  under reference  ANR-10-IDEX-0001-02 PSL.
Modelling the case study with Alloy Alloy  [3]  is a formal system-modelling language amenable to automatic analyses. Alloy is implemented as a cost-less free-software tool, the Alloy Analyzer, which is programmed in Java and hence runnable on the majority of platforms. Alloy has recently been used in the context of security assessment, for instance to model JVM security constraints  [5] , access control policies  [6] , or attacks in crytogrpahic protocols  [4]. Besides, we proposed in earlier work a preliminary study of the safety assessment of the LPV system  [2]. In this article, we propose to enrich this study by considering a more complete architecture and by expressing and verifying both safety and security objectives. The AltaRica  [1]  language, which is widely use for safety assessment, would have been another possible choice.
This paper gathers some contributions to script and its nature identification. Different sets of features have been employed successfully for discriminating between handwritten and machine-printed Arabic and Latin scripts. They include some well established features, previously used in the literature, and new structural features which are intrinsic to Arabic and Latin scripts. The performance of such features is studied towards this paper. We also compared the performance of five classifiers: Bayes (AODEsr), k-Nearest Neighbor (k-NN), Decision Tree (J48), Support Vector Machine (SVM) and Multilayer perceptron (MLP) used to identify the script at word level. These classifiers have been chosen enough different to test the feature contributions. Experiments have been conducted with handwritten and machine-printed words, covering a wide range of fonts.
Experimental Results Analysis Experiments have been carried using two public databases: IAM database for Latin handwritten and IFN-ENIT for Arabic handwritten words. For Latin and Arabic machine-printed scripts, we created our own database by extracting words from various magazines and newspapers which contain variable font styles and sizes. A scanning resolution of 300dpi is employed for digitization of all the words (See Fig. 23 ). The training and test words have 1720 samples each, consisting of equal number of Printed Arabic (PA), Handwritten Arabic (HA), Printed Latin (PL) and handwritten Latin (HL) words. In the training phase, the features and the correct In Table  6 , we give the correct identification rates for each proposed and previously used feature using Bayes (AODEsr classifier)  [21].
the average accuracy is the same, about 98. 72% for handwritten and machine printed words either in Arabic or Latin scripts. Notice that, with the selected features, printed Arabic words can be identified, in a reliable way, with a correct identification rate of 100%. When observing the confusion matrix (See Table  10 ), we note that it is about confusion cases between handwritten Arabic and Latin scripts. Most of them mainly come from their cursive nature. Confusion, between printed and handwritten Latin script arise because of the writing styles of many writers who do not use ligatures between the letters. We also compared the performance of five typical classifiers: Bayes (AODEsr), k-Nearest Neighbor (k-NN), Decision Tree (J48), Multilayer Perceptron (MLP) and Support Vector Machine (SVM) (See Table  11 ).
Comparing with Existing System Using the selected features, the AODEsr classifier captures significant amount of the differences between machine-printed and handwritten Arabic and Latin words providing a good solution for this task. To compare it with a system proposed in  [12]  which deals with the same problem, we used a common database (our database composed of 1720 word samples). Recall that  [12]  proposed an identification system, at word level, based on steerable pyramid transform and using k-NN as classifier. Notice that we tried to reproduce their system considering the same conditions as stated in their paper  [12]. We used steerable-pyramid feature  [21]  with 4 orientation sub-bands, at 2 scales. Feature vector dimension is 48 to represent 8 sub-bands. The feature vector was constructed using the computed mean, the standard deviation, the Kurtosis, the magnitude of the transformed word image and the energy, the homogeneity and the correlation calculated from gray level co-occurrence matrix applied to the same transformed word image.
A. Audio Inpainting The following experiments deal with a single source ( ) formed of a real piano sound sampled at 11025 Hz. A 1. 25 ms-short stereophonic signal ( ) has been synthesized by filtering the monophonic recording of a loud C3 piano note from the MUMS database  [35]  with two room impulse responses simulated using the Matlab code presented in  [36]   5. The TF representation of this signal has then been computed by applying a critically sampled PR cosine modulated filter bank ( ) with frequency bands, involving filters of length samples. The resulting TF representation, of dimension with , is displayed in Fig. 3. In particular, it can be noticed that the two channels are not synchronous (the starting time in the left channel is s, whereas it is s in the right channel), which suggests that the order of filters should be chosen greater than zero.
B. Source Separation In this section, we aim to illustrate the ability of HR-NMF to separate pure tones with close frequencies, based on the autoregressive parameters , in a difficult underdetermined setting ( )  7. For simplicity, we have chosen to deal with a 2 s-long monophonic mixture ( ), composed of a chord of piano notes, one semitone apart (A4 and Ab4 from the MAPS database  [37]     estimation methods, less sensitive to initialization, in order to perform source separation in a fully unsupervised way.
5 µs. The efficiencies where calculated in terms of the area of the pulses. The error bars are the standard deviation of about 5 measurements. light onto a detector (single pass through crystal). The input pulse trace is obtained by creating a transparent window around the input pulse frequency. For the case of cavity enhancement, where we detect the light reflected off the cavity, we measured the input pulse trace by simply inserting a block after the partly reflecting cavity mirror and by normalizing with the known mirror reflectivity. The data shown in Fig. 3b  results in a cavity-enhanced efficiency of 10 for some of the delays, with an average gain of 8. 4. We also note that the single-pass efficiency η single-pass =3. 7±0. 1% obtained at 1/∆=4µs is close to the theoretical limit that is 4.
We thank  Nicolas Sangouard ,  Félix Bussières ,  Hugues de Riedmatten  and  Sergey Moiseev  for useful discussions and  Claudio Barreiro  for technical support. We gratefully acknowledge  R. Cone  and  R. M. MacFarlane  for lending us the isoptically pure 153 Eu:Y 2 SiO 5 crystal. This work was financially supported by the  Swiss National Centres of Competence in Research (NCCR)  project  Quantum Science Technology (QSIT ) and by the  European projects SIQS (FET   Proactive Integrated  Project) and  CIPRIS (People Programme  ( Marie Curie Actions ) of the European Unions Seventh Framework Programme FP7/2007-2013/ under REA Grant No. 287252 ).
INTRODUCTION In the last decade, the information technology explosion has led to changes in the organization and management of companies. In order to improve their reaction and adaptation period, companies have interested in tools supporting capitalization and management  (Gandon, 2002). Knowledge management systems have helped organizations to capture, to capitalize and to share their knowledge. They enrich their in-house knowledge by capturing statements extracted from various sources of information (documents, databases, websites. ). These statements could be transformed into ontology compatible elements or axioms, to describe domains in a formal way. However, the dynamic facet of domain has brought about ontology evolution to keep the knowledge up to date. Handling the ontology evolution process in a distributed, decentralized environment is timeconsuming and complex process.
The ontology engineer uses inconsistence sheets which contain the inconsistency code and the changed term, to reach the modification. Another study of ontology evolution and MAS is given in  (Rahman et al,. 2012 ). The authors present MAEKM (Multi Agent Enterprise Knowledge Management) based on ontologies modelling functional domains and multiagent architecture performing the data retrieval and managing the changes that may occur within the data sources. Our work presented in this paper can be compared with some similar existing studies. (Sellami et al. , 2012)  has presented DYNAMO as MAS for building and evolution TOR from texts. Nevertheless, this approach considers the agent as term and the MAS as ontology and it not has been mentioned the ontology evolution process. In  (Rahman et al.
Learning Module This module receives a document as input. Using Text2Onto  (Maedche, et al,2000)  which is a framework for data-driven change discovery by incremental ontology learning. It uses natural language processing and text mining techniques. The output generated is XML/OWL file. This one contains the extracted terms. These terms are categorised as concepts, instances and taxonomic relations. As example of concept presentation: <a:Concept rdf:ID="non infection inflamatory pathology_c"> <a:Ratingrdf:datatype="http://www. w3. org/2001/XMLSchema#d ouble">0. 0136986301369863</a:Rating> <owlx:Labelrdf:datatype="http://www. w3. org/2001/XMLSchema #string">night</owlx:Label> </a:Concept> Example2. Let's consider a change made by user 1 which adds a new medical report. The user agent verifies if the document exists.
Efficient implementation of linear functions First of all, we notice that matrices described in Sec. 2 are precomputed. As for AES, the matrices for G and H (See Eq. (  16 )), and for  17 )) are precomputed. Also, the one non-trivial linear operation, namely xtime (Eq. (  18 )) is also stored masked, as L (Eq. (  19 )). G T • (G • G T ) -1 and H T • (H • H T ) -1 (Eq. ( Besides, the computation of vector-matrix products, a priori of n × n complexity, can be enhanced by using the natural parallel feature of processors. For instance, one can compute a vector-matrix product in a bitslice manner  [4]. The algorithm for the computation of vector-matrices products is given in Alg. 2. Moreover, a version in C language is in Alg. 3. Algorithm 2 Vector-matrix product (bitslice approach on k = 8 bits) The vector-matrix products are processed by blocks of 8 × 8.
DSML (Domain Specific Modeling Languages)   are an alternative to general purpose modeling languages (e. g. UML or SysML) for describing models with concepts and relations specific to a domain. DSML design is often based on Ecore metamodels, which follow the class-relation paradigm and also require defining a concrete syntax which can be either graphical or textual. In this paper, we focus on graphical concrete syntax, and we introduce an approach and a tool (Diagraph) to assist the design of a graphical DSML. The main principles are: non-intrusive annotations of the metamodel to identify nodes, edges, nesting structures and other graphical information; immediate validation of metamodels by immediate generation of an EMF-GMF instance editor supporting multi-diagramming. We report a comparison experience between Diagraph and Obeo Designer (a commercial proprietary tool), which was conducted as part of a Model Driven Engineering Course.
In this paper we are interested in graphical concrete syntaxes. These have been somewhat neglected by language theorists: there is no consensus, as this exists with MOF for abstract syntaxes or EBNF  (Garshol, 2003)  for textual concrete syntaxes, about a descrip-tion language for graphical concrete syntaxes. Indeed, designing and implementing a graphical notation is a complex activity requiring significant expertise, both in its semiotic and cognitive concerns, and in its technical and operational aspects. Several solutions for developing graphical syntaxes exist, but none of them satisfies all our needs. In particular, we are interested in a framework that offers at the same time: an easy to use solution, a native support of the multi-view paradigm, a native or easy support of nested nodes, an integration in the Eclipse-OSGI ecosystem, which is a de facto standard in the Model Based Engineering field, an open technology, with a published metamodel, MOF compliant, and a released tool (regularly updated).
In this paper, we propose a method and a tool (Diagraph) for agile development of graphical modeling languages on top of Ecore  (Budinsky et al. , 2003). The objective of Diagraph is to design Domain Specific Modeling Languages (DSML). These languages are closely tailored to elicit models representing complex systems in general, even beyond software engineering. Such models, even if they belong to a specific domain, must describe in general, structural concepts (composite things), operational concepts (work-flows, processes) that convert composite things or behaviors that define the states of the systems. The Diagraph framework provides a set of tools and processes that supports the design of these languages, by defining simultaneously their abstract syntax (metamodel) and their concrete syntax (notation and diagrams).
The Diagraph description language allows us defining a new graphical modeling language by annotating the metamodel (abstract syntax). Diagraph includes the multiple view paradigm. We also aim to integrate Diagraph into the Eclipse ecosystem, and to comply with the current standards of Model Based Engineering (MBE). Thus, we designed Diagraph as a technical overlay over GMF  (Gronback, 2009) , which is powerful but overly complex for the end user. In addition, we propose a process, which lacks in most of the existing propositions. In our context of academic research, we wish to propose an open tool and its related concepts at the disposal of the MBE community. At the end of this paper we relate an experiment, where we compare Diagraph and Obeo Designer  (Juliot and Benois, 2009) , a proprietary framework.
In Section 2, we study the existing state of the art. In Section 3 and 4 we present our contribution: A process in two phases, some key features of our tool, the Diagraph language, and its underlying metamodel. In Section 5 we give a use-case that typifies the problem of designing a graphical concrete syntax while designing the metamodel. In Section 6, we relate the experiment we did to compare Diagraph and Obeo Designer. We conclude in Section 7 and discuss future research directions.
Styles are also associated with the graphical elements. Constraints on the model can be expressed in an OCL-like language. The user experience of Obeo Designer goes through capturing the concrete syntax by the mean of property editors, through a process, which is described in a user guide. That process is as complex as it needs a primary help given by Obeo's experts team. The underlying metamodel of Obeo Designer is not published nor documented. Obeo Designer and MetaEdit+ are commercial tools that are split in two different parts: a workbench, a tool for designing modeling languages and a modeler, a tool for using modeling languages. While Diagraph is tightly integrated in the Eclipse platform, its principle is inspired by Eugenia  (Kolovos et al. , 2010) , which consists to annotate the metamodel with concrete syntax statements, by the mean of EAnnotation objects.
However, Eugenia is a very thin layer over GMF, which hides the complexity of the latter, but, it does not provide large scale metamodel handling as does Obeo Designer. As it results from the above survey, several limitations of the existing work lead us to design a new language and framework. The Table  1  summarizes some features available in the candidate frameworks. None of the latter reaches completely our requirements: an ideal tool would combine the ability to work simultaneously on the abstract syntax and the concrete syntax as does Eugenia (but not Obeo Designer), and manage multiple views as does the latter. As we will explain in the remainder of the paper, these 13 features are offered by Diagraph, our tooled method for designing Domain Specific Graphical Modeling Languages.
The Framework The modeling framework, named Diagraph, supports the described process, the annotation language, and includes the mega-model manager. Diagraph contributes to the Eclipse platform  (Budinsky et al. , 2003)  as a plugin, in a non-intrusive way, on the top of legacy tools. The Diagraph Framework is a component conforming to the OSGI (Castro Alves, 2011) industrywide standard, plugged within the Eclipse Platform, contributing to already existing services (e. g. it uses the layout service of the Ecore Tools, through the OSGI protocol). The principle of the user interface is not that of a wizard, but of a grammar that defines the graphical concrete syntax upon the abstract syntax. The user is guided by the reference manual that describes the Diagraph language syntax, at one hand, and the messages (and in the future a code completion feature) generated by the Diagraph internal parser in case of syntax errors, while writing the Diagraph annotations in a compartment beneath the EClass compartments in the class diagram editor.
Key Feature The key feature of Diagraph is the management of the graphical complexity. The paradigm of composition by graphically nesting model elements (when they are semantically and structurally nested), is a key factor in the quality level of cognitive effectiveness. Many well known notations use actively such constructs: statecharts  (Harel, 1987) , package representation in UML, hierarchical functional models  (Ross, 1977). Defining a compartment rather than an external related node is done by changing one keyword of the Diagraph description language (ref becomes kref ). The graph structure of the concrete syntax (considered as an abstract graph) is preserved when switching from nested nodes to associated nodes: further tooling that would handle pattern recognitions or similarity scoring between different models deals with the same computable graph structure  (Falleri et al.
, 2008). When the nesting becomes too deep, the positive effect of the nesting paradigm declines and disappears. It is then necessary to hide the nested details included and adopt the paradigm of additional view equivalent to a zoom on the hidden details. The view definition is a native part of the Diagraph Language. As with compartments, the abstract graph structure of the concrete notation is preserved. The separation of the model into different views represents a System Architecture, conforming to the IEEE 1471 information model  (Muller, 2009) ).
The Diagraph Metamodel The abstract syntax of the Diagraph language is a straightforward metamodel which conforms to a specialized graph. The Figure  1  shows a simplified version of the positional part of the Diagraph metamodel (at the right) associated to the Ecore metamodel (at the left). The stylistic part is based on another independent metamodel that is here out of the scope, for the sake of clarity. The metamodel of Diagraph represents an abstract diagram which has a graph structure. Nodes can be graphically integrated into each other (if the attribute compartment is true). Elements of the concrete syntax (DGraphElement) belonging to the diagram are mapped by the csMappingEdge reference to elements belonging to the Ecore metamodel (ENamedElement). That principle of mapping a concrete syntax onto an abstract syntax is also described by  (Brambilla et al.