dataesr/scientific-paragraphs-categorization huggingface dataset:
Discussion and Positioning Although our approach is designed for warehousing systems, it is supplied with virtual approach features. Particularly, AXML documents consist of two types of XML nodes. The first set of nodes is defined and stored explicitly to represent static and passive parts of the document, but the second set of nodes is defined implicitly by calling services to integrate data on the fly, virtually, to represent the dynamic and active part of the document. It has virtual approach advantages of data integration from a large number of heterogeneous and distributed data sources that are likely to be updated frequently, due to using AXML, but there are no predefined or expected user queries. Indeed, calling information of AXML services may or may not occupy larger storage than their results, but they can certainly be reused infinitely to refresh the repository.
Web standards (e. g. , XML, Web services and related technologies) can help enterprises to integrate such complex data. Typically, Web standards are the core technologies that are utilized in AX-InCoDa for integrating complex Web data. XML is indeed the de facto standard for representing, exchanging, and modeling semi-structured data. Thus, we exploit XML as a pivot language for standardizing data into a unified format. XML is also utilized for modeling and storing complex data. Moreover, Web services can solve the data distribution and interoperability problems by exchanging data between different applications and different platforms. Web services are self-contained, self-describing modular applications that can be published, located, and invoked across the Web. Indeed, a service provides transparent access to a variety of relevant data sources as if they were a single source  (Erl, 2004; Zhu et al.
, 2004; Schlesinger et al. , 2005; Utomo, 2011). Moreover, according to informatica 1  , Software-as-a-Service (SaaS) integrate cloudbased data easily with on-premise systems to ensure users can access accurate, complete, up-to-date data whenever and wherever they need it. Integration-as-a-Service (IaaS) is a flexible, scalable and reusable integration approach where the core integration technology that performs integration functions, such as semantic mediation, data migration, connectivity, and other core integration facilities, is delivered from the Web as a service  (Linthicum, 2010). Therefore, we employ metadata-based services to integrate data from distributed data sources. Embedding calls to services into XML data results in so-called Active XML (AXML). Typically, the goal of AXML is to integrate information provided by any number of autonomous, heterogeneous sources and to query it uniformly  (Abiteboul et al.
, 2008a). Using XML and Web service standards also provides a less expensive and more efficient data integration infrastructure, typically by leveraging services to extract and detect changed Fig. 2  AXML data integration framework data, providing transformation services to unify data, as well as loading services to move data from sources to targets (section 5). Integrated data are targeted to a native-XML based repository, namely an AXML repository; while integration services integrate relevant data from sources to target, description of different framework activities are logged into event repository. Such events are mined on-line in order to extract interesting knowledge to self-maintain, self-manage and automate the execution of integration services, specifically when incorporating the framework with active rules paradigm (section 6).
Metadata Management for Data Integration Metadata are a critical element in effective data integration. They are considered as a potential integration tool providing useful information that facilitates communication between information systems. While metadata management was not considered as a significant part in traditional data integration systems, today's metadata management plays a critical role in developing and maintaining current data integration environments. Integration services in AX-InCoDa are based on a metadata-driven approach for integrating relevant data. The metadata-driven approach allows users to specify "what" data need to be integrated, without regarding "how" to integrate them. Since AX-InCoDa is a metadata-driven, we address in this section the active role of metadata to facilitate data integration.
Active metadata management Traditionally, metadata are used passively and are created and maintained as documentation about the structure, the development and the use of a data integration system. However, there is now a trend in data integration toward metadata taking on a more active role  (William Inmon, 2008). In AX-InCoDa, metadata management helps deal with the heterogeneity, variety, and complexity of data sources, as well as the automation of data integration tasks. For example, specifying sourceto-target mappings (under the form of metadata) serves as the basis for automating extraction and transformation tasks. The well-organized metadata, the easier administration of the data integration environment. Therefore, metadata can minimize the efforts for developing and administrating a data integration platform.
Conceptual Data Model In order to illustrate associations between our framework's entities, we present AX-InCoDa conceptual data model in figure  4  as a UML class diagram. Classes in this model represent metadata such as entity, attribute, table, column, and index. This model describes the relationships between the main entities of the framework, such as data sources, integration services, AXML document, and logged events. The Complex Source class contains metadata descriptions of complex data sources. Since we handle several types of data sources, each data source follows a specific source type (e. g. , relational database, XML, text, image, etc. ). A data source is composed of one or more objects, where each object is composed of one or more fields. The Object class describes the metadata of objects.
Object is an optional entity and may not be available for non-relational data sources. Finally, the Attribute class describes the metadata of attributes. The Event class describes the logged events raised when defining data sources, objects, fields, executing integration services, and querying AXML documents. Although there are several types of events (section 6), an event superclass is specified for simplicity. Logged events are exclusive; each event type has its own description. Events, conditions, and actions are mapped together to form active rules. The Event, Condition and Action classes contain the description of events, conditions, and actions, respectively. Actions are always associated to integration services.
Service-oriented, Near Real-time Integration The Web has become a common platform for the delivery of business applications. In particular, Web service technologies and their extensions, e. g. , SaaS, IaaS, Everything-as-a-Service  (Li and Wei, 2012) , etc. , enable the development of complex business applications on the Internet/in the cloud by integrating and exchanging Web services from different providers. In AX-InCoDa, we present integration services as a set of reusable Web services, which are designed for integrating data from heterogeneous and distributed data sources. Due to the heterogeneity of data sources, integration services utilize several types of interfaces to extract data, transport and store integrated data  (Martens and Teuteberg, 2012). In addition to our custom interfaces for integrating Web data, we benefit from existing Web APIs 2  and exploit them for accessing different databases on the Web, as well as integrating heterogeneous Web content.
Push/Pull Data Integration In AX-InCoDa, there are two complementary serviceoriented directional strategies for integrating and refreshing the AXML repository in near real-time, i. e. , push and pull strategies. The push direction means that relevant data move from data sources toward the AXML repository in a "push" way. In this strategy, beside applying the traditional "initial data integration" using integration services, change detection services play a significant role to incrementally refresh the AXML repository with data in near real-time. Change detection services are employed to capture data changes. Using the subscription-notification paradigm, data integration services can subscribe to change detection services to be notified with only near real-time changes. Figure  5  illustrates the forward direction strategy for pushing data in near real-time onto the AXML repository.
Fig. 5  Push strategy for refreshing data By contrast, in the pull direction strategy, the AXML repository is refreshed with data in near real-time by pulling data from sources (read figure 6 from right to left). Pulling data is attained by invoking embedded AXML services. Such embedded services are invoked to refresh the repository with data in near real-time, achieving on the fly data integration upon request. The timing of invoking embedded services may be defined explicitly (e. g. , triggering temporal events), or implicitly (e. g. , when querying AXML documents/fragments). The pull direction strategy for integrating data in near real-time heavily depends on the AXML language's capabilities.
Data Integration Services Although data integration includes several processes, ETL are still the most important services when integrating data. In addition to extraction, transformation, and loading services for performing ETL tasks, AX-InCoDa includes other services for managing integration tasks as follows. -Metadata extraction services. Metadata extraction services are sets of services designed for generating metadata from heterogeneous data sources, including metadata of Web services residing at data sources, so-called third-party services. Metadata are extracted using a library of adapters, each one dealing with a specific type of data sources. Then, metadata extraction processes are deployed as Web services. The metadata extraction process is an interactive process, where the data steward selects relevant metadata from service results.
Moreover, such services can be scheduled to be explicitly invoked to self-configure the framework's setting. It is worth noting that mined information is evaluated against sets of defined active rules, which are managed by reactive services. In addition, mining services use XQuery to extract the relevant knowledge from the innovative new structure of logged events. -Querying services. Querying services are a set of services that query either metadata by other integration management services or query integrated data by the business user. Thus, the first type of queries is carried out implicitly, without any user intervention. The second type of queries is explicitly formulated by business users or an external analysis module. Queried metadata and AXML data are both in XML format. Therefore, querying services use XQuery to query both the metadata and the AXML repository.
Back-end services The common methods for capturing near real-time data changes include applying triggers in relational or XML databases, adding time-stamp attributes to database records, scanning log files of transactions (log sniffing), and/or monitoring transactions for changes and then targeting these changes to a specific message queue. These methods run on the back-end layer of data sources. In AX-InCoDa, such methods are developed and exposed as services, called back-end services. The data steward defines the appropriate method for detecting changes from each data source as part of metadata, i. e. , metadata enrichment. Then, s/he maps data sources to change detection services, and adapts scheduling configurations for change detection. Scheduling configurations can be different from one data source to another.
Another category of events is logged when querying AXML documents. These events include information about AXML documents, XQuery expressions, XPaths expressions, as well as date of querying. Since events are warehoused into the event repository, the repository can be modeled and stored according to a star schema model  (Kimball and Ross, 2002) , where a single fact document represents all events (figure  8 ). However, there are multiple dimension documents (e. g. , user dimension, machine dimension, session dimension, data source dimension, AXML document dimension, date and time dimension). Warehousing events allows data steward to apply XML On-line Analytical Processing (X-OLAP)  (Park et al. , 2005) , in order to explore and analyze logged events information.
Mining association rules from incremental XML-formatted logged events is different from mining traditional static data, due to several specific issues and challenges either related to data arrival  (Gaber et al. , 2005; Jiang and Gruenwald, 2006; Yu and Chi, 2009) , or the nature of the XML format  (Feng and Dillon, 2004; Zhao et al. , 2006). When logging events, events arrive continuously at moderate or high speed, in unbounded amount, and with varying data distributions. Unlike in traditional data mining, there is not enough time to rescan the whole database whenever an update occurs. Therefore, a single-pass over events is required. Logged events need to be processed incrementally as fast as possible. Processing speed should be faster than event arrival rate. Moreover, mined data should not need to be recalculated each time they are requested.
Discovering frequent events The main objective of constructing the FXT is to mine frequent itemsets and association rules easily using the XQuery language 3. Frequent itemsets are queried by traversing the FXT from breadth nodes to specific nodes (portion of paths), or to leaf nodes (complete paths). Frequent itemsets are usually filtered using a statistical measure called support. Support measures the proportion of transactions that contains a specific item (or itemset). A frequent itemset is an itemset whose support is greater than some user-specified minimum support. Frequent itemsets satisfy the Apriori property, which states that if a given portion of path does not satisfy minimum support, then neither will any of its descendants  (Agrawal and Srikant, 1994). Let I be a set of items within a set of transactions S.
Discovering association rules Association rules have been first introduced in the context of retail transaction databases  (Agrawal and Srikant, 1994). An association rule is an implication of the form X ⇒Y, where X is the rule body, Y is the rule head and X ∩ Y = φ. A rule X ⇒ Y states that the transactions T that contain the items in X are likely to also contain the items in Y. Beside support, association rules are characterized by confidence. Confidence measures the proportion of transactions in S containing items X 3 http://www. w3. org/TR/xquery/ declare variable $input := doc("tree. xml")/root; declare variable $rootCounter := $input/@counter; declare function local:getFrequentItemsets($parent as xs:string, $element as element(*, xs:untyped), $minSupport as xs:decimal) { let $path := concat($parent,'/',name($element)) where $element/@counter div $rootCounter>=$minSupport return (<frequent path="{$path}" count="{$element/@counter}" support="{$element/@counter div $rootCounter}"/>, for $child in $element/* return local:getFrequentItemsets ($path, $child, $minSupport))}; (: call the function :) for $child in $input/* return local:getFrequentItemsets("", $child, 0.
Beside evaluating services implicitly when data are requested, services can also be evaluated explicitly (e. g. , daily, weekly or after occurring some events). Evaluating services explicitly may depend on data update frequency, which differs w. r. t. the nature of various applications. Moreover, the engine manages where service active rules, and logged events. Such databases are employed as utilities for application manager components. Active rules are implemented, triggered and fired using the XQuery trigger facility supported by Sedna. In the Web tier, integration services, dispatcher services, and user interface components bindings are implemented in Java. They are deployed to Oracle We-bLogic server 11g. At the client tier, users can explore our application via a web browser. The application's GUI is developed using components of Oracle Application Development Framework (ADF) and Sun JavaServer Faces (JSF).
The user specifies interesting data sources, and then extraction services bring out the metadata from which to select a relevant schema. Beside defining data sources via the application's GUI, users have access to several functionalities such as mapping data sources with integration services, scheduling the execution of integration services, mapping integration services with targets, browsing and querying the AXML repository, browsing changes of data sources, and defining ECA rules. The GUI also allows applying the general settings of the framework, and applying the configuration of change detection and native-XML database. Moreover, a demo of the AXML browser is implemented in order to navigate AXML documents. The browser is split to display the AXML documents before and after invoking embedded services.
Implementation Remarks We herein discuss some remarks on the qualities of our prototype implementation, e. g. , maintainability, reusability, interoperability, scalability and performance. AX-InCoDa is a metadata-driven framework that allows a data steward to specify what data need to be integrated, without regarding how to integrate them. Accordingly, it makes easy for the steward to maintain the data integration environment for any application. How-  ever, a steward must still be a person who has enough expertise in data integration and its processes. Furthermore, our prototype is service-oriented, and manages its processes and integration tasks using the services technology. These services are designed to be reused by different applications. For instance, a specific service can be reused to integrate the metadata of any database object.
Moreover, employing both XML and Web services in developing our framework tackles interoperability problems among diverse systems. Since the entire framework is services-oriented, it can also benefit from the myriad of options offered by WS-Extensions. For instance, the framework can be augmented with security and reliability services. It is advantageous to use open-source and free software/pieces of software for implementing our prototype. However, the scalability and performance of our prototype is related to that of underlying technologies, such as Sedna, PDI, and the We-bLogic server infrastructure. Note that there are other alternative technologies that may enhance performance. Nevertheless, our choice of technologies bases on their compatibility and satisfaction of our requirements. For instance, oracle ADF components (user interface components) run smoothly with the WebLogic server.
INTRODUCTION A single-step genomic BLUP (ssGBLUP) is a modification of BLUP to use genomic information. In ssGBLUP, the pedigree-based numerator relationship matrix (A) and a relationship matrix based on genomic information (G) are combined into a single matrix H  (Legarra et al. , 2009). The inverse of H has a simple form and can substitute for the inverse of A in existing software  (Aguilar et al. , 2010). Compared with multistep methods  (VanRaden, 2008) , ssGBLUP is simpler and applicable to complicated models. The ssGBLUP has been successfully used for chickens  (Chen et al. , 2011b) , pigs  (Forni et al. , 2011) , and dairy cattle  (Aguilar et al. , 2010 (Aguilar et al. , , 2011b;; Tsuruta et al. , 2011). The computing limit of ssGBLUP is currently up to about 100,000 genotypes of progeny-tested animals  (Aguilar et al.
Data Data were simulated using QMSim software  (Sargolzaei and Schenkel, 2009)  for an additive trait with heritability of 0. 5, 2 chromosomes, and 60 QTL. Performance was simulated for 15,800 individuals in 5 generations, and 1,500 individuals of the last 3 generations were genotyped. Each animal in the simulation had a single phenotypic record. Details of the simulation were reported by  Wang et al. (2012).
ACKNOWLEDGMENTS This project was supported by  Agriculture and Food Research Initiative Competitive Grants  no. 2009-65205-05665  and  2010-65205-20366  from the  US Department of Agriculture National Institute of Food and Agriculture  as well as by  Holstein Association USA (Brattleboro, VT) , and  PIC  (Hendersonville, TN). Discussions with G. R. Wiggans of the  Animal Improvement Programs Laboratory (Beltsville, MD)  were greatly appreciated. Manuscript review by  S. M. Hubbard  of the  Animal Improvement Programs Laboratory  is gratefully acknowledged.
I. INTRODUCTION Developers and users often find issues with software systems and are encouraged to report them in the available issue trackers that are set up by development teams. There exists a variety of issue tracking systems. Popular systems include Bugzilla, Jira, etc. Other development platforms such as Google Code, GitHub or Freecode have in-house implementations of issue tracking systems. Developers thus have ample opportunities to use issue tracking systems in their development and maintenance process. Many research studies have investigated ways to improve the user experience in issue tracking systems  [4] ,  [11] , while others have proposed techniques for helping developers manage and address issue reports  [1] ,  [24] -  [26]. Also, a number of approaches have linked issue reports to changes in source code  [5] ,  [30].
We also investigate the impact of the usage of issue trackers on the ultimate goal of project success. Project success can be characterized in diverse dimensions: monetary returns, number of downloads, or popularity. This study focuses on open source projects, and we only consider popularity as a measure of project success. Our study exploits data from GitHub, a super-repository of software projects containing millions of projects. GitHub is free for open source projects and implements an in-house issue tracking system where users can file issues and tag them into self-defined categories. The issue tracking system is easy to use and is systematically provided to all projects hosted in GitHub. We collect a hundred thousands of projects from GitHub and investigate the adoption of issue trackers as well as the impact of issue tracking on software success.
Our contributions are as follows: 1) We perform a large scale study on thousands of software projects. To the best of our knowledge, it is the largest study conducted on issue trackers. 2) We investigate the adoption of issue trackers in terms of the projects that utilize them, the people that report issues, and the kind of issues that are usually reported. 3) We discuss our findings and share some insights on the correlations between the quantities of issue reports and various characteristics of software projects. 4) We also compare our findings with a previous study  [27]  on Firefox development where the authors have found that the size of the user community influenced the time-to-fix rate of bugs. We find that in general this correlation is small. The structure of this paper is as follows.
It also enables a better follow-up of user's concerns by project developers. Studies have shown that issue trackers can be beneficial to both open and closed source projects  [9] , when they are publicly available for use. There is a plethora of issue trackers used in software development projects. A number of them are more commonly referred to as bug trackers as they focus more on bug reports. Many development teams, including those at the Apache Software Foundation or the Linux kernel community, rely on standalone products such as Bugzilla 1  , and JIRA 2  to track defects in their code, plan fixes, etc. Project hosting platforms, on the other hand, often resort to in-house implementations of issue trackers that are designed specifically to include a set of features in line with their hosting capabilities.