dataesr/scientific-paragraphs-categorization huggingface dataset:
A. Dataset and Experiment Setup Our dataset is comprised of three components: after-update examples used for the update-script creation, one-to-one API mappings from the deprecated APIs to the replacement APIs, and the target files to be updated. We utilize the after-update examples that were used in the evaluation of AppEvolve  [4]. For the target files to be updated, we extend the target file dataset from CocciEvolve  [6]. We randomly selected public GitHub projects obtained using AUSearch  [11] , a tool to search GitHub repositories for API usages. We collected 360 target files containing 20 deprecated Android APIs for our target files dataset. We evaluated the performance of AndroEvolve by comparing its update accuracy (i. e. , the percentage of correct updates) against CocciEvolve's. We also compare the readability of the update results of the two tools, using an automated and a manual approach.
In the automated approach, we utilized a state-of-the-art automated readability measuring tool from Scalabrino et al. [10]  which gives a score of 0. 0-1. 0 where higher score indicates better readability. In the manual approach, we asked two experienced Android developers to score 60 successful updated code fragments, with 30 updated code fragments from each of CocciEvolve and AndroEvolve. We choose 30 as the sample size to represent the variation in the syntax of the updated code. The developers were not told which tool was used to produce each updated code fragment. For each updated code fragment, the developers were asked to give score in the Likert scale of 1-5 for the readability and the naturalness of the code. A higher score indicates higher readability and higher confidence that the code resembles code produced by a human.
B. Experiment Results We manually check the correctness of the updated code produced by both AndroEvolve and CocciEvolve. On the dataset, AndroEvolve and CocciEvolve are able to provide correct updates for 316 and 249 target files, respectively. Our analysis shows that data flow analysis helps to improve the number of correct updates produced by AndroEvolve. It works particularly well in cases where the after-update example uses out-of-method variables. In the readability evaluation, using the automatic approach, we measure the readability scores of the updated code and calculate the average for each API. We found that AndroEvolve's updated code achieves higher readability than CocciEvolve's for all of the evaluated deprecated API migrations. This finding is strengthened by our manual readability measurement where the average readability score given by the developers for AndroEvolve achieves a score of 4.
The system consists of four modules and a tweet opinion database: the tweet sender/receiver is an interactive front-end module, which receives the user's input and provides the result to the user; the tweet credibility calculator module utilizes the tweet opinion classifier to identify both the topic and the opinion of a given tweet; then, it performs a majority decision on contrary opinions in the same topic by using the tweet opinion database, which are stored in the tweet collector module and labeled with a topic-opinion label by the tweet opinion classifier module. Hoaxy  [33]  is a web platform for the tracking of social news sharing. The main goal of this work is to let researchers, journalists, and the general public monitor the production of online misinformation and its related fact checking.
The system presents three components: monitors (URL tracker, scrapy spider, RSS parser), a database as repository, and an analysis dashboard. The system collects data from two main sources, news websites and social media, by using web scraping, web syndication, and where available, API of social networking platforms. Afterward, this stored data is analyzed considering two aspects: the temporal relation between the spread of misinformation and fact checking, and the differences in how users share them. Being off-line systems, these platforms are not able to support real-time analysis. An approach to detect Source Of Fake News (SOFNs), by analysing credibility of tweets based on graph Machine Learning, is proposed in  [34]. The credibility analysis is based on user features (e. g. , created at, name, default profile, default profile image, favourites count, statuses count, description), social graph of users (followers/following graph), and topic annotations, whose information is gathered with the Twitter API.
The aim is to analyze, in real-time, the credibility of tweets regarding to a specific topic. Only the text of each tweet is analyzed to be classified as being entailment, neutral, or contradiction with respect the topic. The system shows a list of news information related to the topic; thus users can decide the veracity of the tweet in question. The Twitter API is used to collect tweets, web scraping is used to get the URLs referenced in tweets, and the Bing news API is used to find articles and retrieve news headlines related to the topic. In  [17] , a framework for credibility analysis on Twitter data, with disaster situation awareness is proposed. This framework is able to calculate in realtime the topic-level credibility (i. e. , emergency situations), by analysing the text, linked URLs, number of retweets, and geographic information extracted from both post text and external URLs, which are kept in a database.
Thus, an event with a higher credibility score indicates that there are more tweets, more linked URLs, and more retweets mentioning this event. Data is collected through Twitter API, to get the information of the tweets and Google Maps Geocoding API to obtain geolocalization information. The text is analyzed, in the event identification module, to extract words that match with keywords that describe a specific event (i. e. , a disaster situation topic); then its credibility is calculated by the credibility module. A more recent system for real-time credibility analysis is described in  [18]. This framework considers text and user credibility, aimed to identify fake users and fake news, based on neural network models. Text credibility is measured in terms of retweets, followers, favorites (i.
The front-end, a web extension (client), sends requests for Global Credibility calculation along with some parameters to the back-end. In the case of users providing a plain text, it requests Text Credibility analysis. The back-end (server) receives the request and returns a response, based on its contents, to the front-end. The back-end is also a client of the third-party services web module, which is not under our control. Arrows in Figure  2  define the dependency relationship among the components from a high-level view. Relationship between the front-end and back-end is mandatory, while the connection to a third-part service is optional and is only needed when the respective API is used. The optional dependency implies that the application can still be usable without access to social network API, but our proposal needs the back-end to be able to connect to that.
2) BACK-END The reason why the back-end is separated from the front-end is that, this way, any external agent from the architecture can access it. It also makes the system more extensible, since it does not have to replicate the logic of the model, only request it. If at any moment there is the need to add another module, it only has to know how to access and use the back-end resources, without knowing what happens behind, making everything in a more declarative way. It offers endpoints to access the mechanisms to calculate all credibility measures, based on REST API or SOAP API (although we recommend the prior because of its flexibility, wide use, and support). The architecture of the back-end, as shown in Figure  3 , is based on a layered pattern: • The first layer corresponds to the Controllers, that contains the REST or SOAP API endpoints that the backend exposes.
The reason of only showing the Twitter API option at the home timeline is because there is no way to scrap the user and account data from each tweet's author, required to calculate the tweets' credibility, only the tweet IDs are accessible via web scraping; thus, the rest of the attributes must be gathered via the Twitter API. On any Twitter user's profile, for full web scraping data gathering, the front-end assumes that all tweets in that timeline are from the user authorship, including retweets (retweets can be considered as a copy of another tweet). In that way, we can collect all user related information of the tweets the header of the user's profile web page and the specific parameters of each tweet (i. e. , text and language) from each single tweet in the feed. After selecting the extraction technique, either web scraping or Twitter API, the front-end analyzes the current timeline, extracting the necessary information, sending them to the back-end, and finally presenting the results over the time-  line.
2) BACK-END T-CREo back-end is a REST API developed using Express. js 4 that implements the proposed architecture for 3 https://twitter. com/dhall_lang 4 https://expressjs. com/ lang query parameter and the possible values are en, es, and fr. The text language is necessary to correctly choose orthography and bad words dictionaries. Currently, we do not have access to a language detection API or library. This endpoint corresponds to the leftmost branch on Figure  1. • /twitter/tweets: it receives the parameters to calculate the credibility of a tweet. It uses the same parameters from the /plain-text resource and the following ones: -The weight of each filter, three in total: weight social , weight user , and weight text. -The tweet ID to analyze. • /twitter/scraped: this endpoint behaves similar to the /twitter/tweets endpoint.
They both correspond to the whole credibility model shown in Figure  1. These endpoints correspond to the Controllers layer from Figure  3. The logic behind each endpoint is on the Calculators layer, where every filter from the credibility model proposed on  [35]  is implemented as 5 https://developer. twitter. com/en/docs/twitter-api/v1/tweets/post-andengage/api-reference/get-statuses-show-id a Javascript function. Each filter function just receives the parameters without worrying about how those were gathered. Thus, it is possible to reuse the same filter on each endpoint without duplicating code: what really changes between each endpoint is if the parameters were gathered through the Twitter API or by web scraping. These filters also interact with the Data Provider layer, specifically to invoke the Text Credibility filters.
Since our API is written in Node. js v1. 16. 0,  6  we have access to the whole NPM package ecosystem  7. The dictionaries used for the misspelling filter of Text Credibility are provided by Wooorm/dictionaries, 8  a GitHub repository containing dictionaries for several languages. To detect if a word is a bad word, we use the washyourmouthwithsoap library in NPM package, that is in essence a database of bad words with a method to lookup a word on a specific language. For SPAM detection, we use a fork of the simple-spam-filter package in NPM, due to the authors of the package stopped to maintain it on 2019. Our fork  9  uses the original logic, replacing the dictionary libraries with the ones from Wooorm/dictionaries. To connect with Twitter API, we use twit,  10  which provides a Node. js API client.
3) THIRD-PARTY SERVICES At this moment, T-CREo only uses Twitter as third-party web service. The Twitter API access is done on its website. 11 From this API, T-CREo uses the following two resources: • GET users/show/:user_id, that receives a user_id and returns the related information to that user. From this resource we use the following fields: verified, that is a boolean indicating if the user is verified or not; -created_at, that is the date when the user account was created; -followers_count, that is the amount of followers of the user; -friends_count, that is the amount of accounts that the user follows. • GET statuses/show/:id, that receives a tweet ID and returns all its information, including the one of the author. From this resource we use the following fields: -full_text, that contains the tweet's text; lang, which is the tweet's language.
This is an important parameter to perform a correct calculus of Text Credibility; -All of the aforementioned fields from the GET users/show/:user_id section. Each endpoint has an usage limit, but it is not a limitation at this moment, since the application is currently on a testingphase. We are planning to create a tweet database to keep more recent tweets and perform more experiments. In the next section, we present the experiments to evaluate the performance of T-CREo.
V. EXPERIMENTAL EVALUATION The experimental evaluation aims to present a quantitative analysis of T-CREo's performance over variables, such as the number of requests and the number of concurrent clients. To be specific, we perform tests that involve simulated users making requests to verify whether T-CREo framework can support the anticipated load and to measure its performance and scalability. The focus is to show how efficiently T-CREo behaves under the pressure of a certain number of requests and concurrency level. The script to perform the evaluation is available here. 12.
On the other hand, the Low droplets features are: • Price: $5/month • RAM/CPU: 1GB / 1 CPU • Disk: 25 GB SSD disk • Network: 1 TB outbound data transfer (inbound bandwidth to droplets is always free). Under normal conditions, the web extension (i. e. , T-CREo's front-end) is responsible for scraping the tweet data and making requests to the back-end to obtain the credibility score. This sequence of operations include local inmemory read operations (at the front-end), Internet access to send/receive the front-end's request/response to/from the back-end, and the back-end operations to calculate the credibility score. Since local read operations are performed at the front-end in despicable times (< 0. 1ms) and to facilitate the tests, we developed a shell script that simulates the frontend tasks, called script-client.
A. IMPROVE THE PERFORMANCE As outlined in Section IV-B2, the back-end is developed in Express, a Node. js framework implemented as a JavaScript runtime built on Chrome's V8 JavaScript engine. Javascript is a single-threaded language and it has not a native way of creating threads to parallelize the work. A possible solution available in Node. js to overcome this limitation is the usage of asynchronous tasks, which are frequently used to parallelize I/O operations, such as reading files and network calls. All endpoints in the current version of T-CREo are implemented as synchronous tasks, since they do not perform network requests or file readings. Making a synchronous task behaves as an asynchronous task is counterproductive and not recommended. Accordingly, T-CREo's endpoints are able to handle only one request at a time.
Another idea to improve the performance is to use a search engine or an external database to implement some of the components of the data provider layers from Figure  3. On the current implementation, the data providers layer runs in the same process of the T-CREo back-end, therefore the dictionary lookup algorithms are implemented in Javascript, which is not ideal for highly intensive CPU operations. This also makes the server to take some time (aprox. 1 minute) to start and be able to receive petitions. By delegating these lookups for misspelling and bad words filters in a separate application, such as Elasticsearch 20 or even a simple RDBMS, like PostgreSQL, the server can be able to receive petitions earlier and the lookups can be made in a most efficient way.
Applying web scraping on Reddit is a hard task since the HTML contents of the page are generated automatically by a thirdparty software, but their API offers the necessary resources for an integration on T-CREo to be possible. The credibility model might need to be modified, since some fields are not available on Reddit, or have another meaning. For example, there is a following and followers notion, but another important metric for social credibility is karma, which is a number that increases as the user is more active in communities and makes good contributions. On Facebook, we cannot do web scraping because of the same reasons of Reddit. The CSS selectors used for scraping are randomly generated on each new release and changes very frequently. They have an API, but we need to explicitly request permission to other users to access their informa-tion, as on LinkedIn.
D. CREDIBILITY ANALYSIS OF TEXT ON IMAGES Another enhancement for T-CREo is to read text from images and run our credibility model with that text. This can be easily done by running Optical Character Recognition 21  (OCR) software on the back-end. The integration can be done in a: • Dedicated endpoint, say /image, that receives the same parameters from /plain-text but instead of a text it can receive an image URL or a sequence of bytes that represents the image. • Enhancing our Twitter API integration to get all images of a tweet and include the text found in any of the images in the tweet's text. Although we do not have experience implementing or using OCR libraries on Node. js, a search of Optical Character Recognition and OCR on npm shows that all popular choices are bindings of Tesseract, 22 which is an OCR engine open-sourced by HP.
E. REDUNDANCY AS A STRATEGY TO OVERCOME SOCIAL MEDIA API LIMITATIONS In the studied social media, Twitter is the one that has the most flexible permissions, but it still has some limitations on the number of requests that we can consume in a time window. This limitation is not exclusive of Twitter API. A solution for this problem is to keep a shallow copy of the requested tweet in a database that T-CREo's back-end can query and synchronize regularly with Twitter real data. A synchronization strategy can be to run a scheduled work until all data is updated. The endpoint to get tweets' detail has a certain number of requests per 15 minutes time window. We can implement a job that updates as much tweets as it can and updates the remaining tweets of our internal database 15 minutes later. This would not only overcome the problem with request usage limits, but can also be used to improve the credibility model from  [4] , by storing more properties and data.
The modularity and simplicity of T-CREo, and the use of the credibility model, enable the creation of a real-time service; however, the connection time (latency) can be a determining factor, that might be considered in the deployment of the system. Our future research is focused on the improvement of T-CREo, starting with the suggestions from Section VI, such as the implementation of several instances or multi-threaded versions of the back-end to improve the performance, keep an external database of posts to overcome API limitations, and incorporate credibility analysis in other social platforms, to provide a robust architecture to the community for the devel- 22 https://github. com/tesseract-ocr/tesseract 23 https://www. npmjs. com/package/node-tesseract-ocr opment of third-party applications.
This research was supported by the  FONDO NACIONAL DE DESARROLLO CIENTÍFICO, TECNOLÓGICO Y DE INNOVACIÓN TECNOLÓGICA -FONDECYT  as an executing entity of  CONSEJO NACIONAL DE CIENCIA, TECNOLOGÍA E INNOVACIÓN TECNOLÓGICA -CONCYTEC  under grant agreement No. 01-2019-FONDECYT-BM-INC. INV  in the project  RUTAS: Robots for Urban Tourism  centers, Autonomous and Semantic-based.
, 2012). For WGS analysis of C. jejuni and C. coli, several typing schemes have been developed, including two cgMLST schemes; a commercial cgMLST schema containing 637 loci from the SeqSphere+ software (Ridom GmbH, Münster, Germany; www. cgMLST. org) and the Oxford cgMLST schema with 1,343 loci  (Cody et al. , 2017). Two wgMLST schemes were also defined for C. jejuni/coli within the SeqSphere+ software (including the cgMLST and 958 accessory loci) and by the Oxford University (1,643 loci)  (Cody et al. , 2013). Moreover, two typing schemes were developed specifically for C. jejuni: a cgMLST (678 loci) and a wgMLST (2,795 loci) from the INNUENDO platform  (Llarena et al. , 2018). The method-dependent definition of a WGS-based genotype underlines the need for an international nomenclature to improve communication in outbreak investigation and in surveillance.
Strain Selection Five thousand C. jejuni isolates, from human and non-human sources collected in Luxembourg between 2006 and 2018, were inspected. Years 2009 and 2010 were not included as no molecular surveillance data were available. Genotypic data associated with this collection included extended MLST profiles indexed on nine loci: 7 targets of MLST  (Dingle et al. , 2001) , the partial sequence of gyrA  (Ragimbeau et al. , 2014) , and the Sequence Variable Region of porA  (Campylobacter MOMP database; Dingle et al. , 2008). The nomenclature for displaying the results of this extended MLST was defined as follows: sequence type (ST), gyrA (allele number), and porA (allele number). For example, the combination of alleles including ST19 associated with gyrA allele number 8 and porA allele number 7 is displayed as follows: ST 19-8-7.
cgMLST and wgMLST INNUENDO Schemes The cgMLST and wgMLST schemes from INNUENDO include 678 and 2,795 loci, respectively, and are publicly available at Zenodo (https://zenodo. org/record/1322564#. X5l_4IhKg2y,  Rossi et al. , 2018). The cgMLST and wgMLST profiles of the INNUca assembled genomes produced in this study were called using chewBBACA suite (v 2. 0. 17. 1)  (Silva et al. , 2018). The achieved cgMLST profiles were added to the cgMLST allelic profiles of the 6,526 C. jejuni genomes of the INNUENDO dataset, which is also available at Zenodo (Allele_Profiles/ Cjejuni_cgMLST_alleleProfiles. tsv, https://zenodo. org/record/ 1322564#. X5l_4IhKg2y,  Rossi et al. , 2018). Minimum Spanning Trees (MST) and goeBURST distances were calculated using the goeBURST Full MST algorithm implemented in PHYLOViZ 2.
Comparison of the Targets Included in Each cgMLST Schemes To crosslink loci with different naming conventions across the four typing schemes, we compared the allele sequences in a pairwise manner. Allele sequences for cgMLST SeqSphere+ were downloaded from https://www. cgmlst. org/ncs/schema/145039/. Allele sequences for cgMLST Oxford were downloaded via the pubMLST RESTful API (scheme 4)  (Jolley et al. , 2017). Allele sequences for cgMLST INNUENDO were downloaded from Zenodo  (Rossi et al. , 2018). We selected the first allele sequence for each loci of the four typing schemes and performed pairwise reciprocal best hit comparison for the three schemes with the rbh function of the MMseqs2 toolkit ver. 11. e1a1c  (Mirdita et al. , 2019)  using nucleotide search including forward and reverse strand, as well as default parameters.
Hits with bitscore above 100 were selected and connected across schemes with a custom script in R 3. 4. 4. (R Core Team, 2018) using the igraph package 1. 2. 5. (Csaŕdi and Nepusz, 2006). Sets of matching loci within the three schemes were visualized with the UpSetR 1. 4. 0. package  (Conway et al. , 2017).
Cluster Analyses In SeqSphere+, Campylobacter isolates are classified in CTs in which the first CT assigned chronologically is definitively fixed in the database and referred to as the CT founder  (Ridom SeqSphere+, 2013). In contrast, the goeBURST algorithm produces a hierarchical classification with the gene-by-gene approach and aims to predict the founder of a clonal complex based on the allele frequency in the dataset. It assumes that the ancestral genotype is the predominant one, which subsequently generates variants. To deduct and visualize, the possible evolutionary relationships between strains, the goeBURST algorithm and its expansion to generate a complete MST implemented in PHYLOViZ 2. 0 was used for the cgMLSTs SeqSphere+, INNUENDO, Oxford, the cgMLST SeqSphere+ combined with the accessory targets and the wgMLST INNUENDO (https://online2.