dataesr/scientific-paragraphs-categorization huggingface dataset:
ACKNOWLEDGMENTS The authors thank medical and molecular geneticists from the  French Genetics and Cancer Group-Unicancer  and patients. The authors thank  Alice Yvard ,  Centre Catherine de Sienne, Nantes ;  Mathilde Warcoin ,  Department of Genetics, Institut Curie, Paris ;  Magalie Peysselon ,  Department of Medical Genetics, CHU Grenoble Alpes , for providing clinical information. We also thank  Denis Boidin ,  Lauriane Briois , and  Nora Boucetta ,  Molecular Oncogenetics ,  Department of Biochemistry and Molecular Biology, Lille University Hospital ; and  S. Miskinyte ,  Department of Genetics, Necker Hospital, Paris , for technical support;  Florent Denoual  and  Marie de Tayrac ,  Department of Molecular Genetics, CHU Rennes , for bioinformatic support.
Experimental procedures The study was conducted on two male rhesus monkeys (Macaca mulatta): G (age 8, 9. 1 kg) and J (age 7, 10. 0 kg). Experimental procedures and data analyses closely resembled those previously described  1. Before training, we implanted in each monkey a head-restraining device and an oval recording chamber under general anesthesia. During the experiments, the animals sat in an electrically insulated enclosure with their head restrained. A computer monitor was placed 57 cm in front the animal. The behavioral task was controlled through custom-written software (http://www. monkeylogic. net/). The gaze direction was monitored by an infrared video camera (Eyelink; SR Research) at 1 kHz. The chamber provided bilateral access to OFC. Structural MRIs (1 mm sections) performed before and after surgery were used to guide electrode penetrations.
Data analysis: Comparing effect sizes across current levels Data were analyzed in Matlab (MathWorks Inc). For each session, we examined separately trials with and without the stimulation (stimON, stimOFF). For each group of trials, we analyzed choices using probit regressions. From the fitted parameters, we derived measures for the relative value, the sigmoid steepness, and several choice biases (Eqs. 1-5). A comparison of the behavioral effects of electrical stimulation at different current levels focused on three measures, namely the rangedependent bias, the change in order bias, and the increase in choice variability. Each effect was computed in each session, rectified such that the expected effect was >0, averaged across the relevant population, and normalized across conditions. The normalized effect sizes were thus defined as follows.
Data availability The supplementary material includes the equivalent of Fig. 1BC  for each session in the data set. Raw data are available at: https://github. com/PadoaSchioppaLab/2022_NatComms_lowCurrent Source data are provided with this paper, and can be found at: https://github. com/ PadoaSchioppaLab/2022_NatComms_lowCurrent/tree/main/source_ data Source data are provided with this paper.
Creation and Upload of Metadata Files This first option is probably more appealing to expert and technical users, especially those that wish to register multiple related records or produce frequently updated versions of LRTs registered in ELG. To facilitate the process of adding records, prefilled metadata templates and examples (with the mandatory and recommended elements) are available in the ELG GitLab repository 1. As mentioned above, any existing metadata record can be exported from ELG as XML to be used as a template. A REST endpoint for metadata validation of single files or zipped archives of XML files is publicly available and offered for providers that want to validate their metadata files and ensure they comply with the ELG schema before uploading them to the platform. 2 The XSD validator checks that all mandatory elements are filled in and that filled-in values are consistent with the data type declared for the elementsfor example, if elements take values from controlled vocabularies or should follow a specific pattern -and returns the results in JSON form.
Users can upload their metadata records through the provider's grid (see Section 2. 3) as single files or in batch mode. The import step includes additional validation rules, which check the syntactic and, to a certain extent, semantic integrity of the record. For example, checks are performed for metadata elements that depend 1 https://gitlab. com/european-language-grid/platform/ELG-SHARE-schema 2 https://live. european-language-grid. eu/catalogue/#/validate-xml on the presence or value of other elements (e. g. , the element "multilinguality type" which is mandatory for bilingual and multilingual resources), or for duplicate values (e. g. , the same "language" value used twice). Validation errors are reported to the user for correction. If the file is valid, it is imported to the platform and the provider can perform further edits with the editor or submit it for publication in accordance with the publication life cycle (see Chapter 2).
This option is helpful because CI services are often restricted, e. g. , Gitlab has monthly quotas. In this case, users must first download the source code to a local folder (including the dockerfile), and then run a sequence of commands similar to Listing 2. Some languages and build systems provide alternatives for building Docker images that do not require developers to write their own dockerfile, or to use Docker at all. For example, Java services based on the Micronaut 15  helper described below can use the Micronaut built-in dockerPush or dockerPushNative gradle tasks to build and push an image in one step using an automatically generated dockerfile, or Google Jib 16  , which is designed specifically around the needs of Java applications and produces intelligently layered images that make more efficient use of space in the container registry.
Helper Libraries for Java For LT service developers working in Java or other Java Virtual Machine (JVM) languages such as Groovy 17  or Kotlin 18  , ELG provides helper libraries for two popular frameworks, Spring Boot 19  and Micronaut 20. The programming style is similar in both cases, though Micronaut is better optimised towards creating smaller, lighter images with faster startup times, so if the service implementation does not already have a dependency on Spring, Micronaut is the recommended option. Both libraries depend on a common bindings library 21  of Java model classes that represent the various JSON message structures in a more Java-native way. An ELG-compatible LT service can be built in three steps 22  using Micronaut: 1. Create a blank Micronaut application using the Micronaut Launch tool.
23  2. Add the ELG helper as a dependency, which is published to the central repository -for Gradle this means implementation ("eu. european -language -grid:lt -servicemicronaut :1. 0. 0 ") 3. Create a controller that extends LTService (for services that process text-based requests) or BinaryLTService (for services that process requests with binary content) and implement the relevant handle or handleSync method. The process 24  is similar for Spring Boot: 1. Create a blank Spring Boot application using the "Spring Initializr" 25  -additional dependencies are not needed, unless the specific code requires them. 2. Add the ELG helper as a dependency, which is published to the central repository -for Gradle this means implementation ("eu. european -language -grid:elg -spring -bootstarter :1. 0.
0 ") 3. Create one or more beans annotated @ElgHandler, with one or more public methods annotated @ElgMessageHandler. Each method should take an ELG request type such as TextRequest as a parameter (and for binary requests a second parameter of type Flux<DataBuffer> for the actual data) and return an ELG response type such as AnnotationsResponse or a reactive streams Publisher producing that type. In both cases, Micronaut and Spring Boot, developers must add their code in the appropriate places to call the actual LT tool and build a response based on the tool's results, using the model classes, e. g. , an AnnotationsResponse object in the case that the results are standoff annotations. Once the objects are created, the frameworks and libraries are able to automatically serialise them into ELG-compliant JSON response messages.
Helper Tools for Python Similar to Java, the ELG team provides helper tools to create an ELG-compatible service from a Python-based LT service. The helper tools are included in the ELG Pypi package presented in Chapter 3. The package provides two Python classes that 1 from elg import FlaskService 2 from elg. model import TextRequest , AnnotationsResponse 3 import langdetect can be extended to create a simple HTTP server that exposes an ELG-compatible endpoint of the LT tool. The ELG Python package also comes with a command-line interface (CLI) that helps with the creation of the Docker image. For the ELG-compatible endpoint, the developer creates a Python class extending either FlaskService or QuartService as a base class, and must implement one of the four following handler methods: process_text, process_structured_text, process_audio or process_image, depending on the required input type for the LT service.
After having defined the HTTP server compatible with the ELG LT internal API using the FlaskService or QuartService class, the next step is to create the Docker image. The ELG CLI that comes with the Python package contains the elg docker create command to help during this step. The command automatically generates the dockerfile based on the arguments. Listing 4 shows an example for the language detection service presented in Listing 3. All the available options of the elg docker create -n ELGService -p elg_service. py -r langdetect Listing 4 CLI command to generate the dockerfile automatically command are accessible with elg docker create --help. Once the dockerfile is generated, the creation and the publication of the Docker image follows the same process as described in Section 4. 1. 4.
Technical Validation and Registration of ELG-Compatible Services When LT providers have completed the packaging of their service, they can add it to ELG by supplying a metadata record via either the XML upload or editor mechanisms described in Section 2. 1, specifying that it is an "ELG-compatible service" when prompted. Submitting the record initiates the validation process, which is performed internally by the ELG team. The validation starts with the service registration process: The metadata or technical validator inspects the metadata record (accessed through the validator's grid) and deploys the service in the ELG Kubernetes cluster by creating the respective entries in the Helm charts that control the cluster. After that, the validator registers the service using a registration form (Figure  9 ), which specifies: • Kubernetes-specific endpoint to be used by the LT execution server when calling the service, derived from the executionLocation metadata element value.
Custom Try Out Interface The ELG-provided trial UIs 30  have been designed to support common service types in a generic way, but there may be specific services for which the standard UIs either do not work or do not represent the results in a particularly intuitive way. If this is the case, it is possible to supply an alternative trial UI that better suits the service to be A trial UI is a single-page HTML/JavaScript application which is loaded into an <iframe> by the catalogue page when the user views an ELG-compatible service. Trial UIs run entirely in the browser and must not send user data to anywhere other than the ELG service endpoint and the i18n message resolver service. The JavaScript inter-frame messaging mechanism is used to supply the UI with the data it needs to configure itself for use with this particular service -when the UI <iframe> loads it must register a message listener that expects to receive message data that can be parsed as JSON, then dispatch a message to the parent frame to trigger the configuration message in return.
32 An example of this mechanism is shown in Listing 5. The message event data sent by the parent frame will be JSON containing the following properties: ServiceUrl The public LT service API URL at which the service can be called. The URL may include query string parameters if the service has more than one deployed version. ApiRecordUrl The catalogue API URL from which the metadata record for this service may be retrieved with a GET request. This provides access to service parameter declarations, sample data, etc. Authorization An HTTP Authorization header value that will authenticate calls to the ServiceUrl and ApiRecordUrl as the user who is logged in. Language (optional) ISO code for the preferred language of the user. If present, this should be used as the lang parameter when resolving status messages to strings using the i18n resolver (see Section 4.
Packaging Data and Splitting Metadata Records: Recommendations Datasets are composed of files that can be organised according to different criteria. For example, a multilingual corpus of texts from various domains can be described as a whole (one metadata record) or split into subsets (with corresponding metadata records) using the language or domain criteria. Depending on their intended use, different ways of packaging datasets and making them available can be suggested. 33 e prepared a set of recommendations for the packaging of data files to enable users, especially those accessing ELG through programmatic APIs, to automatically identify, download and use corpora as is, without having to download them and manually search among them the subsets that interest them. 34 he following cases are foreseen: Multilingual resources are recommended to be split into bilingual pairs, so that users can easily find and use them, for example, in the case of bilingual corpora, to train bilingual models.
Technical metadata are typically mandatory when resources are deployed in a platform. ELG has a detailed schema with a minimum set of required metadata to allow for flexibility and strictness when this is mandated for operational reasons (i. e. , resources deployed in ELG, added by individuals, harvested from other sources). CLARIN has initiated the Component MetaData Infrastructure 38  , which provides a framework to describe and reuse different "metadata profiles" for resource types and communities. Specific metadata profiles, e. g. , those of web services, are "recommended" with an aim to ensure interoperability and operational requirements. However, these profiles may promote different mandatory elements, depending on the use of the profile by each CLARIN Centre. Hugging Face 39  uses a dataset and model card, in which part of the required information is specified via YAML 40  tags.
Provider User Interface and Metadata User Interface User-friendly editors that can cover multiple metadata schemas are difficult to implement, especially when the schemas have a complex structure. Nevertheless, most platforms include such an option. ELG, like META-SHARE 41   (Piperidis 2012;  Piperidis et al. 2014), OpenMinTeD 42   (Labropoulou et al. 2018) and the European AI-on-demand platform 43  , offer provider-specific UIs and a metadata editor supporting their respective schemas for describing resources. Hugging Face offers a rather simple UI with limited functionality. LAPPS Grid 44   (Ide et al. 2016) does not provide such UIs, a provider must communicate with the technical team in order to add services to the Galaxy 45  toolbox. Various CLARIN teams have created editors that support CMDI metadata (e.
Try Out User Interface Hugging Face offers embedded trial UIs to access their public "inference API". These are similar in spirit to the ELG "try out" UI mechanism, with a publicly documented API being called by a generic user interface. In addition, Hugging Face provides "Spaces" 48  which enable users to create and deploy their own UIs for demonstrating a model. The approach followed by Hugging Face Spaces is different from ELG; it is based on developers coding their own back-end server code and front-end UI as a single unit using the Streamlit 49  or Gradio 50  Python libraries. The developer adds this source code to a Git repository and Hugging Face then deploys the code to their infrastructure directly from the source code rather than from a developersupplied Docker image. The UI is tightly coupled to the server-side code and the "API" is an implementation detail that varies from "space" to "space".
Example sequence of commands to build and push a Docker image to a registry 1 # Login to Gitlab container registry 2 $ docker login registry. gitlab. com 3 4 # Build the image and tag it with the name registry. gitlab. com/ ilsp -nlpli -elg/elg -ilsp -lt -services and a version number 5 $ docker build -t registry. gitlab. com/ilsp -nlpli -elg/elg -ilsp -lt -services :1. 0. 0. 6 7 # Push the image to the container registry 8 $ docker push registry. gitlab. com/ilsp -nlpli -elg/elg -ilsp -lt -services :1. 0. 0 Listing 2.
Abstract In the Internet era, the digital architecture that keeps us connected and informed may collaterally amplify the spread of misinformation and falsehood1,2. The magnitude of this problem is gaining global relevance3, as evidence accumulates that misinformation interferes with democratic processes and undermines collective responses to environmental and health crises4,5. Therefore, understanding how misinformation generates and spreads is becoming a pressing scienti c, societal, and political challenge3. Advances in this area are delayed because high-resolution data on coherent information systems are di cult and time-consuming to acquire at global scales. We collated a high-resolution database of online newspaper articles on spider-human interactions. Spiders are widely feared animals6 that frequently appear in the spotlight of the global press7,8.
Our database is unique in that it covers a global scale (5,348 news articles from 81 countries and 40 languages) while providing an expert-based assessment of the content and quality of each news article9. Here, we rst show that the quality of news on spiders is exceedingly poor-47% of articles contained different types of error and 43% were sensationalistic-and we consolidate a quantitative understanding of the relationship between article quality and different news-level features. Among other factors, the consultancy of spider experts, but not doctors and other professionals, decrease sensationalism. Next, we show that the ow of spider-related information occurs within a highly interconnected global network and provide evidence that sensationalism, along with other predictors including numbers of spider species and internet users in a country, are key factors underlying the spread of information.
Stories about spider bites, in particular, are often overplayed by the media  [7] [8] [9]. This makes it relatively easy to quantify sensationalism, insofar as sensationalistic articles consistently use emotional words and images and tend to exaggerate morphological features triggering arachnophobia  7  -e. g. , body size  6, 21, 22  or hairiness  22. For spider experts, it is also straightforward to identify basic errors associated with spider contents. Common errors typically pertain to anatomy and behavior (e. g. , 'spider sting'  23  ), unrealistic outcomes of envenomations  24, 25  , or incorrect taxonomic information (e. g. , 'spiders are insects'  26  ). We capitalized on a global-in-scale, high-resolution database of online newspaper articles on human-spider encounters-consisting of 5,348 news articles from 81 countries and 40 languages  9.
All of this is of central importance given that the spread of misinformation has direct real-world consequences. A recent estimate indicates that the online proliferation of fake news accounts for an economic loss of ~$78 billion annually  31. Thus, a better framing of information on a given topic would translate into measurable bene ts. As far as spiders are concerned, misinformation foremost results in waste of money and resources by people and institutions. Emblematic cases include the closure of schools in the UK due to alleged "invasions" by false black widows (genus Steatoda) (e. g. , article ID UK_328 in our database); or the story of a Californian man accidentally setting his house on re while using a blowtorch to clear spider webs out of his backyard (e. g. , article ID US_0461). Second, the content, tone, and quality of these stories shape people's perception of risk  7, 14, 32  and in uence socio-political decisions around the management and conservation of wildlife  [33] [34] [35].
News article data We analyzed a global database of news articles on human-spider encounters published by online newspapers and magazines in 2010-2020  9. The database is unique in that it covers a global scale while providing an in-depth expert-based assessment of each news article's content and its quality. All news articles across countries and languages were retrieved using the same data mining strategy; furthermore, to increase the accuracy and internal consistency, each news article in the most frequent languages was validated by independent assessment by different experts. The database covers news articles in 40 languages and 81 countries-note that for Botswana and Iceland no spider news items were detected. The total sample size is 5,348 unique news articles, reporting 6,204 human-spider encounters.
However, many of these human-spider encounters were reported by multiple news sources, leaving a total of 2,644 unique encounters-of which 1,121 are classi ed as bites and 147 as deadly bites. For each news article, the database includes a number of news-level variables. We considered the following ones in analyses (see ref. 9  for a full description of the dataset and data collection methods): 1) date of publication ("Year" and "Month"); 2) language ("Language"); 3) newspaper circulation ("Circulation"; categorical variable with three levels: "Regional", "National", and "International"); 4) country in which the news was published ("Country") 5) type of human-spider encounter ("Type_event"; categorical variable with three levels: "Encounter", "Bite", and "Deadly bite"); 6) genus of the species involved in the event ("Genus"); 7) longitude and latitude coordinates of the human-spider encounter ("x" and "y"); 8) presence/absence of photos of the species and the bite (variables "Photo_"); 9) presence/absence of errors ("Errors"; including errors in taxonomy, morphology, venom, and in the spider photo); 10) assessment of the news as sensationalistic vs.
Statistical analyses We performed all analyses and calculations in R version 4. 1. 0 42. We used the package "ggplot2" version 3. 3. 4  43 for visualizations. In all regression-type analyses, we followed Zuur & Ieno  44  for model construction and validation. In discussing model results, we adopted an evidence-based language  45  , referring to effect sizes, directions of effects, and variance explained rather than signi cance  46. Exact estimates and p-values can be found in Tables S1-S5.
Relationships between sensationalism, errors, and news-level attributes First, we explored the role of different news-level attributes in explaining the probability of a given piece of news being sensationalistic or including errors. We tted generalized linear mixed models with the R package lme4 version 1. 1-27. 1  47. Given that the response variables are incidence data (presence/absence of errors; sensationalist or not), we chose a Bernoulli family distribution (0-1, discrete). The structure of the two models, in R notation, was: To check whether there was covariation between sensationalism and errors in the articles, in the model for sensationalism we included the assessment of errors as a response variable (eq. 1) and vice versa for the model of errors (eq. 2). Also note that, in eq. 2, we did not include variables referring to photos, because only articles with photos may contain such an error.