dataesr/scientific-paragraphs-categorization huggingface dataset:
For example, a CFD could state that when two customers are based in the UK, the zipcode uniquely determines the city. A conditional key is a particular type of CFD, where the second set of attributes is a unique identifier for a record in the database. CFD discovery has been addressed in  [6, 10, 15]. The work of  [6]  uses a breadth-first strategy inspired by the schema-based approach TANE  [17]. FastCFD  [10]  finds a canonical cover of all minimal CFDs that satisfy a given support using a depth-first strategy. Compared to  [6]  (which works well when the number of tuples is large), FastCFD  [10]  is efficient when the number of attributes is large. Nevertheless, none of these approaches is able to discover conditional keys in KBs, because they cannot efficiently deal with multivalued properties and would require a post-processing to mine conditional keys from the obtained CFDs.
However, the result are rules with negations, not con-   1. Given a KB K, a dataset D for a class c of K is the set of all facts that have as subject an instance of c or of a subclass of c. Table  1  shows an example dataset 2  about researchers r1,. , r7, each having the properties first-Name, lastName, gender, lab, and nationality -with one or more objects for each property. When D is given, we write p(x, y) to mean p(x, y) ∈ D. Keys. In our setting, a key is defined as follows  [21, 27].
Definition 1. (Key) A key in a dataset D is a set of properties p 1 ,. , p n of D such that: ∀x, y, u 1 ,. , u n i=1. n p i (x, u i ) ∧ p i (y, u i ) ⇒ x = y In our example, the property set {lastName, gender } is a key while {lab, na-tionality} is not a key, because r3 and r4 are both Spanish. Note that {lab, nationality} is a forall-key since no two people share the lab and the entire set of nationalities.
Definition 2. (Maximal non-key) A maximal non-key for a dataset D is a set of properties P of D such that P is not a key, and the addition of any other property makes P a key. In our example, {firstName, lastName, lab} is a maximal non-key, because adding any other property makes the set a key. Key Discovery. To discover the keys of a dataset automatically, a naive algorithm would have to compare all subjects of the dataset to all other subjects -which is prohibitively expensive. To avoid this complexity, the SAKey algorithm  [27]  first finds maximal non-keys. This is more efficient, because to verify that a set of properties is a non-key, it suffices to find two subjects that share values for these properties. SAKey starts with property combinations that contain only a single property, and incrementally adds more and more properties until it arrives at maximal non-keys.
The support of a conditional key with properties {p 1 ,. , p m } and conditions {cd 1 ,. , cd n } is the number of subjects x such that i=1. m ∃u i : p i (x, u i ) and i=1. n cd i (x). A proportional version of the support, which we call the coverage, measures the ratio of subjects in the dataset identified by the conditional key. In our example, the support of the key {lastName} under the condition lab=INRA is 4, and the coverage is 4  7 , since there are 7 subjects. Keys in OWL. Conditional keys can be defined in the ontology language OWL2  [20]. OWL2 allows defining keys not just on atomic classes (such as researcher ), but also on more complex class expressions. We can define, e. g. , the class "Researchers who work at INRA" as c = Researcher ∃lab. {INRA}. Then, {lastName} is a key on the dataset of c according to Definition 1.
Mining Conditional Keys We now present our approach to automatically discover conditional keys on a dataset. To learn conditional keys under the Open World Assumption, we assume that all instances in a dataset refer to distinct real world objects, and that all unknown values are different from the existing ones in the dataset  [7, 13, 14, 21, 27]. The discovery of simple keys alone already requires checking a large number of property combinations (of which there are 2 |P| in total, where P is the set of properties). Discovering conditional keys is even more complex, since the search space is in the order of O(|V| |P| ), where V is the set of objects in the dataset. Our algorithm can discover conditional keys efficiently in spite of this large search space. Our method takes as input a dataset D and a threshold θ for the minimal support of the discovered keys.
Discovery of non-keys The naive method to mine conditional keys explores all possible combinations of properties and conditions in the input KB and verifies whether they fulfill Definition 3. Such an approach is infeasible on large datasets. Our main idea (the key insight, so to speak) is the following (see  [28]  for more details): Observation 1 (Conditional Keys and Non-Keys) Given a minimal conditional key for a dataset D with properties P and conditions {p 1 = o 1 ,. , p n = o n }, the set of properties P ∪ {p 1 ,. , p n } must be a non-key for D. This follows from Definition 4. In our example from Table  1 , {firstName} is a minimal conditional key with condition gender=Female, and {gender, first-Name} is a non-key. Thus, if we want to mine the complete set of minimal conditional keys, it suffices to consider only the property combinations given by non-keys.
Since maximal non-keys are super-sets of all other non-keys (Definition 2), it is sufficient to explore only property combinations given by maximal non-keys. The maximal non-keys in the input dataset can be mined efficiently with the SAKey algorithm  [27]  (Section 3). Thus, we concentrate in the following on mining the conditional keys from these maximal non-keys. As a running example, consider again the dataset in Table  1. It contains two maximal non-keys: {firstName, lastName, lab} and {firstName, gender, lab, nationality}.
Generation of Conditional Key Graphs Our method for discovering conditional keys from non-keys relies on a modifiable data structure that we call a conditional key graph. Such a graph is a tuple P k , P c , cond , G with the following components:  We construct the initial conditional key graphs with Algorithm 1. This algorithm takes as input the dataset, the support threshold θ, and the non-keys discovered in Section 4. 1. We first construct all possible conditions p = a that combine a property p from the non-keys with an instance or literal a from the dataset (Lines 2-3). Conditions with support less than θ are not considered (Line 4). We then look at all non-keys N in which p appears (Line 5). The conditional key graph for the condition p = a will contain as nodes all subsets of N \ {p} (Line 6) except the empty set (Line 7).
As an example, let us consider again the dataset of Table  1  and its two maximal non-keys {firstName, lastName, lab} and {firstName, gender, lab, nationality}. Figure  1  depicts the conditional key graph associated to the condition gender = Female constructed by Algorithm 1. Lemma 1. (Graph Construction) If Algorithm 1 is given a dataset D, a complete set of maximal non-keys N for D and a support threshold θ, then for each conditional key of D with a single condition and with at least support θ, there is a graph in the output that contains the key condition and a node with the key properties. Lemma 1 follows from the fact that Algorithm 1 (a) iterates over all conditions p = o with a least support θ and (b) considers all the possible subsets of properties 2 N \{p} with N ∈ N (except for ∅).
Mining of Conditional Key Graphs Mining conditional keys. We mine the conditional key graphs for keys with Algorithm 2. It takes as input a dataset, a support threshold, and the set of conditional key graphs constructed in the previous phase. All these conditional key graphs have conditions of size 1 (see Algorithm 1). The algorithm proceeds in batches, looking first at the graphs with condition size 1, then size 2, etc. (Lines 2-3). For each batch, it mines the conditional keys (Line 6). The graphs in one batch are then post-processed (Line 7) to give rise to new graphs with conditions of larger size. The algorithm iterates until all sizes are processed (Line 4).
Algorithm 2: ConditionalKeyDiscovery Input: dataset D, minimum support θ, set of conditional key graphs G Output: set of minimal conditional keys CKs 1 CKs ← ∅ 2 for size = 1 to ∞ do 3 G ← {g ∈ G : |g. cond | = size} 4 if G = ∅ then return CKs 5 for P k , P c , cond , G ∈ G do 6 CKs ← CKs ∪ MineGraph(D, θ, P k , P c , cond , G , CKs) 7 G ← newConditions(size, G, θ, D) Mining a conditional key graph. Let us now discuss how one conditional key graph can be mined for keys (Line 7 in Algorithm 2). This task is done by Algorithm 3. This algorithm takes as input a dataset, the support threshold, a conditional key graph, and the set of conditional keys found so far. The algorithm proceeds in levels, looking first at the nodes that contain one property, then two properties, etc. For each level, we consider every node cand.
The corresponding conditional key graph after scanning the first level is shown in Figure  2(a). Nodes with the explore flag set to false are greyed out. At the end of this step, only the property firstName is discovered as a key, since first names are unique among female researchers. It follows that nodes containing this property in the next levels of the graph define non-minimal keys. They are therefore discarded for further exploration (the explore flag is set to false). The search for conditional keys is then applied to the nodes on levels 2 and 3, for which the explore flag is still true. Lemma 2. (Graph Mining) Given a conditional key graph P k , P c , cond , G for a dataset D and a threshold θ, Algorithm 3 will ensure that the result set CKs contains all minimal conditional keys for the condition set cond whose key properties are given by one of the nodes in G, and whose support is at least θ.
This lemma holds because Algorithm 3 traverses all nodes in the conditional key graph, and checks each of them for being a conditional key. It excludes only (a) those nodes whose ancestors already had a support smaller than θ, in which case the node itself must also have a support smaller than θ, and (b) the nodes that lead to non-minimal keys. Merging conditions. Let us now look at the process of generating more complex conditions (Line 8 in Algorithm 2). This work is done by Algorithm 4. It takes as input a set of conditional key graphs, a support threshold, a dataset, and a size parameter. It looks at all conditional key graphs that have a condition set of the given size (Lines 2-3). For each of them, it constructs a clone (Line 4). It then adds one more condition to the condition set of the clone.
p = v 2. p = v. p ∧ v. explore = (v 1. explore ∧ v 2. explore)} -E = {u, v ∈ V : u. p ⊂ v. p ∧ |u. p| = |v. p| -1} As an example, Figure  2 (b) shows the conditional graph with the set of conditions {gender = Female, lab = INRA} produced by Algorithm 4 from the conditional graphs with conditions gender = Female and lab = INRA. This graph is a clone of the graph with the condition gender = Female. A node is marked to be explored only if it was marked to be explored in both of the original graphs. Lemma 3. (New Conditions) Given a dataset D, a set of conditional key graphs G, a size parameter size, and a threshold θ, Algorithm 4 produces all conditional key graphs that contain condition sets of size size+1. Each of those graphs contains all the conditional keys for the given condition. We can prove Lemma 3 by induction.
This will produce graphs with conditions of the form {p 1 = o 1 ,. , p size-1 = o size-1 , p size = o size } with key part P k \ {p size } with support greater than θ. (a) follows from Observation 1, since we have just transferred a property from the key part to the condition part. Theorem 1. (Conditional Key Discovery) Given a dataset D, a set of conditional key graphs G, and a threshold θ, Algorithm 2 produces all conditional keys whose properties are a subset of the properties of any node in any graph in G, whose conditions are built from conditions or properties in G, and whose support is at least θ. This theorem follows from the fact that Algorithm 2 calls Algorithm 3 for all sizes between 1 and the maximal number of property combinations. Lemma 2 makes sure that all possible graphs are generated.
Runtime Experiments Setting. To evaluate the performance of VICKEY and AMIE  [13] , we adapt AMIE to mine rules of the form: P c ∧ P k ⇒ x = y. Here, P c = 1. n pc i (x, A i ) ∧ pc i (y, A i ) corresponds to the condition part of a key expression, and P k = 1. m pk i (x, u i ) ∧ pk i (y, u i ) represents the key part. Both AMIE and VICKEY take as input a set of maximal non-keys. These non-keys are obtained from the input dataset using SAKey  [27]. Like VICKEY, our adapted variant of AMIE uses the non-keys to restrict the search space by pruning the combinations of properties that do not occur in the non-keys. Unlike VICKEY, AMIE searches exhaustively for all rules that define conditional keys in the input dataset, regardless of their minimality. AMIE therefore requires a post-processing phase where all non-minimal conditional keys are removed.
Both AMIE and VICKEY are run with a coverage threshold of 1%. We set the confidence threshold of AMIE to 100%, so that VICKEY and the modified AMIE mine exactly the same set of conditional keys. As datasets, we have used nine classes from DBpedia  [18] , covering different domains such as people, organizations, and locations. All experiments are run on a server with an AMD Opteron 6376 Processor (2. 40GHz), 8 cores, and 128GB of RAM under Ubuntu Server 16. 04. Results. Our results are shown in Table  2. The first three columns show some statistics about the testing datasets, followed by the number of discovered nonkeys (NKs), the runtimes of both VICKEY and AMIE and finally the number of obtained conditional keys (CKs). We observe that a generic rule mining solution cannot handle some of the input datasets in less than 1 day.
VICKEY, in contrast, runs on the smaller datasets Actor, Mountain, Museum and Scientist in less than 1 hour. This is because VICKEY's strategy prunes the search space much more effectively by avoiding candidate CKs that are not minimal. Other classes, such as University and Organization, are more challenging because they have many long non-keys (up to 15 properties). The longer the non-keys, the larger the number of property combinations in the search space. For example, for the class Album, AMIE explores more than 12. 3k rules (including intermediate rules), where 6. 4k rules correspond to potential conditional keys. In contrast, VICKEY explores only 4. 1k candidates. This shows that VICKEY's strategy indeed prunes the search space much more effectively. It can mine conditional keys on hundreds of thousands of facts in a matter of minutes.
We have used the same set of classes as for the runtime experiments. As this type of entity linking assumes that the properties have been aligned, we mapped the properties of these classes manually, and rewrote the properties of YAGO using its DBpedia counterparts. We ran SAKey  [27]  and VICKEY on DBpedia to find standard and conditional keys, respectively. Table  3  shows the number of common properties, the number of keys (Ks), non-keys (NKs) and conditional keys (CKs) in each DBpedia class. Among others, VICKEY finds that motto is a key for universities in Italy and some other countries -but not in all countries; and that the name is a key for organizations in certain places -but not all places. To link the datasets, we use a simple algorithm  [27] : For each key, we iterate over the entities in DBpedia that have the key properties.
If there is an entity in YAGO that shares at least one value for every of these properties, we link the two. For conditional keys, we also check whether the conditions of the key are fulfilled in both datasets. Results. Table  4  shows the precision, recall and F1 measure of the entity linking task using a) classical keys mined by SAKey  [27] , b) conditional keys alone and c) both types of keys (VICKEY). We first observe that the precision is always over 98%. Conversely, the recall is low in some cases. This happens mainly due to our simple linking method, which uses a strict string equality when comparing the values of properties, and also due to the incompleteness of the data in both YAGO and DBpedia. However, even with this simple method, the use of conditional keys can lead to a significant increase in recall -with a negligible impact on precision.
Conclusion We have presented VICKEY, an approach to mine conditional keys on knowledge bases. Our approach overcomes the complexity of the search space by restricting it to the non-keys found by SAKey  [27] , and by pruning it smartly. This allows VICKEY to mine minimal conditional keys in datasets of up to 1. 8M triples. In an extrinsic evaluation, we have shown that conditional keys can increase the recall of entity linking by up to 34 percentage points. As future work we plan to extend VICKEY by exploiting ontological classes and axioms, to discover more expressive conditional keys. The VICKEY system, as well as the datasets and evaluations, are available at https://github. com/lgalarra/vickey.
(Conditional key) A conditional key for a dataset D is a non-empty set of conditions {cd 1 ,. , cd n } and a non-empty set of properties {p 1 ,. , p m } of D (disjoint from the properties in the conditions), such that: ∀x, y, u1,. , um i=1. n (cdi(x) ∧ cdi(y)) ∧ i=1. m (pi(x, ui) ∧ pi(y, ui)) ⇒ x = y Definition 4.
ConstructGraphs Input: dataset D, min. support θ, set of non-keys N Output: set of conditional key graphs G 1 G ← ∅ 2 for p ∈ N ∈N N do 3 for a ∈ I ∪ L such that ∃x : p(x, a) ∈ D do 4 if number of x with p(x, a) is at least θ then 5.
MineGraphInput: dataset D, minimum support θ, conditional key graph P k , P c , cond , G = (V, E) , set of conditional keys found so far CKs Output: modified CKs 1 for level = 1 to maxv∈V |v. p| do 2 for cand ∈ V where |cand. p| = level do 3 if cand. explore then 4 ck ← cond , cand. p 5 isMinimal ← ck is a minimal key w. r. t CKs 6 if isMinimal ∧ support(ck, D) ≥ θ then isMinimal ∨ support(ck, D) < θ then 9 cand. explore ← false 10 for child ∈ descendants(cand, G) do 11 child. explore ← false 12 return CKs.
newConditions Input: size of condition set size set of conditional key graphs G support threshold θ, dataset D Output: modified set of conditional key graphs G 1 G1 ← {g ∈ G : |g. cond | = 1} 2 Gsize ← {g ∈ G : |g. cond | = size} 3 for g ∈ Gsize do ← clone(g) 5 for v ∈ g. V where |g. V. p| = 1 do v ∈ g. descendants(v) do v. explore ← false 9 for g1 ∈ G1 where g1. P c = v. p do 10 if support(g. cond ∧ g1. cond , D) ≥ θ then G ← G ∪ merge(g, g1).
Definition 3. 3 (Conditional key) A conditional key for a dataset D is a non-empty set of conditions {cd 1 ,. , cd n } and a non-empty set of properties {p 1 ,. , p m } of D (disjoint from the properties in the conditions), such that: ∀x, y, u1,. , um i=1. n (cdi(x) ∧ cdi(y)) ∧ i=1. m (pi(x, ui) ∧ pi(y, ui)) ⇒ x = y Definition 4.
Algorithm 1 : 1 ConstructGraphs Input: dataset D, min. support θ, set of non-keys N Output: set of conditional key graphs G 1 G ← ∅ 2 for p ∈ N ∈N N do 3 for a ∈ I ∪ L such that ∃x : p(x, a) ∈ D do 4 if number of x with p(x, a) is at least θ then 5.
Algorithm 3 : 7 CKs = CKs ∪ {ck} 8 if 378 MineGraphInput: dataset D, minimum support θ, conditional key graph P k , P c , cond , G = (V, E) , set of conditional keys found so far CKs Output: modified CKs 1 for level = 1 to maxv∈V |v. p| do 2 for cand ∈ V where |cand. p| = level do 3 if cand. explore then 4 ck ← cond , cand. p 5 isMinimal ← ck is a minimal key w. r. t CKs 6 if isMinimal ∧ support(ck, D) ≥ θ then isMinimal ∨ support(ck, D) < θ then 9 cand. explore ← false 10 for child ∈ descendants(cand, G) do 11 child. explore ← false 12 return CKs.
Algorithm 4 : 4 g 6 if v. explore then 7 v. explore ← false 8 for 44678 newConditions Input: size of condition set size set of conditional key graphs G support threshold θ, dataset D Output: modified set of conditional key graphs G 1 G1 ← {g ∈ G : |g. cond | = 1} 2 Gsize ← {g ∈ G : |g. cond | = size} 3 for g ∈ Gsize do ← clone(g) 5 for v ∈ g. V where |g. V. p| = 1 do v ∈ g. descendants(v) do v. explore ← false 9 for g1 ∈ G1 where g1. P c = v. p do 10 if support(g. cond ∧ g1. cond , D) ≥ θ then G ← G ∪ merge(g, g1).
Since 2008-2009, our experimental design has comprised two successive writing workshops which promote rewriting: a creative writing workshop and a research writing workshop, in which certain elements of the recreational workshop model have been adapted. 4 In the whole program, students engage in reflexive revision of their productions, in both senses of the term (process and product resulting from the process), which is facilitated by the workshop situation and further backed up by the analysis of theoretical material and by keeping a writing diary. Lastly, students are requested to produce a mini-dissertation (henceforth "dissertation"). Figure  14. 1 depicts the overall design dynamics. The dissertation, which is built around the analysis of the creative writ-ing experiment and, if applicable, of the research writing workshop, rests on personal data (the successive drafts of the creative writing texts and, when appropriate, passages from the dissertation as well as excerpts, freely chosen by the students themselves, from the writing diary).
Survey Through an online questionnaire, basic programmatic, institutional, publication, and intellectual network data were initially collected from Argentina, Chile, Colombia and Mexico; then later from Brazil, Puerto Rico, and Venezuela; and finally through open invitation to all Latin American countries. The survey was disseminated through snowball techniques, described below. Through these procedures we have invited 321 participants and received 118 responses. The number of invitations and responses by country are listed in Table  15. 1. We have now opened up the survey to voluntary participation through our project website in order to keep track of unfolding developments, but this current study is based on data collected only by invitation, with collection finishing August 31, 2013. The online survey, designed and piloted in Spanish during summer 2012, is organized in four sections and contains 9 principal questions with open and closed answers.
A global multiproxy database for temperature reconstructions of the Common Era PAGES2k Consortium # Reproducible climate reconstructions of the Common Era (1 CE to present) are key to placing industrial-era warming into the context of natural climatic variability. Here we present a community-sourced database of temperature-sensitive proxy records from the PAGES2k initiative. The database gathers 692 records from 648 locations, including all continental regions and major ocean basins. The records are from trees, ice, sediment, corals, speleothems, documentary evidence, and other archives. They range in length from 50 to 2000 years, with a median of 547 years, while temporal resolution ranges from biweekly to centennial. Nearly half of the proxy time series are significantly correlated with HadCRUT4.
Background & Summary Since the pioneering work of D'Arrigo and Jacoby  [1] [2] [3]  , as well as Mann et al. 4, 5  , temperature reconstructions of the Common Era have become a key component of climate assessments  [6] [7] [8] [9]. Such reconstructions depend strongly on the composition of the underlying network of climate proxies  10  , and it is therefore critical for the climate community to have access to a community-vetted, quality-controlled database of temperature-sensitive records stored in a self-describing format. The Past Global Changes (PAGES) 2k consortium, a self-organized, international group of experts, recently assembled such a database, and used it to reconstruct surface temperature over continental-scale regions  11  (hereafter, 'PAGES2k-2013'). This data descriptor presents version 2.