dataesr/scientific-paragraphs-categorization huggingface dataset:
Additionally, to be able to develop LRTs, researchers with technical but also linguistic skills of the respective languages are needed. Funding Investment in research and innovation in the area of LT is necessary for basic and applied research on which technology development is based. Industry Companies, both well-established and startups, are important drivers of the development and distribution of LT applications, tools and services. Law The legal framework can hinder progress or steer developments in certain directions. Media The creation and distribution of news, newspapers, magazines, films, etc. in a language constitutes, on the one hand, a possible large dataset for the development of LRTs, and on the other hand, demonstrates the willingness to make content accessible to the language community.
Data Sources and Collection Initially, 72 potential contextual factors were identified through the collection of factors considered relevant in publications such as, among others, the STOA study (STOA 2018), the META-NET White Paper Series (Rehm and Uszkoreit 2012) and EFNIL's European Language Monitor (ELM); 4  we also consulted with the 52 ELE project partners. The 72 tentative CFs were clustered into 12 areas (see above) representing different aspects of a language's context  (Gaspari et al. 2021). To be measurable, each factor had to be quantified with an indicator, which depended on the existence and accessibility of corresponding data. First, different data sources were collected including, among others, EUROSTAT, 5  ELM, Ethnologue  6 and various reports and articles. Second, possible indicators for each factor were considered and matched with the available data.
Tables  4 5 6 7 8 9 10 11 12 13 14 15 in the Appendix show all factors from the preliminary definition  (Gaspari et al. 2021 (Gaspari et al. , 2022b)) , their class and the indicator they were quantified with. Overall, 46 factors were quantified with at least one appropriate indicator, and some with two indicators representing different perspectives like total numbers and numbers per capita. The data was collected in late 2021. Many sources provided their data as spreadsheets, while some data was published as HTML documents. The data for 15 indicators had to be collected manually from reports and articles. We attempt to update the contextual factors on an annual basis. Preliminary tests indicate that updating the contextual DLE scores for all EU languages takes up to two weeks of work by one member of staff who is familiar with the structure and nature of the CFs.
Factors which were quantified with data reflecting no big differences between languages were also excluded by the quality criterion, e. g. , the literacy level of all countries varied between 98 and 99 percent, i. e. , hardly at all. To be able to update the metric on a regular basis without much manual effort after the end of the ELE project, the possibility of collecting the data fully automatically was picked as the other main criterion. Based on these criteria, the following CF configurations were examined: 1. Factors with available data: 46 factors 2. Factors that can be updated automatically: 34 factors 3. Factors with good or high data quality: 26 factors 4. Factors that can be updated automatically and that also have good or high data quality: 21 factors 5. A set of manually curated factors using four criteria: automatically updatable, good/high data quality, a maximum of two factors per class, balance between data types: 12 factors (Table  16  shows the factors included in this configuration) Including fewer factors in the metric increased the risk of omitting an important factor.
Open Issues and Challenges The contextual DLE scores calculated have some limitations (see Section 6. 2). First, expanding the dataset to include regional or national sources would result in 1. a higher number of factors, 2. improved data quality, as the gaps in individual indicators may be filled, 3. quantification of more factors with more than one indicator, to reflect different perspectives, and 4. a more complex mapping to language communities based on regional data resulting in a significant impact on RMLs. Second, the data cleaning procedure can be improved. One possibility would be to replace outliers with values outside twice the standard deviation by the respective maximum or minimum values of the data series. Data gaps could be filled using data from previous years and skewed data could be corrected using a square root transformation.
Digital Language Equality Dashboard In order to provide a precise and easy-to-use tool for presenting and monitoring the TFs and CFs that contribute to the DLE Metric, we designed and implemented a web-based dashboard as part of the European Language Grid. 8  It is available at: https://live. european-language-grid. eu/catalogue/dashboard The dashboard shows the contents of the ELG database as interactive visuals dynamically created by user queries, thus providing constantly up-to-date and consistent (i. e. , comparable) measurements of the level of LT support and provision across all of Europe's languages (Figure  3 ). The dashboard provides the figures, statistics and graphs, as appropriate, for: • the TFs and CFs of the DLE Metric, calculated according to the detailed technical description presented above; • LRTs hosted in the ELG catalogue, which constitute the source/base data for the TFs that are at the basis of the technological DLE score.
Architecturally, the DLE dashboard consists of two layers: the database of the ELG catalogue and the frontend. The ELG database contents are indexed and saved in JSON. Each user query retrieves the respective results from JSON and exposes them to the front end. While the TFs are calculated dynamically (see Section 5. 3) and they reflect the status of the ELG catalogue's database at the time of accessing the dashboard, in the current implementation the CFs are calculated offline, stored in a separate file and exposed to the respective tab of the dashboard's frontend.
Conclusions and Future Work This chapter has introduced the definition of DLE adopted in ELE and has described the DLE Metric, explaining the roles and setups of the complementary TFs and CFs and how the scores are computed. By providing an empirically-grounded and realistic quantification of the level of technological support of the languages of Europe, the DLE Metric is intended to contribute to future efforts to level up the digital support of all of Europe's languages, most notably with the implementation of the evidencebased SRIA and roadmap that will drive future efforts in equipping all European languages with the LRTs needed to achieve full DLE (see Chapter 45). The DLE Metric provides a transparent means to track and monitor the actual progress in this direction, as the technological and contextual DLE scores can be visualised through the DLE dashboard.
The overview of the TFs and CFs is accompanied by discussions of the scoring and weighting mechanisms adopted for the computation of the technological and contextual DLE scores, following extensive testing and expert consultations comparing alternative setups. The chapter explains the overall design of the features and their values with the scores and weighting mechanisms that contribute to the DLE Metric scores, based on data included in the ELG catalogue and the factors eventually selected to represent the specific ecosystems of the languages and their communities. As a result of this, the notion of DLE and its associated metric introduced in this chapter represent valuable tools on which to base future efforts to measure and improve the readiness of Europe's languages for the digital age, also taking into account the situational contexts in which the various languages are used via the CFs.
iFogSim and iFogSim2 CloudSim  [34]  and iFogSim  [29]  were developed by the Cloud computing and Distributed Systems (CLOUDS) Laboratory, a software research and development group within the School of Computing and Information Systems at the University of Melbourne, Australia. The iFogSimToolkit  [29] , provides a platform for modeling and simulation of resource management techniques in edge, FC, and cloud environments. A newer version of iFogSim  [35] , was released in 2022, which adds distributed clustering, mobility, and microservices management as new features. Furthermore, it includes new example scenarios to validate and demonstrate their extension for the iFogSim. iFogSim and iFogSim2 are available on GitHub  [29, 36]. The architecture used by iFogSim is shown in Figure  1.
EdgeCloudSim The simulator EdgeCloudSim  [24]  was introduced in 2018 and is based on CloudSim  [34]. However, in order to efficiently utilize it for EC scenarios several functionalities have been added. The architecture used by EdgeCloudSim is shown in Figure  3. EdgeCloudSim provides a modular architecture to provide support for a variety of crucial functions such as network modeling specific to WLAN and WAN, device mobility model, and realistic and tunable load generator. Furthermore, in order to enable users for modeling orchestration actions that arise in EC scenarios, an edge orchestrator module was implemented. EdgeCloudSim is not energy-aware by default  [10] , but as it implements CloudSim, it can become so. In 2020, they release version 4. 0. It includes minor code improvements and some new features requested by the developers (e.
) networks. The cellular module enables to provide support for the heterogeneous way of communication that is WiFi, 5G, 4G, and Ethernet. However, the simulator does not provide any support for 5G core components architecture. Moreover, PureEdgeSim permits the live visualization of the simulation environment. So when a scenario is executed, the simulator opens a window with live visualization of the simulation. The graph shows network utilization, CPU utilization, tasks success rate, and simulation map. The simulator can be downloaded from the GitHub repository  [42]. In terms of its popularity on GitHub, the repository has 85 stars in total. 3. 1. 6. YAFS YAFS  [22] , was first released in 2019. The first version was developed for Python 2. 7. YAFS provides dynamic topology (i. e. , enabling runtime entities and network link creations), dynamic message creation (i.
e. , enabling sensors to generate massages at runtime), and users can extend orchestration and placement allocation algorithms. The architecture of YAFS is provided in Figure  5. A new version was released in 2021, allowing support for python 3. 6+. They added more example scenarios in the newer version and reduced the third-party libraries' dependency. However, it is important to remark that some built-in scenarios are not working in the new version due to breaking changes between Python versions. For instance, it can implement scenarios with mobility, but an example scenario (https: //github. com/acsicuib/YAFS/blob/master/src/examples/mobileTutorial/main. py, accessed on 16 June 2022) provided is not compatible with python 3. 6+. Moreover, some parts of the documentation are not up-to-date.
Although LEAF is simple and faster it has a few limitations as well. The first main limitation is the lack of support for numerous features compared to other simulators. More, it lacks support for bidirectional applications, thus it requires modification in the structure of the application services. Bidirectionally here represents a service that is able to send or receive data. The simulator is accessible via GitHub  [44]. Considering its popularity, LEAF has 59 stars on GitHub. This simulator is a recent project, and as they want to introduce new features related to energy consumption, it will be interesting to follow it in the coming years.
Summary and Discussion The technical and non-technical assessment of simulators provides insight into the simulators' popularity, future directions, and support for different features. In terms of popularity, iFogSim, EdgeCloudSim, and YAFS are the most popular according to their citation count and the GitHub repository usage. Considering features, iFogSim2 and YAFS support the most number of features. However, iFogSim2 supports the important feature of migration (i. e, service) and provides graphical support while YAFS does not. In addition, YAFS provides support for a diverse set of topologies, whereas, iFogSim and LEAF are only restricted to tree topologies. Considering the language support, most of the fog simulators are implemented in JAVA and are based on cloudSim, such as iFogSim, EdgeCloudSim, or PureEdgeSim, and only YAFS and LEAF are developed in python.
Simulation Framework The experiments are performed on a computer with the operating system macOS Catalina version 10. 15. 7. The processor is 2. 3 GHz Intel Core i5 2 core and the memory is 8 Go 2133 MHz LPDDR3. The versions of the programming languages used are Python 3. 7. 12 for YAFS, Python 3. 10. 0 for LEAF, Oracle Open JDK 18. 0. 1 for PureEdgeSim, and Java version 1. 8. 0.
Results All the above scenarios were implemented using iFogSim, YAFS, and LEAF to analyze how well they perform in terms of simulation time (i. e. , time to complete the scenario), CPU consumption (i. e. , percentage of CPU consumed during the simulation), and memory consumption (i. e. , amount of memory consumed during the simulation). The code and the results are available on GitHub  [45]. Simulation time is considered in seconds, CPU consumption is considered in percentage and memory consumption is calculated in MB. The results are grouped according to the simulator for each of the scenarios. We performed 10 simulations and recorded the simulation time, CPU, and memory consumption for each experimental setup. For simulation time we used a bar plot to show the average completion time of all the experiments and a box plot to present both the CPU and the memory consumption of all the experiments.
3 are satisfied. Both the marginal and the upper bounding test can therefore be implemented, and sensitivity and specificity of both approaches will be again simulated for protein structure data. For the analysis presented here, we used a structural database of three-residue fragments (also called tripeptides) extracted from experimentally-determined high-resolution protein structures  [20]. The reason to consider tripeptides instead of single amino acid residues is that the distribution of the φ and ψ angles does not depend only on the amino acid type, but also on the sequence context, and particularly on the closest neighbors. Under H 0 , we will consider structural data corresponding to the central amino acid residue of the Ala-Ala-Ala tripeptide, which is a protein fragment having three consecutive alanine residues.
05) for all the simulated sample sizes, and the upper bounding technique controls power when ∼ 500 individuals form the sample. The lack of individuals should not prevent from performing this second procedure, as the available structural datasets are large-enough for most of the tripeptides. Finally, even if the Central Limit Theorem 2. 5 does not allow goodness-of-fit testing, we can, to conclude, illustrate the asymptotic behavior of Wasserstein distance using protein structure data. For this, we used data from two very different tripeptides from the structural point of view: Ala-Ala-Ala and Ala-Gly-Ala, where the glycine in the middle changes abruptly the configuration. We simulated their squared Wasserstein distance distribution for different sample sizes and represent its normalized deviation from the mean.
* Equal contribution. † Research partially supported by the  AI Interdisciplinary Institute ANITI , which is funded by the  French "Investing for the Future -PIA3" program  under the Grant agreement  ANR-19-PI3A-0004. ‡ Research supported by the  ANR LabEx CIMI  (grant  ANR-11-LABX-0040 ) within the  French State Programme "Investissements d'Avenir ". 1.
Slow, more tortuous movements can result in longer residence times and increased area usage that increase the risk of interaction with fishing vessels in the same area; dive depths can increase the risk if turtles are diving at the same depth and area as fishing gear. Each state was defined by a unique set of values for mean daily move persistence velocity (horizontal movement, the tendency of turtles to persist in a given direction, obtained by multiplying daily swimming speeds by the cosine of the turning angles), mean daily number of dives, and daily proportion of D1 (deeper) and D2 shallower)  (Barbour et al, 2023)  dives. The HMMs were fit with a Markov chain Monte Carlo algorithm and were implemented using the Bayesian programing language Stan and its R interface, rstan  (Stan Development Team, 2022).
Details on the HMM specification and fitting are in Appendix S3. Several R packages have recently been developed to quickly and easily fit HMMs to time-series movement data (e. g. , moveHMM  [Michelot et al. , 2016]  and momentuHMM  [McClintock & Michelot, 2018] ). However, these packages have little room for user parameter modification and can result in problems with convergence, identifiability, and biologically meaningful inference  (Auger-Méthé et al. , 2016). Modifying the structure of our HMM requires the user to have a reasonable understanding of HMMs, Bayesian methods, and the coding software used (e. g. , R, Stan). However, example code and data to replicate methods and similar results are available on GitHub (https://github. com/ barb3800/ExampleFilesandCode_Barbour_etal). Therein, we highlight where users can modify model parameters and input data, perform essential checks for convergence problems, and determine optimal model structures through model selection and comparison.
Monthly kernel density estimates To effectively estimate the probability density function (UD) in time and space, we used the product kernel estimator algorithm, developed by  Keating and Cherry (2009) , on the regularized location data. The R package adehabitatHR and its kernelkcbase function  (Calenge, 2006)  were used for these purposes. To create a leatherback probability density distribution at the same temporal scale as the currently existing SPTW tool, monthly UDs were estimated for each turtle. A smoothing parameter (h) must be specified to determine these UDs. This value is somewhat subjective  (Keating & Cherry, 2009) , and we chose an h of 3 • for the spatial dimension (X, Y) and 30 days for the third dimension, time. This was based on an initial exploration of values for h that yielded a sufficiently heterogeneous surface and an understanding of the resolution of our data, with respect to our goal of estimating monthly surfaces.
Monthly fishing effort To create layers of monthly fishing effort, we utilized opensource data from Global Fishing Watch (GFW), an online database that provides high-resolution (1/100th Data for vessels included location and gear type. Fishing effort is reported with automatic identification system devices deployed on industrial fishing vessels (6-146 m) and measured in hours fishing in a grid cell  (Kroodsma et al. , 2018). Average fishing effort (2018-2020) was used to best capture recent high fishing effort, aggregated to the same spatial resolution as the behavior and UD layers. To match SPTW's monthly temporal resolution already produced for EP leatherbacks, fishing effort was further separated by month (t). To assess gear-specific interactions, fishing effort was categorized by gear type (g), of which there were 8 unique categories (drifting longline, fishing, purse seines, pole and line, set gillnets, set longlines, squid jigger, trawlers, and tuna purse seines).
ACKNOWLEDGMENTS A. Swain and B. Yura assisted with coding for the overlap analysis. J. Mallon assisted with coding for the UD analysis. The National Science Foundation (grant no. DBI1915347) supported W. F. F. 's work. The leatherback movement data for this project were collected by G. Shillinger (Block Lab, Hopkins Marine Station of Stanford University) and collaborators as part of the Tagging of Pacific Predators program of the Census of Marine Life. We thank The Leatherback Trust, Earthwatch.
I. INTRODUCTION Machine learning (ML) is the science of teaching computers to mimic human abilities and autonomously improve their abilities over time by inputting data in the form of observations and real-world interactions  [1]. Over the years, ML has evolved from stand-alone solutions to embedded solutions and has produced technologies integrated into readily available intelligent devices such as mobile phones, tablets, and smartwatches, among others. ML technologies such as Google Assistant, Siri, and Cortana provide evidence The associate editor coordinating the review of this manuscript and approving it for publication was John Mitchell. of advancement in this emerging field. This advancement has become fundamentally ingrained in our society, with impacts ranging from work to daily activities.
C. DEMOCRATIZING ML The study of AI has been restricted to the expert domain in the past. Despite its widespread applications in daily activities, most users of AI feel intimidated by it  [54]. In recent years, continuous efforts have been made to reduce the entry barrier into the world of AI for nontechnical learners. The democratization of AI technologies has also been helping to lower this barrier and has paved the way for children to communicate with machines in diverse ways, not only through popular rule-based programs such as Scratch, but also through natural language, gestures, and other ML-enabling technologies and interfaces  [2] ,  [52] ,  [55]. Such technologies include Google Teachable Machine  [56] , Machine Learning for Kids  [19] , and Learning Machine Learning  [57]. In this study, we engaged learners using Google Teachable Machine and Machine Learning for Kids.
A. GOOGLE TEACHABLE MACHINE Google Teachable Machine (GTM) is a web-based tool developed by Google Creative Lab that offers a no-code and lowcode approach to modeling and building ML applications. GTM connects advanced neural network algorithms with a simple, user-friendly graphical user interface that enables anyone, even children, to make fast and easy ML models, allowing middle school learners to explore the working principles and basics of ML. GTM was initially launched in 2017  [56]. The first version supports only image classification projects using a webcam as a data collection tool. In 2019, GTM 2. 0 was released, which extended its project support categories to include image, audio, and human poses. The Images tool trains an ML model to classify images. The training data can be captured by a webcam or uploaded to the GTM environment from the user's device.
The Audio tool similarly trains a model to classify different sounds, such as different people talking, or distinguish between background noise and an intended audio sound. Finally, the Poses tool employs PoseNet for real-time human pose estimation and identifies different bodily movements. The ML models produced in these project categories can be exported in TensorFlow and Javascript and can be embedded in web apps, mobile apps, among others. GTM has gained traction recently with various software engineers and researchers. For example, Payne and her research team at MIT used GTM as part of an open-source curriculum that applied a hands-on learning model to teach middle school students the basics of AI  [55]. In addition, GTM has been used to introduce students across grade levels, from early childhood education to high school, to AI and ML concepts such as image recognition and pattern recognition  [59] ,  [60].