dataesr/scientific-paragraphs-categorization huggingface dataset:
BI stories are an asynchronous, visual, and interactive means of transmitting and sharing information on data between analysts and their audience. They include visualized data (dashboards, charts or tables) and detailed explanations on the story structure in the form of presentation(s), detailed textual annotations and external resources such as wikis. (2)  Current tools fail to support the storytelling process, which remains cumbersome and requires frequent switching between software (analysis tools, screen captures, text editors, presentation tools, etc. ). We emphasize the need for storytelling support, and extract requirements for enhancing BI tools with visual storytelling capabilities. (3) Following these requirements and a user-centered design approach, we implement a storytelling prototype incorporated in an existing visual analysis dashboard, to fluidly transition from analysis to story creation and reading.
Wohlfart and Hauser  [32]  present a system for demonstrating to audiences the path followed in analyzing 3D volumetric data, while providing audience with limited interaction with the 3D data. Both these systems deal with a single visualization/chart seen over time or from different views. Thus their designs are not necessarily applicable to the multi-dimensional and multi-chart BI visualizations where the connections and links between data are not as clear. Storytelling tools in BI are not yet as advanced. Systems like Sense. us  [15]  and Tableau 5 allow analysts to visualize data, conduct analysis, and store a history of the exploration, that can serve as a step towards creating a story. Many Eyes  [31] , Tableau Public 5 and Sense. us [15]  publish interactive visualizations online, and permit collaborative analysis through comments on a single visualization, creating an evolving analysis.
Interviews To support visual storytelling in BI, we first investigate current practices in transmitting BI analysis results, and identify challenges experts face currently when creating and sharing their stories, or reading and interpreting stories of others. We interviewed 5 BI experts in a leading business intelligence development company, with experience from 6 months to 12 years. Participants' job descriptions included development project manager, project manager, development director, data warehouse engineer and delivery manager. Three experts used dashboards and communicated their analysis or read analysis from others daily, while two several times a week. Interviews were held in person or by phone and lasted over 1 hour (Table  1 ). We report next our major findings. Note that they hold true for all BI reporting tools available today, as indicated by our experts' experience with multiple tools, and our own investigation.
A BI report can be a single page, with only a title and a dashboard (Fig. 1. ). This one-page report summarizes the most important data, and can serve as a starting point for longer reports, up to 50 pages in length, that give more details. Details can be additional visualizations, tables, annotations, links to the data used in the visualizations, and finally block text, although all participants preferred limiting text to 5% of the space in a report. When possible, creators want to make their reports "live", with interactive visualizations for the audience to explore. Thus BI reports have a very strong visual component, with little text added for explanations. The one page report is preferred by clients like company managers, that want an "at-a-glance view" of a project status, and that see many such reports during a day.
Longer detailed reports are used to communicate findings to other analysts, project teams and product owners. Experts mentioned that BI reports are used to (i) answer specific questions (e. g. What is the code development progress in project X the last 3 weeks?); (ii) investigate specific data (e. g. Investigate the increase of bugs in section Y of project X); (iii) manage conflicts and highlight problems (e. g. Team X completed less use cases than planned, because test team Y did not complete testing); and (iv) interpret past data and predict future trends (e. g. Given last year's sales, what is this year's projection?). BI reports are nevertheless only one of the tools used to communicate analysis findings, and are not a complete BI story.
The report creator often draws by hand on a chart the ideal data values, to help compare the current situation to target goals. The audience can ask questions during or after the training sessions, through emails or arranged meetings. Content similar to the presentation, is often put on a wiki page to answer follow-up questions. The session recording, wiki page, and presentation slides, are made available to the audience as reminders and reference material. Experts explained that this material is not a complete story either, as it does not include the visualization and data details shown on the report. Thus a complete BI story is a collection of visual representations of the most important data followed by further data details (BI report), accompanied by instructions on how to read the visualizations (order, connections, importance) in the form of presentations and verbal or textual instructions on a wiki.
At each iteration, creators explore the desired data using interactive visualization dashboard tools, create initial visualizations, provide additional information and details about the analytical techniques used, and finalize reading paths (i. e. how to read a report). Once the story is finalized, it serves to clarify connections in the data and answer specific questions analyzed by BI analysts (see section on BI Reports). These answers often result in more detailed or tangent questions from the audiences, and the need for analysts to conduct side data investigations and generate new stories. As in other visualization domains, BI stories are thus a visual communication medium between storytellers and their audiences, but contrary to other domains, there is an open communication loop, where audiences can continue to ask for new stories.
BI Storytelling Challenges All experts use an in-house reporting tool, that gives access to different data sources and can extract interactive dashboards, charts and tables from their dashboard analysis system. It also provides the capability of adding text. Three (P1,P3,P5) also used Excel for creating less complex reports. Our experts identified several issues with this process, which are similar to other BI analysis and reporting tools. When extracting interactive visualizations from their analysis tools, metadata and annotations from their analysis are not extracted and have to be recreated. Moreover, the annotation capabilities of the report creating software are very limited. They cannot annotate specific data points, while sequences and connections cannot be displayed graphically but have to be explained in one of the supporting material.
g. using drill down/up, filter, link & brush), four (P1,P2,P3,P5) of our experts prefer to have interactive visualizations that permit linking and brushing (i. e. data selection). But they would limit the more advanced interactions such as drill down/up or filtering. They felt that all the data needed to tell the story should be displayed clearly in the report without the need to explore the data further. The fifth (P4) would not be opposed to fully interactive visualizations. Thus authors feel business stories should be mostly author-driven and constraint, known to work best when the goal is storytelling or efficient communication  [26]. Story templates. Going from the current practices of storytelling (BI report, presentations, wiki) to a dedicated storytelling tool is not straightforward.
Requirements For Creating BI Stories Based on expert self-reporting, BI reports, the main communication medium of BI analysis, consist of snapshots of visualizations and textual descriptions, made in a different environment than the one used for analysis. These reports are fact-based and can be interpreted only by an expert audience. To increase their audience, report creators use supplementary material, like wiki pages, presentations, and when possible links to interactive visualizations. Based on our experts' interviews and a participatory design session, we identified a set of requirements for enhancing BI analysis tools with storytelling capabilities: R1. Fluid transition. Analysis tools used to explore data and create visualizations are different from report creation tools. Exporting visualizations from the first to the second to create a BI story costs time and effort, and limits the possibility of embedding meta data or annotations created during the analysis.
R3. Narrative visual aids. Report creators need to add focus expressions to draw attention to specific visualization data, such as highlighting, coloring, annotating and zooming. They also require ways to indicate reading sequence (e. g. vectorial references, like arrows  [13]   [30] ). These are not available in reporting or BI analysis tools. R4. Interactive visualizations. Visualizations on shared reports are often noninteractive when read outside the organization. A storytelling tool should have completely interactive visualizations, although the way that readers interact with the data should be limited (by default to brushing and linking) and be controlled by the creator. This balance has been identified as a challenging aspect of storytelling  [20]. R5. Appropriate BI Story templates.
BI stories have specific structure not necessarily shared by other story narratives identified by Segel et al. [26]. Our experts identified templates of interest (Fig. 2 ) and highlighted the need for a new template that consists of an annotated dashboard. R6. Reuse. Although BI reports and data changes from analysis to analysis, often the underlying structure of BI stories remains the same. It is thus important to be able to easily reuse the structure of stories created within the tool both for stories of evolving data and similar future stories. R7. Optional playback. Readers should be provided with a static representation of the entire story to get an overview and explore it on their own pace, as well as a guided playback to help them follow analysis paths that not easy to discover and understand the important points according to the creator.
By default we deactivate advanced interactions like drill-down/up, but authors can reactivate them through the visualization's properties. The creators may also decide to take a new snapshot of the data (i. e. change the timestamp for the visualizations, and so the values of the data). Thus they can reuse the story structure for a new version of data (R6), which is particularly important for evolving dynamic data. Finally, users can select and replace any visualization with another, even from another dashboard loaded in the system. Thus they can reuse the story structure not only for dynamic data, but also for completely different datasets. Thus our system integrates all the material used currently in BI story creation (R2): BI reports (visualizations and annotations), interactive visualizations, ways to indicate story structure, highlighting, optional story presentation in sequence, and text or audio explanations.
Participants liked the ability to use the annotated dashboard template, saying that "this is how we want to present our analysis story, similarly to our dashboard". They both commented that annotations attached to data points are very important in pointing out to readers important data values "I add a lot of manual arrows to point to annotations that refer to specific data points on a chart, and their ideal value". Both experts suggested our system should support two types of BI narrative stories: (i)Fixed stories, that present snapshots of datasets at specific points in time, yet are interactive (e. g. for filtering), to be shared as tutorials, explanations, or reports. This is the default case in our system. And (ii) Online stories, that present dynamically evolving data, and can have the same analytic scenario regardless of data values.
Thus stories may have the same chart descriptions (e. g. what data is shown), the same KPI relations, and the same reading sequence. Here visualizations in stories are no longer snapshots, but are updated with data changes. We have implemented this extension. Collaboration and Communication with BI stories. Expert P2 commented on how this storytelling prototype can also be used as a means to evolve stories. Multiple analysts can integrate their own comments and knowledge in the story, encouraging peer learning, but also collaboratively creating more complete and detailed stories. Expert P1 mentioned that she could envision using the system to iterate the definition of the story directly with her clients (a process conducted now by email or phonecalls). She envisioned clients adding themselves on the story further explanations on specific entities and their relations (to explain patterns), possible summaries of decisions they took based on the report, or highlighting what information is missing.
SWIFF is a project funded by the Seventh Framework Programme of the European Commission to study the mathematical-physics models that form the basis for space weather forecasting. The phenomena of space weather span a tremendous scale of densities and temperature with scales ranging 10 orders of magnitude in space and time. Additionally even in local regions there are concurrent processes developing at the electron, ion and global scales strongly interacting with each other. The fundamental challenge in modelling space weather is the need to address multiple physics and multiple scales. Here we present our approach to take existing expertise in fluid and kinetic models to produce an integrated mathematical approach and software infrastructure that allows fluid and kinetic processes to be modelled together.
Given these crucial impacts on society, the space weather is attracting a growing worldwide attention and progressively increases presence within international research projects. SWIFF (Space Weather Integrated Forecasting Framework) aims at creating a mathematical model and a software infrastructure able to describe and predict the physical processes in the magnetized plasma all the way between the Sun and Earth. It aims at coupling different regions of space to produce tools that would rise space weather forecasting to qualitatively new level. The principal difference of SWIFF with respect to other similar efforts within Europe, USA and Japan, is the final goal: to create a new modelling framework based on both kinetic and fluid treatments of plasma. We focus here on the steps necessary for achieving a true physics-based capability to predict the arrival and consequences of major space weather storms.
The electromagnetic fields keep the species coupled forming a very nonlinear and multi-scale system. Modeling space weather is a daunting task: daunting because the system is enormous and because it includes a wide variety of physical processes and of timeand space scales. Figure  1  shows the typical physical scales observed from space exploration missions in the Earth environment. The scales are presented in the form of a hourglass with the top part presenting the macroscopic scales of evolution and at the bottom the smallest microscopic scales important to be coupled together with macroscopic once. The fundamental goal of the SWIFF project is to progress beyond the state of the art in two ways. First, in the development of mathematical models and computational methods and software especially designed to handle the multiple physics and the multiple scales characteristic of space weather phenomena.
g. , encountered in multi-dimensional magnetohydrodynamics. The code has played a role within the SWIFF collaboration to benchmark simulation challenges used to intercompare the network toolpark. As an illustrative example which is discussed further on in this paper, Figure  2  shows the instantaneous density variation in a resistive evolution of a reconnecting current sheet. The figure uses a schlieren representation (i. e. , an exponentially stretched quantification of the local density gradient) for a 2D fully periodic test case of a double Harris current sheet setup. A resistive MHD simulation with resistivity parameter g = 0. 0001 follows the evolution of these current sheets when subjected to initial perturbations. At sufficient resolution, one witnesses how they transit to fast reconnection regimes where repeated islands form along the thinning central current sheets.
Hence, Petschek reconnection at the base of the CS seems to be responsible for the observed plasma heating only in the early phases of the post-CME coronal reconfiguration. For the purposes of the SWIFF project we selected two interesting limb events detected by UVCS which occurred on November 2, 2003 and on July 28, 2004. From the UV and white light remote-sensing data we plan to estimate: CS thickness and length (directly observed; WL and UV), density (column density; WL and line ratio; UV), thermal energy content (UV lines; UV), turbulence velocity (line non-thermal broadening; UV), density time fluctuations (intensity fluctuations; WL), Alfven velocity (from propagating blob velocities; WL). Remote-sensing data will be also complemented with in situ observations: CS are observable in the interplanetary medium by in situ data, looking at the current density as the spacecraft crosses the sheet.
In situ data can be used to derive: CS thickness, density, density fluctuations, Alfven velocity. Preliminary analysis of the July 28, 2004 event shows the detection by UVCS of a first short-lived (~1 h) bright peak in the FeXVIII 974 A ˚line intensity, observed ~30 min after the CME,  followed by a slow (~20 h) gradual FeXVIII 974 A ˚line intensity increase (see Fig. 9 ). The persisting and gradually rising FeXVIII emission was detected by UVCS 0. 8 solar radii above the limb and was associated also with a persisting Hard X-ray and Soft X-ray source on disk at the top of the post-flare loops, as observed by RHESSI and GOES/SXI instruments, respectively. From the electron temperature and densities measured by UVCS in the post-CME CS with line ratio technique we will estimate the total CS thermal energy and compare it with that provided by the X-ray sources at the base of the CS.
Acknowledgements. This research has received funding from the  European Commission 's  FP7 Program  with the grant agreement  SWIFF  (Project No. 2633430 , swiff. eu). The KU Leuven simulations were conducted on the computational resources provided by the  PRACE Tier-0  Project No. 2011050747  ( Curie supercomputer ) and by the  Flemish Supercomputer Center  ( VIC3 ). Additional computational support is provided at  KU Leuven  by the  NASA NCCS (Discover)  and  NAS (Pleiades) Divisons , as part of the support to the  NASA MMS Mission. UNIPI acknowledges the HPC resources of CINECA made available within the Distributed European Computing Initiative by the  PRACE-2IP , receiving funding from the  European Community 's  Seventh Framework Programme  ( FP7/ 2007-2013 ) under Grant Agreement No.
The proposed system is designed as such that each component is evaluated separately and its presence is justified. It will be shown that each component yields an increase in classification performance, both separately as well as in a combined configuration, as demonstrated on public and our challenging in-house datasets. The system we propose in this paper is motivated by the need to develop a robust image-based place recognition system as a part of high-level activity analysis system developed within the IMMED project  [7]. As a part of this project, a wearable video recording prototype (see Figure  1 ) video annotation software and activity recognition algorithms were developed as well but will be left out of the scope. More detail on the latter can be found in  [7, 8]. The paper is organized as follows.
Monitoring Using Ambient Sensors. Activity recognition systems have emerged quickly due to recent advances in large video recording and in the deployment of high computation power systems. For this application field, most of proposed methods originated from scene classification where static image information is captured and categorized. Authors in  [9]  use the SVM classifier to classify local events such as "walking" and "running" in a database consisting of very clean and unoccluded video sequences. Perhaps in a more challenging setup, human behavior recognition is performed in  [10]  by proposing specially crafted sparse spatiotemporal features adapted for temporal visual data description. Conceptually a similar approach is proposed in  [11]  where each event in a soccer game is modeled as a temporal sequence of Bag of Visual Words (BOVWs) features used in a SVM classifier, termed strings, which are then compared using the string kernel.
Monitoring Using Wearable Sensors. Alternatively, activity information can be also obtained from simple on-body sensors (e. g. , acceleration) and wearable video. Authors in  [13]  investigated two methods for activity context awareness in weakly annotated videos using 3D accelerometer data. The first one is based on multi-instance learning by grouping sensor data into bags of activities (instead of labeling every frame). The second one uses a graph structure for feature and time similarity representation and label information transfer in those structures. Results favor label propagation based methods in multiple feature graphs. Visual lifelog indexing by human actions  [2, 3, 14, 15 ] is proposed recently in healthcare with expansion of the Alzheimer disease. Early attempts to answer the challenge was done in  [1, 4]  as a part of the SenseCam and IMMED projects proposing lightweight devices and event segmentation algorithms.
Motivation. Classifying the current location using visual content only is a challenging problem. It relates to several problematics that have been already addressed in various contexts such as image retrieval from large databases, semantic video retrieval, image-based place recognition in robotics, and scene categorization. A survey  [18]  on image and video retrieval methods covers the paradigms such as semantic video retrieval, interactive retrieval, relevance feedback strategies, and intelligent summary creation. Another comprehensive and systematic study in  [19]  that evaluates multimodal models using visual and audio information for video classification reveals the importance of global and local features and the role of various fusion methods such as ensembles, context fusion, and joint boosting.
Image Retrieval for Place Recognition. Image retrieval systems work by a principle that visual content presented in a query image is visually similar or related to a portion of images to be retrieved from database. Pairwise image matching is a relatively simple and attractive approach. It implies query image comparison to all annotated images in the database. Top ranked images are selected as candidates and after some optional validation procedures the retrieved images are presented as a result to the query. In  [20]  SIFT feature matching followed by voting and further improvement with spatial information is performed to localize indoors with 18 locations with each of them presented with 4 views. The voting scheme determines locations whose keypoints were most frequently classified as the nearest neighbors.