dataesr/scientific-paragraphs-categorization huggingface dataset:
Input and evaluation were provided through the design workshops, and this informed which app features were worked on for that particular development cycle. In an agile approach to software development, these features are formed through the process of refining User Stories. A user story is a short, simple description of a requirement told from the perspective of the person who desires the new capability, usually a user or customer of the system  [26]. In the context of SafePlan, the user stories originated from the initial requirements survey and were refined over the course of the design workshops.
Diary The diary element of the app is divided into 2 distinct parts. The first is a general diary where a user tracks their overall mood, sleep, or any thoughts they want to note for that day. The second centers around DBT, a well-researched treatment program that aims to help people who have difficulties managing intense emotions  [30]. All health care workers participating in the focus group were in favor of including an interactive version of a DBT diary card within the app. This involves the user entering a rating, generally between 0 and 5, for specific feelings and urges they experience throughout the day. It would also enable the user to track what DBT skills they have used over a certain time frame. One of the key objectives behind the development of the SafePlan was to ensure that it provided access to mental health support for as many people as possible.
The DBT diary card report is slightly different in that the user can select the specific seven-day period in which they would like to view their entries. This was to ensure that consistency was maintained between traditional DBT diary cards, which are generally updated on a weekly basis. The aggregation of a user's digital data and its presentation proved challenging for the design team. The collected data relates both to the user's diary, stored in the app's local database, and their overall app usage. It was agreed that this information would be most effective in chart form. The user can access the diary charts through the My Stats section of the app. The charts are dynamic in that the following options can be selected: 1. Diary item to analyze 2. Period (eg, past 7 days, past 30 days) 3.
Technologies Used The app was built using React Native, a framework for building native mobile apps for iOS and Android devices  [31]. It enables the development of native apps using JavaScript and hence greatly reduces implementation time, as two codebases do not have to be maintained when building an app for both platforms. Owing to the confidentiality and security concerns that were highlighted as part of the clinician survey, it was decided that the app's data should be stored on a device's local database rather than being uploaded to external servers. SQLite was used for the local database because it is lightweight, fast, and reliable  [32]. Sharing and exporting data from the app also impacts privacy and security-related concerns raised by the clinicians. In order for the app to be effective, it is essential that a user shares their safety plan or weekly diary card with their clinician in a secure manner.
The design group concluded that all the control should remain with the user and decided against the facility to upload data to any cloud file or external server. In the current version of the app, a user can generate a report of either their safety plan or DBT diary card for a specified period. These reports can then be printed directly from the user's device or can be saved as a PDF file and distributed as they themselves might require. This solution satisfied the criteria for ensuring that the user is fully responsible for their data and that it will stay within the user's environment unless they decide otherwise.
Quantitative Analysis The quantitative data determined from the SUS are presented in Multimedia Appendix 4. Participants recorded higher scores for ease of use and confidence in using the app. There was a relatively high mean score (3. 17) in the last question on the SUS with regard to users needing to learn many things before commencing using the app. However, this question also resulted in the highest SD (1. 95), suggesting that a greater spread of ratings occurred for this question. The question relating to inconsistency within the app received the lowest mean score (2. 28) and the lowest SD (0. 89). These markers indicate that the participants came to a consensus that the app provides users with an overall cohesive experience. The mean overall SUS rating was 71. 85  (SD 1. 38 ). An SUS score above 68 is considered above average based on research in this area  [41].
Comparison With Prior Work Many members of SafePlan's core design team were previously involved in the development of another app relating to improving outcomes in suicide prevention. The CAATCH app  [44]  was released in 2014, and its main goal was to raise awareness, provide information, and signpost to education and training programs available at the community level within the local area. In terms of the involvement of end users, CAATCH involved members of the public and patients in the design and testing phases, which guided the overall intervention and subsequently shaped the design of the current SafePlan app. It was the experience of young people accessing mental health services and actively seeking a digital means of storing and using their SafetyPlan/DBT code cards, which ultimately led to the development of the SafePlan.
The production of analytic datasets is a significant big data trend and has gone well beyond the scope of traditional IT-governed dataset development. Analytic datasets are now created by data scientists and data analysts using big data frameworks and agile data preparation tools. However, despite the profusion of available datasets, it remains quite difficult for a data analyst to start from a dataset at hand and customize it with additional attributes coming from other existing datasets. This article describes a model and algorithms that exploit automatically extracted and user-defined semantic relationships for extending analytic datasets with new atomic or aggregated attribute values. Our framework is implemented as a REST service in SAP HANA and includes a careful theoretical analysis and practical solutions for several complex data quality issues.
Context and motivation Enterprise Business Intelligence (BI) provides business users with solutions for managed data reporting, analysis, aggregation and visualization. These solutions heavily rely on trusted and well documented analytic datasets comprising multidimensional facts that hold measures and refer to one or more hierarchical dimensions  [1]. Traditionally, these analytic datasets are created by the IT department in the form of data warehouses and data marts  [2]  or by enterprise application software vendors in the form of predefined and customizable analytic models. For example, SAP provisions thousands of predefined and customizable analytic datasets, also known as "virtual data models" for various business application domains (e. g. , SCM, CRM, ERP)  [3, 4]. These datasets are defined as views over the transactional data stored and managed by the SAP S4/HANA business suite and carry information, including sophisticated measures, which is easily understandable by business users, and ready for consumption by BI tools.
Recently, agile data preparation tools  [5, 6, 7]  emerged to empower business users and data scientists to easily create their own high-quality analytic datasets from transactional data and existing analytic datasets and to build insightful and interactive personalized data visualizations. Data preparation tools have the ability to partially automate data cleaning and transformation operations, perform record linkage and duplicate elimination, and even extract structured information from unstructured data. Another typical requirement of business users or data scientists is to augment the schema of an existing analytic dataset with new attributes, coming from one or more semantically related datasets that may represent additional details on dimensions or new measures. This is a critical need in many scenarios such as the creation of data mashups (e.
g. , add demographics to sales information), or the engineering of features within datasets used to train predictive models (e. g. , features engineering to learn identifying customers that are likely to sign up for a credit card in the following quarter). Despite the importance of this task, existing data preparation tools poorly support users in augmenting the schema of an analytic dataset. This lack of assistance compels business users to redefine multiple times similar analytic datasets in a possibly inconsistent manner or to depend on their IT department to create their customized datasets. This creates an important bottleneck on the IT organization and pushes forward the deadline for making the desired datasets available to business users. Addressing the problem of agile schema augmentation in the context of building trusted analytic datasets for specific BI tasks is a major business opportunity for several reasons.
First, companies generally manage large collections of analytic datasets which keep growing with the need for new business data analysis tasks. At the scale of a large company, the facility offered by agile data preparation tools increases considerably the number of available analytic datasets with respect to those created by the IT organization or those predefined by enterprise software application vendors. Second, semantic relationships between analytic datasets, which are essential to support schema augmentation, can be accurately and automatically extracted from the dataset definitions. Indeed, analytic datasets are often defined over other datasets using queries, scripts, or views. For example, in BI applications supported by SAP, it is common to find analytic datasets with five or more levels of nested view definitions.
By parsing these view definitions it is possible to discover the dimensions shared by different analytic datasets. Third, analytic datasets are generally complemented by rich and carefully designed metadata (e. g. , about which attributes represent levels of hierarchical dimensions, or about the units and currencies of measure attributes) to support complex data analysis scenarios, that can be exploited during the schema augmentation process. Finally, IT organization and business users invest time to create analytic datasets containing high quality data (i. e. , clean data) for business process optimization and decision making. Reusing these datasets and their metadata for schema augmentation is therefore worthwhile. For all these reasons, analytic datasets are a "gold mine" of high-quality and interrelated data that is relevant to business users and data scientists, although under-exploited by current data preparation tools.
Main challenges The manual augmentation of an analytic dataset is often a cumbersome and error-prone process, raising multiple challenges illustrated hereafter. Imagine a simple use case with two analytic datasets represented by fact tables Sales and Dem(ographics) as shown in Tables  1  and 2. Attributes ORG ID, CITY   In addition, assume that SALESORG and REGION are also related through common attributes CITY and COUNTRY which means that these attributes have the same meaning in both tables. Then, tables Sales and Dem are naturally related through their common attribute YEAR which comes from the same dimension and attributes CITY and COUNTRY which come from different dimensions but are semantically equivalent. In our example, all tables are defined as views over transactional data as shown on Figure  1.
Dimension tables are represented by rounded rectangles, fact tables by square rectangles. Plain edges represent data dependencies, expressing for instance that the definition of Sales depends on SALESORG, T IM E, and some transactional data. A data analyst now might want to build a new analytic table SalesDem by augmenting the schema of dataset Sales with the measure attributes POP(ulation) and UNEMP(loyment rate) of dataset Dem. This augmentation then corresponds to yet another fact table (view) SalesDem defined by a left-outer join with Dem on the common attributes CITY, COUNTRY and YEAR.
Similarly, fact table DEM uses attributes from dimension T IM E. Thus, relationships can be extracted to identify semantically equivalent attributes of T IM E in both fact tables and to generate left-outer join queries like the query for the augmentation SalesDem of table Sales. Row multiplication. In our example, the outer-join operation increases the number of rows in Sales (e. g. , generates two rows with ORG ID = 'Oh 01') because the join attributes do not constitute a unique identifier in dataset Dem. However, for some application scenarios in feature engineering, data enrichment or data analysis, such a multiplication of rows in Sales is undesirable. There, schema augmentation should be controlled to keep the number of rows in Sales constant, leading to the notion of schema complement introduced in  [8].
This raises the challenge of identifying row multiplication by computing the unique, and possibly minimal, identifiers of analytic datasets. Incorrect and ambiguous reduction. A simple solution to avoid row multiplication is to transform table Dem by reducing partitions identified by the common attributes with Sales into single tuples. For instance, a possible reduction operation is to pre-aggregate the measures of table Dem along attribute STATE before performing a left outer join. However, this raises two new challenges. The first challenge is to choose the correct aggregation functions that can be applied to the aggregated attributes. For this we need the knowledge that POP can be summed and averaged while only a maximal or minimal value can be computed on the unemployment rate values of attribute UNEMP.
Furthermore, if an averaged POP is used to augment Sales, we must determine what aggregation functions are applicable on this new attribute in the augmented Sales dataset to avoid future incorrect aggregation operations. The second challenge is the ambiguity of the aggregated measure attributes added to Sales which, for instance, contain an aggregated value for all cities 'Dublin' in country 'USA', thereby destroying the distinction between cities in different states and sharing the same name. Ambiguous measures to should be detected and controlled, e. g. , by assigning a null value to POP and UNEMP for tuples with ORG ID = 'Oh 01' and ORG ID = 'Ca 01'. Incomplete merge. Another solution to avoid row multiplication would be to add STATE in the schema of Sales (although this is not necessary since ORG ID was supposed to be unique in Sales).
Then the common join attributes would form a unique identifier in Dem and a schema complement for dataset Sales can be obtained without any preaggregation. However, even in that case, summing POP in the augmented Sales dataset along CITY will not return the same result as summing POP along CITY in Dem, even for the same values of COUNTRY and STATE in Sales (e. g. , POP value of city 'San Jose' in 'California' will not be counted). This can be a problem if in the augmented Sales dataset, REVENUE should be compared with POP in each STATE of a COUNTRY. This issue arises because the merge of Sales with Dem is incomplete with respect to Dem and detecting incomplete merge is necessary to avoid such an erroneous analysis.
Research contributions This paper presents a new solution to assist business users and data scientists in augmenting the schema of an analytic dataset with attributes coming from other datasets. This is achieved by automatically discovering related analytic datasets and suggesting ways of building a schema augmentations, including schema complements, that resolve the challenges presented before. More specifically, we make the following technical contributions. • We introduce attribute graphs as a novel concise and natural way to define literal functional dependencies over the level types of hierarchical dimensions from which we can easily infer unique identifiers in both dimension and fact tables, and minimal identifiers in the case of dimensions. • We give the formal definitions for schema augmentation, schema complement and merge query in the context of analytic tables.
We then present several reduction operations for transforming schema augmentations with row multiplication into schema complements extending each row in the source table by a single row in the augmented table. These operations extend previous contributions on schema augmentation and schema complement (e. g. ,  [8] ,  [9] ,  [10] ) to the case of analytic datasets. • We also present formal quality criteria for schema augmentations, schema complements and merge queries. These criteria are used to define automatic repair operations (1) to notify the generation of ambiguous attributes, (2) to infer applicable aggregation functions on new attributes, and (3) to supplement merge results obtained by incomplete schema augmentation. • We describe the implementation of our solution as a REST service within the SAP HANA platform and provide a detailed description of our algorithms.
Paper outline The rest of this paper is structured as follows. In Section 2, we describe the multi-dimensional data model for analytic datasets, which is used to capture all usual concepts of hierarchical dimensions, facts, measures, and cubes  [1]. This makes our results easily applicable to any other database system implementing the concepts of multidimensional models. We also introduce the new concept of attribute graph as a way to define literal functional dependencies between dimension and fact table attributes and to compute dimension and fact table identifiers. In Section 3, we describe the relationships between analytic tables that are used to support schema augmentation and that can be automatically extracted from the definition of fact and dimensions tables. We then provide the formal definitions of schema augmentation and of natural and reduction-based schema complement.
Data Model This section presents our extension of the relational data model to model analytic tables and their semantic relationships. We assume as input to our model any relational database containing a set of non-analytic tables. Analytic tables, i. e. , dimension and fact tables, are then defined bottom-up as views over these non-analytic tables and other analytic tables. We use conventional relational database notations  [11]. Each table T is a finite multiset of tuples over a set of domains of values S = {A 1 ,. , An}, called attributes, where each domain may contain a null marker. We call S the schema of T.
Aggregable attributes In analytic tables, attributes are aggregable, but an attribute does not necessarily aggregate with any aggregate function along any dimension, as shown by extensive previous work in statistical and OLAP databases  [13]. Example 7. In the schema of fact table SALES, measure AMOUNT is aggregable using SUM along all dimension attributes. However, measure QTY ON HAND in fact table INVENTORY is not aggregable along the T IM E dimension, i. e. summing the quantity of products QTY ON HAND over all months produces is considered senseless. So, a SUM over QTY ON HAND must at least be grouped by YEAR. Our model enables the designer of an analytic table to declare for each attribute the aggregate function that is applicable and the maximal set of dimension attributes along which this aggregation can be computed.
Relationships We distinguish between join relationships and attribute-mapping relationships. Both kinds of relationships link semantically equivalent attributes and can be extracted from the view definitions of analytic tables. New join relationships between tables that are not related through views can also be added by the business user if necessary. Definition 7 (Join relationship). A join relationship R (T 1 , T 2 ) between two tables T 1 and T 2 is defined by a nonempty set of equality atoms {P 1 , • • • , P k } where each P i is of the form T 1. A = T 2. B. It relates all tuples of T 1 and T 2 satisfying the join predicate P 1 ∧ • • • ∧ P k , i. e. , the set of all related tuples is defined by Join relationships might also exist in the database schema between non-analytic tables (i. e.
ATGN (DT ID, ATT NAME, LEVEL NUM, OPTIONAL) ATGE (DT ID, ATT NAME, PARENT ATT NAME, LABEL) Each hierarchy in a dimension table is identified by a distinct DT ID value. Table ATGN stores attribute nodes, with their level in the hierarchy and whether they can take null values (OPTIONAL = 1). Table ATGE stores all edges in attribute graphs where LABEL can take values: '+', '1', 'f'. In both tables, attribute names with value ' bot' or ' top' represent the two special attributes ⊥ or respectively. Example 29. Table  9  shows tuples that encode the attribute graph of dimension W AREHOU SE in ATGN and ATGE. When an attribute graph has not been defined by a user over the hierarchy of a dimension table, Algorithm 1 provides the option to efficiently compute it from a sample of the dimension table using the indexing scheme of SAP HANA, called Hierarchy Table (HT)  [18] , which encodes the nodes of a hierarchy instance represented in a dimension or a fact table.
Related Work The notion of natural schema complement was first proposed by  [8]  for web tables (tables extracted from web page) where join relationships between tables are discovered by computing schema matching similarities  [20]  using a combination of similarity in attribute names, data types, and values (through a variant of Jaccard similarity). In the context of web tables,  [9]  presents direct and holistic schema matching techniques to discover natural schema complements for a given web table and user-specified attribute names. Similarly, Data civilizer  [10]  uses schema matching techniques to build a linkage graph between arbitrary datasets for suggesting natural schema complements. Our solution differs firstly by leveraging more "trusted" relationships which are extracted from user defined analytic fact and dimension tables (views).
This is a very positive result because our view generation process is highly accessible to a business users who only can manipulate high-level analytic views and meaningful analytic attributes without any deep expertise about the global analytic schema and table relationships. In contrast to GV, the creation of HCV view requires a strong expertise to manually optimize the sequence of operations in the view, and a precise knowledge of the database schema to express the join conditions, decide when a pre-aggregation is necessary, identify measure attributes and choose which aggregate functions are applicable to them. The preliminary price to pay for our approach is the creation of all the necessary first-level views. However, this is rapidly amortized with the number of join views in the application.
Comparison with related work We first assess previous works with respect to their capability to generate GV through the steps marked in Figure  15. The input is given by the set of analytic tables, which are essentially tables with additional metadata, so previous solutions formulated for relational databases can be applied. The schema complement approach proposed in  [8]  relates tables depending on their schema similarity scores using a combination of attribute name and domain similarity measures. In our setting, we can assume that the relationships shown in Figure  15  can be found using the same schema similarity technique. Next, the merges with natural schema complements applied in steps 1, 5, 6, 7 and 8 of Figure  15  can be suggested and computed by the method described in  [8]. However, ITEM TAX, ITEM DISCOUNT and WEB ORDER are not natural schema complements to LINEITEM, so steps 2, 3 and 4 cannot be handled.