dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgements. A. Carmona  and  C. Pinte  acknowledge funding from the  European Commission 's  7 th Framework Program  ( EC-FP7 ) (contract  PERG06-GA-2009-256513 ) and from the  Agence Nationale pour la Recherche (ANR) of France  under contract  ANR-2010-JCJC-0504-01. Calculations were performed at the  Service Commun de Calcul Intensif de l'Observatoire de Grenoble (SCCI)  on the Fostino supercomputer funded by the  ANR  (contracts  ANR-07-BLAN-0221 ,  ANR-2010-JCJC-0504-01  and  ANR-2010-JCJC-0501-01 ) and the  EC-FP7  contract  PERG06-GA-2009-256513. The research leading to these results has received funding from the  EC-FP7  under grant agreement no  284405. FM acknowledges support from the  Millennium Science Initiative (Chilean Ministry of Economy ), through grant Nucleus  P10-022-F.
PIONIER  is funded by the  Université Joseph Fourier (UJF) , the  Institut de Planétologie et d'Astrophysique de Grenoble (IPAG) , the  Agence Nationale pour la Recherche  ( ANR-06-BLAN-0421  and  ANR-10-BLAN-0505 ), and the  Institut National des Science de l'Univers (INSU PNP  and PNPS). The integrated optics beam combiner is the result of a collaboration between IPAG and CEA-LETI based on CNES R&T funding. Part of this work was funded by the  Agence National pour la Recherche of France  through the  Chaire d'Excellence grant ANR  ( CHEX2011   SEED ). This research has made use of the SIMBAD database, operated at the  CDS, Strasbourg, France. This work is based (in part) on archival data obtained with the  Spitzer Space Telescope , which is operated by the  Jet Propulsion Laboratory, California Institute of Technology  under a contract with  NASA.
For our analysis, we downloaded the Spitzer/IRS observations (AOR 3580672, PI: Houck) from the Spitzer archive and reduced the data again. The short-low data were reduced using the FEPS pipeline (S18. 18. 0, see Bouwman et al. 2008). The short-high and the long-high data were reduced with the c2d pipeline (S18. 18. 0, Lahuis et al. 2006 ). For the high-resolution modules, we used the PSF extraction method, which includes correction for pointing uncertainties. The mid-IR spectrum of HD 135334B is characterized by the absence of the silicate feature at 10 µm, weak PAH emission at 11. 2 µm, and a lack of other PAH emission features (Geers et al. 2006; Maaskant et al. 2013 ).
As expected, different cells were in focus in different planes within the image stack; therefore, to produce a 2D geometry suitable for our analysis, we developed a software tool, called SurfaceProject, to extract a plane from the stack (Figure  1B ; Supplemental Figure  2 ; see Methods). Using this plane (Figure  1C ), we segmented the multicellular root tip geometry and nuclear fluorescence channel using the CellSeT tool  (Pound et al. , 2012) ; these geometries (Supplemental Table  1 ) and fluorescence intensities (Figure  1D ) were read into a vertex-based model, based on the OpenAlea modeling framework  (Pradal et al. , 2008). We prescribed a PIN distribution on our virtual root tissue (Figure  1E ) based on reports in the literature and our own observations using anti-PIN antibodies raised against the central loop of PIN1, 2, 3, 4, and 7 (Supplemental Figure  3 , Supplemental Tables  2  and 3 , and Supplemental Methods, specifying the carrier distributions).
Segmentation Image stacks were taken about the midline of roots to include all nuclei required for quantification (typically 30 steps at 1-µm intervals). 2D planes were constructed from the 3D stacks using the SurfaceProject plug-in for the Fiji image processing package  (Schindelin et al. , 2012). Details of SurfaceProject can be found in the Supplemental Methods, and the software and user documentation are provided at www. simuplant. org. Cell geometries and DII-VENUS and GFP fluorescence intensities were extracted from the confocal images using the CellSeT segmentation tool, as described by  Pound et al. (2012).
Modeling The geometrical and fluorescence measurements from CellSeT were read into an OpenAlea data structure  (Pradal et al. , 2008). Using the resulting multicellular tissue structure, auxin transport was modeled using a vertexbased approach (Supplemental Figure  23 ). The auxin and DII-VENUS dynamics described in the main text were captured by a system of ODEs, which depend on a number of parameter values (Supplemental Tables  4 to  6 ), which were sourced from the literature  (Scott and Allen, 1999; Sze et al. , 1999; Fasano et al. , 2001; Swarup et al. , 2005; Heisler and Jönsson, 2006; Kramer et al. , 2007). Simulations were performed in the Python programming language (www. python. org) using the ODE solver LSODES from the ODEPACK suite  (Hindmarsh, 1983)  to approximate numerically solutions of the system of differential equations.
SimuPlant GUI A GUI called SimuPlant was developed to enable those interested to interact directly with the simulations presented in this study. SimuPlant is written in Java 7, which is easily installable on most modern operating systems (OSX/Windows/Linux). The client connects to a simulation server, where all the computationally intensive operations are performed. The default behavior is for the client to connect to the server provided by the University of Nottingham, available via www. simuplant. org. However, for intensive use, it is also possible to install the server locally. In this case, the software is available from Sourceforge; links to this software can be found on the GUI website www. simuplant. org. The client permits the user to choose between the nine different root tip geometries presented herein, each acquired from confocal images using SurfaceProject and CellSeT; three of these are from wild-type plants (Figure  1C ; Supplemental Figures  4A  and 4G ), three from aux1 null mutant plants (Figure  3A ; Supplemental Figures  10A  and 10F ), and three from the aux1, DII-VENUS 3 aux1, J0951>>AUX1 line  (Swarup et al.
ACKNOWLEDGMENTS This project was supported by the  Biotechnology and Biological Sciences Research Council (BBSRC)  and  Engineering and Physical Sciences Research Council  funding to the  Centre for Plant Integrative Biology. In addition, we acknowledge the support of the  Leverhulme Trust  (L. R. B. ), the  Al-Tajir World of Islam Trust  (H. I. H. ),  National Science Foundation  Grant  DBI0820755  (J. M. A. ), the  Royal Society and Wolfson Foundation  (J. R. K. ), and  BBSRC Professorial Research Fellowship  funding (M. J. B. ). We thank  Antoine Larrieu ,  Caroline Howells , and  Edward Venison  for assistance in generation of the AUX1:VENUS line.
, 2012). As claimed in  Corradini, Amezquita, Normand, and Peleg (2006) , MS Excel ® is a general-purpose software, finding widespread use among industrial food microbiologists, when compared to relatively advanced mathematical software like Mathematica ® , MathCAD ® or Maple ®. In TM-0 (and also in TM-1), coefficient h c is a priori unknown and allowed to vary due to uncertainty and variability in the usual (nonacademic) modus operandi of the kitchen. Coefficient h c is obtained by best-fitting the numerical meal temperature against the profile recorded in loco along with the temperature-time profile of the cooling air flowing nearby  (Rabi et al. , 2012). After 17 technical visits to the kitchen over a year, it was possible to apply the numerical procedure to 119 meal samples and this work presents and discusses the average and lowest values of those best-fitting coefficients h c.
This study presents a comparison of the RT ZTD estimates from three different PPP software packages (G-Nut/Tefnut, BNC2. 7 and PPP-Wizard) to the state-of-the-art IGS Final Troposphere Product employing PPP in the Bernese GPS Software. Overall, the ZTD time series obtained by the software packages agree fairly well with the estimates following the variations of the other solutions, but showing various biases with the reference. After correction of these the RMS differences are at the order of 0. 01 m. The application of PPP ambiguity resolution in one solution or the use of different RT product streams shows little impact on the ZTD estimates.
Discussion and Conclusions The RT PPP ZTD estimates from three different software packages were compared using the IGS Final Troposphere Product as reference. In terms of standard deviation, it was seen that the solution from the G-Nut/Tefnut software library has the best agreement with the reference. After G-Nut/Tefnut solutions, the solutions from BNC2. 7 are the next closest to the reference. Among the BNC2. 7 solutions, a lower bias has been found for the solution computed using the correction stream containing Kalman Filter combination (IGS02) rather than the one computed using a single epoch solution correction stream (IGS01). The ambiguity float solution from the PPP-Wizard has the largest bias with the reference because of the fact that it currently does not apply corrections for receiver antenna phase centre offsets during processing.
g. 10 or even 5 minutes while maintaining a certain level of accuracy. The COST Action 716 specified various user requirements for GNSS meteorology which define threshold and target values on timeliness, accuracy and resolution etc. of ZTD and IWV estimates for use in nowcasting and climate monitoring. In this paper, we have compared the ZTD estimates obtained in RT using three PPP software packages (described in the next section) with the high precision GPS-based troposphere product known as the IGS Final Troposphere Product  [4]  (hereafter mentioned as IGFT) in order to assess the accuracy of these estimates. The effect of integer ambiguity resolution on ZTD estimates has also been studied using two different versions of the software package called PPP-Wizard.
Methodology The real-time processing for this study was simultaneously performed at the University of Luxembourg (UL) and the Geodetic Observatory Pecny (GOP). UL generated the solutions from BNC2. 7 and PPP-Wizard whereas GOP generated the solutions using Tefnut application from the G-Nut software library. The selection of 22 globally distributed stations from the IGS Real-Time GNSS network used for this comparison is shown in Figure  1. A dataset containing real-time ZTD estimates for the previously described network of stations and a time-period of 31-days (2013-04-18 to 2013-05-18) was obtained using the software packages listed in the previous section. The configuration and characteristics of the software packages used during the RT processing are shown in Table  3.
BKG Ntrip Client The BKG Ntrip Client (BNC), developed by the Bundesamt für Kartographie und Geodäsie (BKG)  [5] , is capable of performing PPP in RT (RTPPP). For this study, version 2. 7 of the BNC has been used to perform RTPPP using streams of code plus phase observations, broadcast ephemeris and corrections for satellite orbits and clocks. During the process in BNC, the corrections from the RT streams are applied to the broadcast ephemeris. Along with the precise position estimates, the total tropospheric delay estimates can also be obtained as one of the outputs.
G-Nut/Tefnut Softwrae Library The G-Nut software library  [7]  has been developed at the Geodetic Observatory Pecny (GOP) since 2011 in order to support development of high-accuracy GNSS analysis. Several end-user applications were already derived for meteorology and climatology (Tefnut), geodesy and seismology (Geb) and GNSS quality check (Anubis). In this paper we used G-Nut/Tefnut software that is capable of estimating GNSS tropospheric parameters in RT, NRT and post-processing modes. The overall biases between the RT PPP ZTD estimates from the individual RT solutions and the IGFT are shown in Table  4. The PPP-Wizard's ambiguity float solution (PWFL) has the largest mean bias of 6. 81 ± 2. 42 cm. Here it is important to mention that PPP-Wizard was originally designed to estimate the positions of moving receivers and it does not apply the correction for receiver antenna phase center offsets.
Acknowledgements This project is funded by the  Fonds National de la Recherche, Luxembourg  (Reference No. 1090247 ). The work at GOP was funded by the  Czech Science Foundation  (project No. P209/12/2207 ). The cooperation was supported by the  COST Action   ES1206. We are thankful to BKG for the BNC 2. 7 software and the EUREF and IGS communities for GNSS data and products.
Siam extracted the two hundred most frequent words from Wikipedia Masri, 1 which given the scarcity of available tools proved to be quite a challenge. The idea of incorporating statistical information gathered in this project was the initial incentive to start thinking about how to encode such information in accordance with the TEI Guidelines. Journal of the Text Encoding Initiative, Issue 8, Selected Papers from the 2013 TEI Conference More dictionaries are under preparation. The VICAV database also contains data on Sudanese Arabic, Maltese, Modern Standard Arabic, and the Shawi dialects. One overarching goal of all these endeavors is the creation of a comparative dictionary with an integrated research environment that allows access to all of these data.
Originating in the tradition of textual criticism, this module denes the phrase-level element <app> to embed various versions of a passage in-line, optionally declaring one as the preferred reading. The resulting TEI <text> is a compound object that does not have one single "non-electronic" counterpart, but documents a multitude of fragments from various resources. Likewise, a dictionary, which is closely intertwined with data from language resources, can be conceptualized as the abstraction of this instance data. In order to express the specic nature of its "sources," the textcrit module has to dene a new child to <sourceDesc>, the <listWit> element. Following this example, we propose the introduction of a <listResource> element to hold a list of any language resources from which the dictionary in the document's <body> draws its statistical information.
The purpose of the <resource> element is twofold: rst of all, it enables a user to locate and access the language resource personally. Secondly, it provides a basic description of it through a series of appropriate properties. Although this information is likely to be part of the metadata held alongside the corpus data itself, it seems reasonable to keep a summary of it with the dictionary, especially as corpora may become inaccessible or evolve over time. The TEI Guidelines already provide the components for this in the <bibl> element's content model, with the <extent>/<measure> construct being a natural candidate for the representation of corpus size. Modeling <resource> after <bibl> helps us address some specic limitations of the language resources we currently have to make do with: it lets us distinguish between various kinds of data via the @type and @subtype attributes, while the @statusattribute indicates whether the data in question are expected to be subject to change or not.
The Tenets of Frequency Information What is needed is a denitive system to register quantications of particular items represented in dictionary entries. This of course raises the question as to which parts of a dictionary entry can be considered relevant. First to come to mind, of course, are headwords. But there are many other constituents of dictionary entries that might be furnished with frequency data: inected word forms, collocations, multiword units, and particular senses are relevant items in this respect. The data model should not only provide elements to encode frequencies within elements describing the above-listed constituents of entries, but also allow indication of the source from which the data were gleaned and how the statistical information was created. The basic constituents of our model should contain these items: Journal of the Text Encoding Initiative, Issue 8, Selected Papers from the 2013 TEI Conference • Value (number of occurrences of the particular item) • Rank • Provenance (source from which the data is taken) • Retrieval method (how the statistical information was created) • Query type.
43 We named the root element to carry frequencies "statistical information. " We chose a generic name rather than making use of narrower terms such as "corpusFrequency," as the data we wanted to use might come from other language resources than text corpora, such as word lists, other dictionaries, or databases aggregating statistical data from external sources. The chosen term appeared to be semantically correct and would allow us to keep options open to other scenarios. • <statInfo> (statistical information) contains statistical information about instances of any component of a dictionary entry in one or more language resources.
44 The next step was to nd a way to indicate where the statistical information came from. Intuitively, one might expect a <source> element. However, <source> already exists in the Manuscript Description module (and can only be used as a child of a <recordHist> element). As we considered it good practice to avoid denominational ambiguities, we eschewed using "source" in the namespace of the customization, but introduced a <dataset> element which, through membership of the att. canonical class, inherits the attributes @key and @ref, with the latter providing the mechanism to point to a <resource> element in the <teiHeader>. In the eld of our research, we are still far away from reliable reference corpora in the proper sense of the word. At the moment, we are instead in a situation where we have to integrate anything available in default of anything better.
For comparative purposes it might therefore be important to have a list with several <dataset> elements to give users a more complete picture of the available data beyond the resource proper. The statistical information itself would remain in the TEI namespace. This is exactly the same construct which we have already proposed above. <measure commodity="tokens" quantity="6" unit="count" type="absolute"/> <measure type="rank" quantity="2456"/> A key issue here is the access mode. The element <retrievalMethod> has been proposed to accommodate information regarding the query and possible modications to the result set. This information is dealt with in two child elements: <query> and <evalMode>. <acdh:retrievalMethod> <acdh:query type="CQP">lemma="go"</acdh:query> <acdh:evalMode>manual</acdh:evalMode> </acdh:retrievalMethod> The <query> element contains the query string.
It should also have a @type attribute indicating the applied query language. In the example above, CQP (Corpus Query Processor) refers to the query language of the IMS 15 Corpus Workbench. The element <evalMode> can be lled with either "none", which implies that the data was retrieved automatically, or "manual", which should be applied when some kind of postprocessing has been done. For purposes of reproducibility it may be desirable to document the various steps that produced the nal set of records with ner granularity. In this case, <evalMode> could be replaced by an <evalDesc> element, containing a series of <filter> tags with one child <query> each. Journal of the Text Encoding Initiative, Issue 8, Selected Papers from the 2013 TEI Conference <acdh:retrievalMethod> <acdh:query type="CQL">word=".
51 Of course, this kind of detail is not attainable without the help of specialized software. Aiming toward tighter integration of language resources with dictionaries, we imagine a next generation of dictionary editors providing facilities to query language resources and keep track of userdriven modications of the results, and oering functions to embed them in the markup. Until implementations have reached this level of integration, we have to rely on a combination of components to support this functionality. An example for this is the commercial product Sketch Engine,  16  which includes a web interface for querying language corpora. In particular, it oers the ability to download the resulting frequency data (as well as concordances) in its own, vendor-specic, XML format. This format also contains the sequence of query expressions that leads to the nal result set.
However, funding agencies increasingly insist on open access not only to research results but also to research data. It is therefore to be hoped that the situation with respect to openly accessible lexicographic data as well as to electronic corpora will improve in the years to come. Solutions for integrating these data and/or accessing various resources simultaneously will become even more important. Thinking about how particular language resources can interact and working on appropriate interfaces is an indispensable prerequisite for more linked (open) data and service-based architectures. The more such data become available, the more important it will become for the TEI to provide viable solutions for dealing with them. Journal of the Text Encoding Initiative, Issue 8, Selected Papers from the 2013 TEI Conference 6 While entries and example sentences were originally located directly inside the <body>, we have now settled for a clearer distinction between the two.
Since most of our dictionary data is created and maintained using the Viennese Lexicographic Editor and held in a relational database (described in Budin, Majewski, and Mörth 2012), format changes like this can be applied transparently on all of our dictionaries, making it easy to ensure structural homogeneity. 7 For more detail see Budin, Majewski, and Mörth 2012. 8 The example above exhibits some features which might seem idiosyncratic at rst glance, namely the usage of the @ana attribute and the values in the @xml:lang attributes. The fragment identier in @ana refers to a feature library in the <teiHeader>, providing a concise notation for morphosyntactic annotations. In the example above, it denes the inected <form> to bear the features noun and plural. The composition of the @xml:lang attributes is an extension to the BCP 47 standard tags, which proved necessary in order to provide a higher degree of locational granularity (see Budin, Majewski, and Mörth 2012).
<entry xml:id="mashcal_001"> <form type="lemma"> <orth xml:lang="ar-arz-x-cairo-vicav">mašʕal</orth> <orth xml:lang="ar-arz-x-cairo-arabic">‫/<ﻣﺸﻌﻞ‬orth> <acdh:statInfo> <acdh:dataset ref="#wikiMasri">. </acdh:Journal of the Text Encoding Initiative, Issue 8, Selected Papers from the 2013 TEI Conference.
1, F k /F max = 0. 7 and k x  = 0. 15 m/s-these values were inspired by our previous work  [9]. Due to the highly nonlinear character of the corresponding differential equation to be solved, we generally were not able, by means of the software Matlab and its ordinary differential equation (ODE) libraries, to get the convergence towards the desired position. Figure  1d  is presented as a non-fully successful attempt to simulate the considered problem with k I = 10 m -1 • s -1 with a time scale corresponding to the best obtained result for a reasonable computing time. The result reported in Figure  1d  does not mean that the simulated system cannot converge towards the desired position but, after having tested the different Matlab ODE libraries without finding the good software solution, we did not try looking for a more sophisticated differential simulation method; it was preferred concentrating on experimental testing.
Our contribution is based on the determination of domination relations between nodes. This notion has been applied to data points in the context of databases for the definition of the SkyLine query  [12]. The domination relation between nodes allow comparing compromises between nodes characteristics, and allows nodes to estimate their position in a global domination partial order that would contain all nodes if materialized. This position is used, as for the uni-dimensional slicing, to determine the slice a node belongs to. The remaining of this paper is organized as follows. In Section 2, we present the principle of a representative slicing algorithm for single-dimension attributes, which serves as the basis for the multi-dimensional slicing presented in Section 3. We present an evaluation of our contribution in Section 4.