dataesr/scientific-paragraphs-categorization huggingface dataset:
[8]  showed that where-provenance cannot be captured by semiring provenance: there is no semiring for which semiring provenance allows reconstructing the where-provenance of a query. Assume that every tuple t of a database D come with an independent probability Pr(t) of being true (the simple model of tupleindependent databases  [16, 11]  that has been widely studied). In such a model, every subdatabase D ⊆ D (called a possible world) is assigned probability Pr(D ) := ∏ t∈D Pr(t) × ∏ t∈D\D (1 -Pr(t)). By definition, the probability of a tuple t to be in the result of a query Q over this database is the sum of the probabilities of all subdatabases D such that t ∈ Q(D ). It was first observed in  [20]  (see also  [28] ) that, to compute this probability, one can first compute a provenance annotation for Q as a Boolean function (in the msemiring of Boolean functions), and then compute the probability of this Boolean function.
There are various approaches for this latter part such as direct enumeration of all possible worlds or Monte-Carlo sampling. However, a more general approach is to resort to general knowledge compilation techniques  [14]. Knowledge compilation is the problem of transforming Boolean functions of a certain form into another, more tractable, form. Over the years, a wide variety of techniques, results, heuristics, and tools have emerged from the knowledge compilation community. In particular, tools such as C2D  [13] , DSHARP  [26] , and D4  [24]  compile arbitrary formulas in conjunctive normal form into deterministic decomposable negation normal forms (d-DNNF  [12] ), which are Boolean function representations on which probability computation can be done in linear-time. The use of knowledge compilation in a probabilistic database system is a novel contribution of ProvSQL.
THE PROVSQL SYSTEM We now briefly describe the ProvSQL system. ProvSQL is an open-source software implemented in SQL, PL/pgSQL (the procedural programming language of PostgreSQL), C, and C++, freely available at https://github. com/PierreSenellart/provsql/ and as a Docker container at inriavalda/provsqldemo. ProvSQL is implemented as a module of the PostgreSQL database management system 1  , which means it can be deployed in a straightforward manner on top of an existing installation of PostgreSQL. ProvSQL has been tested with versions PostgreSQL 9. 5, 9. 6, and 10 (inclusive), under Linux and MacOS X. ProvSQL functions by adding a separate column, provsql, to all ProvSQL-aware tables of the database, which contains provenance tokens. Provenance tokens are 128-bit universally unique identifiers (UUIDs) that are generated using the uuid-ossp Post-greSQL module.
These provenance tokens are identifiers of gates in a provenance circuit that is constructed and maintained by ProvSQL. Provenance tokens on base ProvSQL-aware tables are fresh UUIDs and correspond to input gates of the circuits. ProvSQL generates new provenance tokens for results of queries on ProvSQL-aware tables, which identify inner gates of the provenance circuit. UUIDs are assigned in a reproducible manner, so that results to two identical queries are assigned identical provenance tokens. ProvSQL consists of two distinct parts, presented next in detail: a query rewriting module that automatically computes the provenance of query results as gates of a provenance circuit; user-defined functions (UDFs) that introduce provenance annotations to existing tables and allow computation of various forms of provenance and probabilities from the provenance circuit.
Query Rewriting Module. PostgreSQL provides hooks  [25]  at different stages of the query execution engine that modules can use to change the behavior of the software. ProvSQL uses one such hook, planner hook, to perform query rewriting after the query has been parsed and before it is sent to the query planner. The query rewriting module only operates for queries that reference one or more ProvSQL-aware tables. Such a query is rewritten in two steps: first, all direct references to the provsql column are ignored -this column is not meant to be directly manipulated by the user; second, a new provsql column is generated for the query result: the values contained in this column are provenance tokens identifying gates of the provenance circuit that encode all operations performed to produce this result, in the provenance term algebra.
SQL is a very rich language, and the structure of the query parsed by PostgreSQL reflects this richness. This means that the rewriting needs to take into account every possible feature of the SQL language. The following types of SQL queries are currently supported by ProvSQL: • User-Defined Functions. User-defined functions provide a SQL interface to the ProvSQL system, defined within a separate provsql schema  [29]. In particular, the following user-defined functions are available: add provenance( of the subcircuit rooted at token of the provenance circuit, using mapping to label input gates. semiring (token, mapping ): a different UDF is defined for different (m-)semirings, which returns the result of the evaluation of the subcircuit rooted at token of the provenance circuit in the corresponding m-semiring, using mapping to map input provenance tokens to (m-)semiring elements.
DEMONSTRATION SCENARIO Our demonstration scenario will use three different databases: • the example Table  1  (taken from  [27] ), the list of personnel from a fictitious intelligence agency, small and simple enough to be easily understandable in a demonstration setting; • a synthetic large probabilistic graph, used to demonstrate the difference of performances between various methods; • a real-world database of a large public transport network  5 (involving several tables, with more than 10 million tuples) used to showcase realistic examples. Most of the demonstration is done within PostgreSQL's psql command-line client; a special Web-based GUI is provided for visualizing where-provenance, and circuit visualization uses an external PDF viewer. We will illustrate the features of ProvSQL on Table  1  using the following example queries, also from  [27] , as well as variations thereof: • A monotone query Q 1 that asks for cities with at least two persons in the agency: The user will also be free to write her own queries, helping her get familiar with ProvSQL's features and limitations.
SELECT First, we will show how to use the add_provenance UDF to add provenance support to an existing table, assigning fresh provenance tokens to all tuples, and the create_provenance_mapping UDF to create provenance mappings that will be used in further queries. Basic SQL queries will be run to show that every query results is annotated with provenance annotations. Second, we will show the result of executing Q 1 or Q 2 on the table, as a table with new provenance tokens. Using the view_circuit UDF, we will display the provenance circuit corresponding to these provenance tokens, and will also show how this circuit is stored in the database. We will then illustrate how this circuit can be used to compute provenance annotations in any provenance semiring (or, for the case of the non-monotone query Q 2 , in any m-semiring): specifically, we will show how to compute, for instance, the security level needed to access each tuple in the result of Q 1 , or how to get a Boolean formula expressing how the result of Q 2 depends on the presence or absence of individual tuples in the input, using UDFs defined for each provenance (m-)semiring.
If the user so decides, we can also demonstrate implementing a new semiring (such as the tropical semiring) by writing the corresponding UDF. Finally, we will ask ProvSQL to display the where-provenance of query results using the where_provenance UDF, through a Web-based interface: when the user hovers over a value in a query result, the system highlights values in the input that produced this data value. Third, we will move to probabilistic query evaluation, modifying the input table to add probability values onto individual tuples. Using the probability_evaluate UDF, we will show how the probability of individual query results can be computed by different approaches: naive enumeration of possible worlds, Monte-Carlo sampling (with a parameter specifying the number of samples used), and knowledge compilation using either c2d, d4, or dsharp.
Probabilistic query evaluation on the synthetic probabilistic graph will illustrate the difference of performances between these methods. Last, we consider realistic examples. On the transport network dataset, queries can be run, for instance, to compute all stations reachable with at most one transfer from some station. After the computation is performed, the provenance of the result can be used to obtain different kinds of meta-information, without rerunning the query: Is the station reachable for a wheelchair user (using evaluation in the Boolean semiring and accessibility attributes on lines and stations)? What is the probability to encounter a failure on a route given failure probability on each line? A 12-minute video preview of part of the demonstration is available at https://youtu.
Time-aware RS  [2]  respect the chronological order of observations and try to capture the temporal dynamics existing in user-generated data. Most RS and time-aware RS proposed in the literature build first a model from a large static dataset, and then rebuild it periodically as new chunks of data arrive and are added to the original dataset. Training a model on a continuously growing dataset is computationally expensive and the frequency of model updates usually depends on the model's complexity and scalability. Therefore, RS can not take into account the user feedback generated after a model update before the next one, leading to a lower quality of recommendation and to the inability to adapt to quick changes. One way to address this issue is to approach the recommendation problem as a data stream problem and design online RS that learn from continuous data streams and adapt to changes in real-time.
Our approach maintains one global model for all users and several local models built separately for each subset of users. Local models have been exploited for batch RS and are able to capture diverse and opposing preferences  [3]. We propose to continuously evaluate over time user assignments to subsets. Users are moved from one subset to a more adapted one when a change in preferences is detected, and user profiles are updated accordingly. Experiments on three real datasets show promising results. The rest of the paper is organized as follows. In Section 2, we discuss related work on online RS. In Section 3, we present our approach performing online recommendation and adapting to changes in user behaviors. Experiments and results are presented and discussed in Section 4. Finally, Section 5 concludes the paper.
EXPERIMENTS Evaluation protocol. Holdout methods, traditionally used in the evaluation process of RS, are not adapted for the evaluation of online RS  [22]. By randomly sampling data for training and testing, these methods ignore the temporal dimension and do not take into account the natural ordering of observations  [22]. Since our method requires a short offline initialization phase, we adopt the evaluation protocol proposed in  [14]. The dataset is sorted chronologically and then split in three subsets, with the proportions 30%-20%-50%: (1) Batch Train subset, used as a training set for initializing the models in batch. Algorithm 1 Overview of our approach DOLORES 1: for all observations (u, i) do Compute err (l, R u * ) 3: for all l ′ ∈ {1,. , m} s. t. l ′ l do 4: Compute err (l ′ , R ′ u * ) 5: end for 6: set l opt = l ′ s.
t. err (l opt , R ′ u * ) = min l ′ err (l ′ , R ′ u * ) 7: if err (l, R u * ) > err (l opt , R ′ u * ) then 8: Update the global model matrix S д with (u, i) Assign the user u to the local model l opt Update the global model matrix S д with (u, i) 13: Update the local model l matrix S l with (u, i) 14: end if 15: end for (2) Batch Test -Stream Train subset, used as a test set for the initialization set, and also used for incremental online learning to ensure the transition between (  1 ) and (  3 ). (  3 ) Stream Test and Train subset, used for prequential evaluation. The prequential evaluation  [8]  is a test-then-learn procedure performed while iterating over the dataset. For each observation, i. e. , pair (user u, item i), we use the current model to perform recommendation for u, measure the performance of the model given i, and then use the observation (u, i) to update the model.
Evaluation measures. We use two measures for evaluating the quality of recommendation, recall@N and DCG@N, as defined in  [7]. The metrics are computed individually and averaged for all observations. Datasets. We evaluated the performance of our method on three datasets which characteristics are shown in Table  1. The AH dataset is extracted from the hotel industry 1  and gathers actual bookings of European users in the hotels of AccorHotels during a period of 3 consecutive years. The ml-1M and ml-10M datasets correspond respectively to the MovieLens 1M and MovieLens 10M datasets 2  and represent movie ratings. In order to use the data as implicit feedback (positive-only data), we keep in the dataset the pairs for which the rating is in the top 20% of the rating scale of the dataset, i. e.
• By comparing DOLORES-G with DOLORES, we show the benefit of using a global model to capture global patterns, instead of only using local models. • By comparing LORES with DOLORES, we demonstrate the benefit of reevaluating user assignments to subsets as new observations arrive. This also shows that user preferences are shifting over time. Results prove that taking into account this change of preferences has a high impact on the quality of recommendation. We note for example that for the AH dataset, user assignments to subsets are modified for 20% of the received observations. DOLORES outperforms the other methods for the studied datasets and we can see the relative benefit of each of its components.
Introduction A rare disease (RD) affects, by definition, a small number of patients, with a prevalence of no more than 5/10,000 in Europe [1] and 7. 5/10,000 in the USA  [2]. Between 7000 and 8000  [3]  existing RDs may affect a total of 3 to 4 million people in France, representing 4. 5 to 6% of the total French population  [4]. About 30 million people are affected in Europe  [5]  and 25 million in the USA  [6]. The French ministry of health launched the French Rare Diseases Registry project, called the BNDMR project (Banque Nationale de Données Maladies Rares), in 2011. It aims to build a national RD registry system. It is designed to record clinician activities and facilitate socioeconomic and epidemiological RD studies through the identification of RD patients. This national information system collects RD patient data on the basis of a minimum dataset  [7]  and promotes data exchange with existing systems to avoid data re-entry by health professionals.
Interoperability had to be ensured at both levels to allow interconnections between different types of source systems. The first layer of the BNDMR is interconnected to the hospital electronic health records through nominative data related to patients' follow-up in a medical care perspective. Interconnections at the nominative level are not allowed for other source systems, e. g. RD specific registries. Indeed, the legally declared objectives of the systems to be connected are not the same: e. g. medical care follow-up versus epidemiological objective. In this latter case, these systems are thus connected at a de-identified level with the data warehouse. A reliable patient identifier must be used for both levels to avoid creating duplicates in the database, especially at the de-identified level, where the patient identifier has to be assigned to the data by the source system.
The patients' identifier must be non-meaningful. There must be no personal information since the national registry is a de-identified database. A unique and permanent identifier has to be attributed to every patient regardless of his/her medical care pathway in the healthcare institutions. This identifier needs to be unique for a given patient in order to avoid collisions. Children and even foetuses, which represent a large proportion of RD patients  (14)   [9] , must have their own identifiers. Indeed, 80% of RDs are genetic and usually appear during childhood  [4]. French authorities chose the national social security number (NIR) as the new national health identifier  [10]. It is generated at birth (or at entry in the country for non-French residents) and is managed by the national identification directory for the identification of natural persons (RNIPP).
This identification number is unique to the individual. It is displayed on the national health insurance card and used by social security beneficiaries for identification and reimbursement of health spending. However, children do not have a personal social security card. They are registered on their parent's card but their personal NIR is not listed. The parent's NIR is used to reimburse the healthcare expenses of their children. This is an important limitation of using the NIR to identify RD patients since most are diagnosed in childhood. Our objective was to propose a new national RD patient identifier, the IdMR (Identifiant Maladies Rares), built for the French RD registry, but that remains universal in its design. It is illustrated with data from the French RD Registry. This patient identifier must prevent the risk of patient re-identification and allow the federation of patient identities, especially for epidemiological and statistical purposes.
Methods The new identifier for the French RD registry relies on nominative data (i. e. person identity), which are, to date, the most widespread and reliably available information. Four types of input data were used to create the patient identifier: 1) the first name among the names listed Fig. 1  The French rare diseases information system architecture on the birth certificate; 2) the family name, also called patient's birth name or patronymic name as reported on the birth certificate; 3) the complete date of birth: day, month, and year; 4) the legal sex: male, female, or indeterminate. Foetuses that are not yet legally registered may have neither a first name nor a family name, they do not yet have a birth date, and their gender may not yet be known. One solution may be to create an extra file to link the file of the foetus to the mother's identity.
Results The IdMR was generated for all patient files of CEMARA, a RD database containing 359,339 files (patients and family members) with an estimated duplication rate of approximately 9%. Patients' data in the database were collected from the first trimester of 2007 to the first trimester of 2015. The input data of the IdMR algorithm (first name, last name, birth date, and gender) are required items in CEMARA. As stated above, the collision detection was performed at two levels of the IdMR algorithm. First, we estimated the number of collisions introduced by the phase A of the algorithm which is the input nominative data preprocessing. There were fewer exact duplicates in the original nominative data than in the phase A output duplicates. In total, 1771 collisions were detected. We investigated these duplicates by picking a random set of files in which collisions had been detected.
We determined that they were patient duplicates with more than one file in the database. This was mostly due to the use of different accents, extra spaces, the use of special characters for compound first names, and the use of either simple or compound versions of family names. The input data preprocessing, and therefore the IdMR algorithm, functioned as an identity federator for these 1771 cases, as it allowed file deduplication. Second, the same number of duplicates for the strings resulting from the pre-processing phase and their corresponding IdMR were detected. Thus, no collisions were introduced by phases B and C. Amongst the 359,339 distinct patient files in the CEMARA database, 17,470 exact duplicates were detected using the four nominative input elements of the IdMR algorithm as entered by the users, as well as 1771 supplementary duplicates following the pre-processing phase.
The NIH/NCATS Global Rare Diseases Patient Registry Data Repository, GRDR program, defined a patient identifier with the goal of being able to follow a patient across different RD studies and registries (18) (). The GRDR-GUID (global unique identifier), is a unique random alphanumeric set of characters assigned to each patient's data. It is generated by a one-way hash algorithm upon a set of personally identifiable information: legal given name, additional name and family name at birth; day, month, and year of birth; name of city and country of birth; and finally the physical sex at birth (M/F). To our knowledge, neither the method nor the results on the robustness of this global unique identifier have yet been  published. A survey  [14]  performed within the framework of the European joint action for RDs (RD-ACTION)  [15]  showed that among 19 participating countries: 10 had a unique patient identifier used mostly for drug-related groups and often not available for RD patient identification, eight did not have a unique identification system, and one built a specific identifier for rare diseases.
Of note, Denmark, Finland, and Sweden, member of the European Union (EU), are implied in the recent EU general data protection regulation by the European Commission that enforces a unified data protection framework for all EU member states [EU General Data Protection Regulation (GDPR), https://eur-lex. europa. eu/eli/reg/2016/679/oj]. The GDPR became recently enforceable as of May 25th 2018. The European RD-CONNECT project  [18] , funded by the European Union Seventh Framework Program under the International Rare Diseases Research Consortium (IRDiRC), and intended to implement a GUID, of which the GRDR-GUID is one of the possibilities under consideration. The EpiRare project  [19]  defined an EU-GUID among the set of common data elements for the European Rare Disease Registration (RDR) platform.
Third, there may be issues of granularity when using the same standard, i. e. some users could enter 75,000 for Paris and others may more precisely enter 75,001 or 75,002 to focus on a district. Finally, this information is not always available: 16% of patient files in the CEMARA database did not include the city of birth. Moreover, a quantitative study of our database showed that the four proposed nominative data types were sufficiently discriminating to avoid generating collisions. Indeed, the use of the city of birth is not necessary for avoiding collisions, and may instead be a source of errors increasing the risk of creating duplicates. Multimodal systems for data linkage has been proposed. In the US, the SFARI initiative (Simons Foundation Austism Research Initiative) and the NDAR project (National Database for Autism Research) collaborated in building a patient identification method allowing data linkage between different autism registries  [20].
A centralized system exposing web services generates GUIDs. Five identifiers can be generated after the hash of different combinations of personal data related to patients and members of their families. Using these secured web services, each source register retrieves a set of calculated identifiers according to the availability of the sent personal information and subsequently returns the anonymised patients with those GUIDs. In the central registry, data from different sources are linked, based on reconciliation between the different GUIDs. A similar approach has been proposed for the setup of a clinical trial project allowing data linkage of six health institutions in Chicago  [21]. The authors proposed a two-level system. Each institution involved in the study, at a local level, uses an application developed and distributed by the authors to generate a set of hashes of different combinations of identifying information: name, surname of birth, date of birth, social security number and gender.