dataesr/scientific-paragraphs-categorization huggingface dataset:
Taverna Taverna  [55]  is an open source scientific workflow management system that provides a workbench for designing workflows, an embedded workflow engine for local execution, and a separate workflow server for remote execution. Workflow specification. A Taverna workflow is defined in terms of the SCUFL2 language  [56] , an XML format that extends W3C PROV. Taverna workflows are mainly data driven although for-each loops can be expressed. Processors can be associated with local programs (bean script, R-script) or remote programs (REST service, cloud service). A user can specify a workflow from scratch or use existing workflows as embedded subworkflows. Taverna is in principle domain-independent. However, it has been used extensively in the life sciences. Taverna also embeds search capabilities to retrieve workflows and tools from myExperiment and biocatalogue, respectively.
Galaxy Galaxy  [57, 58]  is very popular workflow system in the bioinformatics community. Workflow specification. Galaxy workflows are internally specified as composite tasks, each of which is defined by a tool descriptor specifying the associated software and input and output parameters. Galaxy uses a dedicated JSON format for specifying workflow, although a fork of it utilize the Common Workflow Language (CWL). Galaxy supports nesting of subworkflows. Galaxy uses Toolshed, a repository  [45]  to manage tool versions as well as their dependencies for automated local deployment. It also provides Galaxy Pages to document and share the above-mentioned elements in a humanreadable form. Workflow execution. Galaxy uses Histories, which trackes workflow executions, through tool configuration parameters, input parameters, including reference datasets  [45] , and produced results.
It also provides a GUI for exploring and sharing workflow executions. Context and runtime environment. Galaxy allows the use of a number of external solutions to resolve tool dependencies, such as Docker, to provide a persistent and portable execution environment. Regarding scientific-wide packaging, Gonzalez-Beltran et al. showed how galaxy workflows can be packaged into reproducible research objects and ISA-TAB experiments  [59]. Galaxy: limitations in the context of reproducibility. Galaxy currently encounters four main limitations. The first limitation is due to the technical complexity of the system relying on specific software and reference datasets that must be locally available with the appropriate version to allow workflow repeat. Although best practices for managing the system can prevent such issues, the use of Toolsheds can lead to duplicated maintenance effort, when the same tools need to be available outside of the Galaxy environment.
OpenAlea OpenAlea is an open source scientific workflow system with a visual programming environment that enables users to design, execute and interact with workflows. Being domain-independent, OpenAlea has been used in a variety of domains but its main applications come from the plant science community (e. g. , with the simulation of crop physiology and development). Workflow specification. The architecture of OpenAlea is based on the Python language. Every component in OpenAlea can be accessed through the language, allowing the user to interact with the outputs of a workflow execution, to drive the execution and to extend the system by adding new components dynamically. OpenAlea provides users with the possibility of exporting workflow specifications into a CWL format. OpenAlea tools (e.
g. , models, workflows, components) are published and shared as Python packages on the web either on public repositories (e. g. , PyPi), or through the main OpenAlea web repository and through dedicated web sites of groups which use and contribute to OpenAlea 16. Workflow execution. OpenAlea is equipped with a provenance module to keep track of the data items produced during execution. OpenAlea has recently launched a new feature where workflow executions can be exported as notebooks: Each cell of the notebook contains the script of the workflow node executed  [60]. The input/output data are direct references to the data produced and stored. When workflow executions have a complex structure (e. g. , because loops are involved), this approach is not a suitable solution. Context and runtime environment.
OpenAlea uses the distribution/installation mechanism of Python packages to share both tools and workflows. Workflows and tools are both viewed, in OpenAlea, as components. OpenAlea packages are extensions of classical Python packages. They contain data, tools libraries and workflow specification. OpenAlea packages can be automatically converted to Debian or rpm packages, because they contain enough meta-information and inherit of the features of Python packages. OpenAlea is thus compatible with several systems, from local virtual environment (e. g. , VirtualEnv, Conda) to virtual machines (Vagrant) and Docker containers. OpenAlea: limitations in the context of reproducibility. Reproducibility in OpenAlea encounters several limitations. The first limitation is the possible large and hidden complexity of the system which depends on a large and heterogeneous set of interconnected libraries, both provided by the OpenAlea community, but also developed by single users and dynamically discovered by the OpenAlea package manager.
While this feature allows end-users to add new packages and share them with the OpenAlea community, several workflows may not be usable if their dependencies are not released as public OpenAlea packages. A second limitation which concerns both reproducibility and reuse is the lack of central repository for OpenAlea workflows, packages and provenance. Searching for a given tool or workflow is limited to packages already installed on a given computer. This solution guarantees that any workflow found on a computer will be actually runnable. In return, it hampers the simple exchange of workflows and the discovery of workflows currently in development elsewhere. A third limitation concerns is with respect to workflow execution presentation. While OpenAlea is able to capture the provenance of execution and expose it to users as electronic notebooks, there is no simple solution to visualize and navigate a huge amount of provenance data in a concise way.
Nextflow Nextflow  [61]  is a command-line based workflow system implemented in Groovy  [62]  (a scripting language for the Java Virtual Machine), developed to simplify design of complex parallel scientific workflows. Unlike workflow systems presented above, it comes with no GUI. Workflows are written in text files, and run in a terminal, or with the help of NextflowWorkbench  [63] , an integrated development environment (IDE). Workflow specification. Nextflow is based on the dataflow programming model. A workflow is made of two kinds of nodes: processors (as in Taverna) and operators (that can be seen as native processors), and its edges are channels that represent the data flow and connect two nodes. Nextflow processors are responsible for the execution of scientific computations, and are specified by defining their input and output channels and the computation to execute.
Computations are defined as generic scripts (shell, groovy, or any scripting language). Descriptions of processors also specify how the computation will be executed (local mode, HPC platform or cloud). Nextflow operators are used to apply specific transformations to data (e. g. , connecting or forking channels, filtering data, etc. ). Workflows are specified using a dedicated language that, unfortunately, is not based on a standard. Workflow execution. Workflow execution is deduced from the input and output channels of each processor, and its initial data. If a processor is added or modified, or input data is modified, only computations that are affected by the change are rerun if resume mode is enabled. Moreover, using the cache directive, a processor can specify if it must be rerun each time or not.
Nextflow does not use or extend a standard for workflow execution. It does not provides either a means for annotating them. Nextflow does not provide a proper module to query and/or visualize workflow executions. Context and runtime environment. Nextflow does not directly support tool dependency management. If a tool needed by the workflow is not present in the running system, runs will not complete. However, it uses several systems to minimize the risk of having missing tools, and to keep track of each version of tools that have been run. For example, it is compatible with Docker. Each processor can thus specify in which docker container it must run, or which tool to load from modules. Docker will take care of automatically downloading the containers required for the workflow execution. Nextflow users are encouraged to use git hosting services (e.
g. , GitLab, BitBucket and GitHub) as workflow repositories. Nextflow can automatically retrieve and execute a workflow located in a public repository on GitHub for example. Nextflow: limitations in the context of reproducibility. Nexflow encounters three main limitations. First, as there is no central repository of tools, it is the responsibility of the developer to implement the workflow in a reproducible way. If the workflow does not control the tools used to execute it using Docker module and git, it may be difficult or impossible to reproduce. Second, once the workflow executed, provenance information consists of tags associated with each processor in output log files. As it does not rely on a reference vocabulary, it is not possible to query this data so far. Third, on the one hand, Nextflow is versatile in the sense that it is very easy to install and workflows can be developed very quickly.
Ensuring reproducibility and reuse has obviously to face with numerous social issues (willingness to share, following good practices. ). However, and most importantly, we have identified key issues, proper to reproducibility and reuse with scientific workflows, which highly depend on progress made in several research fields of computer science. Scientific workflows and their executions have very complex graph structures. Comparing workflows or executions, storing the history of workflows (e. g. , to cite the workflows reused), reducing the structure of such graphs to make them more reusable, are directly related to the design of efficient graph algorithms which are key challenges in graph algorithmics and databases. As for chaining the use of workflows (possibly coming from different systems), rewriting a workflow into another equivalent (but more simple) workflow, optimizing a workflow execution while ensuring its repeatability relies on key issues of languages theory and software engineering.
Acknowledgement The authors acknowledge the support of  GDR CNRS MaDICS , programme  CPER Région Bretagne "CeSGO", and programme Région Pays de la Loire  " Connect Talent " (SyMeTRIC). We acknowledge funding by the call " Infrastructures in Biology and Health" in the framework of the French "Investments for the Future"  ( ANR-11-INBS-0012  and  ANR-11-INBS-0013 ). This work was conducted in part at the  IBC (Institute of Computational Biology) in Montpellier, France.
Introduction CompiLIG is a collaboration between Compilatio 1 -a company particularly interested in crosslanguage plagiarism detection -and LIG research group on natural language processing (GETALP). Cross-language semantic textual similarity detection is an important step for cross-language plagiarism detection, and evaluation campaigns in this new domain are rare. For the first time, SemEval STS task  (Agirre et al. , 2016)  was extended with a Spanish-English cross-lingual sub-task in 2016. This year, sub-task was renewed under track 4 (divided in two sub-corpora: track 4a and track 4b). Given a sentence in Spanish and a sentence in English, the objective is to compute their semantic textual similarity according to a score from 0 1 www. compilatio. net to 5, where 0 means no similarity and 5 means full semantic similarity.
The evaluation metric is a Pearson correlation coefficient between the submitted scores and the gold standard scores from human annotators. Last year, among 26 submissions from 10 teams, the method that achieved the best performance  (Brychcin and Svoboda, 2016 ) was a supervised system (SVM regression with RBF kernel) based on word alignment algorithm presented in  Sultan et al. (2015). Our submission in 2017 is based on crosslanguage plagiarism detection methods combined with the best performing STS detection method published in 2016. CompiLIG team participated to SemEval STS for the first time in 2017. The methods proposed are syntax-based, dictionary-based, context-based, and MT-based. They show additive value when combined. The submitted runs consist in (1) our best single unsupervised approach (2) an unsupervised combination of best approaches (3) a fine-tuned combination of best approaches.
Cross-Language Character N-Gram (CL-CnG) CL-CnG aims to measure the syntactical similarity between two texts. It is based on  Mcnamee and Mayfield (2004)  work used in information retrieval. It compares two texts under their n-grams vectors representation. The main advantage of this kind of method is that it does not require any translation between source and target text. After some tests on previous year's dataset to find the best n, we decide to use the  Potthast et al. (2011) 's CL-C3G implementation. Let S x and S y two sentences in two different languages. First, the alphabet of these sentences is normalized to the ensemble = {az, 0 -9, }, so only spaces and alphanumeric characters are kept. Any other diacritic or symbol is deleted and the whole text is lower-cased. The texts are then segmented into 3-grams (sequences of 3 contiguous characters) and transformed into tf.
Cross-Language Conceptual Thesaurus-based Similarity (CL-CTS) CL-CTS  (Gupta et al. , 2012; Pataki, 2012)  aims to measure the semantic similarity between two vectors of concepts. The model consists in representing texts as bag of words (or concepts) to compare them. The method also does not require explicit translation since the matching is performed using internal connections in the used "ontology". Let S a sentence of length n, the n words of the sentence are represented by w i as: S = {w 1 , w 2 , w 3 ,. , w n } (1) S x and S y are two sentences in two different languages. A bag of words S ′ from each sentence S is built, by filtering stop words and by using a function that returns for a given word all its possible translations. These translations are jointly given by a linked lexical resource, DBNary  (Sérasset, 2015) , and by cross-lingual word em-beddings.
More precisely, we use the top 10 closest words in the embeddings model and all the available translations from DBNary to build the bag of words of a word. We use the MultiVec  (Berard et al. , 2016)  toolkit for computing and managing word embeddings. The corpora used to build the embeddings are Europarl and Wikipedia sub-corpus, part of the dataset of  Ferrero et al. (2016)   2. For training our embeddings, we use CBOW model with a vector size of 100, a window size of 5, a negative sampling parameter of 5, and an alpha of 0. 02. So, the sets of words S ′ x and S ′ y are the conceptual representations in the same language of S x and S y respectively. To calculate the similarity between S x and S y , we use a syntactically and frequentially weighted augmentation of the Jaccard distance, defined as: J(S x , S y ) = Ω(S ′ x ) + Ω(S ′ y ) Ω(S x ) + Ω(S y ) (2) where S x and S y are the input sentences (also represented as sets of words), and Ω is the sum of the weights of the words of a set, defined as: Ω(S) = n i=1 , w i ∈S ϕ(w i ) (3) where w i is the i th word of the bag S, and ϕ is the weight of word in the Jaccard distance: ϕ(w) = pos weight(w) 1-α.
Translation + Monolingual Word Alignment (T+WA) The last method used is a two-step process. First, we translate the Spanish sentence into English with Google Translate (i. e. we are bringing the two sentences in the same language). Then, we align both utterances. We reuse the monolingual aligner 4  of Sultan et al. (  2015 ) with the improvement of  Brychcin and Svoboda (2016) , who won the cross-lingual sub-task in 2016  (Agirre et al. , 2016). Because this improvement has not been released by the initial authors, we propose to share our re-implementation on GitHub 5. If S x and S y are two sentences in the same language, then we try to measure their similarity with the following formula: J(S x , S y ) = ω(A x ) + ω(A y ) ω(S x ) + ω(S y ) (6) where S x and S y are the input sentences (represented as sets of words), A x and A y are the sets of aligned words for S x and S y respectively, and ω is a frequency weight of a set of words, defined as: ω(A) = n i=1 , w i ∈A idf (w i ) (7) where idf is the function which gives the inverse document frequency of a word.
Results on SemEval-2016 Dataset Table  1  reports the results of the proposed systems on SemEval-2016 STS cross-lingual evaluation dataset. The dataset, the annotation and the evaluation systems were presented in the SemEval-2016 STS task description paper  (Agirre et al. , 2016) , so we do not re-detail them here. The lines in bold represent the methods that obtain the best mean score in each category of system (best method alone, unsupervised and supervised fusion). The scores for the supervised systems are obtained with 10-folds cross-validation.
Runs Submitted to SemEval-2017 First, it is important to mention that our outputs are linearly re-scaled to a real-valued space [0 ; 5]. Run 1: Best Method Alone. Our first run is only based on the best method alone during our tests (see Table  1 ), i. e. Cross-Language Conceptual Thesaurus-based Similarity (CL-CTS) model, as described in section 2. 2. Run 2: Fusion by Average. Our second run is a fusion by average on three methods: CL-C3G, CL-CTS and T+WA, all described in section 2. Run 3: M5 ′ Model Tree. Unlike the two precedent runs, the third run is a supervised system. We have selected the system that obtained the best score during our tests on SemEval-2016 evaluation dataset (see Table  1 ), which is the M5 ′ model tree  (Wang and Witten, 1997)   M5P in Weka 3. 8. 0 (Hall et al. , 2009) ).
Results of the 2017 evaluation and Discussion Dataset, annotation and evaluation systems are presented in SemEval-2017 STS task description paper  (Agirre et al. , 2017). We can see in  To investigate deeper on this issue, we manually annotated 60 random pairs of each sub-corpus (120 annotated pairs among 500). These annotations provide a second annotator reference. We can see in Table  3  that, on SNLI corpus (4a), our methods behave the same way for both annotations (a difference of about 1. 3%). However, the difference in correlation is huge between our annotations and SemEval gold standard on the WMT corpus (4b): 30% on average. The Pearson correlation between our annotated pairs and the related gold standard is 85. 76% for the SNLI corpus and 29. 16% for the WMT corpus. These results question the validity of the WMT corpus (4b) for semantic textual similarity detection.
Conclusion We described our submission to SemEval-2017 Semantic Textual Similarity task on track 4 (Sp-En cross-lingual sub-task). Our best results were achieved by a M5 ′ model tree combination of various textual similarity detection techniques. This approach worked well on the SNLI corpus (4afinishes 1 st with more than 83% of correlation with human annotations), which corresponds to a real cross-language plagiarism detection scenario. We also questioned WMT corpus (4b) validity providing our own manual annotations and showing low correlations with those of SemEval.
Numerical implementation We are concerned with numerical implementation of the micromechanical model into the commercial software Abaqus Ò via its user subroutine UMAT. Taking the simplified isotropic model for example, the state variables include the scalar damage variable d, the inelastic strain ε p and the state variable 2. 23 )) should be written in its rate form. The increment of the plastic strain can be related to the total strain increment by applying the plastic consistency condition and the normality rule. The following expression is finally obtained: ℂ tan ¼ ℂ m À 1 H 1 À ℂ m : D Á 5 À D : ℂ m Á (38) where D ¼ vf =vs c denotes the flow direction of plastic strain; and H 1 is the hardening modulus and can be written as H 1 ¼ vf vd vg vε p : D 0 vg vd À vf vε p : D (39) As usual, a prediction-correction numerical scheme is followed.
Methods in morphological analysis of 2D images of the growth forms of branching organisms have been developed in several studies  [6, 7]. In these studies the analysis is based on the construction of a 2D morphological skeleton of a branching object in the images. The morphological skeleton of the branching object can be used to measure various biologically relevant characteristics. Many steps in this analysis have been done in a manual way requiring visual interaction in many places. To date, there are open 2D image analysis software that perform on plant organs such as leaves (LeafJ  [8] , LAMINA  [9] , and leaf processor  [10] ). These programs can measure mainly shape, length, width, perimeter, surface of leaves, and leaf venation pattern, but they are not designed to measure some other important morphological traits, which are very essential to our samples, such as branch thickness and branch spacing.
Root system architecture (RSA) software (DART  [11] , root system analyzer  [12] , RootReader2D  [13] ) are the most similar to our software. Their algorithms share some similar features such as junction radius, branch length, and branch angle; however, those also lack the measurements of branch thickness and branch spacing. Riccardia, a plant genus in the liverwort family Aneuraceae, is represented by pinnate to tripinnate thalloid plants creeping or erecting on various substrates (rocks, dead wood, soil), and grows mainly in tropical areas and always in humid climate. Its dimension ranges from some millimeters to a few centimeters. It is the largest genus among the family Aneuraceae, with more than 300 names  [14] , which should be a hundred of accepted species after greatly-needed revision  [15].
Image pre-processing We used the raster graphics editor, GIMP 2. 6. 12 [27]  and the image processing package based on ImageJ, Fiji  [28] , to process original color sample images. The color image is converted to 8-bit grayscale, thereafter thresholding is performed using the Ostu method to obtain a binary image. However, the given threshold value is then adjusted to obtain the best binary image closet to the original image. Therefore, different threshold values are assigned for different images. We use morphological operations to improve the quality of the image by using opening operation to remove some stray foreground pixels in the background and closing operation to fill holes in the foreground.
Morphometric software In our morphometric software, a number of procedures were applied to obtain quantitative measurements (Fig. 3 ). Skeletonization produces a skeleton image from the pre-processed image. Skeleton graph generation then uses the skeleton image to generate skeleton graph. The morphological measurements use the pre-processed   2  The framework of the morphological measurement and analysis system Fig. 3  Schematic overview of procedures in our proposed software image, skeleton image and skeleton graph to produce a set of quantitative results, which are visualized in graphical representation and stored in text files. The software was written entirely in C language for high performance under the developing environment of QT Creator. This allows for greater visual interactivity and control.