dataesr/scientific-paragraphs-categorization huggingface dataset:
Conclusion A new code named FESTIM based on MRE model has been developed and includes extrinsic traps creation, transient heat transfer and 2/3D multi-material simulations. Validation and verification have been performed using a well-known TPD experiment from literature, the Method of Manufactured Solutions and a well-known analytical solution. It has been shown that FESTIM can reliably reproduce experimental results and that its governing equations were solved correctly. FESTIM offers the ability to simulate large problems quicker thus opening up the possibility of performing reactor size simulations of HIs migration. FESTIM has then been used to simulate HIs behaviour in monoblocks during a relevant plasma scenario. At this extent, heat transfers have been simulated at the same time. 2D simulations were needed as edge effects in the resulting fields were significant.
Acknowledgements We would like to express our gratitude to  G. De Temmerman  from  ITER Organization  with whom we had many scientific exchanges about the contents of this paper. This work has been carried out within the framework of the  EUROfusion Consortium  and has received funding from the  Euratom   Research and Training Programme   2014-2018  and  2019-2020  under grant agreement No  633053. The views and opinions expressed herein do not necessarily reflect those of the  European Commission.
birth date". If the rule is taken as an ontological rule, then it would just infer that Spinoza has some birth date. If the rule is taken as a constraint, in contrast, the KB would be considered incorrect. Constraints are thus similar in spirit to database integrity constraints. In practice, constraints often have exceptions. Therefore, it is useful to allow data that does not respect them (in Wikidata, e. g. , constraint violations are simply flagged). Nonetheless, by design, most of the constraint violations are not exceptions but actual errors and proposing to repair them is a good starting point when it comes to improving KB quality. In this paper, we aim at learning how to repair constraint violations. Our goal is to help a KB editor by suggesting how to clean the data locally (providing a solution to a particular constraint violation) or globally (providing rules that can be automatically applied to all constraint violations of a given form once validated by the editor).
To do that, we take advantage of the edit history of the KB. We use it to mine correction rules that express how different kinds of constraint violations are usually solved. To the best of our knowledge, this is the first work that builds on past users corrections in order to infer possible new ones. We validate our framework experimentally on Wikidata, for which the whole edit history of more than 700 millions edits is available. Our experiments show substantial improvements over baselines. More concretely, our contributions are as follows: • a formal definition of the problem of correction rule mining, • a dataset of more than 67M past corrections for ten different kinds of Wikidata constraints (13k constraints in total),  1 • a correction rule mining algorithm, together with an implementation for Wikidata, CorHist, 2  • a suggestion tool for users to correct data based on our mined correction rules, 3  • an experimental evaluation based both on the prediction of the corrections in the history and on user validation of the suggested local corrections.
facts are not necessarily false. They thus classically have only "correctness" constraints, such as disjointness or functionality axioms (corresponding to special cases of denial constraints and equality generating dependencies in databases). To express also completeness constraints, several works propose to use description logics, with varying semantics  [28, 37]. Another possibility is to use queries that should or should not hold as constraints (see e. g. ,  [24]  for methods for writing constraint queries in SPARQL). Other approaches define constraint languages to specify conditions for RDF graph  [9]  validation, such as SHACL  [22]  or ShEx  [8]. It has been argued in  [30]  that description logics under the closed world assumption are also suitable for constraint checking in RDF, which can then be implemented with SPARQL queries.
Again other approaches  [1]  use crowdsourcing to detect Linked Data quality issues. We refer the reader to Section 7. 2 of  [1]  for a recent overview of approaches for data quality assessment. Our method also exploits KB constraints. However, it differs from the above in that it learns the corrections automatically from the edit history. It thus taps a source of knowledge that has so far not been exploited. Rule learning. Mining logical rules by finding correlations in a dataset is a well-established research topic. In particular, learning patterns in the data can be used for completing KBs  [14, 36]. An algorithm for learning conjunctive patterns from a KB enriched with a set of rules is described in  [20]. Methods similar to association rule mining have also been used for induction of new ontological rules from a KB  [33].
PRELIMINARIES In this work, we use description logics (DL)  [4]  as KB language and as constraint language, because they are the foundation of the Semantic Web standard OWL  [16]. Syntax. We assume a set N C of concept names (unary predicates, also called classes), a set N R of role names (binary predicates, also called properties), and a set N I of individuals (also called constants). An ABox (dataset) is a set of concept or role assertions of the form A(a) or R(a, b), where A ∈ N C , R ∈ N R , a, b ∈ N I. A TBox (ontology) is a set of axioms whose form depends on the DL L in question, and expresses relationships between concepts and roles (e. g. , concept or role hierarchies, role domains and ranges. ). A knowledge base (KB) K = T ∪ A is the union of an ABox A and a TBox T. In this work, we assume that T is a flat QL TBox  [23] , i.
Extraction of the Relevant Past Corrections Algorithm 1 constructs the set of relevant past corrections from the KB history. It consists of three main steps. First, it constructs patterns to spot KB modifications that could be part of a relevant past correction. Then it uses these patterns to extract atomic modifications that solved some violation in the past. Finally, the relevant past corrections are obtained by pruning those that have been reversed. T p )} if Γ is a completeness constraint then Patterns(Γ) ∪= ({(A(ì x), _) | A(ì x) ∈ h ′ (ì x), h ′ (ì x) ∈ rewrite(h(ì x), T p )}) // Extract past corrections for 0 ≤ i ≤ p -1 do if (M + i , M - i ) such that K i+1 = (K i ∪ M + i ) \ M - i matches some pattern in Patterns(Γ) then PCDataset ∪= {⟨(M + i , M - i ), Γ(ì a), V, i⟩ | V ∈ Violations(K i , Γ(ì a)) \ Violations(K i+1 , Γ(ì a))} // Remove reversed past corrections for ⟨(M + i , M - i ), Γ(ì a), V, i⟩ ∈ PCDataset do if M + i ⊈ K p or M - i ∩ K p ∅ then PCDataset \= {⟨(M + i , M - i ), Γ(ì a), V, i⟩} Let us explain our algorithm with our running example.
If so, the modification between K i and K i+1 is a solution that solved these violations in K i. In the example we would have found the violation {⟨Zeus, hasGender, masculine⟩} of Γ 0 (masculine) in K 100 , which is not in K 101. So we would have extracted that (⟨Zeus, hasGender, male⟩, ⟨Zeus, hasGender, masculine⟩) is a solution that solved the violation {⟨Zeus, hasGender, masculine⟩} of Γ 0 (masculine) in K 100. We store this information as a tuple in the relevant past corrections dataset (the PCDataset), as shown in Table 2. Finding the constraint instances violated in K i or K i+1 is done via CQ answering (Proposition 1), and computing their violations amounts to computing BCQ justifications (Proposition 2). The final step of the algorithm removes corrections that have been reversed. The result is thus the set of relevant past corrections.
Correction Rule Mining Correction rules. The previous algorithm has given us a list of relevant past corrections (the PCDataset, exemplified in Table  2 ). We now present our approach to mine correction rules from this dataset and the KB history. Definition 8 (Correction rule): A correction rule is of the form r := [Γ(ì x)] : E(ì x, ì y, ì z) → (M + (ì x, ì y), M -(ì x, ì y)), where • Γ(ì x) is a constraint that can be partially instantiated, i. e. , some of its variables have been replaced by constants, • (M + (ì x, ì y), M -(ì x, ì y) ) is a pair of sets of at most one triple, • E(ì x, ì y, ì z) is a set of atoms called the context of the violation such that M -(ì x, ì y) ⊆ E(ì x, ì y, ì z), and both (M + (ì x, ì y), M -(ì x, ì y)) and E(ì x, ì y, ì z) are built from N C ∪ N R ∪ {rdf:type} ∪ N I ∪ ì x ∪ ì y ∪ ì z.
→ (Human(x), ∅) The context of the second rule says that if x is the mother of a human, then x must also be a human. The rule obtained by replacing Human by Animal would express how to solve a violation of Γ 2 in the context where y is an animal. ◁ Mining correction rules. We mine correction rules with Algorithm 2. This algorithm is an adaptation of the algorithm in  [13, 14]  to our context, where we learn rules not from a KB but from the PCDataset and the KB history. We first adapt the definitions of the confidence and support from  [13, 14]  to our case. The support of the body of a correction rule r for a constraint Γ is the number of violations of Γ stored in the PCDataset that could have been corrected by applying r. Such violations are associated with an instance Γ(ì a) of the partially instantiated Γ(ì x) that appears in r and with an index i such that K i |= ∃ì zE(ì a, ì b, ì z) for some ì b.
These two conditions imply that r could be applied to the KB K i. Moreover, we need to check that the result of applying r to K i actually gives a solution to V. BSup = {V | ⟨_, Γ(ì a), V, i⟩ ∈ PCDataset, ∃ ì b K i |= ∃ì zE(ì a, ì b, ì z) and the result of the application of r to K i is a solution to V}. The support of the rule r measures when the past correction is exactly the result of the application of the rule in the cases where it could be applied. Formally, sup rule (r ) = |RSup|, where RSup = {V | ⟨(M + (ì a, ì b), M -(ì a, ì b)), Γ(ì a), V, i⟩ ∈ PCDataset, and K i |= ∃ì zE(ì a, ì b, ì z)}. Finally, the confidence of a correction rule r is conf (r ) = sup rule (r ) sup bod (r ).
Algorithm 2 Correction rule mining Input: PCDataset, (K i ) 0≤i ≤p , minsup, minconf , θ Output: correction rules // Generate basic rules BasicR := ∅ for all ⟨(M + (ì a, ì b), M -(ì a, ì b)), Γ(ì a), V, i⟩ ∈ PCDataset do r 0 := [Γ(ì a)] : M -(ì a, ì b) → (M + (ì a, ì b), M -(ì a, ì b)) BasicR ∪= {σ (r 0 ) | C ⊆ ì a ∪ ì b, σ : C ↣ Var, sup rule (σ (r 0 )) ≥ minsup, conf (σ (r 0 )) ≥ minconf } // Refine the context part of the rules q := [], q. enqueueAll(BasicR) while q is not empty do r := q. dequeue() Output r for all operators op do for all r ′ ∈ op(r ) do if sup rule (r ′ ) ≥ minsup and conf (r ′ ) ≥ conf (r ) + θ then q. enqueue(r ′ ) Algorithm 2 shows our mining algorithm. It takes as input the PCDataset computed by Algorithm 1, the KB history, a minimum support threshold, a minimum confidence threshold, and a regularization threshold θ.
These thresholds are chosen empirically (see Section 7. 3). The algorithm produces correction rules (Definition 8). For this purpose, it first generates a trivial rule r 0 for each entry of the PCDataset. This rule has as context simply the deletion part of the constraint past correction. This trivial rule is then transformed into several more general rules, which we call basic rules, each of which is obtained from r 0 by replacing some of the constants by variables. Formally, the algorithm uses all partial substitutions σ from constants to distinct fresh variables. It retains only those basic rules that meet the minimum support and confidence thresholds. In the second step, the algorithm incrementally refines each rule by building up its context part E(ì x, ì y, ì z). This works similarly to the mining algorithm of  [14] : Each refinement step adds one atom built from the KB concept and role names and the variables and constants that appear in the rule, plus at most one fresh variable.
Wikidata Wikidata is a generalist collaborative knowledge base. The project started in 2012, and as of July 2018, it has collected more than 500M statements about 50M entities. The data about each entity is stored in a versioned JSON blob, and there are more than 700M revisions. Wikidata encodes facts not in plain RDF triples but in a reified representation, in which each main ⟨s, p, o⟩ triple can be annotated with qualifiers and provenance information  [38]. Wikidata knows the property instanceOf which is similar to rdf:type. It does not have a formally defined TBox, but knows properties such as subClassOf, subPropertyOf, and inverseOf. However, only the property subClassOf is used to flag the constraint violations. Therefore, we use only this property in our TBox, which thus contains simple concept inclusions.
Dataset Construction We stored the RDF version  [10, 18]  of the Wikidata edit history in an RDF quad store. We used named graphs for the global state of Wikidata after each revision, and for the triple additions and deletions. Our dataset stores 390M annotated triples about 49M items extracted from the July 1st, 2018 full database dump. We extracted the relevant past corrections as explained in Section 6. 1. Wikidata revisions do not correspond exactly to atomic modifications in our sense. For example, Wikidata bots are able to change multiple unrelated facts about the same entity at the same Table  3 : Wikidata property constraints. R is the property for which the constraint is given. A constraint has several lines when it uses a property whose set of values may be specified or not. ♯constr.
Wikidata users also sometimes prefer to delete a statement then add another one with the same property instead of directly modifying the value, in order to clear the existing qualifiers and references. Therefore, we artificially created a replacement modification for every deletion with a neighboring addition by the same user, which shares at least two components of the triple (analogously for additions). For example, if the correction seed is the deletion of ⟨Zeus, hasGender, masculine⟩, and if this revision or a neighboring one adds ⟨Zeus, hasGender, male⟩, then we consider this a replacement. However, if the same revision added the triple ⟨Zeus, hasMother, Rhea⟩, then we would not consider this a replacement, because it does not share two components with the first one. Since the TBox consists of simple concept inclusions and the constraint bodies contain only roles, the deletion patterns for correction seeds correspond directly to the atoms of the constraint body.
We ignore these cases, which are marginal: they concern less than 6% of the Type constraints. The same goes analogously for Value type. 5 Inverse and Symetric are two distinct kinds of constraints in Wikidata but we treat them together since Symetric is actually a special case of Inverse. for each constraint. In practice, it affects only the most frequent 0. 9% of Type, 2% of Value type, 0. 5% of Item requires statement, and 3% of Value requires statement constraints.
Mining Rules The output of our method is a set of correction rules that form a program (Section 6. 2). To evaluate such a program, we apply it to each of the constraint violations stored in the PCDataset, using the associated stage of the KB to evaluate the part of the context which is not the deletion part of the correction. Then we check whether the correction we compute is exactly the same as the one associated to the constraint violation in the PCDataset. The precision p of the program is given by the fraction of the corrections computed by the program that are actually the same as those that have been applied. The recall r of the program is the fraction of the constraint violations stored in PCDataset for which the program gives some correction. The F1 score is F 1 = 2 p •r p+r. CorHist mines rules as explained in Section 6.
Evaluation against the Test Set Table  5  presents the results of the evaluation of the mined programs against the test set. We computed both the micro and macro average of the precision, recall and F1 score per kind of constraint. The micro average aggregates over the whole set of relevant past corrections for the given kind of constraint, whereas the macro average computes the scores for each constraint of this given kind, and then computes the average. Both numbers are important: The micro average gives more weight to correction rules that fix many violations. It thus measures the overall impact of the correction rules on the dataset. However, if few rules had a large impact, then it would be easier to formulate these rules by hand. Our method, in contrast, can also find rules that by themselves solve less violations, but together contribute a large mass of corrections.
User Evaluation To see whether our corrections are accepted by the community, we designed a user study. We created a tool that suggests our corrections to Wikidata users for validation (available at https://tools. wmflabs. org/wikidata-game/distributed/#game=43). The user can choose a constraint type, and the tool then suggests corrections for random violations of constraints of this type (Figure  1 ). The violations for which corrections are suggested are provided by query. wikidata. org, which limits their number for performance reasons. For each proposed correction, the user has to choose between three options: apply the proposed correction to Wikidata, tag it as wrong, or get another correction to review. We ran the experiment for 3 months and 47 Wikidata users participated. Table  6  presents the results.
Another issue is the quality of the constraints, which in Wikidata are sometimes questionable or difficult to understand (e. g. , an incomplete set of possible types or values for completeness or One-of constraints). However, even lower approval scores do not mean that our approach would be useless: Psychological research  [12]  shows that people find it much easier to choose from given options than to come up with an answer by themselves. The actual time needed to come up with an answer may vary, but if it takes just 3 times longer to come up with an answer than to accept or reject our proposed correction, then achieving a precision of 40% is already useful: If we have a precision of 40%, and if a free-form answer takes time t, then the expected answer time with our tool is 40%× 1  3 ×t +60%× 4 3 ×t < t.
CONCLUSION AND FUTURE WORK We have introduced the problem of learning how to fix constraint violations from a KB history. We have also presented a method based on rule mining to this end. Our experimental evaluation on Wikidata shows significant improvement over baselines. Our tool is live on Wikidata and has already allowed users to correct more than 23k constraint violations. While our evaluation focused on Wikidata for which the whole edit history was available, we believe that our method can be applied in other settings, for example using edits done during the partial cleaning of an automatically extracted KB. For future work, it would be interesting to evaluate the impact of parameters such as the size of the context part of the correction rule in terms of rule quality. We also plan to extend the learning dataset with external knowledge (such as other KBs), or with information extracted from other sources (for instance from Wikipedia).
Construction of PCDataset Input: set of constraints C, current TBox T p , history (K i ) 0≤i ≤p Output: set of relevant past corrections PCDataset // Construct correction seed patterns for all Γ ∈ C such that Γ(ì x) : b(ì x) → h(ì x) do Patterns(Γ) := {(_, A(ì x))|A(ì x)∈b ′ (ì x), b ′ (ì x)∈rewrite(b(ì x),.
For example, consider the case where PCDataset contains both ⟨(∅, R(a, b))), Γ(a), {R(a, b), A(a)}, i⟩ and ⟨(∅, R(a, c))), Γ(a), {R(a, c), A(a)}, j⟩ for Γ(a) : ∃xR(a, x) ∧ A(a) → false. Both violations count for the support of the body of [Γ(a)] : R(a, x) → (∅, R(a, x)) but only the second one counts for the support of the body of [Γ(a)] : R(a, c) → (∅, R(a, c)), even in the case where K i |= R(a, c). Formally, sup bod (r ) = |BSup| where.
Algorithm 1 1 Construction of PCDataset Input: set of constraints C, current TBox T p , history (K i ) 0≤i ≤p Output: set of relevant past corrections PCDataset // Construct correction seed patterns for all Γ ∈ C such that Γ(ì x) : b(ì x) → h(ì x) do Patterns(Γ) := {(_, A(ì x))|A(ì x)∈b ′ (ì x), b ′ (ì x)∈rewrite(b(ì x),.
However, this is achieved by superimposing a specific DNA geometry on the radiation tracks computed in water. Some well-known examples of MCTS codes in continuous development are GEANT4-DNA 5,6 , KURBUC 7,8 and PARTRAC 9,10. The latter is a state-of-the-art MCTS code that also considers a DNA double strand break repair model via the non-homologous end-joining pathway. The main differences between the aforementioned tools and TILDA-V, the MCTS code used in this paper, is that TILDA-V largely relies on differential and total cross sections computed ab initio within a quantum mechanical treatment of interactions and applying a molecular description of both water and DNA, as explained hereafter. For a comprehensive review on the subject of radiation track-structure and the existing MCTS codes the reader is referred to the works of Nikjoo et al.
theory In this section we will discuss the way in which biological media are modeled within TILDA-V and we will summarize the theoretical and semi-empirical models used to describe the different interactions of protons and neutral hydrogen atoms impinging on water and DNA molecules. As mentioned before, the tracking of the secondary electrons is taken into account by EPOTRAN, a MCTS code coupled to TILDA-V, which has been described elsewhere  17. Therefore we will restrict the discussion to the interactions induced by the primary particles. the target description. Regarding the biomolecular targets studied, TILDA-V is based on a cross section database, which refers to isolated molecules in vapor state. In this context, the present work clearly differs from existing studies on condensed matter (water or DNA), where the energy-loss function of realistic biological components, which is extracted from experimental data and interpolated for several energies to cover the paucity of measurements, is used to compute the inelastic cross sections, i.
The different ground state atomic orbitals are described using Roothaan-Hartree-Fock atomic wave functions  29. DNA. In our previous work  30  , we have proposed an ab initio approach to express the molecular wave function of each DNA component with the GAUSSIAN09 software  31. Gaussian 09 is a general purpose computational chemistry software, which optimizes by variational principle, i. e. Hartree-Fock (HF) method, the ground state of atoms and molecules. Thus, DNA components ground states have been obtained by a Restricted Hartree-Fock (RHF) optimization using the 3-21G basis set. Each target is described via N molecular subshell wave functions with N = 35, 29, 39, 33 and 48 molecular orbitals (MOs) for adenine, cytosine, guanine, thymine and sugar-phosphate backbone unit, respectively. Thus, the molecular subshell wave function is expressed as a linear combination of atomic wave functions corresponding to the different atomic components, namely, H 1s , C 1s , C 2s , C 2p , N 1s , N 2s , N 2p , O 1s , O 2s , O 2s , P 1s , P 2s , P 3s , P 3p , and P 3p.