dataesr/scientific-paragraphs-categorization huggingface dataset:
Definition of the TDL Interpreter We call TDL Interpreter the component that embodies the TDL operational semantics we propose. Algorithm 1 shows the main loop of the interpreter. Its input is a TDL package that contains TDL test cases. Each test case uses a specific configuration that must be activated first to enable the test case execution (line 3). It also contains a set of behaviors of different types, each of which has a different operational semantics. For instance, to execute a behavior of type Message (line 5), according to its source gate, indeed the role of its container component, the argument is treated differently. When it has the SUT role, the argument is the expected result that has to be asserted (line 10) and when the role is the Tester, the argument is the test input data that has to be sent to the model under test (line 13).
Consequently, whenever the argument of the behavior is an OCL query, it will be sent to the model through the query evaluator that was previously initialized in line 3. To provide the mentioned communications while decoupling the TDL Interpreter from various execution engines, we rely on an specific interface for execution engines. Figure  5  shows the ExecutionEngine interface and the dependencies of the TDL Interpreter using a class diagram. Following the terminology of popular frameworks such as EMF, we call resource the artifact that contains the model to load and execute. A resource may be a file, or a URL to access the model remotely, or a database connection. The ExecutionEngine interface contains methods for setting up the execution engine based on the model under test (i. e. , the model to be executed) and its conforming xDSL, executing the model, setting the model in a specific state, and getting its current state.
Tool Support We implemented our approach as part of the GEMOC Studio  (Bousse et al. 2016 ), a language and modeling workbench defined on top of the Eclipse Modeling Framework (EMF). TDL is also implemented using EMF technologies, making it easier to make both work together. We used the ATL transformation language  (Jouault et al. 2006)  for implementing the Ecore to TDL transformation. For the TDL interpreter, we used Xtend  (Efftinge et al. 2012)  to implement the execution rules of the TDL operational semantics. To evaluate the OCL queries, we used the Eclipse OCL API  (Damus et al. 2020). The GEMOC Studio supports several metaprogramming approaches. This includes Java-based languages (Kermeta  (Jézéquel et al. 2015) , Xtend  (Efftinge et al. 2012) , and pure Java), the Action Language for EMF (ALE)  (Leduc et al.
2017) , xMOF  (Mayerhofer et al. 2013) , and a combination of a Java-based language with the MoCCML language (Deantoni et. Each of these approaches is supported by a dedicated execution engine. Hence, a significant part of the implementation of the TDL Interpreter is dedicated to managing all these execution engines properly. For instance, the TDL Interpreter must read the xDSL definition in a GEMOC-specific. dsl file to discover the used metaprogramming approach, in order to start the correct execution engine accordingly. Figure  6  shows a screenshot of the resulting tool. The source code is available on a public GitLab instance 5. There are GUI icons in the toolbar and the menu bar allowing the user to choose an xDSL and run the generator for it. To use the tool for testing the bit shifting FSM model (label 4), we initially run the generator for the xFSM DSL and the generated TDL packages can be seen in the Project Explorer (label 1).
e. , already described in Section 2) that are both provided by the GEMOC language workbench. We also used the open source project of the Arduino xDSL with Kermeta semantics, and then we implemented its semantics using the ALE language to have two different implementations of the Arduino xDSL. We made minor modifications in these existing xDSLs to match the assumptions described in Section 2. 1. As the last xDSL used in our evaluation, we have defined BPMN xDSL that is a representative of the Microflow DSL 7  , a real-world interpreted language introduced by the Mendix development platform. Microflow DSL enables the non-technical domain experts to define the application logic throug h data-flow Workflow: We applied our testing approach on each considered xDSL, following the same workflow. In reference to the approach overview depicted in Figure  4 , we initially executed the TDL Library Generator component.
The component generated a TDL library specific to each given xDSL, successfully. Since our approach provides testing facilities for models conforming to a given xDSL, we prepared a set of models under test (MUTs) conforming to each considered xDSL. Afterward, we defined test cases for each MUT using the model execution commands and the OCL queries provided by the generated TDL Library. Finally, all the test cases were executed on their related MUT, the test verdicts were set, and the test results were reported through the graphical view provided by our tool. All the tested models and their test cases are publicly accessible on a public GitLab instance. Evaluation result: Table  2  presents all the information related to our evaluation including 1) the size of each xDSL as the number of the EClasses of its abstract syntax and the number of lines of code (LoC) of its semantics; 2) the tested models with their size in terms of the number of their EObjects; 3) the number of LoC of the TDL library automatically generated for each considered xDSL; and 4) the test suite size as the number of the test cases per tested model along with the number of LoC manually written by the tester.
Most noticeably of all, it can be seen that, unsurprisingly, the size of the generated TDL Library increases with the size of the xDSL. This highlights one benefit of using our approach since the generated library provides all the TDL boilerplate code that the domain expert would otherwise write by hand. Therefore, the proposed approach reduces the cost of providing testing support for a given xDSL. Successful use of the approach for testing different executable models conforming to various xDSLs, demonstrates that it satisfies the genericity aspect. Discussion: Our experiment on the Arduino xDSL reveals some limitations of the proposed testing approach. Using this xDSL, one can define time-dependent behaviors in the Arduino models, such as turning on an LED after 200 milliseconds. It is also possible to define Arduino models that continuously collect data from the outside of the model (e.
g. , the ambient temperature) and react to specific event occurrences (e. g. , high rise and fall of the ambient temperature). To test the behavior of such models, the test cases should be able to communicate with the model under test during its execution. For example, sending test data to the running model at a certain time and asserting if the model reacts as expected. More precisely, to provide testing support for the xDSLs whose contain time-related concepts and/or have an event-driven behavior-called reactive DSLs-, specific requirements must be considered. In models conforming to reactive xDSLs, some behaviors can happen at a specific time or under reception of specific event occurrences from the outside of the model during its execution. For testing these kinds of behaviors, one possibility could be to support at least two new commands in TDL test cases: (1) controlling the execution of the tested model by requesting for the asynchronous execution of the model, waiting for a precise time duration, and requesting to stop the model execution; and (2) interacting with the tested model during its execution through the exchange of the event occurrences.
We say "core," because cloud platforms usually provide specialized serverless services to meet specific application requirements, packaged as BaaS (Backend as a Service). However, the focus of this chapter will be on the FaaS model, and very often, the words "serverless computing" and "FaaS" will be used interchangeably. The reason why FaaS drew widespread attention is because with FaaS platforms, a user-defined function and its dependencies are deployed to the cloud, where they are managed by the cloud provider and executed on demand. Simply put, users just write cloud functions in a high-level language and the serverless systems manage everything else: instance selection, auto-scaling, deployment, sub-second billing, fault tolerance, and so on. The programming simplicity of functions paves the way to soften the transition to the cloud ecosystem for end users.
Beyond some technical challenges, we do not see any fundamental reason why pure serverless data analytics would not flourish in the coming years. In the meantime, we will scrutinize the ServerMix model to provide a simplified programming environment, as much closer as possible to serverless, for data analytics. To this aim, under the context of the H2020 CloudButton project, we will work on the following three points: (i) Smart scheduling as a mechanism for providing transparent provisioning to applications while optimizing the costperformance tuple in the cloud; (ii) fine-grained mutable state disaggregation built upon consistent state services; and (iii) lightweight and polyglot serverful isolationnovel lightweight serverful FaaS runtimes based on WebAssembly  [15]  as universal multi-language substrate.
Beyond the list of sandboxing technologies for serverless computing, most of them battled-tested in the industry (e. g. , Amazon Firecracker VMs), several research works have proposed to relax isolation in order to improve performance. For instance,  [2]  proposes the abstraction of a process in serverless computing, with the property that each process can be run across multiple servers. As a consequence of this multi-server vision, the paper introduces a new form of isolation that ensures multi-tenant isolation across multiple servers (where the functions of the same tenant are run). This new concept of isolation is called coordinated isolation in the paper. Further,  [17]  proposes two ways of relaxing isolation. The first one is based on the fluid code and data placement approach, and the second way is by allowing direct communication and network addressing between functions.
Serverless Data Analytics Despite the stringent constraints of the FaaS model, a number of works have managed to show how this model can be exploited to process and transform large amounts of data  [19, 21, 31] , encode videos  [10] , and run large-scale linear algebra computations  [33] , among other applications. Surprisingly, and contrary to intuition, most of these serverless data analytics systems are indeed good ServerMix examples, as they combine both serverless and serverful components. In general, most of these systems rely on an external, serverful provisioner component  [10, 19, 21, 31, 33]. This component is in charge of calling and orchestrating serverless functions using the APIs of the chosen cloud provider. Sometimes the provisioner is called "coordinator" (e. g. , as in ExCamera  [10] ) or "scheduler" (e.
PyWren  [19]  is a proof of concept that MapReduce tasks can be run as serverless functions. More precisely, PyWren consists of a serverful function scheduler (i. e. , a client Python application) that permits to execute "map" computations as AWS Lambda functions through a simple API. The "map" code to be run in parallel is Scheduler AWS Lambda, Amazon S3 IBM PyWren  [31]  Scheduler IBM Cloud Functions, IBM COS, RabbitMQ ExCamera  [10]  Coordinator and rendezvous servers (Amazon EC2 VMs) AWS Lambda, Amazon S3 gg  [11]  Coordinator AW Lambda, Amazon S3, Redis Flint  [21]  Scheduler (Spark context on client machine) AW Lambda, Amazon S3, Amazon SQS Numpywren  [33]  Provisioner, scheduler (client process) AWS Lambda, Amazon S3, Amazon SQS Cirrus  [20]  Scheduler, parameter servers (large EC2 VM instances with GPUs) AWS Lambda, Amazon S3 Locus  [28]  Scheduler, Redis service (AWS ElastiCache) AWS Lambda, Amazon S3 first serialized and then stored in Amazon S3.
Next, PyWren invokes a common Lambda function that deserializes the "map" code and executes it on the relevant datum, both extracted from S3. Finally, the results are placed back into S3. The scheduler actively polls S3 to detect that all partial results have been uploaded to S3 before signaling the completion of the job. IBM-PyWren  [31]  is a PyWren derived project which adapts and extends PyWren for IBM Cloud services. It includes a number of new features, such as broader MapReduce support, automatic data discovery and partitioning, integration with Jupiter notebooks, and simple function composition, among others. For function coordination, IBM-PyWren uses RabbitMQ to avoid the unnecessary polling to the object storage service (IBM COS), thereby improving job execution times compared with PyWren.
" Consequently, our primary goal is to create a serverless data analytics platform, which "democratizes Big Data" by overly simplifying the overall life cycle and cloud programming models of data analytics. To this end, the 3-year CloudButton research project (2019-2021) will be undertaken as a collaboration between key industrial partners such as IBM, RedHat, and Atos, and academic partners such as Imperial College London, Institut Mines Télécom/Télécom SudParis, and Universitat Rovira i Virgili. To demonstrate the impact of the project, we target two settings with large data volumes: bioinformatics (genomics, metabolomics) and geospatial data (LiDAR, satellital), through institutions and companies such as EMBL, Pirbright Institute, Answare, and Fundación Matrix. The project aims to provide full transparency  [13]  for applications which implies that we will be able to run unmodified single-machine code over effectively unlimited compute, storage, and memory resources thanks to serverless disaggregation and auto-scaling.
Others have partly sacrificed isolation to achieve better performance, for example, by co-locating a tenant's functions in the same container  [1]. Also, a few frameworks for building serverless applications have emerged  [10, 19, 21]. But these systems still require a lot of engineering effort to port existing applications. Software fault isolation (SFI) has been proposed as an alternative isolation approach, offering memory-safety at low cost  [6]. Introducing an intermediate representation (IR) to unify the spectrum of languages used in serverless has also been advocated  [17]. WebAssembly is perfectly suited on both counts. It is an IR built on the principles of SFI, designed for executing multi-tenant code  [16]. This is evidenced by its use in proprietary serverless technologies such as CloudFlare Workers and Fastly's Terrarium  [9].
Finally, we have presented the CloudButton Serverless Data Analytics Platform and explained how it addresses the aforementioned trade-offs. CloudButton has demonstrated different levels of transparency for applications, enabling to run unmodified single-machine code over effectively unlimited compute, storage, and memory resources thanks to serverless disaggregation and auto-scaling. We predict that next-generation Cloud systems will offer a fully Serverless experience to users by combining both Serverless and Serverful infrastructures in a transparent way.
In fact, it is shown in  [BS09]  that this problem in undecidable even on strings. Hence we use here the term "logic" somewhat liberally, since having a recursively enumerable syntax is a usual requirement for a logic. The study of these two formalisms finds its motivation, among other topics such as descriptive complexity, in database theory. As databases are commonly stored on disk that implicitly order their memory segments, when one wishes to express a query in FO, one has access to an additional order on the elements of the database. However, making use of this order without care could result in queries that evaluate differently on two implementations of the same database, which is clearly an undesirable behavior. We want to use this order only in an invariant fashion; this way, the result of a query depends only on the database it is run on, and not on the way the data is stored on disk.
We investigate linguistic markers associated with schizophrenia in clinical conversations by detecting predictive features among Frenchspeaking patients. Dealing with humanhuman dialogues makes for a realistic situation, but it calls for strategies to represent the context and face data sparsity. We compare different approaches for data representation -from individual speech turns to entire conversations -, and data modeling, using lexical, morphological, syntactic, and discourse features, dimensions presumed to be tightly connected to the language of schizophrenia. Previous English models were mostly lexical and reached high performance, here replicated (93. 7% acc. ). However, our analysis reveals that these models are heavily biased, which probably concerns most datasets on this task. Our new delexicalized models are more general and robust, with the best accuracy score at 77.
7% (acc. ). Nevertheless, our analysis demonstrates that it probably corresponds to a bias in our data caused by the constraints imposed during the collection process. Most of the datasets are likely biased the same way. This analysis led us to delexicalized models while focusing on dimensions presumed to be affected in schizophrenia: morphosyntactic, syntactic, dialogue, and discourse information are therefore considered. Our best delexicalized model gets 77. 9% (acc. ) and shows the importance of morpho-syntactic information and high-level features in dialogue. When dealing with medical data, ethical questions arise. The diagnosis of schizophrenia is complex and relies on many indices. Automatic systems could provide psychiatrists with further clues, possibly alleviating the need for the patients to go through several cognitive tests, but this is a longreach goal.
Results Lexical features: We compare different representations for Full and Indiv. settings -the most similar to long narrative texts or short Twitter messages. As in previous work, we found that lexical information is very effective (Table  2 : bow and ngram) with at best 93. 66% in accuracy. However, analysis from previous studies suggested a potential issue:  Mitchell et al. (2015)  reported that healthrelated lexicon is more represented in the tweets dataset, and  Howes et al. (2012b)  that the most predictive unigrams are about conditions, treatment and, medication. We investigate our data using Spearman correlation 6  to rank lexical features and find similar results: terms linked to the condition are in top ranks for schizophrenia (maladie [disease], traitement [treatment], médecin [doctor]), while terms related to studies (licence [bachelor], thèse  [PhD] ) and social life (vacances [holidays], monde [world / people]) are correlated with controls.
Acknowledgements The authors thank the anonymous reviewers for their insightful comments and suggestions. This work was supported by the  PIA  project " Lorraine Université d'Excellence ",  ANR-15-IDEX-04-LUE , as well as the  CPER LCHN (Contrat de Plan État-Région -Langues, Connaissances et Humanités Numériques). We would like to thank the  Centre Hospitalier Le Vinartier  for having contributed decisively to the implementation of the experimentation. Experiments presented in this paper were carried out in secured nodes on the Grid'5000 testbed. We would like to thank the Grid'5000 community (see https://www. grid5000. fr).
Image-based high-content screening (HCS) on 30,000 small molecules has been for example used with a generative adversarial network to propose new small molecule structures that share similar morphological profile  [25]. Therefore, as phenotypic drug discovery studies do not rely on knowledge of the molecular target perturbed by a specific drug, the translation of the molecular mechanism of action in the context of a disease-relevant cell system i. e. , molecular phenotyping is the next challenge. In this context, we decided to develop a pharmacology network for phenotypic screening, integrating the ChEMBL database  [26] , pathways, diseases and a highcontent image-based assay for morphological profiling, Cell Painting  [27] , in a high-performance NoSQL graphics database (Neo4j ® ). The aim is to identify proteins modulated by chemicals that could be related to some morphological perturbations at the cell level and lead to some phenotypes, diseases and/or adverse outcomes.
Kyoto Encyclopedia of Genes and Genomes (KEGG) The KEGG pathway database (Release 94. 1, May 1, 2020, https:// www. kegg. jp) is a collection of manually drawn pathway maps representing the known molecular interactions, reactions and relations networks for several pathway categories such as the metabolism, cellular processes, genetic information processes, human diseases, or drug development  [29]. The KEGG pathway was integrated into the drug-target library collected from ChEMBL.
Morphological profiling Morphological profiling data from 20,000 compounds were gathered from the Broad Bioimage Benchmark Collection (BBBC) using the BBBC022 dataset called "Human U2OS cells-compound-profiling Cell Painting experiment"  [32]  (information: https:// data. broad insti tute. org/ bbbc/ BBBC0 22/). Basically, U2OS osteosarcoma cells were plated in multiwell plates, perturbed with the treatments to be tested, stained, fixed, and imaged on a high-throughput microscope. Then, an automated image analysis using CellProfiler (http:// cellp rofil er. org/) identified individual cells and measured morphological features on each of them in the aim to produce a cell profile  [33]. In the end, the comparison of the cell profiles treated with different molecules (or experimental perturbations) allowed to suit different objectives such as identifying the phenotypic impact of chemical or genetic perturbations, grouping compounds and/or genes into functional pathways, and identifying signatures of disease  [34].
In the BBBC022 dataset, there are 1779 morphological features measuring intensity, size, area shape, texture, entropy, correlation, granularity, angle between neighbours, etc. These parameters concern three "cell objects": the cell, the cytoplasm and the nucleus. For our study, only the relevant information was kept. As each compound has been tested between 1 and 8 times, the average value of each feature for each compound was used. Features with a non-zero standard deviation and not correlated with each other (less than 95%) were kept in each of the three classes. Finally, we have extracted the data matching the compounds extracted from the ChEMBL database.
Scaffold hunter We used a software called ScaffoldHunter  [35]  to cut each molecule into different representative scaffolds and fragments as follow: (i) Removing all terminal side chains preserving double bonds directly attached to a ring. (ii) Removing one ring at a time using a set of deterministic rules in a stepwise fashion to keep the most characteristic "core structure" until only one ring is left. Scaffolds are distributed in different levels based on their relationship distance from the molecule node (Fig. 1 ).
Neo4J ® The main tool used to create the graph database is Neo4j ® (https:// neo4j. com/). It allows the integration of large scales of data from numerous sources. Its architecture is composed of nodes that represent a specific object (e. g. , molecules, scaffolds, proteins, pathways, diseases…) linked by edges representing a relationship between two nodes (e. g. , a scaffold being part of a molecule, a molecule targeting a protein, a target that acts in a pathway, etc. ).