dataesr/scientific-paragraphs-categorization huggingface dataset:
g. species distribution, taxonomic knowledge or literature) and very few combine different kinds of biodiversity data and make it available under a species axis. One such initiative is the Atlas of Living Australia, which is experiencing great success as a biodiversity informatics platform. Such initiatives may serve as a good models for country wide or region based initiatives to collect, curate and disseminate biodiversity information. India is one of ten largest countries in the world with a total area of more than 3 million km². India is also well-recognized as a highly ecologically diverse country, with a high diversity of habitat, ranging from alpine to tropical ecosystems, containing high level of endemicity  (Ahmedullah and Nayar 1987, Ramesh and Pascal 1997)  and one of the eight megadiverse hotspots in the world  (Mittermeier et al.
The Indian Medicinal Plants Database documents information on medicinal uses of plants in Indian systems of medicine. Indian Bioresource Information Network and Indian Biodiversity Information System are known multi-institutional and institutional repositories hosting species information. However, a comprehensive biodiversity information system that can compile various aspects of biodiversity information at the species level, such as spatio-temporal distribution, taxonomic and conservation status, or any relevant information on ecology/ ethology, is currently lacking. This gap may be filled by an inclusive model that allows broad based participation from experts and enthusiasts. Such an information system is thought to be crucial towards implementing India's aims towards the conservation of its biological resources and associated knowledge and facilitating access to them in a sustainable manner  (Gadgil 2003).
In this paper, we introduce the India Biodiversity Portal (IBP), an initiative building on a collaborative platform that integrates an array of biodiversity knowledge and serves it under open access. As discussed below, the core philosophy of this platform is to bring together expertise from research, civil society, advocacy, information technology and legal domains with a strong commitment to open data for effective biodiversity conservation in India. The India Biodiversity Portal is an open access biodiversity information platform for India launched in December 2008, involving various institutions in India (listed in the acknowledgements). IBP has two main objectives: aggregating curated biodiversity data for all species in India and creating/stimulating social networks where biodiversity amateurs and experts can interact.
As no comprehensive species-lists cataloguing all species occurring in India were available, species names of known distribution in India were aggregated from global biodiversity databases such as the GBIF, IUCN, Fishbase (Froese and Pauly 2016) and other regional data to create stub species pages. The structure of the Species Pages Module follows the international standards of the Taxonomic Database Working Group. An adaptation of the Species Profile Model and the Plinian Core format was used to set up the standard data fields for storing data within species pages. The structure has the flexibility to accept information on varied subjects such as taxonomy, natural history, habitat and distribution of species, and allows content contribution in every field from multiple contributors. Species information is populated from species contributors who are recognised experts in their respective taxonomic group, identified and validated by a team of administrators from IBP.
Names can be resolved against global species databases such as the Catalogue of Life (CoL,  Roskov et al. 2015) , GBIF, EoL or by curator input. The provenance of the name status is maintained and displayed to track changes. It also facilitates taxon curators to segregate names into categorized lists based on the validity of a name with respect to geography and taxonomy allowing dynamic species lists for India to be generated and maintained. The name curation exercise is also crucial to building a unified management classification and a taxonomic tree that facilitates the organization and navigation of all species content throughout the portal. Along with the primary modules, IBP also has a number of features and tools to help record, collect and curate data. The "Groups" feature, allows the creation of a micro-site on any theme of interest within IBP.
They are currently 49 groups on the portal (as on 25 July, 2016). A "Datasources module" has recently (2016) been deployed to facilitate aggregation and integration of observation data from external data sources such as GBIF with the portal. The module integrates these records by replicating spatial, temporal and species name attributes of the record on IBP and creating an observation. Media objects are not replicated but will be displayed within the observation gallery from its original source URL if available. This functionality provides IBP with powerful capabilities to aggregate spatial and temporal species records from regional and global databases to enhance its data. A mobile application for Android and iOs smart phones has been developed for users with portable devices. These applications make it easier to record observations, since the date and location of the observation are recorded directly by the device.
As illustrated in Fig. 4 , IBP has seen almost exponential growth in the number of users with over 8500 registered users currently and growing at a rate of over 400 users per month. Statistics revealed by Google Analytics indicate that there are over 86000 page views and approximately 18,000 active visitors per month. Contribution in all of the modules have been on the rise, especially in the Observation Module, with over 4000 observations being uploaded every month. Over 20% of the registered users have uploaded observations on the portal with 15% contributing less than 10 observations per user and over 1% uploading more than 100 observations (Fig. 8 ). Given the current trends in participation, we expect that these figures will continue to grow exponentially in the future. So far, 132,070 observations have been aggregated through user participation and an additional 1,149,228 records from global databases aggregated through its "datasources module".
In a few years, IBP has accumulated a large amount of information on biodiversity, with an exponential increase in data, which has been already cited in academic research (36 publications have cited or used IBP data). We believe that in the next few years, data from IBP will considerably help our ability to understand the long (e. g. biogeographic history) and short (e. g. annual variation) term dynamics of Indian biodiversity, notably in a global change context. Since open data is at the core of IBP's philosophy, data will be shared with global initiatives such as the EoL and GBIF at regular intervals. Thus IBP, well illustrates how national initiatives working in a participatory manner and involving multi-institutional collaboration, may contribute to global biodiversity initiatives through a bottom-up perspective.
Acknowledgements Partners: Institutions which comprise the  IBP consortium: Asian Biodiversity Conservation Trust ;  Azim Premji University ;  Ashoka Trust  for Research in Ecology and the Environment; Bombay Natural History Society; Care Earth;  Foundation for Ecological Research Advocacy and Learning; Foundation for Ecological Security; Foundation for Revitalisation of Local Health Traditions ;  French Institute of Pondicherry; Hornbill Foundation; Indian Foundation for Butterflies; Keystone Foundation ;  Madras Crocodile Bank Trust ;  National Centre for Biological Sciences; OSGeo; Salim Ali Centre for Ornithology and Natural History ;  Strand Life Sciences ;  WWF India ;  Zoo Outreach Organisation.
Our main goal is to understand how the crowd can contribute for API documentation on two programming tasks: how to implement a scenario using an API (how-to-do-it), and how to fix domain-independent bugs in an existing code where there was a misunderstanding regarding the usage of an API (debug-corrective). We classified questions available on Stack Overflow by the main concerns of askers, and we used those classified as how-to-do-it and debug-corrective to analyze the coverage of API elements on the discussions related to such questions. Our cases included the well-known and popular Swing and Android APIs. Results: Our main findings showed that the crowd provides more content for debug-corrective tasks than for how-to-do-it tasks, regardless of the API. Android API elements are more discussed by the crowd compared to Swing.
Training set construction Classification algorithms fall within the category of supervised machine learning algorithms. It means that they must be trained with a set of labeled samples (training data) to be able to distinguish unlabeled samples (test data) between a set of classes. Since we are interested in the selection of Android and Swing threads, we randomly selected 400 questions related to each API from the Stack Overflow database to construct the training sets. We consider that a question is related to an API if some of its tags contain the name of the API ("android" or "swing"). We decided to use non-exact word matching on tags, i. e. , to not accept only those which match the exact "android" and "swing" keywords, as we observed that there are Android-and Swing-related questions tagged with packages of the API.
Input data for the tools The data source used to extract the input data for the tools consists of both the content of questions and the content of one of their answers (the selection of the answer is described in the next paragraph). We used the content of answers since Souza et al. [7]  classified Q&A pairs and reported that the answer body provides relevant information to make decision of the Q&A pair class, even considering that the classification applies to questions. In addition, we used the content of exactly one answer for each question to acquire greater uniformity across the dataset since a question with ten answers has more content than a question with one answer. So, for each question, we selected one of its answers by passing them through a conditional selection sequence: (1) if the question has an accepted answer, select it; otherwise, (2) if there is only one answer with the highest score, select it;  The classification process in Weka uses attribute values extracted from the source data (question plus answer) and in Mallet their textual content is used.
Threads preprocessing Before performing the linkage of threads with API elements, we preprocessed the content of threads. This preprocessing consists of separating the content of each post of threads (question and answer) according to the link types. We used Jericho HTML Parser  [36]  to perform this task. Given a post, for code sample and code markup links, we first collect all <code> elements existing in the post. Then, we verify if there exists white-space between strings in the content of each <code> element. In those cases where it does not occur, we consider the content of the <code> element as code markup. Otherwise, that content is separated for code sample link. For href markup link, we just collect all <a> elements existing in the post. For word link, we removed the content of <code> and <a> elements from a copy of the whole post body.
If the package name of an API element is found, the thread is linked with that API element. Otherwise, i. e. , if no package of those API elements is found, the thread is not linked with any of those API elements. Second, the existence of inner elements in the API raises a problem of matching API elements using word boundaries, as the dot character is considered a non-word character. This problem occurs in two forms. Form A: the name of outer elements also matches the name of their inner elements. For example, at searching the DefaultTableCellRenderer element name by using the regex number 3, the DefaultTableCellRenderer. UIResource name will also be a match. Form B: the name of (inner or noninner) elements can also match with the name of inner elements. For example, when searching the UIResource element name, the ScrollPaneLayout.
UIResource and BasicComboBoxEditor. UIResource element names will also be matches. To avoid this problem, we used negative look-ahead for form A and negative look-behind for form B. Negative look-ahead and look-behind aim at ensuring that the pattern of interest is not immediately followed or preceded by another pattern, respectively. In our case, regarding the DefaultTableCellRenderer element name, we used negative look-ahead (regex number 4 in Table  11 ) for ensuring that the name is not followed by. UIResource. In a similar way, we used negative look-behind (regex number 5 in Table  11 ) in order to ensure that the UIResource name is not preceded by ScrollPaneLayout. and BasicComboBoxEditor. Third, one-word API element short names, like View, can be confused with English words in natural language texts.
Data collection The necessary data for answering the research questions are (1) the Stack Overflow threads on Swing and Android, (2) a list of classes, interfaces and enumerations existing in Swing and Android, and (3) usage references of Swing and Android elements in source code of real software projects. 1) We downloaded the Stack Overflow threads from the Stack Exchange Data Dump  [39] , release of January 2014 of the Stack Overflow public data dump, and we imported these into a relational database to facilitate queries. Specific threads for Swing and Android were selected in the same way as shown in one of the previous sections, i. e. , by searching for threads where their questions have a tag containing the name of the API ("android" or "swing"). 2) We obtained the lists of Swing and Android intermediate elements from javadoc jar files.
swing" and "android", for Swing and Android, respectively, although those jar files contained other utilities. 3) We obtained the usage of Swing and Android elements from the Boa infrastructure  [42] , which provides the metadata for almost 8,000,000 GitHub projects. Projects identified as Java projects also include repository history and source code. The source code of a Java file is stored as abstract syntax tree (AST). Boa provides a syntax inspired by the object-oriented visitor pattern to analyze projects and their ASTs using depth-first search traversal strategy. In a visit function, visit clauses are defined to visit AST node types, and when the visitor visits any node matching the specified node type, the body of the clause is executed. We coded a visit function for collecting Swing and Android usage, which traverses the ASTs of full development histories of Java projects.
The types of AST node of interest are Project, ASTRoot and Type ones. We collected the name of the projects in a visit clause defined for Project node. API usage information is obtained in the visit clauses defined for the ASTRoot and Type nodes. In ASTRoot nodes, we searched imports (generic or not) of the APIs. In Type nodes, we searched (i) fully-qualified name of types (classes, interfaces and enumerations) used in statements and (ii) any other types used in statements of an AST where an import of the API was found. For finding imports and fully qualified name of types, we check if their names start with "javax. swing" and "android", for Swing and Android, respectively. We post processed the non-qualified types found in ASTs where an import of the API was also found. We check whether these types belong to any package found as a generic import in the same AST.
The results for Swing are presented with different perspectives in Fig. 4  and Table  20 , column "Coverage/How-to-do-it". We observed that two packages (out of 18) are completely covered: javax. swing. filechooser and javax. swing. text. rtf, which are also the smallest. Considering the two largest packages, javax. swing has an average coverage (63. 07%), and javax. swing. plaf. basic is poorly covered (18. 13%). Moreover, there is one package completely uncovered (javax. swing. plaf. multi), which is represented by the scratched rectangle. To verify whether the size of package influences coverage, we calculated Spearman's rank correlation coefficient (ρ) between package size and coverage. Correlation coefficients measure the extent to which two variables tend to change together. In the case of ρ, a positive value indicates that coverage tends to increase when package size increases, and a negative value indicates that coverage tends to decrease when package size increases.
For the sizes and the how-to-do-it coverage of the Swing packages, we found ρ = -0. 33, which means a weak negative correlation, i. e. , the coverage tends to decrease when package size increases. For Android (see Fig. 5  and Table  21 , column "Coverage/How-to-do-it"), we observed that nine packages (out of 66) are completely covered, but they are also small (maximum ten elements). The second largest package with 166 elements, android. widget, is reasonably well covered (90. 96%). This package contains (mostly visual) UI elements. However, the largest package with 169 elements (android. provider) is only half covered (50. 89%). This package provides convenience classes to access the content providers that store common data, such as contact information, calendar information, and media files.
There are also three smaller Android packages completely uncovered (scratched rectangles): android. drm, android. mtp and android. service. textservice. We observed that there is a very weak positive correlation between coverage and package size, ρ = 0. 04. It suggests that there is no tendency for coverage increases/decreases when package size increases. So far, we have presented results of the coverage analysis considering if API elements are covered or not. In addition, we present, for the covered API elements, the distribution of the numbers of threads (containing howto-do-it question) to which these were linked. Figures  6a  and 7a  present the distribution for Swing and Android elements, respectively, in boxplots. Note that the y-axis is in a log scale. Highlighted here is that, in general, the distributions for both Swing and Android follow a similar pattern.
Considering the two largest packages, javax. swing has an average coverage (68. 05%), slightly better than in how-to-do-it coverage (63. 07%), and javax. swing. plaf. basic is poorly covered (27. 98%), although it is better than the how-todo-it coverage (18. 13%). Moreover, there is no package completely uncovered. We observed that only 3. 23% of the elements of the package completely uncovered in RQ #1, javax. swing. plaf. multi, are covered in threads for debug-corrective tasks. We also observed that there is a moderate negative correlation between coverage and package size, ρ = -0. 58, compared to a weak negative correlation in how-to-do-it coverage (ρ = -0. 33). For Android (see Fig. 9  and Table  21 , column "Coverage/Debug-corrective"), we observed that 24 packages (out of 66) are completely covered, compared to nine packages in RQ #1.
Association rules are mined from a database containing a set of transactions, and each transaction has a set of items. In our case, threads are transactions, and API elements mentioned in the threads are itemsets. We used R  [43]  for mining association rules by using the Apriori algorithm and for visualizing the results. Also, we had to define thresholds for support (sup) and confidence (conf ) measures to find association rules of interest. The support of an itemset A is the proportion of transactions in the database which contain the itemset, and the confidence of a rule A → B is the proportion of transactions that support B among the transactions that support A. The decision-making regarding the choice of thresholds for such measures is challenging. There is no consensus for such values.
However, confidence of rules is more interesting than support of itemsets to us, i. e. , to which degree can we rely on the occurrence of API elements implies that the occurrence of other API elements is more interesting than how much the API elements occur over the whole database. Therefore, we choose higher thresholds for the confidence measure than for support. More specifically, we defined sup = 0. 01 and we generated association rules for conf = {1. 0, 0. 9,. , 0. 5}. Tables  24  and 25  present the numbers of association rules obtained for Swing and for Android, respectively, from both how-to-do-it and debug-corrective coverage analysis. Even the threshold for sup is low, the number of threads that API elements must be mentioned together for creating association rules is high. For instance, in the how-todo-it coverage analysis for Swing, API elements must be mentioned together in at least 84 threads.
API coverage growth and API-related thread growth To answer RQ #4, during coverage analysis, we obtained for each API element the date in which the element was covered (mentioned for the first time). Then, we calculated the coverage percentage of the APIs day by day, resulting in the growth of API coverage. Moreover, we collected, from our Stack Overflow database, the number of threads related to the APIs (tagged with the API name) grouped by day. From the total number of threads related to each API, we calculated the percentage of threads day by day, resulting in the growth of API-related threads. Figures  13  and 14  present charts, for Swing and Android, respectively, containing three series: the growth of API coverage on threads containing how-to-do-it (dotted line) and debug-corrective questions (dashed line), and the growth of the number of threads related to the API (solid line).
APIMiner tool  [50]  and the Kim et al. 's approach  [51]  automatically extract such code examples from (private and web, respectively) source code repository to enhance existing Javadocs. Souza et al. [5]  used the crowd knowledge available on Stack Overflow to semi-automatically generate cookbooks for API documentation. Generated cookbooks consist of the description of programming tasks and their solutions by using the API. Lafetá et al. [45]  also generated cookbooks, focusing on framework feature instantiation instead of general programming tasks. They mined examples of instantiations from the source code of the framework itself and from existing instantiations to generate cookbooks. Treude and Robillard  [53]  also used crowd knowledge available on Stack Overflow, as Souza et al. [5]  did, to automatically augment API documentation with insight sentences.
Their technique is based on the assumption that code elements mentioned in close vicinity are more likely to be related than code elements mentioned further apart, so they take into account the context in which a code-like term is mentioned-context refers to additional information in various scopes surrounding the term  [37]. They also identified sources of ambiguity inherent to linking code-like terms in unstructured natural language documents. To resolve these ambiguities, they applied a set of filtering heuristics. For example, for a given term identified as a member (e. g. , method, field), the declaration ambiguity filter analyzes the context of this term trying to find its declaring type. Rigby and Robillard's tool, called ACE  [37] , is based on the technique implemented on RecoDoc.