dataesr/scientific-paragraphs-categorization huggingface dataset:
Business Intelligence Tools-Benchmarking The study was based only on the analysis of open-source solutions. To achieve this goal, some works were analyzed using scientific databases. During this process the most used open-source solutions were identified. Then the top six solutions (QlikView, Palo, Jaspersoft, Tableau, Spago, and Pentaho) were selected to be explored. In this study, benchmarking was used in order to compare tools and define evaluation metrics, focusing on the healthcare industry. In the following subsections, an overview of the Business Intelligence (BI) tools tested during this study are presented, based on the experiments made, as well as an extended analysis, i. e. , literature review, of each  [2, 4, 20, 25, 26, [29] [30] [31] [32] [33] [34]. All the BI tools were selected based on web-based studies, i.
QlikView QlikView (QV) is a BI software developed by the Swedish company QlikTech. Although this software is a proprietary product, the company provides a full development version of the software for free. Nonetheless, the company offers various licensing options by limiting the use of the software in accordance with the license acquired by the user. A key feature of this software is that it is fairly simple to extract data from different sources by allowing connections through Open Database Connectivity (ODBC) and Object Linking and Embedding Database (OLEDB), which are communication interfaces between the operating system and the various databases. OLAP also allows several operations by facilitating the user navigation between different dimensions through ad hoc queries. Moreover, it also enables the creation of a friendly and flexible interface with charts, pivot tables, and statistical analyses.
Another important feature of the software is that it does not use a System Management Database (DBMS) as a storage tool. The system connects itself to the base of the Transaction Processing in Real Time (OLTP), used only upon completion of the data loading process. Thus, the data are submitted to ETL processes and compressed in a file with extension. qvw, understood by QV. This QlikView file is a file that contains all the details required for data analysis, including the data itself, necessary to update the QV script file with new data from the data source; the layout information (folders, lists, charts, etc. ); alerts, bookmarks, documents and reports; and information about access restrictions and the module macros. Moreover, the distribution of information is facilitated and the analysis can be performed regardless of the original data location or network conditions.
• Palo OLAP Server is a multidimensional OLAP in-memory (Molap). The data are stored and then organized into cubes, dimensions, elements, and element attributes. Compared with Rolap (Relational OLAP), the Molap has the potential to be 100 times faster. A simple Palo cube can contain data from multiple data sources, which simplifies the analysis of data from different data sources, for example, the comparison of actual and predicted data collection. Users can import data that rises incrementally, from any data source that Palo get access to, and stores them in the structure defined by them. The way that the tables are listed in the database is not relevant, since this architecture is defined in the software itself.
• Jaspersoft iReport Designer is the report designer for JasperReports and JasperReports Server. It enables the creation of sophisticated layouts with graphics, images, and tables. It also allows access to data via JDBC, TableModels, JavaBeans, XML, Hibernate, CSV, and custom sources. On the other hand, reports can be exported in PDF, RTF, XML, XLS, CSV, HTML, DOCX, or OpenOffice formats.
• Spago BI SDK is the specific tool used to integrate services provided by the server. Specifically, it is used by Spago BI Studio so that the users can download/upload the analysis of documents to/from the server. This module allows the integration of documents, due to a wide range of services available through a Web service, and the publishing of documents Spago BI on an external portal. • Spago BI Applications is a collection of analytical models developed using Spago BI. These models are developed taking into consideration the sector of the market and the purpose or the end product, such as analytical specific component.
Pentaho BI Suite Pentaho BI Suite software was developed by Pentaho Corporation in 2001, in the Java language, being the first BI platform to be released as an open-source alternative in the market. The Pentaho offers two types of licenses: the Community Edition (CE), which is the open-source version; and the Enterprise Edition (EE), based on a subscription model. The Pentaho BI Suite project comprises a set of products: BI platform (server), reporting, OLAP analysis, data integration (ETL), dashboards, and Data Mining. The platform that integrates the Pentaho is 100% Java 2 Platform Enterprise Edition (J2EE), thus ensuring its scalability, integration, and portability. Also, it allows the connection to databases of JDBC, IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Firebird, and NCR Teradata types.
Taking this point into consideration along with the fact that Spago BI installation is quite a complex process, there is little supporting documentation, and, in addition, this software takes up way more RAM, Pentaho BI Suite was the tool chosen to implement the case study. To justify this choice, a final quick comparative analysis between Pentaho BI Suite and each of the other tools was made. Thus, comparing Pentaho BI Suite with Spago BI, it appears that both tools are very good, and have very close scores on different requirements. However, the main distinguishing feature between these two tools is that the Spago BI installation is more difficult. Considering the Jaspersoft BI, it appears that the Pentaho BI Suite provides more capabilities and better interactivity in terms of dashboards.
Moreover, Pentaho BI Suite has many more developed plug-ins for use, such as CDE, Saiku, and OpenI, all available in the marketplace, unlike Jaspersoft BI, which presents a very limited number of plug-ins to date. Regarding Palo BI Suite, it does not allow the display of KPIs and, moreover, does not allow the integration of Data Mining (DM) processes, unlike Pentaho BI Suite. One the other hand, the biggest disadvantage of QlikView regarding Pentaho BI Suite is the failure to allow access to dashboards through browsers. This is an important feature since it is essential that the application can be accessed anywhere through a web page and also by multiple users simultaneously. Besides that, QlikView is not a completely open-source software since this feature is only available in the server version.
Conclusions This paper is intended to facilitate the research work of developers who plan to deploy an opensource Business Intelligence (BI) platform in a healthcare environment and do not know which is the most appropriate tool to use. Healthcare institutions requiring similar features to the one presented in this paper may select the same software used in the case study based on the analysis made and benefits mentioned throughout this manuscript. It is also worth mentioning that this type of choice is crucial, since the applications developed in healthcare environments need to be more efficient and effective, as malfunction may have direct or indirect repercussions in terms of patients' health. Thus, with the analysis of all the BI tools discussed throughout this paper, it can be concluded that Spago BI is the most comprehensive open-source software; its Community version contains more features than most Enterprise versions of software analyzed.
It can be concluded that Pentaho BI Suite is also a consistent and complete tool, similar to Spago BI, only differing in the fact that it does not incorporate a dimensional model structure. Therefore, these tools can be considered the two most suitable to healthcare environments, taking into account the characteristics required by this type of institution. Nonetheless, Pentaho BI Suite was chosen to develop the BI application in the Centro Hospitalar do Porto since its installation process is simpler. Additionally, the Pentaho BI Suite software is well developed regarding the integration of plug-ins, since it allows the customization of the software according to the needs of the BI application. Now, we are designing a TAM evaluation in order to assess the quality of the solution developed.
Conclusions This paper is intended to facilitate the research work of developers who plan to deploy an open-source Business Intelligence (BI) platform in a healthcare environment and do not know which is the most appropriate tool to use. Healthcare institutions requiring similar features to the one presented in this paper may select the same software used in the case study based on the analysis made and benefits mentioned throughout this manuscript. It is also worth mentioning that this type of choice is crucial, since the applications developed in healthcare environments need to be more efficient and effective, as malfunction may have direct or indirect repercussions in terms of patients' health. Thus, with the analysis of all the BI tools discussed throughout this paper, it can be concluded that Spago BI is the most comprehensive open-source software; its Community version contains more features than most Enterprise versions of software analyzed.
It is also in charge of instantiating VMs in the IaaS and physical machines such as embedded boards. It includes core modules of a MAPE-K autonomic model  [11]  such as Monitoring, Analysis, Planning, Execution and Knowledge exchange, which help the DM response to changes from surrounding environment. -The Agent is a software component that must be preinstalled and bootstrapped on every VM and device which are managed. Agent probes the status of both hardware and software components and send these data to the DM periodically. These agents communicate with the DM and each other through an asynchronous messaging server. -The Messaging Server is the key component acting as a distributed registry of import/export variables that enable communications between the DM and the agents and among agents themselves.
The parent/children relationship of components is depicted naturally in an example about OSGi-based  [14]  application in Fig. 2. It is a cloud application providing Java message service (JMS) through its software components as Joram  [15]  and JNDI  [16]. These components are containerized as bundles complying to the OSGi specification. A Karaf  [17]  component is also needed serving as OSGi container for the Joram and JNDI bundles. In Fig. 2 , there is an important field: children which lists other components that can be instantiated and deployed over this component. In the OSGi example, it means we can deploy Karaf over a VM instance. In turn, Joram and JNDI can be deployed over instances of Karaf. The hierarchical model resolves the containment relations (i. e. vertical relationship) Fig.
2  An OSGi-based JMS service described by the framework's DSL (the graph in the middle and the initial instances description in the right) amidst components at disparate layers. At runtime, the Graph and the Initial Instances Description are used to determine which components can be instantiated, and how they can be deployed. Abstracted components include the deployment roots (e. g. VMs, containers, devices, remote hosts), databases, application servers and application modules (e. g. WAR, ZIP, etc. ). They list what the deployers want to deploy or possibly deploy. What is modeled in the graph is really a user choice. Various granularity can be described. It can either dig very deeply into the hierarchical description or bundle things together such as associating a given bundle with an OSGi container.
It accepts only one parameter which is an e-mail address. Replicate-Service is to replicate a component on a new machine. It takes a chain of component names as parameters. Delete-Service is to undeploy and remove a component that was replicated. It takes a component name as parameter. To demonstrate for utility of the mentioned rules, we use an example about a J2EE application with three tiers including web (Apache), application (Tomcat) and database (MySQL) servers. The Apache uses "mod_jk" to provide load-balancing mechanism for Tomcat servers which host instances of a Webapp. The autonomic events which can affect to such system are going to be discussed carefully in Sect. 5. In this section, we describe five basic reactions usually used in autonomic replication/migration as follows. The illustration of these five reactions are shown in Fig.
Experiment setup The elasticity context applies to the aforementioned J2EE application. With application tier, we use in initials two Tomcat servers dedicating to serve two different webapps: Webapp1 and Webapp2. We use the "mod_proxy" to build a cluster of Apache servers to avoid yet another bottleneck. Each of Apache server implements the "mod_jk" serving as a load balancer in front of these Tomcat ones. This experiment focuses on elasticity of application tier, thus without loss of generality, the database one is shared among webapps and hosted on a single MySQL server. All the VM used in this system are Microsoft Azure Standard_A2 instances with 2 cores and 3. 5 GB memory. Each Tomcat created in the elastic reactions is a Amazon EC2 m3. medium with 1 core and 3. 75 GB memory. The managed system is called System Under Test (SUT) that we use CLIF server  [25] , an distributed load injector, to create load profile and generate workload for the SUT to observe how the system reacts to changes of average response time (ART).
The polling periods is set to 10 s that means the ART of all requests from all users are collected each 10 s. These gathered data are sent to the framework's analysis module to be aggregated and further analyzed. The analyzed information then is delivered to the planning module to generate new configuration for the system based on ECA (event-condition-action) rules. The ECA rules decide whether the system should create an entire application server or only replicate a webapp instance using the set of reactions. One of the rules is to prevent multiple creating of new VMs or a new instance in a short period of time. At least the system needs to wait until it gets knowledge about the new one before another can be created automatically. It is called synchronization time which includes the VM provisioning, Tomcat installation, Webapp deployment and reconfiguration time for the existing Apache (to know the attendance of the new Tomcat) in the case of creating a new Tomcat/Webapp server.
Acknowledgements This work was partially supported by  Microsoft Research Europe , and project  B2016-SPH-17  from the  Vietnam Ministry of Education and Training. Open Access This article is distributed under the terms of the Creative Commons Attribution 4. 0 International License (http://creativecomm ons. org/licenses/by/4. 0/),which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
ALMA data and reduction The survey setup and data reduction steps are described in detail in  Walter et al. (2016). Here we repeat the most relevant information for the study presented here. ALMA band 3 and band 6 observations were obtained during Cycle-2 as part of projects 2013. 1. 00146. S (PI: F. Walter) and 2013. 1. 00718. S (PI: M. Aravena). Observations in band-3 were conducted between July 01, 2014 to January 05, 2015, and observations were conducted between December 12, 2014 to April 21, 2015 under good weather conditions following observatory project execution restrictions. Observations in band 3 were performed in a single pointing in spectral scan mode, using 5 frequency tunings to cover the frequency range 84. 2 -114. 9 GHz. With this setup, there were a few ranges where there was overlap between independent spectral windows (SPWs).
5 ′′ × 2. 0 ′′ and 1. 5 ′′ × 1. 0 ′′ from the low to high frequency ends of bands 3 and 6, respectively. Flux calibration was performed on planets or Jupiter's moons, with passband and phase calibration determined from nearby quasars. Calibration and imaging was done using the Common Astronomy Software Application package (CASA). The calibrated visibilities were inverted using the CASA task CLEAN using natural weighting to create data cubes at different channel resolutions. In particular, for the line search in the 3-mm and 1-mm bands, we created data cubes at 8. 0 MHz channel -1 and 31. 25 MHz channel -1 , equivalent to 24 and 37 km s -1 per channel, respectively. The final rms varies mildly as a function of frequency, but such variation is mostly dominated by atmospheric lines across the 1-mm window and by the loss of sensitivity at the SPW edges.
Multi-wavelength ancillary data The Hubble UDF is the cosmological field with the deepest observations in all important wave-bands, with 18,000 catalogued galaxies  (Coe et al. 2006). In this study, we use a sample of 58 z > 5. 5 optical dropout galaxies that were located within the 1 arcmin 2 region covered by our 1-mm mosaic in the Hubble UDF. This sample, enabled by the great depth of the UDF in all optical and NIR bands, was compiled from several searches for such objects based on Hubble Space Telescope (HST) imaging over the deepest area, the 4. 7 arcmin 2 eXtremely Deep Field (XDF;  Illingworth et al. 2013). This includes all available HST Advanced Camera for Surveys (ACS) optical and Wide Field Camera 3 (WFC3) IR data from the HUDF09, HUDF12 and from the Cosmic Assembly Near-infrared Deep Extragalactic Legacy Survey (CANDELS) programs.
For more details about these datasets, see  Bouwens et al. (2014)  and ref-erences therein. In particular, we use the most complete catalog of galaxies selected to have photometric redshifts in the range 5. 5-8. 5 compiled by  Schenker et al. (2013 ), McLure et al. (2013)  and  Bouwens et al. (2015). None of these objects have optical or NIR spectroscopy or previously confirmed redshift that could allow us to directly look for the [CII] line emission in our data cube. The full list of drop-out galaxies investigated in this paper is given in Table  1. The HST observations and dropout catalogs are complemented with recent spectroscopic constraints and redshifts from deep Multi Unit Spectroscopic Explorer (MUSE) integrations taken with the Very Large Telescope (VLT) as part of the Guaranteed Time Observations (GTO) on the Hubble UDF  (Bacon et al.
While our spectroscopic coverage permits us to search for  [CII]  line emission in the redshift range z = 6 -8, we allow for a extended range in the photometric redshift of the optical counterparts to take into consideration the typical uncertainty of these estimates, δz ∼ 0. 5. We choose a distance of 1. 0 ′′ to be about half the size of our synthesized beam. We find a total of 14 [CII] line candidates, two of which are blindly detected and selected based on their high significance in the data cube. Another 12 candidates are selected based on their association to a nearby optical dropout. Details on these searches are provided below.
We performed a line search using the Astronomical Image Processing System (AIPS) task SERCH. The SERCH task uses a Gaussian kernel to convolve the data cube along the frequency axis with an expected input line width, and reports all channels and pixels having a signal-to-noise ratio over the specified limit. For our search, we used a set of different Gaussian kernels, from 180 to 500 km s -1 in order to ensure that all possible line widths were considered. We searched for all line peaks with signal to noise (S/N) values above 3. 5. Here, the S/N is defined as the maximum significance level achieved after convolving over the various Gaussian kernels. This means that the the signal and noise levels are defined after averaging each image plane over several channels. We average over velocity ranges from 180 to 500 km s -1 , which corresponds to the typical line widths observed in the ISM of star-forming galaxies (e.
Blind [CII] line candidates We look for possible [CII] line candidates by directly searching for significant positive line peaks in our 1. 2mm data cube. We restrict this search by setting a limit on the fidelity level down to P =70%, which is equivalent to a line peak S/N> 5. 3. Since detection of a single line in the 1-mm cube could correspond to CO line emission at lower redshift, we further restrict the sample to those objects that either do not have an obvious optical counterpart in the HUDF catalogs or that have a counterpart with a photometric redshift z > 5. 5. The reason to select this fidelity level, compared to the 60% level set in Paper I for detections, is to statistically increase the chances that the identified peak is real as we are explicitly looking for objects that lack of or have a faint optical counterpart.
Using this procedure, we found two positive line peaks with S/N= 5. 3 -5. 4 in the 1-mm data cube in which no optical counterpart was identified. Figure  6  shows the millimeter spectra for these line candidates. If we associate these candidate line peaks to the [CII] emission, they would correspond to redshifts of ∼ 6. 36 and 7. 50 for sources IDX25 and IDX34, respectively. For each spectrum we fit a single Gaussian to the candidate line emission, thereby deriving an integrated intensity (I [CII] ) and line full width at half maximum (FWHM). We checked for extended emission by collapsing each candidate emission line along the frequency axis, and producing a integrated (moment 0) map. This collapsed map was then fitted with a two-dimensional Gaussian. In all cases, the emission was found unresolved and the integrated line intensity obtained in the collapsed map was found to be consistent with the value derived from the fitted spectrum.
We searched in the MUSE cube for possible optical emission lines at the location of the blind [CII] line candidates and at the position of the optical counterparts of the lower significance [CII] candidates. We find that no obvious optical lines showed up in the spectra extracted at the locations of the blind [CII] candidates (sources IDX25 and IDX34), and thus we did not obtain further information on the reality of these objects. Similarly, the MUSE data does not provide good redshift constraints for any of the optical dropout galaxies associated to the [CII] line candidates, based on the spectra extracted at these locations, except in the case of ID52 where MUSE confirms z = 2. 379. This implies that the line peak identified in the 1-mm cube is spurious since no ISM line (e. g. CO, [CI]) at the frequency of the peak matches the MUSE optical redshift.
CONCLUSIONS We have used our molecular ALMA survey of the Hubble UDF to search for [CII] line candidates in the redshift range 6. 0 < z < 8. 0. We do this by blindly searching for significant line peaks in the 1-mm data cube, and by specifically looking around 58 known dropout galaxies with photometric redshifts that are consistent with the redshift range covered by  [CII]  (5. 5 < z < 8. 5). Our survey field within the UDF was chosen such that the number of known drop-out sources was maximised. The spectroscopic survey reaches an approximately uniform depth of L [CII] ∼(1. 6-2. 5)×10 8 L ⊙ at an angular resolution of ∼ 1", well matched to the expected size of the galaxies at that redshift. We discuss our statistical tools to search for line emission in the vicinity of the drop-out galaxies.