dataesr/scientific-paragraphs-categorization huggingface dataset:
The first was based on the hybrid software Jahia and was developed by a private company. The second relied on the open source software Alfresco for its specific developments, which were outsourced to private service providers. Despite this lack of "official" support, CommunesPlone's success (28 communes were partners in 2007, 75 by the end of 2008, 91 by the end of 2009, 120 by the end of 2010. ) led to the termination of the Agoracités project, and to the merging of the management of the CommunesPlones and Qualicité projects into a new inter-communal structure organized on the basis of the CommunesPlones project (and employing the main CommunesPlone developers): IMIO. CommunesPlones may thus shed light on the specific qualities of FLOSS over more conventional solutions for the public sector, but also on why such a structure was chosen -a private company owned by the public authorities which are its clients -, rather than more common FLOSS solutions, such as a foundation.
Method To speak of addressing needs, and of the financial and nonfinancial resources mobilized to do so, and how they are funded (time allocated, money spent. ), is to speak of a project's "business model"  [11]. As for any projects, the needs, the resources, or the technology evolve over time. When the actors judge the current organization too unsatisfactory, they try to develop and implement one or more action plans to resolve the observed maladjustment. Doing so they change the organization, the governance of the project, its "business model"  [12]. This calls for a longitudinal study of the project throughout its life-cycle identified by these moments of test and the solutions found to address them  [12]. We collected data from public presentation of the project, including: several conference presentations by the Com-munesPlone founders between 2005 and 2011; a feature in the 2012 Walloon local authorities association's magazine regrouping interviews of actors of the IMIO creation project; yearly management reports published by the IMIO from 2012.
They helped understand the chronology of the project. Several academic reports were also commissioned by public authorities, on the pooling of IT developments  [13] , the rationalization of ongoing projects 3 , and the involvement of public authorities in FLOSS projects  [14]. They helped understand what were the difficulties to be addressed and the solutions proposed. We completed these elements by interviewing two longstanding members of the project, during respectively 143 and 83 minutes. One has participated in the creation of IMIO and is still involved in it, the other is a former contributor to the project who has today a private consulting activity (on CommunesPlone and other public sector software solutions). The interviews helped clarify the previous points: the project timeline, the different challenges and how they were understood by the actors, but most of all the role of the specific institutional background: local politicians, local authorities, and companies.
This has limited the presence of private companies within the IMIO ecosystem to a few Python specialists providing an always smaller number of municipalities with solution deployment services. To maintain their business, these providers have turned to other actors (regions, communities, Brussels local authorities, etc. ), outside IMIO's scope, that has favored the dissemination of the solution. However, this has transformed the development side. IMIO has integrated several CommunesPlone key developers, and its quality expectations have rapidly exceeded the skills of the remaining occasional contributors. In practice, external developments were thereafter carried out by subcontracting contracts that are subject to public procurement. The creation of value through direct contribution from Iusers has been relegated to the background.
DISCUSSION AND CONCLUSION This case sheds light on several points. A successful software project may mean the end of a FLOSS initiative, i. e. a  project developed by its (I-)Users. This may appear "naturally" because mature software requires fewer technical contributions/adaptations, and is of less interest for I-Users, or because an actor becomes dominant and does not wish to finance the animation of and collaboration with the I-Users. The project may remain an open-source project, as the code is still protected by an open (source) license, but it is no longer cooperatively developed and managed (what we have called a FLOSS project). This stresses the question of the users' capacity to remain in control of the project. While the CommunesPlone public FLOSS project started and evolved in a classic way for a FLOSS project, as summarized in Table  5 , it has innovated through this new form of resource pooling by a trusted third party, IMIO, that allows the users to remain in control.
to invest in software production, and are thus reserved for I-Users. The organizations in which a central, autonomous editor exists, whether a private one or a foundation (left hand side of the figure), are less demanding for the users, but make it harder for them to control the project's governance. I-Users always have the capacity to contribute in code (foundations) or to fork the project (open-source editors, third party, and foundation) if they are unsatisfied with the editor/project management. F-Users/N-Users do not. This is where having control over a third party which in turn controls the project may be interesting. This comes at extra cost for these users, both monetary (in order to pay the third party) and in effort (to participate in the strategic decisions and to learn to do so), but CommunesPlone/IMIO proves it potentially rewarding.
Funding This work has been supported by the  French government , through the  UCA   JEDI Investments  in the Future project managed by the  National Research Agency (ANR)  with the reference number  ANR-15-IDEX-01  and by the  Projet de Recherche Inter-instituts Multi-Equipes  ( 80   PRIME) CNRS. It is part of the Compu tabra in project and the  eXplA In CNRS  research team.
In  (Linderoth et al. , 2006) , the authors modified the problem to obtain an instance with 10 6 scenarios. Problem ssn is a problem of telecommunication network design taken from  (Sen et al. , 1994)  and storm is a cargo flight scheduling problem described by  (Mulvey and Ruszczyński, 1995). The two last instances come from https://people. orie. cornell. edu/huseyin/research/research. html. The first one, product, is the large instance of the product distribution problem available at https://people. orie. cornell. edu/huseyin/research/sp_datasets/ sp_datasets. html. The second one, Fleet20 3 was found at http://www. ie. tsinghua. edu. cn/lzhao/ which was itself taken from https://people. orie. cornell. edu/huseyin/research/research. html. It is a fleet-sizing problem, close to 20term, with a two-week planning horizon.
Acknowledgments This project has been funded by  RTE (Réseau de Transport d'Electricité) ,  French  company in charge of the electricity network management, through the projects Antares and Antares Xpansion: https://github. com/AntaresSimulatorTeam/antares-xpansion, which are used for long-term adequacy studies. Computer time for this study was provided by the computing facilities  MCIA (Mésocentre de Calcul Intensif Aquitain) of the Université de Bordeaux  and of the  Université de Pau et des Pays de l'Adour. We thank the anonymous referees, whose comments helped improve and clarify this paper.
The aim of this review is to survey the tools that have been used to measure motivation in the context of rehabilitation. Following the PRISMA guidelines, we will conduct a systematic review including four databases: PubMed, Embase, Web of Science, Google Scholar. Selected studies will include all types of studies related to motivation and rehabilitation (e. g. , randomized, non-randomized controlled trials, case reports …). Studies involving children and elderly people will be excluded as well as articles regarding traumatic brain injury in the context of sport concussion without subsequent rehabilitation. The data will be classi ed according to patient population, rehabilitation context, and tools used to assess motivation. We will summarise these data and make recommendations for clinicians and researchers regarding which tools to use in which contexts.
for an example). A review on a similar topic was recently published  (Verrienti et al. , 2023)  but their authors limited the research to stroke patients, only included clinical trials or randomised clinical trials, only examined studies published between 2012 and 2022, and limited their search to two databases (Google Scholar and PubMed). Thus the objective of the current review is to perform a larger survey of the literature including both stroke and TBI patients, and to identify tools that have been used to assess patient motivation in all types of studies involving these patient populations, and to analyse the results taking into account the various contexts in which the tools are used. Our long-term goal is to identify an easy-touse, clinically-informative tool that can be used in clinical practice with a population of French-speaking ABI patients.
Identi cation The research equation will combine several words related to : motivation, brain injury and assessments. Table  1  contains the search equations. OR assess* OR evaluat* OR assess*)) NOT AB=("hemispatial neglect" OR "visually impaired persons" OR blind* OR "visuospatial de cits" OR child* OR pediatric* OR aphasi* OR "virtual reality" OR "video games") Interrogation of the databases using these equations will result in identi cation of records. Once the PRISMA procedure completed, additional reference will be searched within the references of the article included in the systematic review.
Study Eligibility Two authors will independently examine the full text of each study to ensure that it meets the inclusion criteria. As in stage 1, any discrepancies will be discussed until consensus is reached. If the two authors are unable to reach consensus a third investigator will assess paper eligibility. The whole selection procedure will be reported in a PRISMA ow diagram. Data will be extracted from the studies that pass the screening process and tabulated using a standardized data extraction form in Excel. The following data will be extracted from each article: study design and methodology; name of the measurement tool and its subscales (when relevant); the authors' reasons for choosing this particular tool; context or domain of the study (i. e. motor, cognitive, physical …); objectives; outcomes; number of participants ; time post injury; time of the assessment with the tool in the study; validation of this particular tool for the ABI population; psychometric properties of the measurement tool; information about the measurement tool regarding its : development, underlying theory, de nition of motivation, languages in which it is available, response mode, completion time.
Digital tools to support healthcare delivery and education are increasingly used. Measuring acceptability of these digital tools is necessary to improve intention of use and subsequent implementation success in diverse settings. The main objective of this presentation is to describe various models to examine acceptability, so that knowledge users can make informed decisions on which measurement tools to use. We conducted a rapid literature search of different models used to examine the concept of acceptability of various digital tools (e. g. , serious games, virtual simulation, e-learning), among many audiences (including but not limited to healthcare providers, caregivers, patients), across many disciplines (e. g. , psychology, medical education, nursing). We searched the following databases: PsyInfo, EMbase, Pubmed, EmPremium.
For instance, our experiments show that IBU can provide better utility than MI, especially in high privacy regimes (i. e. , when ϵ is small). Our paper provides insights for practitioners to use IBU in conjunction with existing LDP mechanisms for more accurate and privacy-preserving data analysis. Finally, we implemented IBU for all fourteen LDP mechanisms into the state-of-the-art multi-freq-ldpy Python package (https://pypi. org/project/multi-freq-ldpy/) and open-sourced all our code used for the experiments as tutorials.
Introduction The widespread availability of Big Data has led to the development of new methods for extracting valuable insights from large datasets. However, the increased capacity to collect and analyze data also raises significant concerns about privacy, particularly in cases where sensitive information about individuals is involved. Thus, the direct collection and storage of users' raw data on a centralized server should be avoided as these data are subject to illegal access  [21]  or internal fraud  [28] , for example. To address this issue, recent works have proposed several mechanisms satisfying Differential Privacy (DP)  [12, 13] , in the distributed setting, referred to as Local DP (LDP)  [19]. One of the strengths of LDP is its simple trust model: since each user sanitizes their data locally, user privacy is protected even if the server is malicious.
In addition, we also extended the analysis to seven state-of-the-art memoizationbased LDP mechanisms, namely, Longitudinal GRR (L-GRR)  [3] , four Longitudinal Unary Encoding (L-UE)  [3, 16]  mechanisms, and two Longitudinal Local Hashing (L-LH)  [6]  mechanisms. To further broaden the scope of our study, we have evaluated two popular utility metrics by varying the number of users n, the privacy guarantee ϵ, and the domain size k, with both synthetic and realworld datasets. Finally, this paper open-sources the implementation of IBU for all aforementioned LDP mechanisms into the multi-freq-ldpy Python package  [4] , as well as the code used for our experiments in the form of tutorials. In summary, the three main contributions of this paper are: -We present an in-depth analysis of the utility gain of IBU over MI for seven state-of-the-art LDP mechanisms designed for one-time data collection; -To the authors' knowledge, we are the first to extend IBU and conduct a detailed analysis of its utility gain over MI for seven state-of-the-art longitudinal LDP mechanisms designed for multiple data collections; -We open-sourced the IBU implementation for all aforementioned LDP mechanisms into multi-freq-ldpy  [4] , facilitating future research in the area and making it easier for researchers to replicate and build upon our findings.
Setup of Experiments Environment. All algorithms are implemented in Python 3 and run on a local machine with 2. 50GHz Intel Core i9 and 64GB RAM. The codes we develop for all experiments are available in the tutorials folder of the multi-freq-ldpy GitHub repository (https://github. com/hharcolezi/multi-freq-ldpy) [4]. IBU parameters. We fix the # iterations to 10000 and the tolerance to 10 -12. Data distribution. For ease of reproducibility, we generate synthetic data following five well-known distributions and use one real-world dataset. -Gaussian. We generate n samples following the Gaussian distribution with parameters µ = 1000 and σ 2 = 100 and bucketize to a k-bins histogram; -Exponential. We generate n samples following the Exponential distribution with parameters λ = 1 and bucketize to a k-bins histogram; -Uniform.
We generate n samples following the Uniform distribution in range [100, 10000] and bucketize to a k-bins histogram; -Poisson. We generate n samples following the Poisson distribution with parameters λ = 5 and bucketize to a k-bins histogram; -Triangular. We generate n samples following the Triangular distribution with parameters a = 100 (right), c = 4500 (center), and b = 10000 (left) and bucketize to a k-bins histogram; -Real. We query for n samples of the Income dataset, which is retrieved with the folktables  [11]  Python package. We only use the "PINCP" numerical attribute and set the parameters: survey year='2018', horizon='5-Year', survey='person'. Afterward, we bucketize to a k-bins histogram. Varying parameters. When generating our data, we considered different: -Domain size. We varied the domain size k of attributes as k ∈ {2, 50, 100, 200}; -Number of users.
We varied the number of users n as n ∈ {20000, 100000}. Methods evaluated. We assessed the following LDP mechanisms for: -One-time collection. All seven pure LDP mechanisms from Section 3. 1, i. e. , GRR, SUE, OUE, SS, THE, BLH, and OLH; -Multiple collections. All seven longitudinal pure LDP mechanisms from Section 3. 2, i. e. , L-GRR, L-SUE, L-SOUE, L-OUE, L-OSUE, L-BLH, and L-OLH. Stability. As LDP protocols and the synthetic data generation procedure are randomized, we report average results over 20 runs. Metrics. We evaluated the privacy-utility trade-off of all fourteen LDP mechanisms according to: -Utility metrics. We measured the utility gain of IBU over MI following Eq. (  1 ) for both MSE and MAE metrics; -Privacy guarantees. We varied ϵ of LDP mechanisms for one-time collection as ϵ ∈ {1, 2, 4}, representing high, medium, and low privacy regimes, respectively.
e. , last two columns). For example, for both tables, the higher utility gain was observed for the Poisson distribution followed by the real data distribution. The lower utility gain considering all LDP mechanisms was for the Gaussian distribution followed by the Triangular distribution. Implementation details. The multi-freq-ldpy Python package  [4]  is function-based and simulates the LDP data collection pipeline of n users and one server. Thus, for each solution and/or mechanism, there is always a client and an aggregator function. As multi-freq-ldpy had only aggregator functions based on MI, our implementation of IBU contributes with another aggregator function for LDP mechanism in both pure frequency oracle and long freq est enforce both. Experiments in  [26]  were perfomed with the OLH mechanism.
Statistical Postprocessing of medium-range weather forecasts is an important component of modern forecasting systems. Since the beginning of modern data science, numerous new postprocessing methods have been proposed, complementing an already very diverse field. However, one of the questions that frequently arises when considering different methods in the framework of implementing operational postprocessing is the relative performance of the methods for a given specific task. It is particularly challenging to find or construct a common comprehensive dataset that can be used to perform such comparisons. Here, we introduce the first version of EUPPBench, a dataset of time-aligned forecasts and observations, with the aim to facilitate and standardize this process. This dataset is publicly available at https://github.
Providing weather-or climate-related datasets to the scientific community in a standardized and persistent way remains a challenge, which was recently simplified by the introduction of efficient tools to store and provide data to the users. We can mention for example xarray  (Hoyer and Joseph, 2017) , Zarr  (Miles et al. , 2020) , dask and the package climetlab recently developed by the European Center for Medium-range Weather Forecasts (ECMWF). The dataset introduced in the present article is for instance provided by a climetlab plugin, but also accessible through other means and programming languages (see the Supplementary Information). The EUPPBench dataset consists of gridded and point ECMWF sub-daily forecasts of all kinds (deterministic high-resolution, ensemble forecasts and reforecasts) over central Europe (see Figure  1 ).
EUPPBench encompasses both station-and grid-based forecasts for many different variables, enabling a large variety of applications. This -complement by the inclusion of reforecasts -enables a realistic representation of operational posptrocessing situations, allowing users and institutions to learn and improve their skills on this crucial process. These operational aspects are, to our knowledge, missing in the currently available postprocessing benchmark datasets. The forecasts and reforecasts of EUPPBench are paired with station observations and gridded reanalysis for the purpose of training and verifying postprocessing methods. To demonstrate how this dataset can be used, a benchmark of state-of-the-art postprocessing methods has been conducted to improve medium-range temperature forecasts.
Although limited in scope, the outcome of this benchmark already emphasizes the potential of the dataset to provide meaningful results and provides useful insights in the potential, diversity and limitations of postprocessing over the study domain. Additionally, performing the benchmark for the first time with a large community also allows to address the usefulness of the established guidelines and protocols and to draw lessons-learned which are important assets for the delivery of many more benchmarks to come. This article is structured as follow: The dataset structure and metadata is introduced in Section 2. The design and the verification setup of the benchmark which was carried out on the occasion of the publication of this dataset is explained in Section 3, while in Section 4, the benchmarked methods are detailed.
EUPPBench v1. 0 dataset The EUPPBench dataset is available on a portion of Europe covering 47. 75°to 53. 5°in latitude, and 2. 5°to 10. 5°in longitude. Therefore, this domain includes mainly Belgium, France, Germany, Switzerland, Austria and the Netherlands. It is stored in Zarr format, a CF compatible format  (Gregory, 2003; Eaton et al. , 2003)  which provides easy access and allows users to "slice" the data along various dimensions in an effortless and efficient manner. In addition, the forecast and observation data are already paired together along corresponding dimensions, providing therefore an analysis-ready dataset for postprocessing benchmarking purposes. EUPPBench includes both the 00Z (midnight) sub-daily ensemble forecasts and reforecasts  (Hagedorn et al. , 2008; Hamill et al.
This includes the forecast control run which is assumed to have the "closest" initial conditions to reality. The choice of the years 2017 and 2018 was motivated by the relative small number of model changes of the ECMWF forecast system during that period, and most importantly, the absence of model resolution modifications, as shown by Table  1. This implementation constraint is crucial to ensure that no supplementary model error biases are introduced in the datasets, as those biases can lead to a more-or-less severe degradation of the postprocessing performances  (Lang et al. , 2020; Demaeyer and Vannitsem, 2020). The forecasts and reforecasts time steps are 6-hourly (including the 0-th analysis time steps) up to a lead time of 120 hours (5 days). The variables considered are mainly surface variables and can be classified in two main categories: instantaneous or processed.
General data structure The EUPPBench dataset consists of observations and forecasts in two types: a gridded dataset and a dataset at station locations. All forecasts are based on the ECMWF IFS forecasts. However, while the observational dataset at the station locations is based on ground measurements, the reanalysis ERA5 is taken as the gridded observational dataset. All forecast and reforecast datasets are provided for 31 variables, and additionally, the forecast dataset includes 9 EFI variables. The observations, on the other hand, include only 5 and 21 variables for the station-location and gridded datasets, respectively. Additionally metadata on the model and observations is provided. How to access the datasets is documented in the Section 7. We now detail in the following subsections the sources and properties of both dataset formats.