dataesr/scientific-paragraphs-categorization huggingface dataset:
Comparison of CusProSe with existing SMKEs predictors. To assess the performance of CusProSe in predicting SMKEs relative to other predictors, the catalogs of proteins obtained for each fungus were compared to those obtained with antiSMASH  18  and SMURF  16. The total numbers of SMKEs detected with the three predictors are shown in Fig. 3. The list of all proteins identified is available in supplementary data (File S3). Comparisons of the results obtained with the three software are also presented in Venn diagrams and tables of Fig. 4. As shown in both Figs. 3  and 4 , the effectiveness of CusProSe, antiSMASH and SMURF software varies according to the families of SMKEs. For DMATS, all members of this family were detected by the three software (Fig. 3 ). In contrast, differences were observed between the software for both the number of sequences recovered and the number of sequences correctly assigned, regarding PKS, NRPS and the PKS-NRPS hybrid enzymes.
fa b. fa c. fa and x. fa) and a set of other protein sequences such as a proteome (named here as dataset. fa) to iteratively feed the HMM profile. The output of iterHMMBuild includes, for each protein/protein domain of interest, the final HMM profile file (enriched. hmm). The different HMM profiles are then concatenated, and a database of profiles (database. hmm) is created and displayed in the output directory. ProSeCDA allows to search in a given protein dataset for multiple proteins of interest, defined by a user-specified set of domains and rules. The program takes as input a protein dataset of interest such as a proteome (dataset_2. fa file), an HMM profile database (database. hmm file) and a user-defined set of rules (rules. yaml file). The HMM profile database can the one created with IterHMMBuild or, alternative, any other user defined compatible database (in hmm format).
(b) Overview of the IterHMMBuild iterative enrichement process. In the first step of the procedure an HMM profile model is build from the query protein sequences (x. hmm). This initial profile is then used to identify sequences with similar domains in the user-specified protein sequence dataset (dataset. fa). If matching sequences are found, they are added to the initial query sequence file (creating a new file named x-enriched. fa), and a new HMM profile is built. This process is repeated until no new sequences are recovered (i. e. convergence is reached). When convergence is reached a final HMM file is build (named here as x-enriched. hmm) and dispalyed in the output directory. (c) Overview of the ProSeCDA steps. The first step of the procedure consists in the annotation of the protein dataset of interest used to mine proteins (such as a proteome, named here as dataset_2.
fa), with protein domains from a user-specified HMM profile database (HMM DB). In the next step, the annotated proteins (dataset_2. domtblout file) are filtered according to user-specified rules (rules. yaml file). Each rule is defined by different features including the protein family name, the "mandatory" list of domains (list of domains the protein must contain, green), and the "forbidden" list of domains (optional, list of domain the protein must not contain, red). All proteins matching those rules are selected and accessible in the output files. More details of Prosecda outputs are presented in Fig. 2. ◂ gus using the custom HMM profiles and ProSeCDA annotation rules were carefully analyzed and compared to previously published annotations  43, 44, 47, 48. The number and lists of all SMKEs are displayed respectively in Fig.
Discussion CusProSe, a novel protein annotation software, is a versatile and flexible tool that can be customized to suit different types of genome/proteome analyses. As an illustration, this software was here used to mine fungal genomes for key enzymes involved in SM. One of the goals of CusProSe was to improve the accuracy of detection of each type of fungal SMKEs. Our HMM profiles were built exclusively from well-annotated fungal genome sequences already mined for SMKEs. Our main purpose was to carry out a careful analysis of the output of CusProSe including a manual examination of the predicted enzymes. We focused our search on major fungal SMKEs such as PKS, NRPS, hybrid PKS-NRPS, DMATS, and the large family of TS. CusProSe performance was either similar to, or better than, antiSMASH and SMURF for the identification of fungal SMKEs.
This is due to a combination of both specific profiles and strict and carefully defined rules. In particular, CusProSe performed better for PKS-NRPS hybrids. CusProSe also clearly differentiated complete PKS and NRPS from PKS-like or NRPS-like enzymes. Moreover, for TS CusProSe was more sensitive than ant-iSMASH as it allowed the detection of all TS types and their classification into distinct sub-families, thanks to sub-family specific HMM profiles and rules, avoiding false positives. This is a major novelty and advantage as regards the search for TS enzymes, relatively to the existing predictors. Finally, our data demonstrate that, using HMM profiles built from a few well-annotated and representative proteins, and well-defined and adequate rules, it is possible to accurately identify candidate proteins of each enzyme family with high sensitivity and specificity.
CusProSe has so far been successfully used with genomes from well-known fungal species, representing the Eurotiomycetes, Leotiomycetes, Sordariomycetes and Dothideomycetes classes of the Ascomycota. Different species representing these or other fungal classes may also be mined. Our HMMs models may be further enriched by mining additional fungal genomes, including genome sequences from representatives of the Basidiomycota. The database of fungal HMM profiles created within the framework of the present study is available to the community, as well as the file of rules used by ProSeCDA for protein annotation. Each user can either use these tools directly or adapt them/create new ones according to specific needs. The rules file can evolve to take into account new requirements, for example detection of a new protein family or sub-family.
This means that a rule for a novel protein family can be added. A rule can also be easily deleted, or modified, in this case by adding a new "mandatory" or "forbidden" protein domain for example. A completely new rules file can also be constructed either manually using the required yaml format or the proposed graphical interface, as specified in the CusProSe Documentation. Importantly, CusProSe is not restricted to the prediction of SMKEs. It is a custom genome mining software package, whose integrating tools can be exploited in the context of any protein family / biological system. Its successful utilization for a fast, easy and accurate prediction of major fungal SMKEs presented here illustrates its interest to a broad community of biologists.
Methods Implementation, system requirements and availability. CusProSe was coded on Python 3, and details on its implementation can be found at the Documentation page https:// i2bc. github. io/ CusPr oSe/. The application requires Python version 3. 7. The external dependencies are the programs HMMER (version 3. 3)  49  , MUSCLE (version 3. 8. 1551)  50 , and Usearch  51. CusProSe is freely available. Its source code is distributed at https:// github. com/ i2bc/ CusPr oSe and updated versions will be accessible there. CusProSe is compatible with all platforms supporting Python, HMMER, and MUSCLE. The user runs the CusProSe tools IterHMMBuild and/ or ProSeCDA from the command line. The two packages can be run independently. The main steps of both pipelines are summarized in this "Methods" section.
IterHMMbuild package. Rationale, input and outputs of IterHMMBuild. The CusProSe IterHMMBuild tool allows the user to build an HMM profile representative of (a) seed protein sequence(s) by using a set of other defined protein sequences to iteratively feed the HMM profile (training set). Two inputs are required in a fasta file format: (i) either a fasta file with at least one protein sequence or a directory location where multiple individual fasta files are stored and (ii) a fasta file of protein sequences (dataset), such as a proteome, used to enrich initial protein sequence(s) of interest. There is no limit on protein sequence length, genome size or any other similar constraints for the input files. Input working examples are available in the cusProSe/iterhmmbuild/ datas directory of the CusProSe archive (https:// github.
com/ i2bc/ CusPr oSe). The fasta sequences of each seed set are aligned with MUSCLE and the resulting multiple sequence alignment is given as input to HMMER (both integrated in the IterHMMBuild software). The HMM profiles are then built for each domain/family with an iterative search protocol (see Sequence enrichment step below). An output directory includes, for each protein/ protein domain of interest, the final HMM profile file (domain. hmm), the final sequences file in fasta format used to build the HMM profile (domain_seed. fa), the multiple alignment file of those sequences at Clustal W format (domain_seed. clw), a log file containing a summary of the computation (info. log), and iter_i directories containing files obtained at each iteration cycle (i). More details on the iter_i/ files as well on the usage of Iter-HMMBuild and its different possibilities and parameters can be found at the IterHMMBuild Usage guideline section of the Documentation file (https:// i2bc.
github. io/ CusPr oSe/ ihb_ usage. html). Sequence enrichment step. The HMM profiles initially built are searched against the protein dataset given as input using the hmmsearch command from HMMER, integrated in the software. The purpose is to enrich the HMM profile models. All matching sequences with E-values less than 0. 01 (default value) and an expected accuracy per residue of the alignment above or equal to 0. 6 (default value) are retrieved. Those sequences are then merged to the initial input sequences. To ensure that sequences are not redundant, Usearch is applied with a threshold identity value of 90%. A new HMM profile is then build and the process is repeated until convergence is reached. The convergence is reached when the number of sequences at iteration i + 1 (Nseq i+1 ) is strictly equal to the number of sequences at iteration i (Nseq i ).
However, because the number of new sequences found after multiple consecutive iterations can be really low, or even negative, a counter is also used to evaluate the convergence status in order to prevent unnecessary iterations (i. e. iterations that will increase the computation time without significantly enrich the number of new sequences). This counter is incremented each time the difference between Nseq i+1 and Nseq i is negative or equal to 1 (default value). The convergence is then also reached when the value of this counter is equal to 3 (default value). In the end of the process a last HMM profile is build, the final enriched HMM profile. Building the HMM profile database. An HMM profile database from a set of individual enriched HMM profiles representative of different domain sequences of interest can be generated manually, by concatenation of the profiles, with the command create_hmmdb.
This is the case when profiles for each protein domain of interest are constructed separately in different runs, with a single seed domain fasta file given as input at each run. As an alternative the HMM database can also be built automatically when running IterHMMBuild, if a directory with multiple individual fasta files is given as input (see Documentation for further information on the different possibilities of HMM profiles and database constructions). ProSeCDA package. Rationale, input and outputs of ProSeCDA. The CusProSe ProSeCDA tool allows the user to detect proteins matching specific given domain architectures rules, defined by the user, in any desired dataset of proteins, such as a proteome. Three input files are required: a dataset of proteins in fasta format (dataset. fa), an HMM profile database (database.
hm), and a file describing the rules (rules. yaml). As for IterH-MMBuild there are no particular input constraints besides the specified file format. Input working examples are available at the cusProSe/prosecda/datas directory of the CusProSe archive (https:// github. com/ i2bc/ CusPr oSe). The output of ProSeCDA includes (i) a info. log file containing the summary log of the computation run, (ii) an output file of hmmsearch for the protein dataset analyzed (dataset. domtblout), (iii) an interactive web page allowing to visualize the results (index. html), (iv) 3 additional folders containing files read by index. html (css/ js/ and images/) and (v) a directory nammed "Results" containing different output files for rules matching proteins. This directory contains sub-directories for each rule for which proteins have been found, where the user can find, for each identified protein, an individual summary at an xml format, containing information such as the protein sequence and the boundaries of the conserved domain architectures (protein_ID.
xml). The protein sequence file in fasta format is also provided for each individual match (protein_ID. fa). Plots at the pdf format (protein_ID. pdf) showing a graphical representation of all of the domains that matched to the rules for a given protein can also be created (optional) and are displayed in the results/ sub-directories. Examples are shown in Fig. 2  of the manuscript. The computation time of an average Prosecda run with default parameters, on a computer with a Intel ® Core™ i7-4900MQ CPU @ 2. 80 GHz × 8 processor running the Linux operating system, was about 2. 4 sec. This time was increased to 2. 5 min on average with the plots at the pdf format option.
Creation of rules. Rules are written in a specific yaml (Yet Another Markup Language) format (https:// yaml. org/). A Graphical User Interface (GUI) accessible by running the create_rules script was implemented to help users in this task (see details in the CusProSe Documentation file). Each rule was defined by different features: Name (protein category/family name), Comment (optional feature; can be used to describe the rule), Mandatory list (list of domain names the protein must contain), and Forbidden list (optional list of domain names the protein must not contain). Annotation step: selection of matching domains. The annotation step of ProSeCDA assigns domains from the user-defined HMM profile database to matching sequences from a protein dataset of interest. The annotation procedure uses hmmsearch from HMMER to search for each of the HMM domain profile present in the userdefined rules file (see Creation of rules above) against the protein dataset.
Annotation of SMKEs with CusProSe and comparison with antiSMASH and SMURF. The test sets used to evaluate CusProSe predictions were composed of protein sequences from known protein families from manuallyanotated and revised fungal genomes and also from experimentally characterized proteins. The sequences are available in the Supplementary material (Folders Data S1 and Data S2). The initial training set was the genome of the fungus Magnaporthe oryzae (v. 8, Broad Institute) used to create the first hmm models. These were latter enriched by screening other fungal genomes. The enriched hmm models were then tested in a second round of analysis on additional well annotated fungi representive of different species and classes. The same fungal genomes mined with our tool (same version coming from the same public database) were given as input to antiSMASH  18  and SMURF 8 software (FASTA + GFF3 files as recommended) and the programs were run using their respective integrated profiles and rules.
Figure1. CusProSe package functionalities. (a) Overview of CusProSe. CusProSe contains two independent but complementary programs, IterHMMBuild and ProSeCDA. The figure schematizes the functioning of these tools. The IterHMMBuild program provides users with representative HMM protein profiles of interest, constructed by an iterative enrichment process, starting from a small set of defined protein seed sequences. Two inputs are required in a fasta file format: original seed sequence(s), (examplified here as a. fa b. fa c. fa and x. fa) and a set of other protein sequences such as a proteome (named here as dataset. fa) to iteratively feed the HMM profile. The output of iterHMMBuild includes, for each protein/protein domain of interest, the final HMM profile file (enriched. hmm). The different HMM profiles are then concatenated, and a database of profiles (database.
hmm) is created and displayed in the output directory. ProSeCDA allows to search in a given protein dataset for multiple proteins of interest, defined by a user-specified set of domains and rules. The program takes as input a protein dataset of interest such as a proteome (dataset_2. fa file), an HMM profile database (database. hmm file) and a user-defined set of rules (rules. yaml file). The HMM profile database can the one created with IterHMMBuild or, alternative, any other user defined compatible database (in hmm format). (b) Overview of the IterHMMBuild iterative enrichement process. In the first step of the procedure an HMM profile model is build from the query protein sequences (x. hmm). This initial profile is then used to identify sequences with similar domains in the user-specified protein sequence dataset (dataset.
fa). If matching sequences are found, they are added to the initial query sequence file (creating a new file named x-enriched. fa), and a new HMM profile is built. This process is repeated until no new sequences are recovered (i. e. convergence is reached). When convergence is reached a final HMM file is build (named here as x-enriched. hmm) and dispalyed in the output directory. (c) Overview of the ProSeCDA steps. The first step of the procedure consists in the annotation of the protein dataset of interest used to mine proteins (such as a proteome, named here as dataset_2. fa), with protein domains from a user-specified HMM profile database (HMM DB). In the next step, the annotated proteins (dataset_2. domtblout file) are filtered according to user-specified rules (rules. yaml file). Each rule is defined by different features including the protein family name, the "mandatory" list of domains (list of domains the protein must contain, green), and the "forbidden" list of domains (optional, list of domain the protein must not contain, red).
Acknowledgements This work and N. C. were supported by a grant from the  ANR (Agence National pour la Recherche, France ,  Herbifun  project  16-CE20-0023-01 ). We would like to thank all members of the  Herbifun consortium  for helpful discussions. We thank particularly  Adeline Simon  for sharing expertise on Botrytis cinerea secondary metabolism enzymes. The  INRAE BIOGER  unit benefits from the support of the  Saclay Plant Sciences-SPS  ( ANR-17-EUR-0007 ).
PURPOSE: Surgical workflow and skill analysis are key technologies for the next generation of cognitive surgical assistance systems. These systems could increase the safety of the operation through context-sensitive warnings and semi-autonomous robotic assistance or improve training of surgeons via data-driven feedback. In surgical workflow analysis up to 91% average precision has been reported for phase recognition on an open data single-center video dataset. In this work we investigated the generalizability of phase recognition algorithms in a multi-center setting including more difficult recognition tasks such as surgical action and surgical skill. METHODS: To achieve this goal, a dataset with 33 laparoscopic cholecystectomy videos from three surgical centers with a total operation time of 22 hours was created.
Labels included framewise annotation of seven surgical phases with 250 phase transitions, 5514 occurences of four surgical actions, 6980 occurences of 21 surgical instruments from seven instrument categories and 495 skill classifications in five skill dimensions. The dataset was used in the 2019 international Endoscopic Vision challenge, sub-challenge for surgical workflow and skill analysis. Here, 12 research teams trained and submitted their machine learning algorithms for recognition of phase, action, instrument and/or skill assessment. RESULTS: F1-scores were achieved for phase recognition between 23. 9% and 67. 7% (n=9 teams), for instrument presence detection between 38. 5% and 63. 8% (n=8 teams), but for action recognition only between 21. 8% and 23. 3% (n=5 teams). The average absolute error for skill assessment was 0.
, 2019b)  and autonomous annotation assistance of surgical workflow  (Bodenstedt et al. , 2019a; Lecuyer et al. , 2020)  underlines the importance and usefulness of surgical workflow recognition through machine learning. Another open data set is the Heidelberg Colorectal data set. It comprises 30 videos of three different types of laparoscopic colorectal surgeries, corresponding sensor data from medical devices in the OR and pixelwise semantic segmentation of surgical instruments  (Maier-Hein et al. , 2021). The successful use of the Heidelberg Colorectal data set during the Endoscopic Vision (EndoVis) challenges.
Due to their achievements, EndoVis (https://endovis. grand-challenge. org/) (28%), Cholec80 (21%), and JIGSAWS (17%) were mentioned as the most useful publicly available datasets for surgical data science  (Maier-Hein et al. , 2020a) , but there is still an urgent demand in the scientific community and medical device industry for high-quality data sets from laparoscopic surgery that allow a comparison of machine learning algorithms  (Maier-Hein et al. , 2020a). Apart from this, it is generally important to view medical recognition challenges with caution due to the lack of standardized and evidence-based quality control. For example, it is possible for later participating teams to boost their performance if the test data has been published  (Maier-Hein et al. , 2018). Moreover, standardized phase definitions are missing in the existing data sets, especially for laparoscopic cholecystectomy  (Garrow et al.
Data collection The data set contains n=33 videos of laparoscopic cholecystectomies from three surgical centers in Germany with a total video length of 22 hours. The total number of cases was chosen based on annotation capacity. The operation videos at Heidelberg University Hospital To comply with ethical standards and the general data protection regulation of the European Union, routinely collected data was used and anonymized. To this end, scenes outside the abdominal cavity, for example when the camera was pulled out for cleaning purposes, were manually censored (frames replaced were replaced with white frames) and files were renamed anonymously (HeiChole-1, HeiChole-2 etc. ).
Data annotation The anonymized video data were annotated with surgical knowledge by medical experts following annotation rules in the appendix. Annotation, i. e. labelling of each video frame with information about what is depicted in this frame, was performed using the video annotation research tool Anvil  (Kipp, 2014). The annotation included framewise annotation of surgical phases, actions and instruments as well as skill classification for procedures and selected phases. Thus, different perspectives of the surgical activity were annotated. According to Neumuth et al. a surgical activity consists of five components  (Neumuth et al. , 2009) , which are the functional, organizational, operational, spatial and behavioral perspectives. In this study, all perspectives exempt from the spatial were annotated.