dataesr/scientific-paragraphs-categorization huggingface dataset:
Even if these service providers protect data adequately and process queries accurately, they may be curious about the stored data and may attempt to profit by disclosing this sensitive information to third parties. This raises the question of whether it is possible to protect confidentiality and privacy of the outsourced data. A recent study  [10]  by the Ponemon Institute indicates that since 2005 more than 250 million customer records containing sensitive information have been lost or stolen. The same study reports the average organizational cost of data leakage between 2005 and 2009, to be about $6. 6 million. Hence, there seems to be a clear financial motivation to protect data privacy and confidentiality even when records are leaked. Related Work. One approach to protect confidentiality and privacy of the outsourced data is based on encrypting all tuples in outsourced databases  [8, 7].
With this approach, one crucial question is that of how to efficiently execute queries. Clearly, when using deterministic encryption techniques equality-match queries are simple to evaluate. However, range queries and aggregations become more difficult to perform as we must decrypt all records to evaluate this kind of queries, which makes query execution on the outsourced encrypted data much more difficult. Therefore, our main focus in this paper is about preserving both privacy and confidentiality of outsourced database while ensuring a secure way for querying outsourced data. One promising method to meet this requirement is to use data fragmentation. Basically, data fragmentation procedures are not particularly designed for preserving data security, they are aimed to improve data manipulation process, optimize storage, and facilitate data distribution.
g. employees' bank account numbers of a company). While they do constitute an interesting way to ensure confidentiality of outsourced database, these approaches have the major limitation that it assumes that data to be outsourced is represented within a single relation schema (or table). Clearly, this assumption is too strong and seldom satisfied in the real environments, as generally, relational databases are normalized to minimize redundancy and dependency by dividing large tables into smaller (and less redundant) tables and defining relationships between them. In this paper, we strive to protect the confidentiality and the privacy of sensitive outsourced database using both encryption and fragmentation, combining the best features of both approaches. Furthermore, we aim to overcome the previously mentioned limitations of  [4, 6]  by presenting an approach which is able to deal efficiently with multi-relation normalized databases.
In a distributed environment, the problems encountered in one-relation 1 databases take on additional complexity when working with multi-relation normalized databases as it gives rise to new problems such as protecting the relatioships between relational schemas and defining a secure and efficient technique allowing authorized users to query these sensitive relationships. We will show how to protect data unlinkability of different fragments of the original database by protecting user query privacy using a practical Private Information Retrieval (PIR) technique. Unlinkability of two items of interest (e. g. , records stored into different fragments) means that within the system, from an adversary point of view, these items of interest are no more and no less related. In our approach, a relation containing sensitive information will be fragmented into two or more fragments.
Motivating Example Consider a relational hospital database D with relations: Patient(Id, Name,ZIP, Illness, Id Doctor *) and Doctor(Id, Name, Specialty) where Id Doctor is a foreign key referencing the column Id of the relation Doctor. Let us assume that the hospital is going to outsource the database to a third party. Sensitive information contained in D should be protected. If we look carefully, we can consider that the list of patients and their attributes (Id, N ame, Zip) are not sensitive, and also that the list of illnesses could be made public. Nevertheless, the relationship between these two lists (list of patients and list of illnesses) should be protected. Therefore if we can find a way (e. g. vertical fragmentation  [11] ) to break relationships between patients and their respective illnesses, there is no need to encrypt all records of the P atient relation.
Confidentiality using fragmentation and encryption Our approach extends in several ways the vertical fragmentation-based approach described in  [4, 6]. This approach considers that all data is stored in a single relation, while in our approach data can be stored in several relations, which is the case in typical database environments. In our approach, we consider that databases to be externalized are normalized so that two relations can be only associated together through a primary key/foreign key relationship. For this purpose, we introduce a new type of confidentiality constraint for fragmentation, the inter-table fragmentation constraint. The aim of this new fragmentation constraint is to protect the relationship between relations. This section first presents the different kinds of confidentiality constraints used to achieve our goals of protecting the confidentiality by encryption and fragmentation, and second formalises the concept of fragmentation in our approach which extends ideas presented in  [4] [5] [6].
Definition 1 (Confidentiality Constraint). Consider that data to be secured are represented with a relational database D, which is composed of a list of relational schemas R = (R 1 ,. , R n ), with each of these relational schemas R i containing a list of attributes A Ri = (a 1,i , a 2,i ,. ). A confidentiality constraint over D can be one of the following: Singleton Constraint (SC). It is represented as a singleton set SC Ri = {a j,i } over the relation R i. This kind of confidentiality constraint means that the attribute a j,i of the relational schema R i is sensitive and must be protected, typically by applying encryption. Association Constraint (AC). This kind of confidentiality constraint is represented as a subset of attributes AC Ri = {a 1,i ,. , a j,i } over the relational schema R i.
Inter-table Constraint (IC). It is represented as a couple of relational schemas IC = {R i , R j } of the relational database D. Relations R i and R j should be associated through a primary key/foreign key relationship. The use of this kind of confidentiality constraint ensures protection of the primary key/foreign key relationship between the two relational schemas concerned with the inter-table constraint IC. Note that protecting the relationship between two tables relies on protecting the primary key/foreign key relationship and storing involved relations separately. The association constraint can also be addressed through encryption (encrypt at least one of attributes involved in the constraint), but clearly this will increase the number of encrypted attributes and make interrogation of the database more complicated.
An interesting approach for modeling constraints and resolving the data fragmentation problem was proposed in  [6] , that efficiently computes data fragments that satisfy the confidentiality constraints. It is based on Boolean formulas and Ordered Binary Decision Diagrams (OBDD) and uses only attribute-based confidentiality constraint (Singleton Constraints and Association Constraints). However, it cannot deal as-is with Inter-table Constraints. In order to use this approach, we define a way to reformulate Inter-table Constraint as a set of Singleton Constraints and Association Constraints. We explain this transformation in the definition and theorem below. Definition 2 (Inter-table Constraint transformation). Consider a relational database with two relations R 1 (a 1 ,. , a n ) and R 2 (b 1 ,.
A transformation of an Inter-table constraint c to a set of confidentiality constraints C is correct if the satisfaction of C enforce the protection of the unlinkability between records of the two relations involved in c. The following Theorem formalizes this concept. Theorem 1 (Transformation correctness). Given a relational database D composed from two relational schemas R 1 (a 1 ,. , a n ) and R 2 (b 1 ,. , b m * ) related through relationship between the foreign key b m of R 2 and the primary key a 1 of R 1. Let c = {R 1 , R 2 } be an Inter-table constraint, the set of constraints C be the result of the transformation of c, and F = {F 1 ,. F q } be a fragmentation of D that satisfies C. The Inter-table constraint c is correctly transformed into a set of constraints C if all the following conditions hold : 1.
2. ∀ AC i,j = {a i , b j } ∈ C, i ∈ [1, n], j ∈ [1, m], if a i ∈ F k and b j ∈ F l then k = l The main advantage of the Inter-table constraint is that it allows treatment of multi-table relational databases. In addition, it gives a simple way to formulate confidentiality constraints between relations. As we have seen in Item (i) of Definition 2, the attribute b m (foreign key of the relation R 2 ) should be encrypted. However, to be able to query data and construct relationship between relations, the chosen encryption algorithm must be deterministic  [1]  in order to preserve uniqueness and allow the construction of relationship between relations (e. g. through JOIN queries). As is known, in normalized multi-relation databases, three types of relationship between relations exist: (1) one-to-one, (2) one-to-many and (3) many-to-many relationships.
Definition 3 : Fragmentation [5] Let us consider a relational database D with relations R 1 ,. , R n and A the list of all attributes contained in different relations. Given A f the list of attributes to be fragmented, the result of the fragmentation is a list of fragments F = {F 1 ,. , F m } where each of these fragments satisfies: i ∀F i ∈ F, i ∈ [1. m], F i ⊆ A f. ii ∀a ∈ A f , ∃F i ∈ F : a ∈ F i. iii ∀F i , F j ∈ F, i = j : F i ∩ F j = ∅. Note that the list of attributes to be fragmented A f contains all attributes in A, except those concerned with Singleton Constraints (attributes to be encrypted). Condition (i) guarantees that only attributes in A f are concerned by the fragmentation, condition (ii) ensures that any attribute in A f appears in clear at least in one fragment and condition (iii) guarantees unlinkability between different fragments.
Logically, to be able to get information about the original database, we should be able to reconstruct original database from fragments. So after defining the fragmentation process, we shall define a mechanism to combine fragmentation and encryption. More clearly, a mechanism to integrate attributes involved in the Singleton Constraints (attributes to be encrypted) in the suitable fragment. These encrypted attributes allow only authorized users (users who know the encryption key) to construct the sensitive relationships. Based on the definition of P hysicalf ragment proposed in  [4] , we define our mechanism called Securef ragment to combine fragmentation and encryption. Definition 4 : Secure Fragment : Let D be a relational database with a list of relations R = {R 1 (a 1,1 ,. , a j,1 ),. , R n (a 1,n ,.
Example 4. 2. Assume that we have a relational database D of a medical insurance company that contains two relations P atient and Doctor represented respectively in Table  1  and Table  2. The insurance company has defined the a set of confidentiality constraints CC = {C 1 = {SSN }, C 2 = {N ame pat, Illness}, C 3 = {P atient, Doctor}}. As shown before, the first step in the fragmentation pro-  ). Relations P atient and Doctor are linked through the foreign key Id doc in the relation P atient, therefore C 3 will be replaced by C 4 = {Id doc} and all possible Association constraints composed of an attribute of the relation Doctor and an attribute of the relation P atient (Guarantee that the relation P atient will not be in the same fragment as the relation Doctor). In our example, attributes SSN and Id doc of the relation P atient are involved in singleton constraints C 1 and C 4 respectively.
Query Execution Model Before discussing techniques for processing query over distributed fragments, we will first present the architecture of our proposed approach. It includes three principal entities : (1) a U ser which attempts to execute queries over the original database, (2) a Client which rewrites user queries by splitting them to create an optimized distributed Query Execution Plan QEP; QEP is a set of sub-queries and other operations (e. g. , decryption, join. ), it is created by the Query T ransf ormative based on the M etaData which contains information (relations, clear attributes, encrypted attributes, selectivity of attributes) about data distribution in different fragments. Furthermore, the Query Executor executes each of these sub-queries over the appropriate fragments and sends back the results to the client.
While (1) can be cheaper than (2) in terms of sub-query execution, it is much more costly in the join operation because in (1), sub-queries results might contain a lot of records that will not be part of the final results. In addition to traditional query optimization methods such as selecting conditions as earlier as possible, the QT attempts to minimize the execution cost of the created QEP by applying the selection condition with the most selective attribute, i. e the selection condition which is satisfied by the smallest number of tuples. To give this ability to the QT , we assign a selectivity 3 to each attribute contained in the original database to the M etadata stored in the Client. We apply the optimization method to the example below.
To meet this requirement, we will use a Private Information Retrieval keyword-based technique. PIR keyword-based was presented in  [2]  to retrieve data with PIR using keywords search over many data structures such as binary trees and perfect hashing. Later,  [12]  investigated the use of SQL for PIR, based on the use of B+ tree. In the next part of this paper, we will explain how we can use technique presented in  [12]  to ensure our semi join queries privacy requirement. Theorem 2. Let D be a multi-relation normalized database, F = {F 1 , F 2 } be a fragmentation of D, and Q be a multi-fragment query that joins records from both fragments F 1 and F 2. Consider that SCPs in which the fragments F 1 and F 2 are stored can collude to link data stored in these fragments, and that Q is evaluated using semi join operations.
Conclusion Existing approaches based on fragmentation and encryption have focused on single-relation schema database which is a strong and rarely encountered assumption in real environment. In this paper, we have presented a new approach based on fragmentation, encryption and query privacy techniques which ensures confidentiality of outsourced multi-relation databases. We have presented also a way to optimize and execute queries over distributed data fragments. Our future work will include the implementation of our approach. It will also include enhanced query optimization and execution techniques to overcome some limitations of our approach, such as processing nested queries. A f key = {a ∈ Ci, Ci ∈ C : |Ci| = 1 and isForeignKey(a) = T rue} /* A f key : The set of foreign keys to be encrypted*/ F := Fragment(D, C f ) for all Fi = {ai 1 , ai 2 , • • • , ai n } in F do R f = classifyAttributes(Fi) /* Classify attributes*/ for all R f i in R f do for all r in R f i do r s [salt] := GenerateSalt(R f i , r) /* r : record */ r s [enc] := E k (t[aj 1 , • • • , aj q ] ⊕ r s [salt]) /* aj 1 , • • • , aj q = Ri -R f i */ for all a in R f i do r s [a] := r[a] /.
Acknowledgments We are grateful to  Jaroslav Ševčík ,  Kayvan Memarian , and  Peter Sewell  for enlightening discussions, to  John Regehr  and  Xuejun Yang  for help with Csmith, to  Aldy Hernandez ,  Andrew MacLeod  and  Torvald Riegel  for promptly fixing our bugreports. This work was partially supported by  IRILL  and  ANR  grant  WMC  ( ANR-11-JS02-011 ).
Materials and Methods Malaria Parasite Culture, Image Acquisition Process and Image Analysis Algorithm Our HCS system (illustrated in Figure  1 ) consists of the following five parts: an automated 384-well screening platform to set up the experimental assay, an Operetta TM harmony 2. 0 imaging platform (PerkinElmer) to acquire the images, a central database server to store the acquired image data and final analysis results, an image analysis software platform, and finally the malaria image analysis algorithm designed as plug-in's to the IM platform. The experimental assay was set up using the following protocol: P. falciparum strain 3D7 (MRA-102) was obtained from the Biodefense and Emerging Infections (BEI) research resources (Manassas, VA) and maintained in human RBC (blood type O + , Gyeonggi Blood Center, Korean Red Cross) at 4% hematocrit in media consisting of RPMI 1640, 25 mM HEPES buffer (pH 7.
Following the parasite and red blood cell staining as described in the previously (Figure  1A ), five microscopic image fields (red boxes of the grid in Figure  1B ) were acquired from each well using an automated Operetta 2. 0 imaging system (Figure  1B ). The images were taken using 406 lens and the dimension of each image is 136061024 pixel 2 ( = 3406256 mm 2 ). In real-time, the acquired images were transferred to a central database and stored as TIFF image format with a bit depth of 16 bits (unsigned integer, values ranging from 0 to 65535) (Figure  1C ). We used an in-house developed (proprietary) image analysis software platform called Image Mining (IM) which is able to access the central database and serve as an interface between the acquired image data and the dedicated image analysis algorithm (Figure  1D ).
Parasitaemia and Viability Calculation Parasitaemia is measured by the ratio of the number of infected RBCs over the total number of RBCs. Here we compute proportions of early ring, ring, trophozoite and schizont stages by the ratio of the number of early ring-infected, ring-infected, trophozoite-infected and schizont-infected RBCs over the total number of infected RBCs. Viabilities of the stages are also calculated by the ratio of the number of early ring-infected, ringinfected, trophozoite-infected and schizont-infected RBCs which have Mitotracker fluorescence signals over the total number of early ring-infected, ring-infected, trophozoite-infected and schizont-infected RBCs. These proportions are important data to find hit compounds which block schizont development in malaria parasites.
The parasite life cycle stage classification process provides key information of viabilities of different life cycle states. The parasitaemias are computed by the ratio of number of infected RBCs and total RBCs. The viabilities of different life cycle stages are computed by the ratio of the number of infected RBCs of live parasites and total infected RBCs. Precise determination of culture parasitaemia and parasite viability is especially necessary to detect and prioritize highly effectiveness drug candidates with novel MoA for development. Additionally, as shown by our time-point stage detection and quantification data (Figure  7 ), the developed algorithm accurately quantifies each parasite stage in cultures. This potential of our algorithm could be employed to characterize various drugs cellular mechanisms of actions including the drug effects on schizont development, egress and host cell invasion.
This work was supported by the  National Research Foundation of Korea (NRF)  grant funded by the  Korea government (MEST) (No. 2012-00011 ),  Gyeonggi-do and KISTI. Myungjoo Kang  was supported by the  Basic Science Research Program  ( 2012-001766 ) through the  National Research Foundation of Korea. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
HbVar (http://globin. bx. psu. edu/hbvar) is one of the oldest and most appreciated locus-specific databases launched in 2001 by a multi-center academic effort to provide timely information on the genomic alterations leading to hemoglobin variants and all types of thalassemia and hemoglobinopathies. Database records include extensive phenotypic descriptions, biochemical and hematological effects, associated pathology and ethnic occurrence, accompanied by mutation frequencies and references. Here, we report updates to >600 HbVar entries, inclusion of population-specific data for 28 populations and 27 ethnic groups for a-, and b-thalassemias and additional querying options in the HbVar query page. HbVar content was also inter-connected with two other established genetic databases, namely FINDbase (http://www.
findbase. org) and Leiden Open-Access Variation database (http://www. lovd. nl), which allows comparative data querying and analysis. HbVar data content has contributed to the realization of two collaborative projects to identify genomic variants that lie on different globin paralogs. Most importantly, HbVar data content has contributed to demonstrate the microattribution concept in practice. These updates significantly enriched the database content and querying potential, enhanced the database profile and data quality and broadened the inter-relation of HbVar with other databases, which should increase the already high impact of this resource to the globin and genetic database community.
HbVar database of hemoglobin variants and thalassemia mutations is one of the oldest and the mostappreciated locus-specific databases (LSDBs), not only from the globin but also from the wider genetic database community. HbVar was launched in 2001 and derived from previous compilations  (2, 3) , as a publicly available LSDB, to provide timely information to interested users, e. g. the globin research community, patients and their parents and providers of genetic services and counseling. HbVar is developed such as to accommodate the need for regular data entry updates and corrections, as new hemoglobin variants and thalassemias continue to be discovered. In addition, HbVar has a comprehensive query interface that allows easy access to this information, particularly for the research community and also for physicians as an aid in diagnosis.
Since its launch, HbVar has rapidly become an important data resource for the globin research community and is considered to be one of the premier LSDBs available to date (4). We report here several new updates in HbVar structure and contents, aiming at increasing the quality of the database, the accuracy and breadth of data coverage and, above all, its impact to the scientific community. Also, the various synergies with other data resources, namely LSDBs and National/Ethnic Genetic databases, are discussed.
UPDATES TO EXISTING DATA Since the launch of HbVar  (5)  and the previous database updates in  2004 (6)  and 2007  (7) , HbVar information has been expanded by >600 additional entries and data corrections, made continually by the database curators. Also, to cope with the increased need of regular data updates and corrections, Dr Joseph Borg (University of Malta, MT), Dr Kamran Moradkhani (Nantes, FR) and Dr Philippe Joly (Lyon, FR) have joined the HbVar team as data curators for thalassemia mutations and hemoglobin variants, respectively. To identify new hemoglobin variants and thalassemia mutations not previously documented in the database, we continued to manually scan articles from the specialized journal 'Hemoglobin', which frequently publishes new hemoglobin variants and thalassemia mutations, and where applicable, previously undocumented variants have been entered into HbVar.