dataesr/scientific-paragraphs-categorization huggingface dataset:
Functional annotation Gene candidate sequences retrieved from both transcript-discovery approaches were then compared to existing databases for gene name assignment. First, gene candidates were compared to the NCBI RefSeq transcript database by using BLASTN (parameters: -strand plus; -dust no; -soft_masking no). Comparison was limited to Aves (birds) sequences (taxid 8782). Gene candidates with a percentage of identities >90% for chicken genes or 75% for bird genes, and bidirectionally covered on at least 50% of their length were assigned to the corresponding hits. Gene candidates matching several discordant gene names, such as chimeric and fused gene candidates, were manually investigated and corrected. Non-annotated gene candidate sequences were then compared to the NCBI human (taxid 9606) and mouse (taxid 10090) non-redundant protein database by using BLASTX from BLAST+ v2.
2. 31+  (Camacho et al. , 2009)  (parameters: -strand, plus; -seg, no). Gene candidates with a percentage of homology of at least 30% and covered by at least 50% of their length were filtered. Matching protein accession numbers were converted into gene accession numbers by using the Hyperlink Management System  (Imanishi and Nakaoka, 2009). ORF prediction was finally performed on remaining gene candidates by using TransDecoder v2. 1. 0 (Haas et al. , 2013)  (strand specificity parameter: -S). ORFs of at least 100 amino acids were annotated by using Trinotate v3. 0. 1 (https://trinotate. github. io/). Functional annotation was based on the following protein predictions: (i) BLASTX and BLASTP homology search against the SwissProt database  (Bairoch et al. , 2004) ; (ii) protein domain prediction against the Pfam database  (Punta et al.
Comparison with galGal5 UCSC (galGal5) and Ensembl (release 89) reference annotations associated with the galGal5 genome version were downloaded from the UCSC browser and merged by using the Cufflinks tool Cuffmerge v2. 1. 1  (Trapnell et al. , 2010). RNA-seq strand-specific read pairs were mapped against the chicken genome galGal5  (Warren et al. , 2017)  by using TopHat2 v0. 14  (Kim et al. , 2013)  ( parameters: -r 150; -N 3; -read-edit-dist 3; -library-type fr-firststrand; -i 50; -G) and the merged reference annotations as guide. Sequences of annotated galGal5 transcripts were retrieved from the RefSeq database (ftp://ftp. ncbi. nih. gov/genomes/Gallus_gallus/RNA/) and compared to the predicted gene candidates by using BLASTN ( parameters: -perc_identity 90; -strand plus; -dust no; -soft_masking no).
Fragment counting Strand-specific read pairs mapped against the chicken genome and the artificial chromosome generated from the de novo transcript discovery were first split by strand by using SAMtools v1. 2  (Li et al. , 2009)  according to their FLAG field (strand plus: -f 128 -F 16, -f 80; strand minus: -f 144, -f 64 -F 16). Fragments (both reads of a pair) mapped on gene features were counted by using featureCounts v1. 4. 6-p3  (Liao et al. , 2014)  (parameters: -p; -s 2; -ignoreDup; -B; -R). Chimeric fragments aligned on different chromosomes were taken into consideration to overcome the gene fragmentation due to the location of gene parts on multiple chromosome contigs.
Acknowledgements We thank  Georgeta Leonte  ( Freie Universität, Berlin, Germany ) for helping preparing and collecting the samples,  Steṕhane Descorps-Declere  and  Marc Monot  ( Institut Pasteur, Paris, France ) for critical reading of the manuscript, and  Roman Eremchenko  for fruitful discussion. We are grateful to the  Sequencing Core Facility of the Max Planck Institute for Molecular Genetics  for processing the RNA-seq. We are thankful to  Peter Hansen  and  Peter N. Robinson  ( CharitéUniversitätsmedizin, BCRT, Berlin, Germany ), as well as  Marius van den Beek  and  Christophe Antoniewski  ( Institut de Biologie Paris-Seine, ARTbio, Paris, France ) for providing access to Galaxy web servers.
Data availability RNA-seq data have been deposited on the Gene Expression Omnibus (GEO) database under the SuperSeries accession number GSE100517. Both samples that have been used for this study are available under the SubSeries GSE100516 via the accession numbers GSM2685833 and GSM2685834. Gene annotation model in GTF format associated with the galGal4 version of the chicken genome and sequence of the artificial chromosome in FASTA format are available at https:// sourceforge. net/projects/dualtranscriptdiscovery/.
For this purpose, a model set of PPARγ template ligands was generated on the basis of PPARγ agonist-receptor complexes from the Protein Data Bank (PDB). More specifically, the template set was created from twenty-three PDB PPARγ ligands accounting eleven full and twelve partial agonists (see S1 File). Each template was made from an agonist-bound PPARγ structure and removal of the receptor leaving the template agonist in its crystal conformation. Afterwards, individual alignment attempts of a given test molecule on each of the generated templates followed by reintroduction of the receptor and energy calculation, provided a hit list of matching binding modes. According to the targets encoded by these templates, a binding profile for the test ligand was generated. In order to identify and implement rational threshold values for the docking screen, all twenty-three known PPARγ model ligands were docked with the procedure described above.
Competitive binding assays IC 50 values for respective compounds were determined by competitive binding using timeresolved fluorescence resonance energy transfer (LanthaScreen, Invitrogen) on a Victor2 microplate reader (PerkinElmer). Briefly, a terbium labeled anti-GST antibody was used to label purified GST-tagged PPARγ-LBD (ligand binding domain). Energy transfer from terbium to the tracer, a fluorescent pan PPAR agonist, enabled read-out of each test compounds's ability to displace the tracer. RFU values from dose-response curves (triplicate sampling) for test compounds as well as positive controls (rosiglitazone) were then analyzed using GraphPad Prism  [33]. An unrestrained sigmoidal (one-binding site) dose-response curve was fitted to each data set by linear regression and allowing for determination of IC 50 values.
Six hours after addition of transfection mix to the cells, the media was changed to media (MEM or DMEM) supplemented with vehicle (0. 1% DMSO), positive control (1 μM Rosiglitazone, 30 nM GW7647, 1 μM L165041 or 0. 2 μM LG1069 for PPARγ, PPARα, PPARδ and RXRα, respectively), or compound. Approx. 18 hours later, cells were harvested and lysates analyzed for Photinus and Renilla luciferase activity by luminometry. All data points were performed in at least triplicate and each sample measured in duplicate. Luminometer raw data was analyzed in Microsoft Excel spreadsheets and presented as column graphs depicting average values of triplicates and including standard deviations.
Multiple flexible alignment template Evaluation of the dihydropyrano[2,3-c]pyrazoles 4, 10a-10ah PPARγ binding modes was carried out using a multiple flexible alignment approach. The model was developed, refined and evaluated using the flexible alignment application of the MOE software. The agonist model set was generated using the SVL Batch FlexAlign script, based on a PDB compound set of eleven PPARγ full agonists and twelve seven PPARγ partial aonists. The set of model agonists was composed of known antidiabetic drugs, including Rosiglitazone (TZD) and Farglitazar (non-TZD) and other biological relevant agonist with either selective PPARγ or dual PPAR-α/γ, PPAR-δ/γ selectivity; no pan PPAR agonists were included. The compound set employed in the development of the PPARγ agonist binding model is given in S2 File in the Supporting Information.
A common file data format encourages a decentralized community of atlas development, in contrast to the Scalable Brain Atlas's centralized model. This decentralized development model would also allow ''best of breed'' or specialized tools to become widely used across many atlas projects, building community and simplifying user training. As members of 1 https://www. gnu. org/licenses/licenses. en. html 2 https://github. com/INCF/HAWG-examples HAWG, we have contributed our experience with internal data formats in 3D Slicer  (Pieper et al. , 2004) , our open source medical image informatics and visualization platform, towards the standard development process. While the HAWG standardization efforts have their genesis in neuroscience, a flexible atlas interchange format has clear utility for the broader atlas community as well.
, 2015) , but with HAWG's data format as a foundation for interoperability. Compared to BrainBrowser, we have chosen to tailor OABrowser more as a standalone application suitable for use by a wide audience. OABrowser also includes novel collaborative features such as globally-shared bookmarks and dynamic shared views. The OABrowser is part of our effort to open our atlas development pipeline and encourage community participation and code reuse. OABrowser and our larger atlas efforts are funded through the Neuroimage Analysis Center (NAC), an NIH-sponsored biomedical resource center. Our anatomy atlases are used by various NAC internal research efforts and also serve as a way to disseminate the results of the Center's biomedical research. While NAC is focused specifically on neuroimaging, our broader biomedical research has produced atlases of the head and neck, abdomen and knee.
With NAC's charter of dissemination, and based on our success in developing free and open source medical software  (Pieper et al. , 2006; Kapur et al. , 2012) , we have chosen a development philosophy emphasizing freely available tools and an open development process for creating shared anatomy atlases and atlas software. Our code, data and tools are licensed under the 3D Slicer open source license 7  , which allows for liberal use, reuse, and redistribution for any purpose, including commercial applications. Furthermore, OABrowser is designed to be as accessible as possible to a broad community, including the general public. In order to test OABrowser, we have converted several of our imaging-derived anatomy atlases to draft HAWG data format and made the resulting atlases available for viewing.
METHODS The OABrowser application is implemented as a single-page web application using current web standards. It is designed to work with three-dimensional anatomy atlases with volumetric imaging, geometric models and text metadata. The user interface consists of a cross-sectional slice panel on the left, a threedimensional structure panel in the middle, and a text-based structure hierarchy on the right. The 3D display window shows geometric models of anatomic structures along with textured cross-sections of volumetric data, which are also displayed in the slice panel. An information bar lying along the bottom of the interface is used to display information about selected structures. Screenshots of OABrowser viewing the SPL/NAC brain atlas is shown in Figure  1. The rest of this section describes the underlying software architecture of OABrowser.
Software Technology Stack OABrowser is implemented in the ES2015 dialect of JavaScript. It uses the Google-created Angular web framework 8 and the AngularUI 9 interface toolkit to manage the subwindows, menus and application state. WebGL is used to display three-dimensional models of anatomy. WebGL is implemented on all major desktop and mobile platforms and web browsers, providing accelerated three-dimensional graphics and imaging capabilities to a large audience. HTML canvases are used for image display in the cross-sectional slice panel. The higher-level JavaScript graphics library THREE. js 10 abstracts low-level WebGL graphics calls. THREE. js includes loaders for common image and geometry file formats. We have extended THREE. js's existing loaders to include better support for VTK files 11 and the NRRD image file format 12.
The application state data structure is indexed by unique identifier (known as a UUID 13  ) and saved either in application memory or a persistent database. Given a UUID, OABrowser can look up its state information and restore itself to the given configuration. For undo and redo, OABrowser using an in-memory internal stack to store application state. Every user interaction with the browser pushes a state object onto the stack. When the user clicks the browser's back and forward buttons, for example, OABrowser restores the respective state object and updates the user interface accordingly. OABrowser can also save application state to a centralized, world-readable networked database with a UUID key. Whenever the state of the user interface changes, the application state data object is saved away and a new one is created with a new UUID.
This UUID is included in the browser's URL string, which is updated as the user manipulates the atlas. At any one moment, then, the OABrowser URL contains enough information to load the application and recover sufficient application state to restore a viewing session. This URL is effectively a bookmark that allows the entire browser's state to be restored. OABrowser uses Firebase, a Google database and application framework, to implement shared application state. Firebase provides scalable real-time database services to web-browser based applications. It implements social logins from service providers such as Facebook, Google, GitHub and Twitter to allow users to write and edit their own bookmarks while allowing anyone to read them. While Firebase is a closedsource, commercial product, we are not fully dependent on it.
Open source alternatives such as RethinkDB/Horizon 14  or deepstream. io 15 could be adapted to provide the same type of services as Firebase if needed. In addition to traditional database services, Firebase broadcasts changes to entries in the database to interested web clients as they occur. Clients can use this information to update their internal application state. This feature allows multiple OABrowsers running across the network to synchronize, mirroring the appearance of the user interface for all users and allowing collaborative viewing and interaction. Firebase is part of the Google Cloud infrastructure, which assures sufficient capacity to support dynamic shared views between individuals, small teams, or in teacher-classroom settings.
DataSource The HAWG data format abstracts out the details of data access from the nodes that use the data. Data access is isolated in the DataSource node, which holds primary responsibility for describing data access through file names, URLs, or database queries. DataSource nodes, like all HAWG nodes, can be specialized by listing multiple types (For instance, a DataSource node that knows about remote files could be of type (''DataSource'' ''HTTPDataSource''). The use of types consisting of JSON lists is part of the JSON-LD standard and allows readers to function without implicit type information stored in a type hierarchy. Even naïve readers can distinguish DataSources from other node types, and more sophisticated ones can act differently on nodes that have more specialized subtypes. It is anticipated that one DataSource might provide data to multiple Segments (if, say, a single file contains multiple image segments, in which case the key for selecting the correct segment is stored in the Segment itself and passed on to the DataSource).
Revision Control and Data Store While not strictly part of the OABrowser application, the workflow we use for managing software development, creating atlases and distributing atlas data is an important element that underlies the AOBrower user experience. In our current atlas development workflow, we use the git distributed revision control system 16 and the GitHub collaborative code and data repository 17 for both collaborative editing and distribution. The atlas viewer software is stored in a public GitHub repository. Master copies of the data for all of our atlases also reside on GitHub, where they are accessible to all. Through GitHub, users and other developers can offer modifications and file bug reports that can be used to improve OABrowser and our atlases. For testing and modification, a developer can check out the latest ''master'' version (or any previous revision) of OABrowser or an atlas into a local repository on his or her computer.
The atlas browser can view local data during development. Once changes and edits have been made, the developer commits in the local version to the master atlas repository. Clones of the GitHub atlas repositories can be copied to any standard web server as needed. We are actively testing deployment release versions of the atlas using distributed content networks such as Google Cloud infrastructure. We currently use 3D Slicer as the primary authoring tool for our atlases. A python-based converter script extracts relevant atlas data and visual styles from Slicer's internal file format MRML and writes it out in the HAWG-derived format. The script is stored as part of the atlas viewer's source repository. We also have converter scripts to create HAWG files from simple TSV (tab-separated value) text tables.
Licensing The OABrowser software and sample atlases are licensed under the 3D Slicer License, which is based on the popular two-clause BSD license and includes some additional terms related to appropriate use in medical contexts. In particular, the Slicer License does not place any requirements on users or developers to release the source code of incorporating applications, in contrast to other licenses such as the GPL. We have found these licensing terms simplify collaboration with and dissemination to a wide range of academic and corporate institutions.
RESULTS OABrowser's original purpose was to validate the HAWG atlas data format and make our existing anatomy atlases available to the public through an ordinary web browser. We have been able to accomplish these goals and further gain new experience by 16 https://git-scm. com/ 17 https://github. com/ implementing collaborative features made possible through the use of contemporary web technologies. We explain our results by first explaining the basic features of OABrowser, followed by our experience with HAWG-based atlas creation, and concluding with a look at performance and current deployment issues.
Bookmarks Recall that OABrowser bookmarks are URL-indexed, globallyreadable descriptions of atlas and application state. To store personal bookmarks, an atlas user can log in to the atlas infrastructure using social logins such as Google, Facebook, Twitter, or GitHub. Once logged in, the user can save a bookmark to a Firebase-backed central store. The user can return to the same view of the atlas by accessing a bookmark list in the browser application or by pasting the bookmark's URL into a web browser (Figure  3 ). The user who creates a bookmark can also delete it. Because bookmarks from all atlas users are stored centrally on the network, bookmarks can be exchanged among users (assuming that the atlas data is network-accessible). Any user can load any bookmark (though only the bookmark creator can delete the bookmark) provided they have the bookmark URL.
OABrowser in Use Even as it serves a primary role as a data format test bed, OABrowser has been well-received by our user community. It functions as a lightweight atlas viewer and complements 3D Slicer's status as a capable but much heavier weight image analysis package in our environment. OABrowser requires no user training for installation and no infrastructure for download, making it suitable for casual use or classroom environments. It provides free access to a handful of locally-developed digital atlases for use in anatomy education and data inspection. Figure  5  shows screenshots of the atlases outside of the brain. Open access is available for both the application source code and the atlas data. Though our anatomy atlases are converted from 3D Slicer's internal data format to HAWG, the new format is simple enough that other source atlases can be converted to it using relatively simple scripting or text editing.
In addition to our 3D Slicer converter script, we also provide a python script that can produce an atlas from a text spreadsheet that includes structure names, label values and geometry file names. This approach is perhaps the simplest method of atlas creation. To test interoperability with atlases from other sources, we have converted one of the Mindboggle project's labeled brain data sets  (Klein and Tourville, 2012)  to an atlas (Figure  6 ). Bill Lorensen assisted with the conversion of MindBoggle datasets to VTK as part of his Open  Atlas project 18. The MindBoggle atlas generally displays well in OABrowser, although the initial release of this atlas has misregistration between slices and 3D models. Full compatibility and correct display of community atlases is a high priority for our ongoing work.
18 https://github. com/lorensen/OpenAtlas Performance Interactive performance is an important requirement of any end-user tool. Our current implementation provides adequate performance on a variety of computer platforms. For example, when displaying the SPL/NAC Brain Atlas (which contains 100 of structures and is represented by polygonal models with approximately 500K polygons), the anatomy browser can render image at 60 frames per second on common desktop and laptop computers, and maintain 20 fps on lower-end computers such as Chromebooks and Apple iPad Air 2. As such, we believe that rendering performance of the current application is sufficient for many uses and users. Loading atlas datasets across the network inevitably produces delays before interaction is possible. OABrowser uses standard web browser caching mechanisms to save local copies of the anatomy atlas data and the viewer application code itself.
Implementation Improvements The current implementation of OABrowser reflects its history as a development test bed and concept demonstration tool. We anticipate several near-term improvements in its implementation to make it both more useful and more maintainable. At the heart of our future plans for OABrowser is modularization. Several components of OABrowser functionality are independent, capable of being used in other applications and swapped for new implementations. These components include the HAWG parser, the WebGL rendering engine, the image format readers, the bulk data store and cache, the user interface and application core, and the collaborative synchronization mechanism. Modularizing these elements of OABrowser would greatly simplify the community development of the software and encourage new applications with similar features.
ACKNOWLEDGMENTS The authors wish to thank  Marianna Jakab  for her expert management of the SPL atlases. We would also like to thank the contributors who helped author our anatomy atlases, including  Florin Talos  and the  Psychiatry Neuroimaging Laboratory at BWH. Thanks to  David Kennedy  for introducing us to the  Human Atlas Working Group. Bill Lorensen  has been a supportive and knowledgeable advocate for open atlases for many years, and assisted us with testing and the conversion of the MindBoggle atlas.
DATA SHARING AND SOFTWARE AVAILABILITY OABrowser-based anatomy atlases are available at https://www. openanatomy. org/. The source code for OABrowser is available on GitHub at https://github. com/mhalle/oabrowser/. The SPL brain atlas is available at https://github. com/mhalle/splbrain-atlas. OABrowser and the SPL atlases are available under terms of the open-source 3D Slicer license: https://github. com/ Slicer/Slicer/blob/master/License. txt.