dataesr/scientific-paragraphs-categorization huggingface dataset:
Data Accessibility Simulated data are available from  Lotterhos KE, Whitlock MC (2015)  Data from: The relative power of genome scans to detect local adaptation depends on sampling design and statistical method. Dryad Digital Repository: http://dx. doi. org/10. 5061/dryad. mh67v. The  Atwell et al. (2010)  data are publicly available from https://github. com/Gregor-Mendel-Institute/atpolydb. The POPRES data were obtained from dbGaP (accession number phs000145. v1. p1).
Discussion In this work we have introduced CAFBA, an extension of FBA inspired by the proteome allocation scenario underpinned by bacterial growth laws  [3, 5, 21, 60]. By integrating a single additional global constraint in FBA, CAFBA formulates the interplay of growth and expression in metabolism as a simple and elegant growth-rate optimization problem, with the same computational complexity as standard FBA. States of optimal growth found by CAFBA therefore encode for optimality from both an energetic and a proteome allocation perspective. A most distinctive feature of CAFBA lies in the extremely simple empirical inputs required to make quantitatively accurate predictions. The 3 parameters on which the proteome allocation constraint relies, namely w R,0 , φ max and λ max , can be easily obtained in experiments  [5, 6].
Discriminating between the two scenarios we have just presented could be achieved already in bulk experiments, by changing the weight of specific enzymes over time (e. g. , by expressing useless proteins specific to certain pathways) and monitoring whether the associated fluxes adjust dynamically in real time. Naturally, tests of cell-to-cell heterogeneities would also allow to favor one scenario over the other. Finally, we address the magnitude of fluctuations of the weights w i. The spread in the enzyme catalytic rates k cat,i , as tabulated in databases, is notoriously broad, exceeding 3 orders of magnitude  [32, 67]. In the absence of more refined information, it is reasonable to expect that the weights w i should fluctuate by about the same amount. However, we have seen that unrealistic results are generated by CAFBA if weights are allowed to fluctuate more than 10-fold.
Implementation We implemented CAFBA on the E. coli iJR904 genome-scale model  [45] , comprehensive of 761 metabolites and 1075 reactions, as a Matlab function, using the COBRA Toolbox  [74]  to load the network reconstruction with a minor modification. Specifically, we shut off the glucose dehydrogenase reaction, since it is only functional if the cofactor pyrroloquinoline quinone is supplied in the environment (see the Ecocyc  [75]  entry on the enzyme). Both GLPK-and Gurobi-compatible CAFBA solvers for Matlab are provided as additional supplementary material, along with a small set of utility functions. Running times for a single CAFBA optimization of the iJR904 network with a common laptop (single thread of an Intel Core i7-2630QM CPU @ 2. 00GHz) are around 0. 12 s for the GLPK (version 4.
Extension to different growth media and/or organisms Besides the full study of the E. coli iJR904 model, we have tested CAFBA on the more recent reconstructions iAF1260  [58]  and iJO1366  [59] , obtaining very similar results. COBRA-compatible Matlab functions  [74]  to run CAFBA on these models are provided as additional supplementary material. Note C in the Supporting Text describes in detail how to port CAFBA to different growth media, nutrient limitations and/or bacterial species. However, provided the input coming from empirical growth laws is available together with the network structure and the biomass composition, the CAFBA framework can in principle be extended to growth-maximizing organisms other than bacteria. for contributing growth rate data for comparing between MG1655 and NCM3722 strains.
Cross sections, secondary ionisations and propagation In the following section we briefly summarize the ionisation cross sections used in our code CRIME (Cosmic Ray Interactions In Molecular Environments). In addition we derive a general expression describing the secondary ionisations. Figure  1  shows the cross section and secondary ionisations for molecular hydrogen. Finally we shortly adress the issue of cosmic ray propagation into a molecular cloud. These section describes the building blocks of the CRIME online tool.
A. Agustí-Panareda et al. : Biogenic flux adjustment scheme for CO 2 analysis and forecasting system http://icos-atc. lsce. ipsl. fr); Environment Canada (www. ec. gc. ca/mges-ghgm) -which are assimilated by global tracer transport models to infer changes in atmospheric CO 2 (e. g. Massart et al. , 2015)  or by flux inversion systems (e. g. Peylin et al. , 2013)  to estimate the large-scale surface fluxes of CO 2. The current C-IFS CO 2 analysis is produced by assimilating CO 2 data retrieved from GOSAT by the University of Bremen  (Heymann et al. , 2015) , as well as all the meteorological data that is routinely assimilated in the operational meteorological analysis at ECMWF. Massart et al. (2015)  have shown that the atmospheric data assimilation system alone cannot completely remove the biases in the background atmospheric CO 2 associated with the accumulation of errors in the CO 2 fluxes from the model.
, 2007). However, these are not all suitable for the C-IFS real-time monitoring system. Flux inversion systems adjust the fluxes by either inferring the model parameters in Carbon Cycle Data Assimilation Systems also known as CCDAS  (Rayner et al. , 2005; Scholze et al. , 2007; Rayner et al. , 2011) , or the fluxes themselves  (Houweling et al. , 2015). CCDAS has the advantage of working in prognostic mode once the model parameters have been optimized. Nevertheless, it can also be prone to aliasing information to the wrong model parameter when the processes that contribute to the variability of atmospheric CO 2 are not properly represented in the model or missing altogether. Estimating directly the CO 2 fluxes does not rely on the accurate representation of complex/unknown processes in the CO 2 flux model, but the resulting optimized fluxes do not have predictive skill.
For this reason, it is paramount to provide information on all the input data going into BFAS. These are primarily continentalscale climatological budgets from modelled NEE and optimized fluxes. There is also some input from the anthropogenic emissions and the biomass burning emissions to extract the NEE as a residual from the optimized fluxes. The documentation of the specific components used in the C-IFS BFAS system and their uncertainties can be found in  Boussetta et al. (2013) ,  Chevallier et al. (2010) , Chevallier (2015), Janssens-Maenhout et al. (  2012 ) and  Kaiser et al. (2012). The input data streams used in BFAS can be obtained from http://copernicus-support. ecmwf. int for C-IFS NEE and GFAS biomass burning fluxes; from the EDGAR database http://edgar. jrc. ec. europa. eu for the anthropogenic fluxes; and from www-lscedods.
Acknowledgements. This study has been funded by the  European Commission  under the  Monitoring of Atmospheric Composition and Climate (MACC)  project and the  Copernicus Atmosphere Monitoring Service (CAMS). TCCON data were obtained from the  TCCON Data Archive , hosted by the  Carbon Dioxide Information Analysis Center (CDIAC)  -tccon. onrl. gov. The authors would like to acknowledge the PIs of the different TCCON stations used in this study:  Rigel Kivi  ( Sodankylä, Finland ),  Nicholas Deutscher  ( Bialystok, Poland), Paul Wennberg (Lamont, USA ) and  David Griffith  ( Wollongong, Australia ). We acknowledge  Ed Dlugokencky  and  Arlene Andrews  ( NOAA/ESRL ) for the NOAA/ESRL in situ data used in this study. The  NOAA/ESRL Global Monitoring Division data from the baseline observatories at Barrow (Alaska, USA), Mauna Loa (Hawaii, USA), American Samoa (USA), South Pole (Antarctica) , as well as the tall towers at  Argyle (Maine, USA), Park Falls (Wisconsin, USA) and West Branch (Iowa, USA ) were obtained from ftp: //aftp.
In the past decade imaging atmospheric Cherenkov telescope arrays such as H. E. S. S. , MAGIC, VERITAS, as well as the Fermi-LAT space telescope have provided high quality images and spectra of the γ-ray universe. Currently the γ-ray community is preparing to build the nextgeneration Cherenkov Telecope Array (CTA), which will be operated as an open observatory. Gammapy v0. 3 (available at https://github. com/gammapy/gammapy under the open-source BSD license) is a new in-development Astropy affiliated package for high-level analysis and simulation of astronomical γ-ray data. It is built on the scientific Python stack (Numpy, Scipy, matplotlib and scikit-image) and makes use of other open-source astronomy packages such as Astropy, Sherpa and Naima to provide a flexible set of tools for γ-ray astronomers.
PoS(ICRC2015)789 Figure  1 : Gammapy is a Python package for high-level γ-ray data analysis. Using event lists, exposures and point spread functions as input you can use it to generate science results such as images, spectra, light curves or source catalogs. So far it has been used to simulate and analyse H. E. S. S. , CTA and Fermi-LAT data, hopefully it will also be applied to e. g. VERITAS, MAGIC or HAWC data in the future.
Introduction 1. 1 What is Gammapy ? Gammapy is an open-source Python package for γ-ray astronomy. Originally Gammapy started as a place to share morphology fitting Python scripts for the work on the H. E. S. S. Galactic plane survey  [1]  two years ago. Since that time Gammapy has grown steadily: functionality as well as development infrastructure has been improved and it has been accepted as an in-development Astropy-affiliated package. Now, in this proceeding, we would like to introduce Gammapy to the community and present our vision of Gammapy as a future community-developed, general purpose analysis toolbox for γ-ray astronomers. The general concept of Gammapy is illustrated in Figure  1. Based on pre-processed input data (e. g. event lists) provided by instruments such as H. E. S. S. , Fermi or CTA, Gammapy offers the high-level analysis tools to generate science results such as images, spectra, light curves and source catalogs.
The Gammapy stack Gammapy is primarily built on the scientific Python stack. We employ Numpy and Astropy  [4]  as main dependencies and integrate other packages as optional dependencies where necessary. The current dependency structure is illustrated in Figure  2. Numpy provides the low level data structures and the framework for numerical/array computations. Astropy is used for higher level data structures like tables (Table ) and n-dimensional data objects (NDData), for I/O, coordinates and WCS transformations, and handling of physical quantities with units. Scipy is used for advanced numerical and data processing algorithms. For specific image processing routines we additionally use scikit-image. To allow morphology and spectral fitting of TeV sources with Gammapy we use the established X-ray modelling and fitting package Sherpa  [5].
The radiative models available in Naima can be called as source models in the Gammapy environment and be used, for example, to simulate spectra for source population studies. Data visualizing and plotting of sky images is done with matplotlib and the astropy-affiliated package wcsaxes. Further astropy-affilated packages we allow as optional dependencies are photutils and reproject. Photutils is used for source detection and photometry and reproject for reprojection of sky images. While this is a large number of dependencies, most of them are optional and only needed for small specific tasks so we do not see this as a strong disadvantage. Optional packages can be easily installed using package managing tools like pip or conda. By re-using other packages' functionality which would be complex to re-implement, new tools and techniques can be easily integrated into Gammapy to help obtain scientific results more quickly with a minimal coding effort.
Development workflow Gammapy uses all the standard tools of modern community-driven open-source software development. The code repository is hosted on GitHub 5  , which allows for convenient and public interaction of developers, contributors and users via the GitHub interface. This includes, for instance, feature requests for missing functionality, issues for bugs or questions and pull requests for code contributions. The code base is continuously built and tested in different virtual environments using the continuous integration service Travis CI. This helps to maintain high coding standards and compatibility with different versions of Numpy and Astropy. The documentation of Gammapy is generated using Sphinx. An online version of the latest documentation is built automatically and is available on Read the Docs 6.
The Gammapy toolbox 4. 1 Sub-packages The Gammapy code base is structured into several sub-packages where each of the packages bundle corresponding functionality in a namespace. This follows the concept of other Python packages such as Astropy and Scipy. The following list gives a rough overview of the different sub-packages with a short description: • gammapy. astro -Galactic population and emission models of TeV sources There are some cases (e. g. gammapy. spectrum. models and several sub-modules of gammapy. utils) where the end-user functionality is exposed one level further down in the hierarchy. This is because putting everything into the top-level gammapy. spectrum or gammapy. utils namespace would lead to an unstructured collection of functions and classes. A large part of Gammapy 's functionality uses an object-oriented API.
Morphology fitting command-line tool Gammapy includes a simple to use command-line script gammapy-sherpa-like to perform a Poisson maximum likelihood morphology fitting using FITS files as input. The input counts, exposure and background maps can be specified by the corresponding parameters --counts, --exposure and --background. The source model is defined in a JSON file and should be passed using the --sources option. The model parameters for a multi-Gaussian point spread function (PSF) can be specified in JSON format using the --psf option.
Planned functionality Gammapy already includes key analysis features like morphology and spectrum fitting but both are currently limited to either 2D image-based data or 1D spectral data. As a major next step we plan to support joint likelihood fitting of datasets, as illustrated in Figure  5. Events are binned into longitude, latitude and energy cubes and fitted simultaniously with spectral and spatial models taking energy-dependent background, exposure and point spread function (PSF) into account. Support for un-binned analyses is not planned.
Summary Gammapy 0. 3 is still alpha quality software. It is a package where standard γ-ray analyses are available on the one hand while, on the other hand, integration and prototyping of new methods is easily possible. So far it only contains limited functionality but the setup of documentation, testing and deployment is already very advanced. It's scope will continously grow and we hope that many users and developers show interest in open and reproducible γ-ray astronomy with Python. As long-term goal we would like Gammapy to turn into a fully community-developed package. So all contributions to Gammapy are welcome! If you don't know how to turn your scripts into production-quality, reusable code, please get in touch with us (e. g. using the mailing list) and we will help you get there! For further information on how Gammapy and other tools are being used for H.
gammapy. background -Background estimation and modeling PoS(ICRC2015)789 • gammapy. catalogγ-ray source catalog access and processing • gammapy. datasets -Easy access to bundled and remote datasets • gammapy. detect -Source detection tools and algorithms • gammapy. hspec -Interface to spectral fitting with Sherpa • gammapy. image -Image processing and analysis tools • gammapy. irf -Instrument response function (IRF) access and handling • gammapy. morphology -Morphology models and tools • gammapy. obs -Observation handling • gammapy. spectrum -Spectrum models and tools • gammapy. stats -Statistical functions • gammapy. time -Handling of time series and γ-ray lightcurves • gammapy. utils -Utility functions and classes (in sub-modules).
• gammapy. background -Background estimation and modeling PoS(ICRC2015)789 • gammapy. catalogγ-ray source catalog access and processing • gammapy. datasets -Easy access to bundled and remote datasets • gammapy. detect -Source detection tools and algorithms • gammapy. hspec -Interface to spectral fitting with Sherpa • gammapy. image -Image processing and analysis tools • gammapy. irf -Instrument response function (IRF) access and handling • gammapy. morphology -Morphology models and tools • gammapy. obs -Observation handling • gammapy. spectrum -Spectrum models and tools • gammapy. stats -Statistical functions • gammapy. time -Handling of time series and γ-ray lightcurves • gammapy. utils -Utility functions and classes (in sub-modules).
Open information extraction approaches are useful but insufficient alone for populating the Web with machine readable information as their results are not directly linkable to, and immediately reusable from, other Linked Data sources. This work proposes a novel paradigm, named Open Knowledge Extraction, and its implementation (Legalo) that performs unsupervised, open domain, and abstractive knowledge extraction from text for producing directly usable machine readable information. The implemented method is based on the hypothesis that hyperlinks (either created by humans or knowledge extraction tools) provide a pragmatic trace of semantic relations between two entities, and that such semantic relations, their subjects and objects, can be revealed by processing their linguistic traces (i. e.
Populating the Semantic Web from natural language text The vision of the Semantic Web is to populate the Web with machine understandable data so that intelligent agents will be able to automatically interpret its content -just like humans do by inspecting Web content -and assist users in performing a significant number of tasks, relieving them of cognitive overload. The Linked Data movement  [3]  realised the first substantiation of this vision by bootstrapping the publication of machine understandable information, * Corresponding author. E-mail: valentina. presutti@cnr. it mainly taken from structured data (typically databases) or semi-structured data (e. g. Wikipedia infoboxes). However, a large part of the Web content consists of natural language text, hence a main challenge is to extract as much relevant knowledge as possible from this content, and publish it in the form of Semantic Web triples.
This work aims to solve this problem by extracting relational knowledge that is "hidden" in hyperlinks, which can be either defined manually by humans (e. g. Wikipedia pagelinks) or created automatically by Knowledge Extraction (KE) systems (e. g. a KE system can automatically add links to Wikipedia pages or to local datasets of Semantic Web entities). Current KE systems address the task of linking pieces of text to Semantic Web entities very well (e. g. owl:sameAs) by means of named entity linking methods, e. g. NERD  1   [41] , FOX 2  , conTEXT  3   [24] , Dbpedia Spotlight  4  , Stanbol  5  , TAGME  [14] , Babelfy  [29]. Some of them (e. g. NERD) also perform sense tagging, i. e. adding knowledge about entity types (rdf:type). Nevertheless, it is desirable to enrich Web content with other semantic relations than owl:sameAs and rdf:type, i.
The main difference is that with the abstractive approach, subjects and objects are identified as Semantic Web entities, the predicate is as close as possible to what a human would define for a Linked Data vocabulary by possibly using terms that are not mentioned in the original text. In addition to what Table  1  shows, the predicate would be formally 8 https://d5gate. ag5. mpi-sb. mpg. de/ pattyweb/ 9 http://lcl. uniroma1. it/wisenet/ 10 http://wordnet. princeton. edu/ 11 http://openie. cs. washington. edu/ 12 Notice that this is the output of OIE for this sentence defined in terms of OWL axioms and possibly aligned with existing Semantic Web vocabularies.
Two entities are resolved on DBpedia, i. e. dbpedia:Evile, and dbpedia:Russ_Russell, and two frame occurrences are identified, i. e. fred:begin_1 and fred:process_1. Furthermore, each node is assigned with a type that, when possible, is aligned to existing Linked Data vocabularies. For Example, The Legalo design strategy for generating predicate labels is based on three main generative rules (GR). The first one concerns the concatenation of the labels that are used in the shortest path connecting the two nodes, including the labels of the edges and the labels of the node types in the path. This rule is defined by GR 1. It is important to remark that the path used as a reference for generating the predicate label is the one connecting the nodes v subj and v obj and not the corresponding resolved DBpedia entities.
For each hyperlink in s associated with a true assessment of ϕ s (e subj , e obj ) (cf. Axioms 1, 2, and 3), Legalo produces at least one RDF triple. As explained in Section 3. 3, the nodes v subj and v obj in G representing e subj and e obj are resolved on DBpedia, when possible, which links the triples to the Linked Data cloud. The predicate is formalised as an OWL object property having λ as label and an ID de-rived by transforming λ according to the CamelCase notation 17. For example, consider the enriched frame-based formal representation of the sentence The New York Times reported the death of John McCarthy. He invented the programming language LISP. depicted in Figure  4 , Legalo produces the triples depicted in Figure  5 , according to the generative rules GR 1, 2, and 3, where the prefix legalo: is a namespace defined using the checksum of the sentence s.
Briefly, Legalo-Wikipedia takes in input a DBpedia entity URI, and retrieves all its pagelinks triples from the Pagelinks DBpedia dataset. For each pagelink triple it extracts all Wikipedia snippets containing an hyperlink corresponding to the triple by means of a specialised sentence extractor. Then, the subject resolver selects all and only the snippets that contain a lexicalisation of the Wikipedia page subject, by relying on the DBpedia Lexicalizations Dataset 28. For example, the wikipage wp:Ron_Cobb includes a link to wp:Sydney in the sentence: "In 1972, Cobb moved to Sydney, Australia, where his work appeared in alternative magazines such as The Digger. " This sentence will be selected and stored as it contains the term "Cobb", which is a lexicalization of dbpedia:Ron_Cobb. The same wikipage includes a link to wp:Los_Angeles_Free_Press in the sentence: "Edited and published by Art Kunkin, the Los Angeles Free Press was one of the first of the underground 27 A demo is available at http://wit.
istc. cnr. it/ stlab-tools/legalo/wikipedia 28 http://wiki. dbpedia. org/Datasets/NLP?v= yqj newspapers of the 1960s, noted for its radical politics. " This sentence will be discarded as it does not include any lexicalisation of dbpedia:Ron_Cobb. This procedure is needed for identifying pagelinks that actually convey a semantic factual relation between the Wikipedia page subject and the target of the pagelink. Each snippet is then passed to Legalo as input for generating the Semantic Web property. The version of legalo-wikipedia presented in  [38]  relied on a previous version of Legalo, which supported less general generative rules and did not perform the relevant relation assessment or the formalisation of the generated property.