dataesr/scientific-paragraphs-categorization huggingface dataset:
Software overview In this section, we introduce our open-source software with an overview of its architecture. This software is composed of two main modules, represented in Figure  3. While the robot is learning the Probabilistic Movement Primitives (ProMPs) associated to the different tasks, the robot is controlled by its user. The user's guidance can be either manual for the real iCub, or through a haptic device for the simulated robot. A Matlab module allows replaying movement primitives or finishing a movement that has been initiated by its user. By using this module, the robot can learn distributions over trajectories, replay movement primitives (using the mean of the distribution), recognize the ProMP that best A C++ module forwards to the robot the control that comes either from the user or from the Matlab module.
Then, the robot is able to finish a movement initiated by its user (directly or through a haptic device) in an autonomous way, as shown in Figure  1. We present the C++ module in Section 6. 2 and the theoretical explanation of the Matlab module algorithms in Section 3. A guide to run this last module is first presented in Section 5 for a simple example, and in Section 6 for our application, where a simulated robot learns many measured information of the movements. Finally, we present results on the real iCub application in Section 7. Our software is available through the GPL licence, and publicly available at: https://github. com/inria-larsen/icubLearningTrajectories. Tutorial, readme and videos can be found in that repository. First, the readme file describes how to launch simple demonstrations of the software.
The first lines of these functions give an explanation of their functioning and precise what are the input(s) and output(s) parameters. • Matlab scripts called "demo *. m". They are simple examples of how to use this toolbox. The script demo plot1DOF. m, can be used to compute a ProMP and to continue an initiated movement. The ProMP is computed from a dataset stored in a ". mat" file, called traj1 1DOF. mat. In this script, variables are first defined to make the script specific to the current dataset: 1 %%%%%%%%%%%%%%%VARIABLES, please look at the README 2 %Can be either ". mat" or ". txt". In the current demo, you can also write. DataPath = Data/traj1 if you want to use the text files of this dataset. 12 %('MO':model/'ML'maximum likelihood/ 'ME' average/'DI' distance).
To recover data recorded in a ". txt" file, we call the function: t{1} = loadTrajectory(PATH, nameT, varargin) Its input parameters specify the path of the recorded data, the label of the trajectory. Other information can be added by using the varargin variable (for more detail, check the header of the function with the help comments). The output is an object that contains all the information about the demonstrated trajectories. It is composed of nbTraj, the number of trajectory; realTime, the simulation time; y (and yMat), the vector (and matrix) trajectory set , etc. Thus, t{1}. y{i} contains the i-th trajectory. The Matlab function drawRecoverData(t{1}, inputName,'namFig', nFig, varargin) plots in a Matlab figure (numbered nFig) the dataset of loaded trajectories. An example is shown in Figure  4 , on the left.
Incidentally, the different duration of the trajectories is visible: on average, it is 1. 17 ± 0. 42 seconds. To split the entire dataset of demonstrated trajectories t{1} into a training dataset (used for learning the ProMPs) and a test dataset (used for the inference), call the function For debugging purposes and to understand how to tune the ProMPs' parameters, it is interesting to plot the overlay of the basis functions in time. Choosing an appropriate number of basis functions is important, as too few may be insufficient to approximate the trajectories under consideration, and too many could result in over-fitting problems. To plot the basis functions, simply call: drawBasisFunction(promp. PHI,M) where promp. PHI is a set of RBFs evaluated in the normalized time range t ∈ [1 : s]. Figure  5  shows at the top the basis functions before normalization, and at the bottom the ProMP modeled from these basis functions.
Setup for simulated iCub For this application, we created a prototype in Gazebo, where the robot must reach three different targets with the help of a human. To interact physically with the robot simulated in Gazebo, we used the Geomagic touch, a haptic device. The setup consists of: • the iCub simulation in Gazebo, complete with the dynamic information provided by whole-BodyDynamicsTree (https://github. com/robotology/codyco-modules/tree/master/src/ modules/wholeBodyDynamicsTree) and the Cartesian information provided by iKinCarte-sianController ; • the Geomagic Touch, installed following the instructions in https://github. com/inria-larsen/ icub-manual/wiki/Installation-with-the-Geomagic-Touch, which not only install the SDK and the drivers of the GeoMagic but also point to how to create the yarp drivers for the Geomagic; • a C++ module (https://github.
com/inria-larsen/icubLearningTrajectories/tree/ master/CppProgram) that connects the output command from the Geomagic to the iCub in Gazebo, and eventually enables recording the trajectories on a file. A tutorial is included in this software. The interconnection among the different modules is represented in Figure  3 , where the Matlab module is not used. The tip of the Geomagic is virtually attached to the end-effector of the robot: x geo → x icub hand When the operator moves the Geomagic, the position of the Geomagic tip x geo is scaled (1:1 by default) in the iCub workspace as x icub hand , and the Cartesian controller is used to move the iCub hand around a "home" position, or default starting position: x icub hand = hapticDriverM apping(x 0 + x geo ) where hapticDriverMapping is the transformation applied by the haptic device driver, which essentially maps the axis from the Geomagic reference frame to the iCub reference frame.
Data acquisition The dark button of the Geomagic is used to start and stop the recording of the trajectories. The operator must click and hold the button during the whole movement and release the button at the end. The trajectory is saved on a file called recordX. txt for the X-th trajectory. The structure of this file is: Demonstrated trajectories and their corresponding forces can be recorded directly from the robot, by accessing the Cartesian interface and the wholeBodyDynamicsTree module. 13 n our project on Github, we provide the acquired dataset with the trajectories for the interested reader who wishes to test the code with these trajectories. Two datasets are available at https:// github. com/inria-larsen/icubLearningTrajectories/tree/master/MatlabProgram/Data/: the first dataset called "heights" is composed of three goal-directed reaching tasks, where the targets vary in height; the second dataset called "FLT" is composed of trajectories recorded on the real robot, whose arms moves forward, to the left and to the top.
Another use for the demonstrated wrenches is for detecting abnormal forces while the robot is moving: this use can have different applications, from adapting the motion to new environment to automatically detecting new demonstrations. Here, they are simply used to detect when the partner breaks the contact with the robot, and the latter must continue the movement on its own. In the following, we present how to realize the experiment for predicting the user intention with the real iCub, using our software. The robot must learn three task trajectories represented in Figure  11. In red, the first trajectory goes from an initial position in front of the robot to its left (task A). In green, the second trajectory goes from the same initial position to the top (task C). In blue, the last trajectory goes from the top position to the position on the left (task B).
To provide demonstrations for the tasks, the human tutor used three visual targets shown on the iCub GUI, a basic module of the iCub code that provides a real-time synthetic and augmented view of the robot status, with arrows for the external forces and colored objects for the targets. One difficulty for novice users of iCub is to be able to drive the robot's arm making it perform desired complex 3D trajectories  [76] , but after some practice in moving the robot's arm the operator recorded all the demonstrations. We want to highlight that having variations in the starting or ending points of the trajectories is not at all a problem, since the ProMPs are able to deal with this variability. We will see that by using the ProMPs method and by learning the end-effector Cartesian position, the robot will be able to learn distributions over trajectories, recognize when a movement belongs to one of these distributions and infer the end of the movement.
In this experiment, the robot received 10 demonstrated trajectories per movement primitive, all provided by the same user. We recorded the Cartesian end-effector position and the wrenches of the robot's left arm. Data are retrieved using the function used functions/retrieveRealDataWithoutOrientation. m. The output parameters of this function are three objects (one per ProMP) that contain all the These three objects are saved in 'Data/realIcub. mat'. A Matlab script called demo plotProMPsIcub. m recovers these data, using the function load('Data/realIcub. mat'). This script follows the same organization as the ones we previously explained in Sections 5 and 6. By launching this script, the recovered data are plotted first. Then, the ProMPs are computed and plotted, as presented in Figure  12.
In this figure, the distributions are visibly overlaid: • during the whole trajectories duration for the wrench information; • during the 40% first samples of the trajectories for the Cartesian position information. After this learning step, the user chooses which ProMP to test. Using a variable that represents the percentage of observed data to be used for the inference, the script computes the number of early observations n o 16  that will be measured by the robot. Using this number, the robot models the time modulation parameter α 17  of each ProMP, as explained in Section 3. 4. Using this model, the time modulation of the test trajectory is estimated and the corresponding ProMP is identified. Then, the inference of the trajectory's target is performed. Figure  13  represents the inference of the three tested trajectories when wrench information is not used by the robot to infer the trajectory.
To realize this figure, with the comparison between the predicted trajectory and the ground truth, we applied our algorithm offline. In fact, it is not possible at time t to have the ground truth of the trajectory intended by the human from t + 1 to t f : even if we would tell to the human in advance the goal that he/she must reach for, the trajectory to reach that goal could vary. So, for the purpose of these figures and comparisons with the ground truth, we show here the The prediction of the future trajectory from the learned ProMPs computed from the position information for the 3-targets dataset on the real iCub (Figure  12 ) after 40% of observations. set used to learn the ProMP) as ground truth, and imagine that this is the intended trajectory. Figure  13 , the ground truth is shown in black, whereas the portion of this trajectory that is fed to the inference, and that corresponds to the "early observations", is represented with bigger black circles.
We will address these issues and the continuous prediction in future works. Improving computational time -Finally, we plan to improve the computational time for the inference and the portability of our software by porting the entire framework in C++. Learning tasks with objects -In many collaborative scenarios, such as object carrying and cooperative assembly, the physical interaction between the human and the robot is mediated by objects. In these cases, if specific manipulations must be done on the objects, our method still applies, but not only on the robot. It must be adapted to the new "augmented system" consisting of robot and object. Typically, we could image a trajectory for some frame or variable or point of interest for the object, and learn the corresponding task. Since ProMPs support multiplication and sequencing of primitives, we could exploit the properties of the ProMPs to learn the joint distribution of the robot task trajectories and the object task trajectories.
CONCLUSION In this paper we propose a method for predicting the intention of a user physically interacting with the iCub in a collaborative task. We formalize the intention prediction as predicting the target and "future" intended trajectory from early observations of the task trajectory, modeled by Probabilistic Movement Primitives (ProMPs). We use ProMPs because they capture the variability of the task, in the form of a distribution of trajectories coming from several demonstrations of the task. From the information provided by the ProMP, we are able to compute the future trajectory by conditioning the ProMP to match the early observed data points. Additional features of our method are the estimation of the duration of the intended movement, the recognition of the current task among the many known in advance, and multimodal prediction.
Figure7: The prediction of the future trajectory given n o = 40% of early observations from the learned ProMP computed for the test dataset (Figure4). The plots show the predicted trajectory, using different criteria to estimate the best phases of the trajectory: using the average time modulation (Equation11); using the distance criteria (Equation13); using the maximum log-likelihood (Equation12); or using a model of time modulation according to the time variation (Equation14).
Decision and Trace Variants Mining Based Approach The approach presented in Fig. 2  is the global workflow of the proposal and enables the achievement of the current research objective through seven steps. The first step of the approach concerns the construction of the event log from the past process executions. These latter represent the process traces generated with respect to the trace metamodel depicted in  [22, 23]  and expressed in XMI (XML Metadata Interchange) format. These traces should be automatically merged into a single XES  7 (eXtensible Event Stream) event log in order to be processed in ProM, the framework in which the selected decision mining technique is developed. This automatic merge is implemented using ATL  8  (Atlas Transformation Language). The second step concerns the generation of the petri net model from the event log.
Therefore, to avoid this situation and be sure to have a correct decision rule, authors propose to execute the data flow discovery plug-in for each variable, this results in as much decision rules as variables (step 3 in Fig. 2 ). The PNML files, that are generated in step 3, should be automatically merged into one single PNML file that contains the complete decision rules, i. e. related to all the event log's variables (step 4 in Fig. 2 ). This automatic merge is implemented using the Java programming language. In parallel with decision mining (finding the Or and XOR rules), the trace variants mining can be performed in order to find the end-to-end processes (e. g. patterns 1 to 9 in Fig. 1 ). The Explore Event Log visualizer, as discussed in Section 2, is used to explore patterns in an event log.
Thus, the employee has to understand the customer's needs and elicit his/her preferences while configuring the Geohub. An important challenge is to propose a smart interface, smart enough to let the customers configure the Geohub by themselves. The customers would have a phone conversation with a virtual assistant. We know that natural language processing (NLP) deals with NP-complete problems, which is why such an interaction needs many contextual elements to limit the possibilities. However, even with context, the problem remains quite hard since it implies important expertise to be able to translate the needs expressed in a natural language into a set of Forth scripts and programs written in other languages. Thus, there is a need for tools to capture these sometimes imprecise requirements (e.
Syntax is part of formal grammar that deals with rules for the structure of a string (distribution of words, noun and adjective agreements, etc. ). Meaning and formal syntax are the basis of the comprehension, according to Chomsky  [9]. Moreover, there have been a lot of works about semantic parsing and question answering. For example, Popescu and collaborators developed semantic parsing for querying databases  [10] , Berant et al. trained a semantic parser on a web database, learning from question-answer pairs  [11] , and Shi and Mihalcea integrated several lexical resources into a unified knowledge base to enable robust semantic parsing  [12]. Our aim is a bit different: we aim at building a (rather small) business-oriented database, depending on the needs of customers and on the way the experts define the business processes.
NLP and Fuzzy Linguistics Offering an interface based on a full natural language dialogue is a complex task that is NP-hard. Thus, reducing the complexity is compulsory. The semantic analysis implies using a substantial database to catch the meaning of the dialogue and to take into account the imprecision and subjectivity due to the natural language and human reasoning. In the following, we propose an approach to elicit the choices (in a natural language interface), so the experts can express their business process needs: configure the GPS mobiles and create geolocation alerts easily.
The first step of the dialogue interface construction is to prepare a lexicon to be able to analyze the sentences. The lexicon is built from a corpus of documents among which are advertisements from the company, some documentation of the web applications and of the Application Programing Interface (API), and language files (if the interface is conceived and designed for several countries). In software engineering, texts displayed in the applications as well as the labels, the buttons, the menu titles, the help menu, and so forth are grouped together in a single "key-value" file for each supported language. Values are dynamically loaded while the software is being started and the language file chosen is the one that the user speaks. This permits separating style (text) and content (code) and facilitating the software translations.
). These tags may help to disambiguate certain words (e. g. , "base" can be an adjective, a noun, or a transitive verb) since this kind of ambiguity is very common in a natural language  [8]. PoS tagging is realized through automatic tagging tools such as TreeTagger (http://www. cis. uni-muenchen. de/ ∼schmid/tools/TreeTagger/). TreeTagger permits regrouping the PoS tagging and the lemmatization: it groups together the different inflected forms of a word so they can be analyzed as a single item. Then, we add semantic tags to the most relevant lexicon inputs, from a business-level point of view. These tags permit representing the knowledge and the semantic concepts. Thus, several inputs (words) can be linked to these semantic tags. The empirical way to build the lexicon is unavoidable and necessary because expert knowledge is needed.
Towards an Approach of a Dialogue Software Agent The dialogue interface in natural language we propose is a kind of software agent. then to realize the tasks that follow, such as creating an alert on the Geohub, configuring a mobile device, and displaying information of a user account. The agent uses the business lexicon and grammar that it loads dynamically while launching. The lexicon is stored in a hash table while the grammar is loaded through a TAG (tree-adjoining grammar). Despite the fact that the tree representation is restrictive regarding the knowledge representation, the tree is easier to use for immediate processing through database querying. In case of ungrammatical statements, the sentence is analyzed without any error because only the semantic tags are retrieved. If no semantic tag is detected, the agent asks a question to obtain those tags.
Prototype Implementation. We have developed a prototype software agent for a dialogue in natural language specialized for geolocation in an Android application. To facilitate the dialogue, we used the speech recognition and synthesis of Android system for the user interaction. The application called DeveryDialog permits realizing several tasks like programing an alert, displaying the mobile list for a count, changing the frequency of data (GPS positions) collection, and so forth. Figure  5  shows a short dialogue (in French) in four screens (from left to right and from top to bottom). Screen 1 is the welcome message ("Hello, what do you want to do?"). Screen 2 shows the wish of the user ("I would like to create an alert when my son gets close to Paris") and the answer of the software agent ("Who do you want to send the notification to?").
Conclusion Starting from a real-case study for a company, this paper proposes and explains a generic method to take into account natural language in a geolocation interface where an implementation has been proposed. A lexicon has been created, dedicated to the geolocation field using PoS tagging and dictionaries of synonyms. The internal representation of the imprecision, that is, the fuzzy semantics of the sentences, is dealt with in a model inspired by the 2-tuple fuzzy linguistic representation model by Herrera and Martínez where unbalancement is the key concept. The partition is constructed while taking into account the semantics of the concepts (synonyms and resemblance rate matrices). A dialogue software agent has been implemented on Android platform. In future works, we will formalize the partitioning method that uses synonyms.
Software industry has evolved to multi-product and multi-platform development based on a mix of proprietary and open source components. Such integration has occurred in software ecosystems through a software product line engineering (SPLE) process. However, metadata are underused in the SPLE and interoperability challenge. The proposed method is first, a semantic metadata enrichment software ecosystem (SMESE) to support multi-platform metadata driven applications, and second, based on mapping ontologies SMESE aggregates and enriches metadata to create a semantic master metadata catalogue (SMMC). The proposed SPLE process uses a component-based software development approach for integrating distributed content management enterprise applications, such as digital libraries. To perform interoperability between existing metadata models (such as Dublin Core, UNIMARC, MARC21, RDF/RDA and BIBFRAME), SMESE implements an ontology mapping model.
Introduction With more and more data available on the web, how users search and discover contents is of crucial importance. There is growing research on interaction paradigms investigating how users may benefit from the expressive power of semantic web standards. The semantic web may be defined as the transformation of the worldwide web to a database of linked resources, where data may be widely reused and shared  [1]. Web services can be enhanced by drawing on semantically aware data made available by a variety of providers. In addition, as information discovery needs to become more and more challenging, traditional keyword-based information retrieval methods are increasingly falling short in providing adequate support. This retrieval problem is compounded by the poor quality of the metadata content in some digital collections.