dataesr/scientific-paragraphs-categorization huggingface dataset:
DISCUSSION The ability of the ABC skyline plot to detect changes in population size varies largely across the different scenarios evaluated. The evidence for demographic change was often strong (even very strong) in declining and expanding populations. However, demographic changes of small magnitude and close to the present were the hardest to detect. Recent or small magnitude events leave a weak signal in the genetic data and are also hard to identify for alternative methods (see  Girod et al. , 2011; Leblois et al. , 2014; Nikolic & Chevalet, 2014). In any case, the method is conservative, since most analyses of stable populations yielded negative or little evidence for demographic change. The main appeal of skyline plots is to depict demographic trajectories not bounded by a mathematical function, thus potentially reflecting more realistically the demography of natural populations.
An extended Bayesian skyline plot on microsatellite data suggested an expansion, but it was not significant, and the skyline plot on mitochondrial DNA data did not show any demographic change. In contrast, analysis of microsatellite data with MSVAR (a coalescent sampler approach,  Beaumont, 1999; Storz & Beaumont, 2002)  suggested a strong population decline. However, it must be noted that MSVAR assumes a strict SMM, which can lead to biases in the demographic estimates when microsatellite mutations include a substantial proportion of multi-step changes  (Girod et al. , 2011; Faurby & Pertoldi, 2012). Our estimates of the P GSM parameter and the two-phase model used in BEAST suggest a strong departure from the SMM and lead us to favour the hypothesis of population expansion. Finally, the original analysis of the two colobus species found significant evidence of population decline for both of them  (Minhós et al.
Extensions to other molecular markers will be straightforward to develop and already exist for genomic data (e. g. ,  Boitard et al. , 2016). Finally, other demographic parameters, such as the migration rate  (Pool & Nielsen, 2009) , could be subject to variation with time and they, too, could be inferred with a similar scheme. To sum up, there is potential to develop this approach in different directions, to address new questions in future research. In this work we presented a detailed description of how to compute an approximate-Bayesian-computation skyline plot and assessed its performance on stable and changing simulated populations characterized with microsatellite markers. Its power to detect the signal of demographic change is similar to alternative methods. However, its potential ability to depict the demography of natural populations more realistically must not be overrated.
ACKNOWLEDGEMENTS We thank  Jean-Marie Cornuet  and  Renaud Vitalis  for helpful discussion on this project and  Alexandre Dehne-Garcia  for his technical support. We thank  Benoît de Thoisy  and  Tania Minhós  for kindly sharing their data on the leatherback turtle and colobus monkeys, respectively. Suggestions from two anonymous reviewers helped to improve this work and  Ruth Hufbauer  kindly revised and improved the English of the manuscript. All analyses were performed on the INRA MIGALE (http://migale. jouy. inra. fr), GENOTOUL (Toulouse Midi-Pyrénées)  and  CBGP HPC  bioinformatics platforms.
Data Availability The following information was supplied regarding data availability: Code for DIYABCskylineplot is available on ZENODO (doi: 10. 5281/zenodo. 267182) and on GitHub (http://github. com/mnavascues/DIYABCskylineplot) including code to automatically simulate pseudo-data. Data from whale sharks is available at DRYAD database (doi: 10. 5061/dryad. 489s0 ).
A machine reader is a tool able to transform natural language text to formal structured knowledge so as the latter can be interpreted by machines, according to a shared semantics. FRED is a machine reader for the semantic web: its output is a RDF/OWL graph, whose design is based on frame semantics. Nevertheless, FRED's graph are domain and task independent making the tool suitable to be used as a semantic middleware for domain-or task-specific applications. To serve this purpose, it is available both as REST service and as Python library. This paper provides details about FRED's capabilities, design issues, implementation and evaluation.
Introduction This paper describes FRED 1   [43] : a tool that automatically generates RDF/OWL ontologies and linked data from multilingual natural language text. The approach implemented by FRED falls into the machine reading paradigm  [12] , which aims to transform (part of) a natural language text into data. FRED adds to that paradigm the ability to generate knowledge graphs that can be interpreted by machines, according to a shared formal semantics, and is linked to available background knowledge. As an example of a formal knowledge graph, the text "Valentina gave Aldo a book by Charlie Mingus. " can be formalised according to OWL semantics and the OWL n-ary relation pattern 2 , as sketched by Figure  1. The class Give and its instance give_1 represent the "gave" n-ary relation holding between "Valentina", "book", and "Aldo", which have their representative instances, in turn related to give_1.
g. refactor or enrich) for empowering their domainor task-specific client applications. Some examples are automatic text annotation, search engine optimisation, opinion mining, automatic summarisation. Examples of applications built on top of FRED are given in Section  4. FRED 1 is available as RESTful API (providing RDF serialisation in many syntaxes) as well as Python API (fredlib  3  ). Additionally, any user can access FRED's demo application online, which features a graphical user interface. FRED's output graph is designed according to Frame Semantics  [15]  and ontology design patterns  [20]. A frame is usually expressed by verbs or other linguistic constructions, hence all occurrences of frames that can be recognised in an input text are formalised as OWL n-ary relations, all being instances of some type of event or situation (e.
From Discourse Representation Structures to RDF/OWL n-ary relations The core of FRED takes as input Discourse Representation Structures (DRSs), based on Hans Kamp's Discourse Representation Theory (DRT)  [25]. DRSs, informally called "boxes" (due to their graphical representation), represent natural language sentences, and include two parts: a set of discourse referents, and a set of conditions providing the interpretation of the discourse referents. The DRS language is within first order logic, and its discourse referents are arbitrary entities, including events modeled according to a neo-Davidsonian semantics  [25]. The DRSs taken by FRED as input are produced by Boxer  [5] , which performs deep parsing out of Combinatory Categorial Grammar (CCG) parse trees  [47]. It also makes use of both VerbNet  [27]  and FrameNet  [4]  for frame labelling and semantic role labelling, i.
In the first case, the event type fred:Love is    (c) FRED output with FrameNet labels. Fig. 3. : Boxer versus FRED result (in two varieties labelling with either VerbNet and FrameNet frames and roles) for the sentence "People love movies", which exemplifies the case of a box that does not add any semantics to its content, which in turn maps to a specific frame. aligned to vn. data:Love_31020100, and therefore roles are labeled as vn. role:Experiencer and vn. role:Theme respectively. In the second case, the event type fred:Love is aligned to ff:Experiencer_focus, and therefore roles are labeled as fe:Experiencer:experiencer_focus and fe:Content:experiencer_focus respectively. Natural language text on the web is rarely such simple as "People love movies", hence the possibile configurations of boxes and their contents have a wide range of complexity.
Other FRED's capabilities Multilingualism. FRED takes as input a text in one of 48 different languages, it translates it in English and then processes it for producing its corresponding graph. Therefore, the resulting graph always has English labels. As for the translation, FRED relies on Bing Translation APIs 7. If the input language is different from English, the input text must be preceded by the tag <BING_LANG:lang>, where lang is the code for the language 8. Textual annotation grounding. As part of its OWL/RDF output, FRED provides annotations that link text fragments to their corresponding graph elements. These annotations are expressed by means of the Earmark vocabulary  [39]  and the NLP Interchange Format (NIF)  [23].
Text processing. FRED takes as input a text in natural language (NL). It can be a short text (to be processed at once) or a corpus of NL documents; at the moment, the latter is available only by using the fredlib Python API. The input text is processed and transformed into DRSs. This processing includes also frame detection and semantic role labelling (based on Verb-Net  [27]  and FrameNet  [4] ), identification of relations between frames, named entity recognition (NER) and coreference resolution (CRR). Boxer  [5]  is in charge of producing DRSs (see Section 2 for more details 7 http://www. microsoft. com/web/post/ using-the-free-bing-translation-apis 8 The website http://msdn. microsoft. com/en-us/ library/hh456380. aspx provides the list of language codes about Boxer) nevertheless, after observing a significant number of cases during FRED implementation and experience of usage, it emerged that Boxer's pronoun CRR capability is limited.
For this reason FRED also integrates CoreNLP 9  as an additional component for this specific task. A similar approach is used for NER, in fact FRED integrates TAGME  [14] , which uses Wikipedia content as context to disambiguate named entities. For both tasks, i. e. NER and CCR, FRED takes as input the union of Boxer, TAGME and CoreNLP outputs, where TAGME overrules Boxer for NER (when both provide results) and CoreNLP overrules Boxer for CRR, in an analogous situation. The output of TAGME is reused also later (in the RDF graph enrichment phase) for performing Entity Linking. The result of this processing is transformed into an intermediate representation and passed to the second phase. Implementation. This phase is implemented as a Python software component that uses system calls for getting Boxer, TAGME and CoreNLP outputs, integrate them in an internal representation and pass the result to the next component.
This task is addressed by integrating an external component: at the moment FRED reuses UKB  [1] ; an integration with Babelfy  [34]  is under development as well. The result of this phase is the final graph, which is provided in RDF format: FRED supports most RDF serialisation formats. Implementation. The third phase is implemented as an independent Java software framework, named K~ore. K~ore is a modular set of Java components, each accessible via its own RESTful interface. All components are implemented as OSGi  [38]  bundles, components and services based on Apache Felix 11. For example, the WSD service has been implemented as an OSGi wrapper for UKB  [1]. Pragmatically, K~ore wraps FRED's Python components, and enriches their output by means of additional services implemented as OSGi bundles.
The whole wrapper is deployed as a REST service. Additional implementation and deployment details. FRED is also released as a Python API named fredlib, which relies on the K~ore REST services, and allows to query FRED with a user-specified corpus, also enabling the manipulation of the resulting graph. More specifically, a Python function hides details related to the communication with the FRED service, and returns the user a FRED graph object that is easily manageable. FRED graph objects expose methods for extracting qualified parts (motifs) from the graph. These methods include functions for extracting the set of individual and class nodes, equivalence axioms, typing axioms, categories of FRED nodes (i. e. events, situations, qualities, general concepts) and categories of edges (roles and non-roles).
Community feedback Besides rigorous evaluation, FRED's quality is supported by evidence of its impact in the community (ii). A public forum in the software engineering community, stackoverflow. com, contains independent discussions about extending FRED's usage to other platforms (Python, C#) 15. Another forum, answers. semanticweb. com, contains independent analyses and discussion of related works, revealing FRED's uniqueness in providing a solution for producing rich RDF datasets from text 16. The Wikipedia entry for Knowledge Extraction 17 contains a list of tools for knowledge extraction from text, and even looking only at the column for "extracted entities", FRED has the largest set. The only comparable entry is for a proprietary tool that does not provide any demo on the web. More literature shows the impact of FRED beyond semantic technology circles: a 2014 study about deal- "The knowledge extraction from unstructured text is still a hard task, though some preliminary automated tools are already available.
Automatic entity typing Tipalo 26   [18]  relies on FRED to automatically type DBpedia entities based on their natural language definitions. An entity definition is extracted from its corresponding Wikipedia page and transformed by FRED in a graph representation. Tipalo defines a set of heuristics for extracting taxonomies of types that classify an entity, from FRED output. It also disambiguates the sense of learned concepts and align them to existing ontologies, hence providing an alternative to DBpedia and YAGO  [48]. Figure  12  shows the pipeline of Tipalo, which includes external resources such as UKB  [1]  for word sense disambiguation, OntoWord- Net  [17]  and WordNet 3. 0 Supersenses RDF 27 for concept alignment. The tool was evaluated against a sample of DBpedia entities and showed high accuracy for the entity typing tasks  [18] : type selection (F 1 =.
Most work has been opportunistic: on one hand exploiting NLP algorithms and applications, such as named-entity recognisers and sense taggers, to populate semantic web datasets or ontologies, or for creating NL query interfaces; on the other hand exploiting large semantic web datasets and ontologies (DBpedia, YAGO, Freebase) to improve NLP algorithms. For example, Alchemy API  28  , Apache Stanbol  29  , NERD  [45] , and FOX 30 perform grounding of extracted entities in publicly available identities such as Wikipedia, DBpedia and Freebase. Nevertheless, their output lacks information about how the identified entities are related to each other, which is one of the features provided by FRED. Relation extraction and question answering are mostly domain-dependent and supervised: they use a finite vocabulary of predicates (e.
Quipper  [14, 15]  is a domain specific, higher-order, functional language for quantum computation, embedded in the host-language Haskell. It allows automated quantum circuit generation and manipulation; equipped with a gate-count operation, Quipper offers a universal automated LRE tool. We demonstrate how Quipper's powerful capabilies have been exploited for the purpose of this work. We underline that our research contribution is not merely providing the LRE results, but also to demonstrate an approach to how a concrete resource estimation can be done for a quantum algorithm used to solve a practical problem of a large size. Finally, we would also like to emphasize the modular nature of our approach, which allows to incorporate future work as well as to assess the impact of prospective advancements of quantumcomputation techniques.
B. Context and setting of this work Our analysis was performed within the scope of a larger context: IARPA Quantum Computer Science (QCS) program  [16] , whose goals were to achieve an accurate estimation and moreover a significant reduction of the necessary computational resources required to implement quantum algorithms for practically relevant problem sizes on a realistic quantum computer. The work presented here was conducted as part of our general approach to tackle the challenges of IARPA QCS program: the PLATO project 2  , which stands for 'Protocols, Languages and Tools for Resource-efficient Quantum Computation'. The QCS program BAA  [17]  presented a list of seven algorithms to be analyzed. For the purpose of evaluation of the work, the algorithms were specified in 'governmentfurnished information' (GFI) using pseudo-code to describe purely-quantum subroutines and explicit oracles supplemented by Python or Matlab code to compute parameters or oracle values.
While this IARPA QCS program GFI is not available as published material  3  , the Quipper code developed as part of the PLATO project to implement the algorithms and used for our LRE analyses is available as published library code  [18, 19]. In our analyses, we found the studied algorithms to cover a wide range of different quantum computation techniques. Additionally, with the algorithm parameters supplied for our analyses, we have seen a wide range of complexities as measured by the total number of gate operations required, including some that could not be executed within the expected life of the universe under current predictions of what a practical quantum computer would be like when it is developed. This approach is consistent with the one commonly used in computer science for algorithms analysis.
The specified example problem that has been subject to our LRE analysis has the somewhat larger size N = 332, 020, 680, while the other relevant parameters have the values κ = 10 4 , d = 7, and ǫ = 10 -2. Logical resources to be tracked are the overall number of qubits (whereby we track data qubits and ancilla qubits separately), circuit width (i. e. , the max. number of qubits in use at a time, which also corresponds to the max. number of 'wires' in algorithm's circuit), circuit depth (i. e. , the total number of logical steps specifying the length of the longest path through the algorithm's circuit assuming maximum parallelism), the number of elementary (1-and 2-qubit) gate operations (thereby tracking the quantity of each particular type of gate operation), and 'T-depth' (i. e. , the total number of logical steps containing at least one T -gate operation, meaning the total number of Tgate operations that cannot be performed in parallel but must be implemented successively in series).
Indeed, these large iterative factors explain why we get such large gate counts and circuit depth. It is useful to differentiate between the resources associated with the 'bare algorithm' excluding oracle implementations and those which also include the implementation of oracles. In order to perform the LRE, we chose an approach which combines manual analysis for the bare algorithm ignoring the cost of oracle implementations (see Sec. III) with automated resource estimates for oracles generated via the Quipper programming language and compiler (see Sec. IV). Whereas a manual LRE analysis was feasible for the bare algorithm thus allowing a better understanding of its structural 'profiling' as well as checking the reliability of the automated resource counts, it was not feasible (or too cumbersome) for the oracle implementations.
The actual instructions for computing the elements of the linear system's matrix A and vector b, as well as of the vector R whose overlap with the solution x is used to calculate the far-field radar cross-section (see Sec. III C), are specified in our Quipper code for QLSA, see  [18, 19]. The metallic scattering region is thereby given in terms of an array of scattering nodes denoted as 'scatteringnodes'. Here we briefly summarize the FEM dimensions and the values of all other system parameters that are necessary to reproduce the analysis. For all other details, we refer the reader to our QLSA's Quipper code and its documentation in  [18, 19]. The total number of FEM vertices in x and y dimensions were n x = 12, 885 and n y = 12, 885, respectively, yielding N = n x (n y -1) + n y (n x -1) = 332, 020, 680 for the total number of FEM edges, which thus determines the number of edge basis vectors, and hence also the size of the linear system, and in particular the size of the N × N matrix A.
The lengths of FEM edges in x and y dimensions were l x = 0. 1m and l y = 0. 1m, respectively. The analyzed 2D scattering object was a square with edge length L = 2λ, which in our analysis was placed right in the center of the FEM grid. In our Quipper code for QLSA  [18, 19]  it is represented by the array 'scatteringnodes' containing the corner vertices of the scattering region. The dimensions of the scattering region can also be expressed in terms of the number of vertices in x and y directions; using λ = 1m, the scatterer was given by a 200×200 square area of vertices. The incident and scattered field parameters were specified as follows. The incident field amplitude, wavenumber and angle of incidence were set E 0 = 1. 0 V /m, k = 2π m -1 (implying wavelength λ = 1m) and θ = 0, respectively.
Hence, we attempted to find an actual lower bound for κ 2 numerically. To this end, because an estimate for κ 1 can be obtained with much less computational expense than for κ 2 for a given matrix of a very large size, we used Matlab and extrapolation techniques to attain a rough approximation of κ 1 from the given code specifying the matrix of our toy problem. We found a value κ 1 ≈ 10 7. This allowed us to infer a rough estimate for the lower bound for κ 2. Indeed, using the above relation between the matrix norms • 1 and • 2 for a square matrix and realizing that both A 1 and A 2 have values of order O(1), we may conclude that N = O(h -n ), κ 2 is bounded by O(N 2/n ) (see κ 2 ≥ κ 1 / √ N × O(1) , which is of order approximately 10 3 -10 4.
The cost of each algorithmic building block is thereby measured in terms of the number of calls of lower-level subroutines or directly in terms of the number of specified elementary gates, data qubits, ancilla uses, etc. To obtain an accurate LRE of QLSA, we thus need to represent each algorithmic building block in terms of a quantum circuit that then enables us to count elementary resources. In what follows, we present quantum circuits for selected subroutines of QLSA. Well-known circuit decompositions of common multi-qubit gates (such as, e. g. , Toffoli gate, multicontrolled NOTs, and W gate) and their associated resource requirements are discussed in the Appendix.
The efficiency of oracular algorithms is commonly characterized in terms of their query complexity, assuming each query is given by an efficiently computable function. However, in practice oracle implementations must be accounted for. Our analysis aims at comprising all resources, including those which are needed to implement the required oracles. Their automated implementation using the programming language Quipper and its compiler is elaborated on in Sec. IV. Here we briefly discuss the high-level tasks of these oracle functions. Their resource estimates are presented in appendix 3. Oracle b is used to prepare quantum state |b T 2,6 , see Eq. (  7 ) and Fig. 13. Its task is accomplished by subroutine 'Oracle b(x, m, p)', which takes as input the quantum state of the n 2 -qubit register R 2 (argument x; spanning the linear system global edge indices), computes the corresponding magnitude value b j and phase value φ j , and stores them in the two auxiliary computational registers R 4 and R 5 (labeled by arguments m and p), each FIG.