dataesr/scientific-paragraphs-categorization huggingface dataset:
expert_mean Value is the mean observed for a taxon across its range or in this particular dataset, as estimated by an expert based on their knowledge of the taxon. Data fitting this category include estimates from floras that represent a taxon's entire range, and values for categorical variables obtained from a reference book, or identified by an expert. expert_max Value is the maximum observed for a taxon across its range or in this particular dataset, as estimated by an expert based on their knowledge of the taxon. Data fitting this category include estimates from floras that represent a taxon's entire range. experiment_min Value is the minimum of measurements from an experimental study either in the field or a glasshouse experiment_mean Value is the mean or median of measurements from an experimental study either in the field or a glasshouse experiment_max Value is the maximum of measurements from an experimental study either in the field or a glasshouse individual_mean Value is a mean of replicate measurements on an individual (usually for experimental ecophysiology studies) individual_max Value is a maximum of replicate measurements on an individual (usually for experimental ecophysiology studies) literature_source Value is a site or multi-site mean that has been sourced from an unknown literature source unknown Value type is not currently known.
A table containing observations of site characteristics associated with information in 'traits'. Cross referencing between the two dataframes is possible using combinations of the variables 'dataset_id' , 'site_name'. contextsA table containing observations of contextual characteristics associated with information in 'traits'. Cross referencing between the two dataframes is possible using combinations of the variables 'dataset_id' , 'context_name'. methods A table containing details on methods with which data were collected, including time frame and source. excluded_data A table of data that did not pass quality test and so were excluded from the master dataset. Main elements of the harmonised AusTraits database. See Tables 2-8 for details on each component.
Primary identifier for each study contributed into AusTraits; most often these are scientific papers, books, or online resources. By default should be name of first author and year of publication, e. g. 'Falster_2005'. original_nameNamegiven to taxon in the original data supplied by the authors cleaned_name Name of the taxon after implementing any changes encoded for this taxon in the metadata file for the correpsonding 'dataset_id'. taxonIDCleanWhere it could be identified, the 'taxonID' of the 'cleaned_name' for this taxon in the APC. taxonomicStatusClean Taxonomic status of the taxon identified by 'taxonIDClean' in the APC.
Acknowledgements We acknowledge the work of all Australian taxonomists and their supporting institutions, whose long-term work on describing the flora has provided a rich source of data for AusTraits, including:  Australian National Botanic Gardens ;  Australian National Herbarium; Biodiversity Science, Parks Australia; Centre for Australian National Biodiversity Research; Department of Biodiversity, Conservation and Attractions, Western Australia; Department of Environment, Land, Water and Planning, Victoria; Flora of Australia; Kew; National Herbarium of NSW; National Herbarium of Victoria; Northern Territory Herbarium ;  NSW Department of Planning, Industry, and Environment; Queensland Herbarium; State Herbarium of South Australia; Tasmanian Herbarium ; and the  Western Australian Herbarium.
taxa A table containing details on taxa associated with information in 'traits'. This information has been sourced from the APC (Australian Plant Census) and APNI (Australian Plant Name Index) and is released under a CC-BY3 license. definitions A copy of the definitions for all tables and terms. Information included here was used to process data and generate any documentation for the study. sources Bibtex entries for all primary and secondary sources in the compilation. contributors A table of people contributing to each study. taxonomic_updates A table of all taxonomic changes implemented in the construction of AusTraits. Changes are determined by comparing against the APC (Australian Plant Census) and APNI (Australian Plant Name Index). build_info A description of the computing environment used to create this version of the dataset, including version number, git commit and R session_info.
trait_name Name of trait sampled. value Measured value. sites key value dataset_id Primary identifier for each study contributed into AusTraits; most often these are scientific papers, books, or online resources. By default should be name of first author and year of publication, e. g. 'Falster_2005'. taxon_name Currently accepted name of taxon in the Australian Plant Census or in the Australian Plant Name Index. site_name Name of site where individual was sampled. Cross-references to identical columns in 'sites' and 'traits'. context_name Name of contextual senario where individual was sampled. Cross-references to identical columns in 'contexts' and 'traits'. observation_id A unique identifier for the observation, useful for joining traits coming from the same 'observation_id'. These are assigned automatically, based on the 'dataset_id' and row number of the raw data.
key value dataset_id Primary identifier for each study contributed into AusTraits; most often these are scientific papers, books, or online resources. By default should be name of first author and year of publication, e. g. 'Falster_2005'. site_name Name of site where individual was sampled. Cross-references to identical columns in 'sites' and 'traits'. site_property The site characteristic being recorded. Name should include units of measurement, e. g. 'longitude (deg)'. Ideally we have at least these variables for each site -'longitude (deg)' , 'latitude (deg)' , 'description'. value Measured value.
Primary identifier for each study contributed into AusTraits; most often these are scientific papers, books, or online resources. By default should be name of first author and year of publication, e. g. 'Falster_2005'. original_nameNamegiven to taxon in the original data supplied by the authors cleaned_name Name of the taxon after implementing any changes encoded for this taxon in the metadata file for the correpsonding 'dataset_id'. taxonIDCleanWhere it could be identified, the 'taxonID' of the 'cleaned_name' for this taxon in the APC. taxonomicStatusClean Taxonomic status of the taxon identified by 'taxonIDClean' in the APC. key value dataset_id alternativeTaxonomicStatusClean The status of alternative records with the name 'cleaned_name' in the APC. acceptedNameUsageID ID of the accepted name for taxon in the APC or APNI.
In an effort towards the democratization of Robotics, this article presents a novel End-User Development framework called Robot Interfaces From Zero Experience (RIZE). The framework provides a set of useful software tools for the creation of robot-oriented software architectures and programming interfaces, as well as the modeling and execution of robot behaviors, with a specific emphasis on social behaviors. Programming interfaces built on top of RIZE enable professionals with different backgrounds and interests to design, adapt, and scale-up robotics applications. As an example of a programming interface, we present Open RIZE, which exploits an End-User Programming paradigm combining blocks, tables, and forms-filling interfaces. Unlike previous approaches, robot behavioral code generated by Open RIZE is intrinsically modular, re-usable, scalable, neutral to the employed programming language, and platformagnostic.
It is considered a sociotechnical activity  [10] , where problem owners, i. e. , end-users, become independent from high-tech scribes  [2]. End-User Programming (EUP) is a sub-area of EUD which only focuses on the program coding phase. EUD also includes those methods supporting the entire software development life-cycle, i. e. , installation, configuration, re-design, debugging, scaling, and execution  [11]. This article presents (i) the Robot Interfaces from Zero Experience (RIZE) framework, and (ii) an EUD/EUP tool called Open RIZE. On the one hand, the RIZE framework proposes a general software architecture and a set of software tools for the creation of EUD/EUP programming environments for Robotics systems. On the other hand, Open RIZE is an experimental programming environment built on top of the RIZE tools for enabling social researchers to create real-world HRI applications with social and service robots.
Open RIZE can be installed as a typical Windows and OSX application using Wizards. Detailed instructions on how to install, use, and modify Open RIZE (including Linux-bases systems) are available in  [12]. The article is organized as follows. Section II presents related work and summarizes our contributions. Section III presents an overview of the RIZE framework. Section IV describes the main features of Open RIZE, whereas Section V describes the cognitive software architecture implemented in Open RIZE. Section VI briefly describes a set of applications developed using different versions of Open RIZE and presents results from an initial usability assessment. Conclusions and future work follow.
However, the interface developed to demonstrate the capabilities of this framework, denoted as Open RIZE, is mostly aimed to be an easy-to-use tool that enables different types of adult end-users the rapid prototyping of real-world HRI applications. Therefore, the rest of the article will center in EUD/EUP tools for proffesional use. HRI processes (and the interaction with virtual agents), including those involving social capabilities, are typically designed by expert developers using general-purpose scripting languages such as Python. This approach is error-prone and generates accessibility, usability, and maintainability issues  [27]. A recent trend towards improving the accessibility of scripting approaches is to enable the adoption of more user-friendly and engaging programming environments through the use of block-based programming languages such as Snap!  [28] , Scratch  [29]  and Google Blockly  [30].
Composite nodes use these three possible statuses to perform behavior composition. For a deeper explanation of BTs the reader is referred to  [38] ,  [41]. Compared with FSM, BTs are known to be more modular: portions of code, denoted as ''sub-BTs'', can be easily re-used to create more complex tasks. The main objective of RIZE is to provide a set of conceptual and operative tools that facilitate the integration of robot behavioral modules, specifically robot social skills, organized in a full-fledged software architecture. Rather than only focus on some specific programming or behavior modeling approach, RIZE was designed to enable the exploration of novel, structured, modular, reactive and advanced behavioral modeling methods and visual languages. This perspective represents the main difference with respect to previous EUP/EUD tools for robotics  [1].
In the next sections, we present an example of a programming interface built on top of RIZE framework denoted as Open RIZE which uses a combination of FSMs and BTs for enabling decision-making. This interface integrates a programming environment extending the functionalities of Google Blockly to enable the intuitive creation of robot behaviors by novice end-users as well as the rapid prototyping and integration of robot-based applications. Most approaches in the literature employing a block-based Visual Programming Language (VPL), such as Google Blockly, allow for the direct translation of block definitions to code in a text-based programming language. We explored this approach in an early prototype of RIZE  [42]. The programming environment proposed in  [42]  translates the structure developed in Google Blockly to text-based code in Python.
On the other hand, several open source projects assume the use of modules developed for a limited set of programming languages, or targeted at specific operating systems. Open RIZE is free for research purposes and enables the integration of modules developed in a wide variety of programming languages. It can also be executed on the most popular desktop and mobile operating systems. On a practical side, many EUD tools for Robotics require the use of the command line for installing main and third-party libraries, which is error-prone and subject to the help of experts. This issue affected also previous versions of RIZE  [42] ,  [45] , which required the use of the Python Package Index (PyPI) using the command line  [49]. In its current version, RIZE interfaces can be installed, uninstalled, and executed in either Windows or OSX using installation wizards.
NEP has been designed to allow developers who are not proficient in ROS/ROS2 development, or whose main focus is not Robotics-oriented, to easily integrate their modules. Modules, which are part of the Application Layer, can be developed using different, modern programming languages and environments, such as C#, Python (2 and 3), Java, Matlab, and JavaScript (via Node. js). RIZE includes NEP in its installer package. At the top layer of the architecture lies the RIZE programming environment, also referred to as the End-user Layer. A RIZE interface uses HTML/CSS for defining visual elements and JavaScript for the development and integration of web-based libraries, such as Google Blockly. It uses Vue. js for building user interfaces  [53]. This JavaScript framework uses the Model-View-ViewModel (MVVM) methodology  [54] , which is a software architectural and structural pattern aimed at enforcing the separation and development of Graphical User Interfaces (GUIs).
RIZE interfaces use Electron, i. e. , a JavaScript framework for creating native applications with web technologies, and node. js, which is an event-driven and asynchronous JavaScript run-time environment used to create server-side applications. In this way, RIZE supports the creation of cross-platform desktop applications, which can be installed from user-friendly desktop installers. This approach avoids the use of command line instructions and the compilation of source code for software installation and execution. It also hides low-level tasks or interfaces, such as terminals, thereby enabling the development of production-ready programming environments applications for social robots. Moreover, web-based tools enforce an easy development of usable, modern, attractive, and beautiful interactive tools.
Whilst different communication-related design patterns exist and have been discussed in the literature, RIZE adopts a simple publish-subscribe strategy for inter-RIZE module communication, with the aim of enforcing asynchronous data exchange and improving the overall robustness and fault-tolerance of the resulting software architecture. In order for a module to communicate with other modules in the architecture, a developer must specify its required (i. e. , the topics it is subscribed to) and provided (i. e. , the topics it is publishes information upon) interfaces. Every topic structure must be registered beforehand with the master node, which then manages the endpoint information for each topic. When a topic registration request is detected by the master module, an endpoint direction is assigned to a specific topic.
B. DESIGN AND FEATURES OF THE OPEN RIZE INTERFACE To design the graphical elements in the Open RIZE interface we use Vuetify. js, a material design framework  [62]. As described in  [60] , material design is a group of ''guidelines, components, and tools that support the best practices of user interface design''. These guidelines were originally proposed by Google, and are used in many software products, examples being Gmail, Google Docs, Google Translator, Google Maps, and the Android and Google Search interfaces. These are, as a matter of fact, tools widely used by the generic user in everyday life. Therefore, the adoption of material design not only allows for the creation of user interfaces adhering to current aesthetic tendencies, but that are also more familiar and consistent. Figure  3  shows the home tab of the current version of Open RIZE.
An example is shown in Figure  5. Robot behaviors are classified as reactions and goals, which are explained in depth in Section V. Furthermore, Open RIZE provides graphical elements encapsulating a sequence of robot actions in modules. Open RIZE includes a predefined set of lists of sub-programs, whereby the user can add, delete or update relevant behavioral modules. Each sub-program is modeled as an independent BTs. Therefore, a Open RIZE project consist of a set of modular behaviors or sub-BTs organized by categories in lists. When selecting an item from one of these lists, a new interface appears. An example is shown in Figure  6. Programming interfaces in Open RIZE provide error prevention and recovery mechanisms, such as confirmation options before performing risky actions, undo and redo buttons.
C. COMBINING BLOCKS AND FORMS Open RIZE is a novel approach to program complex robot social behaviors, expanding the capabilities of such blocks-based programming tools as Google Blockly with form-filling interfaces. In our use cases, blocks are used to  organize and structure robot behaviors as a combination of social skills, modules to manage perceptual inputs and to perform robot actions, whereas the associated form-filling interfaces are used to tune their parameters. Figure  7  shows an example of a block element representing a given social skill, and its related form-filling interface, whereby robot text-to-speech capabilities can be modified. In this case, the user can alter either the velocity or the pitch (or both) of the robot's voice, the text to utter, and select whether this action requires the concurrent execution of any contextual animation.
D. MODIFYING ROBOT SOCIAL BEHAVIORS IN OPEN RIZE Any visual element in Open RIZE can be modified using a Python tool called Open RIZE Blockly Generator. As shown in Figure  8 , developers can add new robot social behaviors to the Open RIZE programming environment by defining their main attributes in a JSON file. These specifications are read by a Python tool that generates the JavaScript and HTML code defining the design of block elements and their parameters in the form-filling interfaces of each behavior. All the guidelines for adding new robot social behaviors to Open RIZE are described in the documentation web page of the Open RIZE Blockly Generator tool  [63]. As an example, let us suppose speech capabilities must be added, as shown in Figure  7. If a speech-related behavior is available (maybe it corresponds to a set of specifically developed ROS nodes), the associated parameters can be defined using a formalism similar to that reported in Listing 1.
V. THE OPEN RIZE's COGNITIVE ARCHITECTURE Figure  9  shows the scheme of an interaction-oriented cognitive architecture implemented in Open RIZE and adopted in a series of real-world applications and software development workshops with non technically-skilled end-users. The architecture is composed of a set of knowledge-making modules (i. e. , sensory and perception behaviors), a blackboard system, a hybrid decision-making engine, and a set of robot action-making modules. Communication among modules is mainly managed by the NEP master node. Specific applications using nodes developed in ROS require the integration with a ROS master node and the rosbridge server.
D. ACTION-MAKING The primary function of this module is to manage the execution of the robot commands sent by the decision-making engine. It is important to highlight that to enable a BT-based architecture to react to changes, periodical feedback of the state of the actions must be done between the decision-making engine and the action-making  [38]. For this, the action-making publishes the current state of the robot's actions back to the decision-making engine. This information is used for the decision-making engine to manage the robot behaviors. The implemented action-making modules in Open RIZE are written in Python and can also be connected to low-level control modules (e. g. Moveit  [65]  for motion planning and execution) in other programming languages using NEP or ROS frameworks. To help with the integration and re-use of robot functionalities written in Python, we provide the rize package.
Through collaborative project with various people in this situation, we refined incrementally Open RIZE. End-users were invited to directly program and execute the desired robot behaviors using several versions of the Open RIZE interface. Applications developed by end-users include robots on stage (performed in 2017 and presented in  [42] ), robots in domestic settings (performed in 2018 and presented in  [68] ), Children-Robot Interaction (CHI) (performed in 2019 and presented in  [46] ), and co-design workshops (performed in 2020 and which preliminary results are presented in  [69] ,  [70] ). For each collaboration, the main outcomes were: (i) the integration of novel methods and technologies to satisfy the requirements of end-users, (ii) design of a block-based programming environment adapted to the context of the end-user applications, and (iii) evaluation and implementation of applications developed by end-users in real and public settings.
We briefly describe main objectives of these collaborative projects below. Main outcomes, requirements, and technologies implemented in each of these projects are summarized in table  2. The initial version of RIZE used a programming interface where robot behaviors are modeled as simple IF-THEN-ELSE rules which launched a set of sequential behaviors. As described in  [45] , this interface was developed on top of a Python-based web server and basic functionalities of Google Blockly. We use initial version to enable comeand social researchers to design and develop simple interactive scenarios with social robots  [42]. In this way, professionals were able to explore new paradigms supporting their profession. An example of application shown in  [71]  is the design of a set of short comical sketches between human actors and a NAO social robot.
For the creation of interactive scenarios in domestic environments  [68]  and CHI  [46] , it was required to increase the reactivity, re-usability, and complexity of those behaviors designed by end-users. In these two cases, social robots required to dynamically react to multi-modal inputs and perform different types of activities, such as games, exercise routines, dance, display current weather conditions, among others. To enable the easy creation of more reactive, complex, and dynamic behaviors, we substituted the rule-based systems as the main programming approach by Behavior Trees. We also substituted the proposed Python-based web-server developed in  [45]  by a Node. js to back-end RIZE interfaces (as described in section III). In comparison with server-side web frameworks in Python, Node.
One of this questionnaire was the System Usability Scale (SUS), giving an idea of the level of usability of Open RIZE. SUS consists of 10 Likert items with five response options varying from strongly agree (5) to strongly disagree (1). This questionnaire is an industrial standard that researchers and practitioners should strongly consider using  [73]. SUS allows a reliable and valid evaluation of a wide variety of products and services such as hardware, software, websites, and applications. Moreover, it can be used in a small group of people and still offer reliable results with twelve persons  [74]. To calculate SUS score is required to follow the next steps: (1) subtract 1 from the score obtained in odd questions, (2) for each even question subtract their value from 5, (3) add the values obtained from step 1 and 2 to the total score, (4) multiply the total score by 2.