dataesr/scientific-paragraphs-categorization huggingface dataset:
Decision Models The Dopler approach  [36]  allows defining decision models together with the reusable assets of a product line (e. g. , reusable software components) and mappings between the assets and the decisions. A domainspecific meta-model defines the possible types of assets, their attributes, and dependencies. In addition to hierarchical dependencies among decisions, other dependencies (comparable to cross-tree constraints) are modeled using rules of the form if condition then action  [36]. The Dopler tool suite  [36]  uses a Java-based Rule Language (JRL) and execution engine as a back-end for evaluating the rules defined in models. For a description of diverse application examples refer to  [36, 47]. The implementation of the Dopler decision modeling approach to provide Invar configuration services was straightforward, as the Dopler approach itself was designed to be used for questionnaire-based product configuration  [37].
For Dopler we do not delegate any order options to the Invar ordering component, as Dopler models have been created keeping in mind a configuration process and has its own mechanisms  [36]  to define the order as described above. Feedback: In Dopler, making decisions leads to the inclusion and/or parametrization of assets related to the decisions. For example, selecting the document management solution by answering a decision question leads to the inclusion of the respective software component(s) implementing document management. Answering a lower-level decision (e. g. , on which type of scanner is required) parametrizes the document management software component. Feedback to the user of the Invar service implementation for Dopler is thus given by presenting her with the assets that are required for the product currently being configured.
We conducted the following steps to set up a configuration application in Invar for this scenario. 1. As in the previous scenario, web services capable of reading feature models, decision models, and OVM models were registered to Invar. 2. The configuration application was defined by referencing three models. However, not all three models are included in the configuration process by default. The supplier models are embedded into the configuration process using conditional inclusion actions defined in IMDI packets. The start model is defined to be the ERP vendor decision model. 3. Inter-model dependency links were defined using conditional inclusion actions: if vendor. D3. isSelected() then DatabaseArchive. includeModel() and if vendor. D3. isDeselected() then FileSystemArchive. includeModel().
The Android permissions system Android is based on Linux, thus it provides a privilege-separated access system 6. This is, each application runs with a different identity (user/group ID). Different parts are also separated, in doing so separating applications from each other and from the operating system itself. A finer-grained security access is also provided through a "permission" mechanism that enforces restrictions on the specific operations that a particular process can perform. Table  6  shows the set of Android permissions related to the hardware features it requires. We will be using these relations in between features and permissions to enable the configuration of valid products according to certain user-selected security aspects.
Discussion Without Invar, considerable manual efforts would have been required to integrate the different models to support product configuration in a multi product line environment. More specifically, instead of just linking existing models using Invar IMDI links, modelers would need to either create one large model using one particular approach that integrates all the other models or configure options provided by each model and check manually which dependencies between the different models need to be taken into account. While the first strategy would be sufficient for smaller examples, for large multi product line or software ecosystem settings, it will not be feasible. The second strategy would require the configurers to understand all the different modeling approaches, which is also not feasible.
While we are confident that using Invar is beneficial in the described configuration scenarios and will outperform manual configuration, conducting experiments with practitioners is an important part of our future work to compare a manual configuration based on multiple models with a configuration process automated by Invar. We evaluated the performance of the tools (i. e. , that is of different model enactment strategies) using randomly generated models. The validity of the results therefore also depends on the random model generators in use. However, we used BeTTy  [55]  to generate random models. BeTTy provides a welltested implementation for the algorithm presented and evaluated by Thüm et al. [56]. We conclude that while several threats exist, our results are promising considering that we have been able to encode variability of ecosystems in different contexts such as the Android permissions system or an ERP system.
[15]  have presented an approach to integrate feature models and orthogonal variability models, by differentiating between product variability and software variability. The Invar approach is different as we focus on variability of different subsystems, rather than different abstractions of the same subsystem. Coordination during product derivation. Czarnecki et al. [33]  present an approach supporting the staged configuration of features models. Focusing on large-scale embedded systems Reiser et al. [65]  propose product sets and configuration links to define dependencies between different feature models at the time of their selection. Hubaux et al. [66]  propose feature configuration workflows as a new formalism for supporting configuration of large-scale systems. They also propose a technique to specify concerns in feature diagrams and to automatically build concern-specific configuration views  [67].
The issue of multi-level configuration is also addressed by Rabiser et al. [18]  who demonstrate how decision models can be used to support the configuration of a complex system across multiple levels of software vendor, customers and end users. Czarnecki et al. [68]  discuss the customization in application engineering over multiple levels. Invar focuses on presenting the configuration options provided by multiple models created with different heterogeneous modeling approaches to the end user in an integrated fashion. Software integration. Our work is also related to integrating complex software solutions and tools. In the area of EAI (enterprise application integration) Hohpe and Woolf  [69]  present fundamental patterns for integrating heterogeneous and asynchronous systems. More recently, this issue has also been addressed in the area of software and systems engineering.
Standardization efforts. There is an ongoing effort to standardize variability modeling based on the common variability modeling language (CVL)  [2] , a generic language to define variability. The goal of CVL standardization is to create a new standard notation. In contrast, the goal of Invar is to integrate existing notations, rather than defining a new one. Invar could be extended to use CVL and other approaches side-by-side. Some CVL concepts like configurable units (consisting of a variability interface) and their composition with other configurable units can be compared to the composition of different configuration services in Invar.
We showed the flexibility and feasibility of the approach and its implementation by applying it to three different variability modeling approaches and by showing that we are able to integrate them in the context of an example ERP system and in the context of the Android permissions system. We also provided initial evidence on the performance of the approach, more specifically, its different model enactment strategies, during configuration. We can conclude after this research that, i) is important to enable the support for different enactment strategies to scale in terms of CPU related costs; ii) the use of IMDI is a mandatory aspect when configuring software ecosystems such as the Android ecosystem; iii) is important to offer a common facade to configure software ecosystems as complex as Android where we see a misuse of the permissions system; iv) different users use to speak different languages, this is, we need to support a diversity of modeling languages to then better communicate and integrate the work of different practitioners.
Material A version of Invar is hosted in http://invar. lero. ie. Please note, that the software is distributed with a closed license that does not allow redistribution. However, some of the plug-ins linked in Invar are open-source and can be found in http://github. com/invar-fama-pluggins. COPAS (TIC-1867) project. Also, we would like to express special thanks to Dominik Seichter for his previous contributions to this research.
Acknowledgements This work was supported, in part, by  Science Foundation Ireland  grants  03/CE2/I303 1  and  10/CE/I1855  to Lero; by the  Christian Doppler Forschungsgesellschaft (Austria) ,  Siemens VAI Metals Technologies , and  Siemens Corporate Technology ; by the  European Commission (FEDER) , by the  Spanish government  under TAPAS ( TIN2012-32273 ) project and the  Andalusian government under Talentia program  and the.
Background: Numerous simulation tools based on specific assumptions have been proposed to simulate populations. Here we present a simulation tool named DHOEM (densification of haplotypes by loess regression and maximum likelihood) which is free from population assumptions and simulates new markers in real SNP marker data. The main objective of DHOEM is to generate a new population, which incorporates real and simulated SNP by statistical learning from an initial population, which match the realized features of the latter. Results: To demonstrate DHOEM's abilities, we used a sample of 704 haplotypes for 12 chromosomes with 8336 SNP from a synthetic population, used for breeding upland rice in Latin America. The distributions of allele frequencies, pairwise SNP LD coefficients and data structures, before and after marker densification of the associated marker data set, were shown to be in relatively good agreement at moderate degrees of marker densification.
Nevertheless the number of SNP markers simulated with a re-sampling approach is usually limited to that of a reference panel  [3] , in contrast to forward or backward approaches where theoretically no such limitation exists. What is more, reference panels are not available for all species, and the individuals included in these panels have to be representative of the population being studied, otherwise the realized features of the simulated population may deviate substantially from those of the target population under study. Here we present a new simulation software named DHOEM (which stands for densification of haplotypes by loess regression and maximum likelihood) that does not belong to the three aforementioned approaches. DHOEM is a statistical procedure that simulates new markers, according to statistical modeling of local data characteristics, in real SNP marker data sets.
The main objective of DHOEM is to increase the marker density in a marker data set for simulation studies. For each chromosome in a marker data set, the statistical procedure defined in DHOEM models the probability distribution generating the allele frequencies and the relation between LD and physical distance between consecutive markers. To some extent, DHOEM resembles imputation methods used to increase marker density in an existing marker data set based on a reference panel. However, DHOEM does not require a reference panel since it simulates new markers only according to a statistical procedure. In addition, unlike DHOEM, imputation methods are not intrinsically simulation softwares. Yet, they can be another strategy for increasing marker density for simulation studies, although the concordance of the imputed markers, with respect to allele frequencies and LD in the marker data set, will depend on the available reference panel  [17].
Data sets The marker data set used was composed of 704 haplotypes with 8,336 SNP for 12 chromosomes. It came from a synthetic population used for breeding upland rice in Latin America  [23]. The data set had no monomorphic markers and 7,879 SNP had a minor allele frequency (MAF) ≥ 1 %. A reference panel for this population, composed of 334 haplotypes with 16,444 markers (6,717 SNP + 9,727 DArT) as described in  [24] , was used for imputation of the marker data set with BEAGLE 4. 0. All 16,444 markers in the reference panel had a MAF ≥ 1 %. The reference panel and the marker data set had 4,015 SNP markers in common. Two individuals in the reference panel, out of a total of 167, shared recent common ancestry with the 352 individuals associated with the marker data set  [23, 24]. Imputation with BEAGLE 4.
Simulation with DHOEM The following single line command was used to call DHOEM for the densification of the marker data set to at least 16,444 SNP with MAF ≥ 1 %. The marker data set is provided with the simulation software and is composed of the three. txt input files in the command. Densified_marker_data=DHOEM( User_Name, "Haplotype_file. txt", "Physical_map_file. txt", "Physical_map_centromeres_file. txt", Average_length_Kb_centromeres_low_SNP_coverage=1000, Nb_chromosomes=12, MAF_limit_for_all_SNP=0. 01, Nb_more_less_SNP_per_chromo_per_run=5,.
New_minimum_maximum_nb_SNP_specified=16444 ) The parameter User_Name in the command is the current user name in any Windows environment. The second parameter corresponds to the average length (in Kb) of the regions around centromeres with low SNP coverage. The three last parameters control the MAF limit, the number of SNP added to (or removed from) the marker data set, at each run of the program, and the desired minimum (or maximum) marker density after densification (or loosening) of the marker data set. The MAF limit parameter is not involved in the statistical procedure defined in DHOEM. This parameter only assures that the MAF of the output markers are greater or equal to the defined limit. The computation time for this command is 3 to 4 minutes on a personnal computer with 4 cores (16 GB RAM).
Description and relevance of the data generated by BEAGLE 4. 0 and DHOEM The imputed marker data set obtained with BEAGLE 4. 0 had 16,444 markers. The reference panel and the marker data set had only 4,015 SNP markers in common. Hence only 4,015 SNP markers from the data set were found in the imputed data set since BEAGLE 4. 0 always excludes variants that are absent from the reference panel (see BEAGLE 4. 0 documentation). Only 9,154 out of the 16,444 markers from the imputed marker data set had a MAF ≥ 1 %, and only 10,105 out of the 16,444 had a MAF ≥ 0. 5 %. This makes the imputed data set very impractical for GS simulation studies since the effects of markers with extremely low MAF are difficult to estimate. If markers with a MAF < 1 % are removed from the imputed data set, only 818  (9, 336)  supplementary markers can be obtained with BEAGLE 4.
0, with respect to the marker data set. The high number of markers with very low MAF in the imputed data set might be a result of the poor degree of genetic relationship between the marker data set and the reference panel. Indeed, only two individuals of the reference panel shared recent common ancestry with the 352 individuals associated with the marker data set  [23, 24]. The densified marker data set obtained with DHOEM had 16,459 SNP with a MAF ≥ 1 %. DHOEM allows the user to control the MAF limit and this makes the software very practical for simulation studies. The marker data set and the densified data set had 7,879 SNP in common. The Kullback-Leibler (KL) divergence was used to compare the dissimilarity between the distributions obtained from the marker data set and those obtained from the data generated by the two softwares.
For each chromosome, Fig. 1  shows the KL divergences between allele frequency distributions and LD distributions, obtained before and after imputation and densification with BEA-GLE 4. 0 and DHOEM respectively. The KL divergences were calculated using the entropy package  [25]. In Fig. 1  the KL divergences between the distributions are lower for DHOEM compared to BEAGLE for most chromosomes. This means that the observed distributions obtained from the marker data set are closer to the Fig. 1  KL divergence between allele frequency distributions and LD distributions obtained before and after imputation and densification, with BEAGLE 4. 0 and DHOEM respectively, for chromosomes 1 to 12 distributions obtained from the densified data set than the ones obtained from the imputed data set. This is not surprising since there is a close connection between the minimization of KL divergence and maximum likelihood estimation theory.
For example, Figs. 2  and 3  illustrate the distributions of allele frequencies and pairewise SNP correlations (i. e. LD), for chromosome 1 and 2, before and after densification of the marker data set with DHOEM. The histograms were drawn using the HistogramTools package  [26]. As can be seen in Figs. 2  and 3 , there seems to be a good persistence of the initial data structure in the densified marker data. This persistence was evaluated for each chromosome and is discussed in the following subsection on the limits and advantages of DHOEM.
Limits and advantages of DHOEM The persistence of the initial marker data structure in the densified marker data set was evaluated by performing, for each chromosome, a Mantel test of the correlation between the 2N by 2N haplotype correlation matrices, obtained before and after densification of the marker data set. Persistence was also evaluated for a marker densification of at least 12,000 SNP. For both simulations, the mantel tests were carried out with 10,000 permutations and the p-values obtained for all chromosomes were < 10 -16 which led to the rejection of the null hypothesis of a random correlation. For each chromosome, Fig. 4  shows the correlations between the haplotype correlation matrices at the two marker densification levels. Figure  4  shows a general decrease in the Pearson correlation for all chromosomes, with an increase in marker density from 12,000 to 16,444 SNP.
Conclusions We have presented DHOEM, a simulation tool that exploits real data characteristics to simulate markers that mimic real ones in terms of allele frequencies and LD. DHOEM is a user-friendly tool that allows the user to specify the desired marker density, with a user defined MAF limit, which is produced in a reasonable computation time. Moreover, any method and software, such as those described in  [18]  for example, can be used to phase unphased genotype data as input for DHOEM as long as DHOEM file formats are respected. However, DHOEM is a data dependent procedure and it may therefore suffer from the amount and quality of available data, and the increase in marker density applied to a marker data set. Depending on the objective of the simulation study, a reasonable tradeoff between the amount of initial data and increase in density applied to the latter should therefore be sought.
Objective: The objective of our study was to assess the efficiency and reliability of full-text searches in major medical journals for identifying shared decision making publications. Methods: A full-text search was performed on the websites of 15 high-impact journals in general internal medicine to look up publications of any type from 1996-2011 containing the phrase "shared decision making". The search method was compared with a PubMed search of titles and abstracts only. The full-text search was further validated by requesting all publications from the same time period from the individual journal publishers and searching through the collected dataset.
In contrast to PubMed searches, the website full-text search method relied on journal or publisher websites whose search syntaxes were not explicit. To compare our results with a validation dataset, we contacted the editorial board of each selected journal to request authorization to obtain all published materials since 1996. After receiving their authorization, we collected published material in an electronic version to build a custom-designed database of full-text publications. We designed and launched an automated search script (Python Software, version 2. 6, Python Software Foundation, Wolfeboro Falls, NH, USA). We used the same 6 SDM-related phrases for publication retrieval. This text retrieval method on a locally stored full-text corpus is referred to as downloaded full-text search  [18].
Results Through the website full-text searches, we included 1286 SDM publications out of a total of 229,179 publications in the 15 journals from 1996-2011 (Figure  1 ). Through the PubMed searches, 119 SDM publications were included. Of these publications, only 2 were missed by the website full-text searches; one due to unavailable data on the journal website for years 1996-1997, and while the other was available on the journal website, the browser failed to retrieve it (Figure  2 ). The BMJ published the highest number of SDM publications over 16 years with a minority found through PubMed searches (5. 8%, 16/274) (Table  1 ). The Journal of General Internal Medicine and the JAMA followed with high numbers of SDM publications. Over time, the total number of SDM publications increased but the proportion found through the PubMed searches appeared to decrease from 11.
Principal Results The website full-text searches identified 1286 SDM publications in 15 major medical journals, which was about 10 times more than through the corresponding PubMed searches. The search method was reliable with a good concordance rate when compared with a validation dataset of downloaded publications. To our knowledge, full-text searches have never been assessed on medical journal websites. Our results are concordant with those of previous studies in other fields (eg, genomics), where the sensitivity of detecting keywords in full-text publications is much higher than when limited to a title and abstract PubMed search  [19, 20]. This may be especially useful when searching for information about study limitations or adverse drugs reactions  [21] , which are less likely to appear in abstracts or titles.
Acknowledgments We thank  Isabelle de Kaenel  ( Medicine Faculty Library, Lausanne, Switzerland ) for assisting with the correspondence with the selected journals, and the 6 journals that provided their published materials (American Journal of Preventive Medicine, the  BMJ, Canadian Medical Association Journal, Journal of General Internal Medicine ,  Mayo Clinic Proceedings, Journal of Pain and Symptom Management ). This study received internal funding from the  Department of Community Medicine and Public Health, Lausanne, Switzerland. Dr T-H Collet 's research is supported by grants from the  Swiss National Science Foundation  ( PBLAP3-145870 ,  P3SMP3-155318 ).
( 68 ) Figure  15  visualizes the mean y q and variance var(y q ) of the Gaussian process over the input domain, given 10 and 20 data points of our example training data. We see that for areas where no training data is available, the mean tends to go towards zero (i. e. to the mean of the Gaussian Process) and The open parameters of a Gaussian Process, e. g. the parameters σ 2 f and W in (  62 ), are known as the hyperparameters. In our terminology, these correspond to the meta-parameters of the gpr algorithm for regression. Rather than tuning the hyperparameters by hand, it is customary to tune them automatically by minimizing their log likelihood on a training dataset, i. e. argmin θ log p(y|X, θ), where θ contains all the hyperparameters. For a zero-mean Gaussian process with Gaussian kernel as in (61) for instance, θ contains σ 2 f and W.