Irvin Dongo
email: irvin.dongo@univ-pau.fr

Yudith Cardinale
email: ycardinale@usb.ve

Firas Al-Khalil
email: firas.alkhalil@ucc.ie

Richard Chbeir
email: richard.chbeir@univ-pau.fr

Semantic Web Datatype Inference: Towards Better RDF Matching

Keywords: Datatype Analysis, Datatype Inference, XML, RDF, Semantic Web

In the context of RDF document matching/integration, the datatype information, which is related to literal objects, is an important aspect to be analyzed in order to better determine similar RDF documents. In this paper, we propose a datatype inference process based on four steps: (i) predicate information analysis (i.e., deduce the datatype from existing range property); (ii) analysis of the object value itself by a pattern-matching process (i.e., recognize the object lexical-space); (iii) semantic analysis of the predicate name and its context; and (iv) generalization of numeric and binary datatypes to ensure the integration. We evaluated the performance and the accuracy of our approach with datasets from DBpedia. Results show that the execution time of the inference process is linear and its accuracy can increase up to 97.10%.

Introduction

The Semantic Web enables the integration and combination of data from different sources by providing standard models such as RDF, OWL, etc. [START_REF] Sandro Hawke | W3C Semantic Web Activity[END_REF]. Particularly, heterogeneous RDF documents can express similar concepts using different vocabularies. Hence, many efforts focus on describing the similarity between concepts, properties, and relations to support RDF document matching/integration (e.g., Linked Open Data integration, ontology matching) [START_REF] Mukkala | Current state of ontology matching. a survey of ontology and schema matching[END_REF][START_REF] Algergawy | XML Schema Element Similarity Measures: A Schema Matching Context[END_REF][START_REF] Algergawy | A sequence-based ontology matching approach[END_REF].

RDF describes concepts as triples, subject, predicate, object , where subject, predicate, and object are resources identified by their IRIs. Objects can also be literals (e.g., a number, a string), which can be annotated with optional type information, called datatype. A datatype is a classification of data, which defines types for RDF, adopted from XML Schema [START_REF] Paul | XML Schema Part 2: Datatypes Second Edition, W3C Recommendation[END_REF]. There are two classes of datatypes: Simple and Complex. Simple datatypes can be primitive (e.g., boolean, float), derived (e.g., long, int derived from decimal), or userdefined, which are built from primitive and derived datatypes by constraining some of its properties (e.g., range, precision, length, format). Complex datatypes contain elements defined as either simple or complex datatypes. A W3C Recommendation [START_REF] Patrick | RDF 1.1 Semantics, W3C Recommendation 25 February[END_REF] points out the importance of the existence of simple datatype annotations to detect entailments between objects that have identical datatype but a value represented in different formats. Moreover, it has been proven that the presence of datatype information, constraints, and annotations on an object improves the similarity measures between two documents (up to 14%) [START_REF] Algergawy | XML Schema Element Similarity Measures: A Schema Matching Context[END_REF].

When this information is missing, datatype inference emerges as a new challenge in order to obtain more accurate RDF document matching results. In the context of XSD, works such as [START_REF] Chidlovskii | Schema extraction from xml collections[END_REF][START_REF] Hegewald | Xstruct: Efficient schema extraction from multiple and large xml documents[END_REF] infer simple datatypes by a patternmatching process on the format of the values; i.e., the characters that make unique a datatype, which is called lexical space according to the W3C Recommendation [START_REF] Paul | XML Schema Part 2: Datatypes Second Edition, W3C Recommendation[END_REF]. These works consider a limited number of simple datatypes (date, decimal, integer, boolean, and string), thus for other datatypes, as year (e.g., 1999), this method cannot determine its correct datatype. Others works in the context of programming languages and OWL are focused on inferring complex datatype through axioms, assigned operations, and inference rules [START_REF] Fluet | Practical datatype specializations with phantom types and recursion schemes[END_REF][START_REF] Holdermans | Random testing of purely functional abstract datatypes: Guidelines for dealing with operation invariance[END_REF][START_REF] Paulheim | Type inference on noisy rdf data[END_REF], which are elements not present in an RDF document for simple datatypes. Thus, in the context of RDF document matching/integration, these works are not suitable mainly for two reasons: (i) lexical space based methods cannot infer all simple datatypes, since there are intersections between datatype lexical spaces (e.g., 1999 can be an integer or a gYear according to the lexical space of both W3C datatypes); and (ii) complex datatype inference methods cannot be applied to simple datatypes, since in RDF, a simple datatype is an atomic value associated to a predicate.

To overcome these limitations, we propose a new approach that considers, in addition to the lexical space analysis, the analysis of the predicate information related to the object. It consists of four steps: (i) Analysis of predicate information, such as range property that defines and qualifies the type of the object value; (ii) Analysis of lexical space of the object value, by a pattern-matching process; (iii) Semantic analysis of the predicate and its semantic context, which consists in identifying related words or synonyms that can disambiguate two datatypes with similar lexical space; and (iv) Generalization of Numeric and Binary datatypes, to ensure a possible integration among RDF documents. Moreover, we experimentally evaluated the accuracy and performance of our approach by using DBpedia databases. Results show a high accuracy (F-score up to 97.10%) and a linear execution time (O(n)).

The rest of the paper is organized as follows: Section 2 presents a motivating scenario. Section 3 surveys the related literature. RDF terminologies are presented in Section 4. Section 5 describes our inference approach. Section 6 shows the experiments. We conclude in Section 7.

Motivating Scenario

In order to illustrate the importance of datatype information for RDF documents, we consider a scenario in which we need to integrate three RDF doc- uments with similar concepts (resources) but based on different vocabularies. Fig. 1 shows three concepts from three different RDF documents. Figs. 1a and1b describe the concept Light Switch, with property (predicate) isLight, whose datatype is boolean. However, they are represented with different lexical spaces: binary lexical space with value 1 in Fig. 1a and string lexical space with value true in Fig. 1b. In both cases, isLight property expresses the state of the light switch (i.e., turned on or turned off). Fig. 1c shows the concept Light Bulb, with property Efficiency, whose datatype is integer, and property Light representing the luminosity of the light (luminous flux), whose datatype is float.

For the integration, it is necessary to analyze the information of their concept properties. Intuitively, considering the datatype information, we can say that:

1. Both Light Switch concepts from Figs. 1a and 1b are similar, since their properties are similar: the isLight property is boolean in both cases, and boolean literals can be expressed either as binary values (0 or 1) or string values (true or false) according to the W3C [START_REF] Paul | XML Schema Part 2: Datatypes Second Edition, W3C Recommendation[END_REF]. 2. Light Bulb concept is different from the other ones. Indeed, the Light property is expressed with float values, expressing the light intensity instead of light switch state (i.e., turned on or turned off). If the datatype information is missing and the integration is made only based on literals, we have problems related to the ambiguity of properties. Contrary to our intuition, concepts in Figs. 1a and1b are incompatible because of the use of different lexical spaces (i.e., value 1 is not compatible with value true, which can be considered as a string datatype instead of boolean). The integration of concept Light Switch from Fig. 1a with concept Light Bulb from Fig. 1c will be possible, even though it is incorrect. The Light properties of both documents are compatible because the lexical spaces of their values are the same (1 and 1275 respectively, can be integer). With the presence of datatype information, we can avoid this ambiguity even if the lexical spaces of the values are compatible.

In this scenario, we can realize the role of datatypes for matching/integration of RDF documents. Thus, when this information is missing, an approach capable of inferring the datatype from the existing information is needed.

Related Work

To the best of our knowledge, no prior work manages simple datatype inference for RDF documents. However, datatype inference has been addressed in the context of XSD, programming languages, and OWL (theoretical approaches and tools). To evaluate the existing works, we have identified the following criteria of comparison: (i) consideration of simple or complex datatypes; (ii) analysis of local information, such the object value, and external information, since the Semantic Web allows the integration of resources available on the Web; and (iii) suitability for the Semantic Web, the whole method should be objective and complete.

For theoretical approaches, we classify the existing works into four groups: -Lexical space based approaches: In the inference of XSD from XML documents, datatypes are reduced to a small set of values (date, decimal, integer, boolean, and string) or to only string datatypes. The authors in [START_REF] Chidlovskii | Schema extraction from xml collections[END_REF][START_REF] Hegewald | Xstruct: Efficient schema extraction from multiple and large xml documents[END_REF] propose a hierarchy between the reduced datatypes according to the lexical spaces of the W3C Recommendation. The proposal returns the most specific datatype that subsumes the candidate datatypes obtained from the patter-matching of the values. However, a gYear value is reduced to interger, which is incorrect.

-Axioms, constructors, and operations based approaches: In the context of programming languages, the authors in [START_REF] Fluet | Practical datatype specializations with phantom types and recursion schemes[END_REF] focus on inferring complex datatypes, modelling them as a collection of constructor, destructor, and coercion functions. Other works [START_REF] Holdermans | Random testing of purely functional abstract datatypes: Guidelines for dealing with operation invariance[END_REF][START_REF] Wang | Refactoring pattern matching[END_REF], also use axioms and pattern matching over the constructors of the datatype during the inference process. In [START_REF] Arts | Testing erlang data types with quviq quickcheck[END_REF][START_REF] Boulytchev | Combinators and type-driven transformers in objective caml[END_REF], operations and a syntax associated to datatypes are analyzed to infer complex datatypes. Simple datatypes such as date and integer are mainly inferred by a pattern-matching process of the value format using the lexical spaces. However, some simple datatypes have intersection among their lexical spaces as gYear and integer.

-Inference rules based approaches: In the context of OWL, the authors in [START_REF] Paulheim | Type inference on noisy rdf data[END_REF] propose a method to heuristically generate type information by exploiting axioms in a knowledge base. They assign type probabilities to the assertions. In the domain of health-care, [START_REF] Sleeman | Entity type recognition for heterogeneous semantic graphs[END_REF] proposes a type recognition approach (inference type) by associating a weight to each predicate, using support vector machines to model types and by building a dictionary to map instances. For [START_REF] Liu | An incremental and distributed inference method for large-scale ontologies based on mapreduce paradigm[END_REF], the Semantic Web needs an incremental and distributed inference method because of the long ontology size. The authors use a parallel and distributed process (MapReduce) to "reduce" the "map" of new inference rules. The authors in [START_REF] Kellou-Menouer | Discovering types in rdf datasets[END_REF] state that DBpedia only provide 63.7% of type information. Hence, they propose an approach to discover complex datatypes in RDF datasets by grouping entities according to the similarity between incoming and outgoing properties. They also use a hierarchical clustering and the confidence of types for an entity. The use of inference rules helps to infer datatypes where a specific information is known (e.g., type of properties, knowledge database). However, RDF data is not always available with its respective ontology, which makes impossible the task of formulating inference rules.

-Semantic analysis based approaches: In [START_REF] Gunaratna | Gleaning types for literals in rdf triples with application to entity summarization[END_REF], the authors analyze two types of predicates: object property and datatype property. They propose an approach to infer the semantic type of string literals using the word detection technique called Stanford CoreNLPto identify the principal term. However, a semantic type is not always related to the same datatype, since it depends on Semantic Analysis Only string X Tools: [START_REF]XML Grid -Online XML Editor[END_REF][START_REF]Free Formatter -Free Online Tools For Developers[END_REF][START_REF]Xml Schema Inference -Developer Network[END_REF] Not provided Not provided X X the datatype defined in the structure. A value can be expressed as a string or integer according to two different ontologies.

On the other hand, there are tools that generate XSD from XML documents, such as XMLgrid [START_REF]XML Grid -Online XML Editor[END_REF], FreeFormatted [START_REF]Free Formatter -Free Online Tools For Developers[END_REF], and XmlSchemaInference by Microsoft [START_REF]Xml Schema Inference -Developer Network[END_REF]. However, they do not share a standard process to infer datatypes. For example, the attribute weight and isLight from the following XML document extracted from Fig. 1, have different inferred datatypes according to these three tools. <Light_Bulb> <Light>1250</Light> <weight>30.00</weight> </Light_Bulb> <Light_Switch> <isLight>1</isLight> </Light_Switch> XMLgrid infers weight as double and isLight as int; using FreeFormatted, the datatype for weight is float and for isLight is byte; while according XmlSchemaInference weight is decimal and isLight is unsignedByte. The criteria used to infer the datatype are unknown since these tools do not describe their algorithms. Thus, the direct application of existing approaches presents limitations in the context of RDF document integration/matching.

Table 1 shows our related work classification. Note that none of the works satisfies all the defined requirements. Before describing how our approach overcomes the limitations of existing works and addresses these requirements, the following section introduces some common terminologies and definitions of RDF.

RDF Terminologies and Definitions

RDF is the common format to describe resources that represent the abstraction of an entity (document, abstract concept, person, company, etc.) in the real world. RDF uses IRIs, blank nodes, and literals nodes as elements to build triples and provide relationships among resources.

The RDF Schema (RDFS) is a set of classes with certain properties (vocabulary), which are extensions of the basic RDF vocabulary [START_REF] Brickley | RDF Schema 1.1[END_REF]. RDFS defines properties to better describe resources. For example, the rdfs:domain property designates the type of subject that can be associated to a predicate and the rdfs:range property designates the type of object. The Semantic Web proposes an implicit representation of the datatype property in the literal object as a description of the value (e.g., "value"^^xml:string). Def. 1 presents the formal definition of datatype according to W3C [START_REF] Jeremy | XML Schema Datatypes in RDF and OWL, W3C Working Group Note 14[END_REF].

Definition 1. Simple Datatype (dt): In RDF, a simple datatype, denoted as dt, is characterized by: (i) a value space, denoted as VS(dt), which is a non-empty set of distinct valid values; (ii) a lexical space, denoted as LS(dt), which is a non-empty set of Unicode strings; and (iii) a total mapping from the lexical space to the value space, denoted as L2V(dt) [START_REF] Jeremy | XML Schema Datatypes in RDF and OWL, W3C Working Group Note 14[END_REF].

The datatype boolean from Fig. 1a, has the following characteristics:

-V S(boolean) = {true,false};

-LS(boolean) = {"true", "f alse", "1", "0"};

-L2V (boolean) = {"true" ⇒ true, "f alse" ⇒ f alse, "1" ⇒ true, "0" ⇒ f alse}.

Table 2 presents abbreviations to denoted several sets of RDF elements, that we use in our formal approach description. -s ∈ I ∪ BN represents the subject to be described; -p is a property defined as an IRI in the form namespace prefix:property name; N amespace pref ix is a local identifier of the IRI, where the property (property name) is defined; -o ∈ I ∪ BN ∪ L describes the object. The predicate (p) is also known as the property of the triple.

The example presented in Fig. 1 underlines four triples with different RDF resources, properties, and literals:

-t1: <Light Switch,house:isLight,1> -t2: <Light Switch,house:isLight,true> -t3: <Light Bulb,light:Light,125> -t4: <Light Bulb,dbp:weight,30.00>

In the following section, we describe our datatype inference process.

Inference Process: Our Proposal

Our datatype inference approach mainly relies on a four step process that considers the annotations on the predicate, the specific format of literal object values, the semantic context of the predicate; and the generalization of datatype for Numeric and Binary groups. Fig. 2 shows the framework of our inference process composed by the four steps. Each step can be applied independently and in different orders according to user parameters. The input of our framework is an RDF Description which can be in different serializations (such as RDF/XML, Turtle, N3) and the user parameters (infer-ence steps and their order). The output is an RDF Description with its respective inferred datatypes. A description of each step is presented as follows:

-Step 1 -Predicate Information Analysis: In a triple t: <s,p,o>, the predicate p establishes the relationship between the subject s and the object o, making the object value o a characteristic of s. Information (properties) such as rdfs:domain and rdfs:range can be associated to each predicate to determine the type of subject and object. We propose as a first step to deduce the simple datatype of a particular literal object, based on the use of the property rdfs:range, if this information exists. We formally describe the Step 1 with the following definitions and rule. Definition 3. Predicate Information ( PI): Given a triple t :< s, p, o >, Predicate Information is a function, denoted as PI(t), that returns a set of triples defined as: P I(t) = {t i | t i =< s i , p i , o i >}, where: -s i is the predicate of t (t.p), acting as a subject on each t i triple; -p i is an RDF defined property ∈ {rdf s : type, rdf s : label, rdf s : range, ...}; -o i is the value of p i .

Table 3 shows the set of triples (PI), returned by the function Predicate Information, for property dbp:weight, which is presented in Fig. 1c. Applying Def. 4 to the set of predicate information (PI) of property dbp-:weight (see Table 3), the Predicate Range Information function returns the value xsd:double. Definition 5. Is Available (IA): Given a predicate p, Is Available is a boolean function, denoted as IA(p), that verifies if p is an IRI available on the web:

IA(p) =
T rue if p returns code 200; F alse otherwise.

Using the three previous definitions, we formalize our first inference rule.

Rule 1. Datatype Inference by Predicate Information Analysis:

Given a triple t :< s, p, o >, in which o ∈ L, the datatype of o is determined as follows:

R1: if IA(p) =⇒ datatype = PRI(t).
Rule 1 verifies if the predicate of the triple is an IRI available (Def. 5), extracts the set of triples corresponding to the predicate information (Def. 3), and determines if the rdfs:range property exists (Def. 4). -Step 2 -Datatype Lexical Space Analysis: According to a W3C Recommendation, the lexical space of a datatype describes the representation format and restricts the use of characters for the object values. Table 4 shows the lexical spaces of several simple datatypes according to the W3C. In some cases, the datatype can be inferred from its lexical space, when it is uniquely formatted (e.g., value 1999-05-31 matches with the format CCYY-MM-DD, which is the lexical space of datatype date). However, in several cases (such as boolean, gYear, decimal, double, float, integer, base64Binary, and hexBinary), the lexical spaces of datatypes have common characteristics, leading to ambiguity (e.g., value 1999 matches with lexical spaces of gYear and float -see Table 4). Figure 3 illustrates graphically the lexical space intersections of W3C simple datatypes. To analyze the lexical spaces, we propose the following definition. By Def. 6, the set of candidate datatypes of the object literal value 1 presented in Fig. 1a is: CDT(1)={float, decimal, double, hexBinary, base64Binary, integer, boolean, string}. Based on this definition, we formally define our second inference rule.

Rule 2. Datatype Inference by Lexical Space:

Given a triple t :< s, p, o >, in which o ∈ L, the datatype of o is determined as follows:

R2: datatype =      string if |CDT (o)| = 1, dt | dt ∈ CDT (o) ∧ dt = string if |CDT (o)| = 2, null otherwise.
Rule 2 analyzes the number of possible datatypes of a literal object value. In all cases, the datatype string is a candidate datatype, since it has the most general lexical space (see Fig. 3); if the number of candidate datatypes is one, then the only datatype, which is string, is returned. If the number of candidate datatypes is two, then the other datatype is returned. Otherwise, we have an ambiguous case and cannot provide any decision.

-Step 3 -Predicate Semantic Analysis: In presence of ambiguous cases, a semantic analysis of the predicate can be done to resolve ambiguity. Regarding the W3C datatype lexical spaces, the datatypes boolean, gYear, decimal, double, float, integer, base64Binary, and hexBinary datatypes are ambiguous. However, the ambiguity of boolean, gYear, and integer, in some specific scenarios, can be resolved by examining the context of its predicate according to a knowledge base. For example, the predicate dbp:dateOfBirth has the context date, then it is possible to assume gYear as the datatype; the predicate dbp:era has the context period and the datatype assigned can be integer; however, for predicate dbp:salary, it is possible to assign datatypes decimal, double, or float; the ambiguous case persists. In order to describe our inference process in this step, we formalize a knowledge base as follows: Definition 7. Knowledge Base (KB): Knowledge bases (thesaurus, taxonomies, and ontologies) provide a framework to organize entities (words/expressions, generic concepts, etc.) into a semantic space. A knowledge base has the following defined functions: -Similarity (sim): Given two word values n and m, Similarity is a function, denoted as sim(n,m), that returns the similarity value among the words: sim(n, m) = A similarity value ∈ [0, 1] between n and m according to KB.

-IsPlural (IP): Given a string value n, IsPlural is a function, denoted as IP(n), that returns True if the word n is plural:

IP (n) =
T rue if n is plural according to KB; F alse otherwise.

-IsCondition (IC ): Given a string value n, IsCondition is a function, denoted as IC(n), that returns True if the word n is a condition:

IC(n) =
T rue if n is a condition according to KB; F alse otherwise.

The semantic context is formalized, based on the knowledge base, as follows: Definition 8. Context (ct): A context is a related word or synonym, which clarifies or generalizes the domain of a word. It is associated to a similarity value according to a knowledge base. A context is denoted as a 3-tuple ct :< w, y, v >, where w is a word; y is a related word of w; and v is sim(w,y) ∈ [0, 1]. Definition 9. Set of Contexts (CT ): Given a word w, a set of contexts of w is defined as CT = {ct i | ct i :< w, y i , v i > is a context of w}.

For example, from Fig. 1c, the set of contexts of predicate weight is: CT = {<weight,load,0.8>, <weight,heaviness,0.5>, ...} Definition 10. Predicate Context (PC ): Given a triple t :< s, p, o > and a threshold h, Predicate Context is a function, denoted as PC(t,h), that returns a set of contexts defined as:

P C(t, h) = {cti | cti :< p.property namei, yi, vi >, vi ≥ h}.
The context can determine the datatype for some literal objects through a semantic analysis, then we assume two scenarios for an ambiguous case:

-If the context is date (< word, date, 0.5 >), the datatype is gYear because gYear (1999) is a part of datatype date (1999-05-31); -If the context is period (< word, period, 0.5 >), the datatype is integer because it is about quantity. However, if the context is date, the word from which we obtain the context, can not be plural, since plural words express quantities and it is related to datatype integer according to our scenarios. Based on our scenarios, the following definition is formulated: Definition 11. Predicate Name Context (PNC ): Given a triple t :< s, p,o >, in which o ∈ L, and a threshold h, Predicate Name Context is a function, denoted as PNC(t,h), that returns a datatype defined as:

P N C(t, h) =              gYear if ∃cti ∈ P C(t, h) | cti = date ∧ gYear ∈ CDT (o); integer if ∃cti ∈ P C(t, h) | cti = date ∧ integer ∈ CDT (o) ∧IP (p.property name); integer if ∃cti ∈ P C(t, h) | cti = period ∧ integer ∈ CDT (o); null otherwise.
In addition, to determine a datatype as boolean, we assume that a word is defined as condition in a knowledge base (e.g., Wordnet).

Using the previous definitions, we formally define our third inference rule. Rule 3 returns the datatype of the object value when a defined context associated to the predicate exists. If that is not the case, we are still under an ambiguous case. Note that Rule 3 is proposed for a scenario where the data is consistent with the W3C recommendations (e.g., self-descriptive names).

-Step 4 -Generalization of Numeric and Binary Groups: If we still have ambiguity, as an alternative to disambiguate the datatypes decimal, double, float, integer, base64Binary, and hexBinary, we propose two groups of datatypes: Numeric and Binary. In each group, we define an order among the datatypes by considering lexical space intersection (see Fig. 3). Hence, for the Numeric Group, we have decimal > double > float > integer and in the Binary Group, base64Binary > hexBinary. According to these groups, we return the most general datatype, if all candidate datatypes belong only to one of these two groups. Definition 12. Generalization (G): Given a literal object o, the set of its candidate datatypes is reduced by the function Generalization, defined as:

G(o) = {dt | dt ∈ CDT (o) ∧ (dt
is the most general datatype according to Numeric and Binary groups)} Note that datatype string is always part of candidate datatypes. We formally define our fourth inference rule as follows: Rule 4. Datatype Generalization: Given a triple t :< s, p, o >, in which o ∈ L, the datatype of o is determined as follows:

R4: datatype = dt | dt ∈ G(o) ∧ dt = string if |G(o)| = 2, null otherwise.
However, we can have a case where an object value has decimal and base64-Binary as candidate datatypes and our inference approach cannot determinate the most appropriate datatype.

Our inference approach allows to improve the datatype analysis for RDF matching/integration by complying with the identified requirements (see Section 3): (i) the use of local available information, as the predicate value in Step 1 and Step 3 and the datatype lexical space in Step 2, as well as external available information, such the predicate information in Step 1 and the predicate context in Step 3 ); and (ii) this method is objective and complete for the Semantic Web, since all simple datatypes are considered, which are available in the most common Semantic Web databases as DBpedia.

Complexity Analysis. A complexity analysis of our inference approach indicates a linear order performance in terms of the number of triples (O(n)). For Step 1, the predicate information of each triple is extracted to search the rdfs:range property, since the number of properties associated to the predicate of each triple (Def. 3) is constant, then its execution order is O(n). In the case of Step 2, for each triple a pattern-matching is executed for all simple datatypes (finite number of execution) thus, it is of linear order (O(n)). In Step 3, for each triple, its set of contexts is extracted to determine the best related work (in a constant time), thus its time complexity is also O(n). Finally, Step 4 reduces the finite set of candidate datatypes (generalization) in a linear order (O(n)). As the four steps are executed sequentially, the whole inference datatype process exhibits a linear order complexity, O(n). The following section evaluates the accuracy and demonstrate the linear order performance of our proposal.

Experimental Evaluation

To evaluate and validate our inference approach, an online prototype system, called RDF2rRDF4 , was developed using PHP and Java. For Step 3, we implemented our assumptions of contexts using the semantic similarity service UMBC: Semantic Similarity Service Computing, which is based on distributional similarity and Latent Semantic Analysis (Def. 10). UMBC service is available online and an API is provided 5 . Also, we used Wordnet6 to recognize if a word is plural assuming that every word has a root lemma where the default plurality is singular. Additionally, we assume that a word is a condition if it has the prefix "is" or "has". All these assumptions compose our knowledge base. Table 5 shows the different datatypes available in several semantic web databases. Note that DBpedia has more variety of datatypes compared with the others, thus our experiments were made with DBpedia database. Experiments were undertaken on a MacBook Pro, 2.2 GHz Intel Core(TM) i7 with 16.00GB, running a MacOS Sierra and using a Sun JDK 1.7 programming environment.

Our prototype was used to perform a large battery of experiments to evaluate the accuracy and the performance (execution time) of our approach in comparison with the related work. To do so, we considered two datasets: (i) Case 1: 5603 RDF documents gathered from DBpedia person data 7 , in which 1059822 triples, 38292 literal objects, and 8 different datatypes are available, and (ii) Case 2: the whole DBpedia person data as a unique RDF document with 16842176 triples, in which only datatypes date, gMonthDay, and gYear are presented.

For Case 1, we evaluated the accuracy and performance of each step of our datatype inference approach, Step 1 + Step 2, Step 1 + Step 3, Step 2 + Step 3, and the whole inference process. The order of the whole inference process was established starting from a general solution (Step 1 ), that can be applied to all simple datatypes, until a specific solution for particular cases (Step 3 and Step 4 ). In Case 2, we only evaluated the whole inference process, since it is mainly used for performance because the high number of triples.

Accuracy evaluation

To evaluate the accuracy of our approach, we calculated the F-score, based on the Recall (R) and Precision (PR). These criteria are commonly adopted in information retrieval. Test 1: In Table 6, for Step 1, 24059 datatypes were inferred (45.35% of the total, 38292) with a Precision, Recall, and F-score of 99.89%, 62.81%, and 77.12% respectively. This process inferred 26 invalid simple datatypes because inconsistencies on the data. In Step 2, 17435 datatypes were inferred (45.35% of the total) with a Precision, Recall, and F-score of 96.91%, 44.76%, and 61.24% respectively. This process inferred 537 invalid datatypes (14 simple and 523 complex datatypes) and it could not determine the datatype for 20857 literal objects. The best F-score was obtained with the whole inference process; however, the Precision decreased from 99.89% (Step 1 ) to 97.71% because of Step 3 and Step 4 (Precision 95.20% and 89.60% respectively). For Case 2, the Precision decreased to 76.01%. It is caused by the noise and inconsistencies of the DBpedia datasets [START_REF] Polleres | Can we ever catch up with the web?[END_REF] (e.g., dbo:deathDate should have the datatype property date, but in the queried datasets, it was set as gYear). Test 2: We also evaluated the accuracy of our approach in comparison with alternative methods and tools, namely Xstruct, XMLgrid, FreeFormated, and XMLMicrosoft [START_REF]XML Grid -Online XML Editor[END_REF][START_REF]Free Formatter -Free Online Tools For Developers[END_REF][START_REF] Hegewald | Xstruct: Efficient schema extraction from multiple and large xml documents[END_REF][START_REF]Xml Schema Inference -Developer Network[END_REF]. Since these works infer datatypes in XML documents, we transformed all literal nodes to XML format by using the value and its relation. Table 7 shows the accuracy results obtained for Case 1. Note that our approach has the best Precision and F-score. Our Recall is less than the other ones because we consider a bigger number of datatypes and thus, there are more ambiguous cases (lexical space intersections).

Performance evaluation

To evaluate the performance, we measured the average time of 10 executions for each test. Table 8 shows the results obtained in our performance evaluation. Test 4: Additionally, we implemented in Step 1 and Step 3 the use of cache to store predicate information and predicate contexts, respectively (see Table 8 -column 3). This cache is reused for consequential analysis of triples, since same predicates are available in different triples. For Case 1, the use of cache in Step 1 reduced the execution time in more than 65% and made the execution time of Step 1 + Step 2 less than Step 1 and Step 2, separately. The cache in the whole inference approach represented more than 70% of improvement in the performance and an average of 157 × 10 -7 sec. per triple. Moreover, for more than 16 millions of triples (Case 2), the execution time remained in the order of seconds (59.28s) and the average execution time per tripe was reduced to 35 × 10 -7 sec. We presume in Case 2 that the majority of triples were inferred in Step 1, which uses cache. Fig. 4 shows the execution time with respect to the number of triples. The performance obtained confirms the linearity of our inference approach. Note that the use of cache makes the function stable for high number of triples because of the finite number of predicates available in the DBpedia database.

Conclusion

In this paper, we investigated the issue of datatype inference for RDF documents matching/integration. We proposed an approach, consisting of four steps: the analysis of the predicate information associated to the object value, analysis of the lexical space of the value itself, semantic analysis of the predicate name, and generalization of datatypes. We evaluated the accuracy and performance of our inference process with DBpedia datasets (DBpedia person data). Results show that the inference approach increases the F-score up to 97.10% (accuracy) and it does not incur in high execution time (performance). We are currently working on extending this work to include other datatypes and propose more context rules to resolve extra ambiguity. We also plan to evaluate our approach with other databases from Semantic Web initiatives. Acknowledgments: FINCyT/INNOVATE Peru -N 104-FINCyT-BDE-2014.

1 .

 1 (a) Light Switch. Datatype boolean: Binary Lexical Space (0, 1) (b) Light Switch. Datatype boolean: String Lexical Space (f alse, true) (c) Light Bulb Fig. Three concepts from three different RDF documents

Fig. 2 .

 2 Fig. 2. Framework of our RDF Inference process

Fig. 3 .

 3 Fig. 3. Datatype Lexical Space Intersection Definition 6. Candidate Datatypes (CDT ): Given a literal object o, the set of its candidate datatypes is determined by the function Candidate Datatypes, defined as: CDT (o) = {dt | dt ∈ SDT ∧ o ∈ LS(dt)}

Rule 3 .

 3 Datatype Inference by Semantic Analysis: Given a triple t :< s, p, o >, in which o ∈ L, and a threshold h the datatype of o is determined as follows: R3: datatype = boolean if boolean ∈ CDT (o) ∧ IC(p.name property); P N C(t, h) otherwise.

Test 3 :

 3 In Case 1, the execution time of Step 1 was greater than Step 2, because the use of external calls increased the execution time. However, the execution time of Step 1 + Step 2 was similar to Step 1, since Step 1 works as a filter of triples and leaves less analysis for Step 2. Step 3 has the greatest execution time, since it depends of an external service. Step 4 depends of the list of candidate datatypes; thus its execution time should be greater than Step 2 because the use of extra operations to reduce the set of datatypes (generalization).

Fig. 4 .

 4 Fig. 4. Execution Time of our Inference Approach

Table 1 .

 1 Related Work Classification

	Work	Inference Method	Simple Datatypes	Requirements Information Local External XML/XSD RDF/OWL Semantic Web
	[7,11]	Lexical Space	Reduced Set	X	X
	[9,12,24,5,6]	Axioms, operations, constructors	Only Complex	X	X
	[20,23,14]	Inference rules	Only Complex	X	X
	[10]

Table 2 .

 2 Description of setsSet Description IA set of IRIs is defined as:I = {i | i is an IRI}. LA set of literal nodes is defined as: L = {l | l is a literal node}. BN A set of blank nodes is defined as: BN = {bn | bn is a blank node}. DT A set of Datatypes is defined as: DT = {dt | dt is a datatype}. SDT The set of simple datatypes proposed by the W3C, is defined as: SDT = {string, boolean, decimal, ...} Definition 2. Triple ( t): A Triple is defined as an atomic structure consisting of a 3-tuple with a Subject (s), a Predicate (p), and Object (o), denoted as t :< s, p, o >, where:

Table 3 .

 3 Example of the set of triples of Predicate information (PI) for dbp:weight

	Subject	Predicate (Property) Object (Value)
	dbp:weight rdf:type	owl:DatatypeProperty
	dbp:weight rdfs:label	weight (g) (en)
	dbp:weight rdfs:range	xsd:double
	dbp:weight prov:wasDerivedFrom	http://mappings.dbpedia.org/OntologyProperty:weight

Definition 4. Predicate Range Information (PRI ): Given a triple t :< s, p, o >, Predicate Range Information is a function, denoted as PRI(t), that returns the value associated to the rdfs:range property, defined as: PRI(t) = ti.o if ∃ti ∈ P I(t) | ti.p = rdfs:range, null otherwise.

Table 4 .

 4 Lexical Space for several Simple Datatypes (W3C Recommendation[START_REF] Paul | XML Schema Part 2: Datatypes Second Edition, W3C Recommendation[END_REF])

	Datatype Lexical Space	Examples
	date	CCYY-MM-DD	1999-05-31
	gYear	CCYY	1999
	boolean	true, false, 1, 0	false
	float	32-bit floating point type 12.78e-2, 1999
	decimal	Arbitrary precision	12.78e-2, 1999
	integer	[0-9]	1999

Table 5 .

 5 Semantic Web databases

	DataBase	Datatypes
	DBpedia	integer, gYear, date, gMonthDay, float, nonNegative, double, Integer and decimal
	Wordnet	string
	GeoLinked data point (complex datatype)

  Combining Step 1 and Step 2, the Precision, Recall and F-score values increased considerably (99.17%, 88.85%, and 93.73% respectively). In Step 3, only 2480 datatypes were inferred (Recall 6.85%), since it is proposed for particular cases (context rules). Precision in Step 4 is less than all other Steps; however, the Recall is greater than Step 2 and it makes a F-score similar to Step 2. Other combinations as Step 1 and Step 3 and Step 2 and Step 3 have high Precision but low Recall, because the Recall of Step 3 (specific cases).Executing the whole approach, 37066 datatypes were inferred (96.80%). The Precision, Recall and F-score are 97.71%, 96.50%, and 97.10% respectively.

	Inference			Accuracy Evaluation
	Process	Valid Not Valid Ambiguity Precision Recall F-score
	Case 1: Step 1	24033	26	14233	99.89%	62.81% 77.12%
	Case 1: Step 2	16898	537	20857	96.92%	44.76% 61.24%
	Case 1: Step 3	2480	119	35812	95.20%	6.85% 11.62%
	Case 1: Step 4	16899	1962	19431	89.60%	46.52% 61.24%
	Case 1: Step 1 + Step 2 33771	281	4240	99.17%	88.85% 93.73%
	Case 1: Step 1 + Step 3 26394	145	11753	99.45%	69.19% 81.61%
	Case 1: Step 2 + Step 3 19259	656	18377	96.71%	51.17% 66.93%
	Case 1: Whole Approach 36132	551	1609	97.71%	96.50% 97.10%
	Case 2: Whole Approach 2250402	710234	0	76.01% 100.00% 86.37%

Table 7 .

 7 Accuracy Comparison with the Related Work for Case 1

	Work	Precision Recall F-score
	Xstruct	83.28%	100%	90.88%
	XMLgrid	83.61%	100%	91.07%
	FreeFormated 43.32%	100%	60.45%
	XMLMicrosft 43.23%	100%	60.36%
	RDF2rRDF	97.71% 96.50% 97.10%

Table 8 .

 8 Performance Evaluation

	Inference	Performance Evaluation
	Process	Execution Time Cache Building Time
	Case 1: Step 1	31.336s	11.582s
	Case 1: Step 2	15.939s	15.939s
	Case 1: Step 3	243.826s	40.764s
	Case 1: Step 4	17.879s	17.879s
	Case 1: Step 1 + Step 2	33.216s	13.966s
	Case 1: Whole Approach	53.247s	14.236s
	Case 2: Whole Approach	-	59.282s

http://rdf2rrdf.sigappfr.org/

http://swoogle.umbc.edu/SimService/api.html

WordNet is a large lexical database of English (nouns, verbs, adjectives, etc.)

Information about persons extracted from the English and Germany Wikipedia, represented by the FOAF vocabulary -http://wiki.dbpedia.org/Downloads2015-10


Gabriele Nava
email: gabriele.nava@iit.it

Quentin Sablé
email: quentin.sable@laas.fr

Marco Tognon
email: marco.tognon@laas.fr

Daniele Pucci

Antonio Franchi
email: a.franchi@utwente.nl

Direct Force Feedback Control and Online Multi-task Optimization for Aerial Manipulators

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. INTRODUCTION

Nowadays, Unmanned Aerial Vehicles (UAVs) are widespread and employed in several application scenarios such as surveillance, remote monitoring and aerial photography. The recent development of aerial manipulators physically interacting with the environment, significantly enlarged the number of feasible tasks spanning from manipulation and grasping of objects to the contact-based inspection [START_REF] Tognon | A truly redundant aerial manipulator system with application to push-and-slide inspection in industrial plants[END_REF]. Such interaction tasks often require the aerial manipulator to precisely regulate both position of the contact point (possibly moving) and the amount of force that is exerted on it.

There is a rich literature concerning the modeling and control of aerial manipulators [START_REF] Ruggiero | Aerial manipulation: A literature review[END_REF]. Regarding the motion control, different methods can be applied, e.g., full dynamic inversion [START_REF] Yang | Dynamics and control of quadrotor with robotic manipulator[END_REF], flatness-based [START_REF] Tognon | Dynamic decentralized control for protocentric aerial manipulators[END_REF], and adaptive sliding mode [START_REF] Kim | Aerial manipulation using a quadrotor with a two DOF robotic arm[END_REF]. On top of those, if the system is over actuated with respect to the desired task, a nullspace-based behavioral control [START_REF] Baizid | Behavioral control of unmanned aerial vehicle manipulator systems[END_REF] or a task priority controller [START_REF] Santamaria-Navarro | Task priority control for aerial manipulation[END_REF] can be applied at the kinematic level exploiting the redundancy to achieve secondary tasks (e.g., obstacle avoidance, minimum energy consumption, etc.). In particular, the latter acts as a local motion planner providing the reference trajectory of each degree of freedom of the robot to the low level motion controller. The main limitation of this control architecture is the inability to consider additional hard constraints to be respected, e.g., input/state bounds, dynamics of the system which is not taken into account at the kinematic level, friction cone in case of interaction, etc. The mentioned constraints are very important because, if not respected, they might bring the whole system to instability in real scenarios.

From the interaction control side, one of the most common strategy is to use an admittance filter. In [START_REF] Ryll | 6D interaction control with aerial robots: The flying end-effector paradigm[END_REF] and [START_REF] Suarez | Physical-virtual impedance control in ultralightweight and compliant dual-arm aerial manipulators[END_REF], such technique has been employed to control the interaction force in the case of a fully-actuated platform equipped with a rigid tool, and of an under-actuated platform equipped with a robotic arm, respectively. In [START_REF] Rashad | Port-hamiltonian passivity-based control on se (3) of a fully actuated uav for aerial physical interaction near-hovering[END_REF], a passivity-based controller has been proposed as well. However, in those works, the force-control is only indirect. In fact, the force is not directly measured but rather estimated using the robot dynamics. Since the method is strongly model based, it is thus prone to error in case of parameter uncertainties. Furthermore, if the system is affected by external disturbances, it might not be possible to discriminate them from the interaction forces. A first attempt in using a direct force feedback can be found in [START_REF] Antonelli | Impedance control of an aerial-manipulator: Preliminary results[END_REF] where a force sensor has been attached to the end-effector. Nevertheless, this feedback is not used to precisely control the interaction force but is rather used in an impedance control framework to make the end-effector compliant.

In this work we propose a whole-body force control strategy for aerial manipulators that allows, in a unique formulation, to achieve hybrid position/force control, considering multi-task optimization under hard-constraints. We shall show that with the proposed control framework, the aerial manipulator can perform different contact-based tasks using the same strategy, only changing the tasks priority and contact-constraints. In our framework, we consider several control objectives organized in a weighted prioritization. The controller is implemented in the form of a Quadratic Programming (QP) optimization, which is a rather known technique in the field of humanoid robotics [START_REF] Charbonneau | Learning robust task priorities of QP-based whole-body torque-controllers[END_REF], [START_REF] Mansard | A versatile generalized inverted kinematics implementation for collaborative working humanoid robots: The stack of tasks[END_REF], but whose applicability and effectiveness was never demonstrated until now in the challenging field of aerial manipulators -where the physical interaction tasks are made very complex by, e.g., the absence of stabilizing contacts, limited propeller forces, inaccurate and time varying aerodynamics models, and mechanical vibrations.

Furthermore, to provide an accurate interaction control, our controller implements a direct force-feedback employing a 6-axis force-torque sensor (FT) mounted on the manipulator end-effector. We shall show through real experiments that the FT sensor feedback ensures the robustness of the proposed control law with respect to disturbances and modeling errors. The effectiveness of the overall control framework has been shown through real experiments for three different tasks: 1) pushing under external disturbances, 2) sliding while pushing and 3) high-acceleration motions exploiting contacts, but of course these are just a few of the many real world tasks can be achieved with the proposed method.

The remainder of the paper is organized as follows: Sec. II recalls the notation, the dynamics model of the aerial manipulator and the rigid contact model. Sec. III details the task-based control strategy and the QP optimization problem. Simulations and experimental results with a real hexarotor equipped with a three degrees of freedom manipulator are presented in Sec. IV. Conclusions and perspectives end the paper.

II. MODELING

We consider an aerial manipulator composed of an aerial platform equipped with a robotic manipulator as in Fig. 1. Given the flying nature of the system, we model it as a floating base system [START_REF] Featherstone | Rigid Body Dynamics Algorithms[END_REF]. We assume that the robotic arm is composed of n + 1 links, connected by n actuated joints with a single degree of freedom each.

To describe the state of the aerial manipulator we define a world frame F W = {O W , x W , y W , z W }, with arbitrarily placed origin O W , and unit axes (x W , y W , z W ) such that z W points in the opposite direction of the gravity vector. An additional frame F R = {O R , x R , y R , z R } is rigidly attached to the aerial platform base. Finally, we rigidly attach a frame F E = {O E , x E , y E , z E } to the end-effector of the robotic arm such that z E is parallel to the last link of the manipulator.

The robot configuration is then given by q

= (p R , R R , q A ) ∈ C ⊆ R 3 × SO(3) × R n where p R ∈ R 3 and R R ∈ SO(3)
represent the position and orientation of F R with respect to (w.r.t.) F W , respectively, while q A ∈ R n are the manipulator joint angles which characterize the configuration of the robotic arm. The velocity relative to q is given by v 3 and ω R ∈ R 3 are the aerial platform linear and angular velocities, and v A ∈ R n are the joints velocities. More precisely, ω R is the angular velocity of F R w.r.t. F W expressed in F R , which satisfies 1ṘR = S(ω R )R R . The system equations of motions can be computed by applying the Euler-Poincaré formalism [START_REF] Marsden | Introduction to Mechanics and Symmetry: A Basic Exposition of Classical Mechanical Systems[END_REF]Ch. 13.5] :

= [v R ω R v A ] ∈ R 6+n , where v R ∈ R
M (q) v + c(q, v) + g(q) = w R τ A + J E (q) w E , (1)
where M (q) ∈ R (n+6)×(n+6) is the mass matrix, c(q, v) ∈ R n+6 accounts for the Coriolis and centrifugal effects, g(q) ∈ R n+6 is the gravity vector, w R ∈ R 6 is the control wrench (forces and moments) applied to the aerial vehicle by the propellers, and τ A ∈ R n are the joint torques of the manipulator. We assume that the interaction with the environment occurs at the manipulator end-effector only. When the robot end-effector is in contact with the environment, the external wrench w E ∈ R 6 has to be included in the equations. The Jacobian J E (q) ∈ R 6×(n+6) is the map between the system velocity v and the linear and angular velocities of the end-effector at the contact location. It is assumed that for the applications proposed in this paper the aerodynamics phenomena such as, e.g., wind effect, blade flapping, cross interference between propellers, and ground/wall effect do not significantly affect the robot dynamics, and therefore can be neglected. Considering the aerial vehicle actuated by a set of p ∈ N rigidly attached propellers, the control wrench w R can be conveniently rewritten as a function of the propellers angular rates. In particular we consider, as usual, a quadratic relation between propeller angular rates and corresponding generated thrust:

w R = G w (q)ω 2 P := G w (q)(ω P ω P ), (2)
where ω P ∈ R p is the vector of propellers angular rates, is the component-wise product between two vectors, and G w ∈ R 6×p is the mapping between the propellers square angular rates and the control wrench. In particular we can partition

G w in two blocks, G w1 ∈ R 3×p and G w2 ∈ R 3×p such that G w = [G w1 G w2 ]
. G w1 and G w2 map the propellers square angular rates into control force and moment, respectively. In this work, we consider both cases of 1) under-actuated, and 2) fully-actuated vehicles. For under-actuated vehicles, 0 < rank(G w1 ) < 3 which means that the total thrust cannot change in all directions without reorienting the whole platform. This is the case of standard quadrotors where the propellers are all collinear and the thrust direction is fixed w.r.t. F R . On the contrary, for fully-actuated vehicles, rank(G w1 ) = 3 (it has to be that p ≥ 6) which means that the total thrust can change in all directions. In both cases, G w2 = 3, i.e., there is full control on the moment applied by the aerial platform.

A. Contact Modeling

We assume that the robot interacts with a rigid and planar environment. 2 In an industrial environment, such assumptions may occur while executing tasks such as polishing, inspection or welding. Possible types of interaction from the end-effector constraints point of view are:

• Fully constrained: the end-effector position and orientation remain always constant w.r.t. the inertial frame; • Only the position is constrained: the end-effector can freely rotate, but it cannot change its position. This is the case of a single contact point; • Only the normal translation is constrained: the translation in the direction normal to the contact plane is constrained, while the end-effector is free to move in the perpendicular directions. The end-effector can also rotate; • Rotations and the normal translation are constrained: the end-effector position is constrained as in the previous case. However, the end-effector can rotate about the normal direction only;

We model those interactions by a set of holonomic constraints which describe the limitations of the end-effector motion [START_REF] Ortenzi | Hybrid motion/force control: a review[END_REF], [START_REF] De Wit | Motion and force control[END_REF]. Often it is easier to express those constraints w.r.t. local reference frame F E . Differentiating such constraints w.r.t. time one obtains:

S c E v E E ω E = 0,
where E v E and E ω E are the end-effector linear and angular velocities w.r.t. F E , while S c ∈ R n c ×6 is a selector of the constrained directions of motion. n c ∈ N >0 represents the number of motion constraints applied to the end-effector. Note that in the local reference frame the selector matrix S c usually remains constant during each interaction task. Using the kinematic relation, the contact constraints can be expressed as a function of the robot velocities v:

S c R v E ω E = J c E v = 0, (3)
where 3 J c 3) being the rotation matrix describing the orientation of F E w.r.t. F W . The equations complementary to (3) represent instead the directions of motion of the endeffector that remain free to move, and can be written as:

E := S c RJ E ∈ R n c ×6+n , R = blkdiag(R E , R E ) with R E ∈ SO(
S f R v E ω E = J f E v =: v f , (4)
where

J f E := S f RJ E ∈ R 6-n c ×6+n with S f ∈ R 6-n c ×6 the selector matrix complementary to S c .
Rewriting the system dynamics (1) including ( 2) and taking into account the contact model ( 3)-( 4) gives:

M v + c + g = Gu + J c E f c + J f E f f (5a) J c E v + J c E v = 0, (5b)
where

G = blkdiag(G w , I 3 ), u = [ω 2 P τ A ] , f c ∈ R n c
are the contact forces and/or moments, while f f ∈ R 6-n c represent forces and moments that may arise in the unconstrained directions of motion, e.g., viscous friction during motion. Equation (5b) is the time differentiation of (3) and highlights the constraints on the accelerations v.

III. CONTROL DESIGN

Let us denote the vector of outputs of interest (called tasks) with y = [y 1 . . . y m ] ∈ R m , where m ∈ N >0 . The control method is composed of an outer loop and an inner loop. The outer-loop assumes that a certain time-derivative for each task, defined by the symbol 4

a = [y (r 1 ) 1 . . . y (r m ) m ]
, is directly controllable by a virtual input a , i.e.:

a = a . (6)
Based on this assumption any kind of stabilizing controller (PID, sliding mode, robust control, etc) can be applied by the outer loop designing a such that to steer y along a sufficiently smooth desired trajectory y d (t). In what follows, we apply to the outer loop a PID controller, whose effectiveness in stabilizing the desired output has been verified experimentally. The role of the inner-loop is instead to compute the real system inputs in order to verify as much as possible ( 6) via the resolution of a constrained optimization problem [START_REF] Charbonneau | Learning robust task priorities of QP-based whole-body torque-controllers[END_REF]:

minimize u (a -a ) W a (a -a ), (7)
subjected to several constrains, e.g.: 1) input and state boundaries, 2) contact stability constraints, 3) system dynamics, etc. The (semi) positive and diagonal weight matrix W a ∈ R m×m allows to defines soft priorities among all the tasks. As demonstrated in other robotic fields, 5 this technique can handle complex system dynamics and a large number of tasks. An additional advantage is the flexibility in adding and removing both tasks and constraints. As an example, if strict tasks priorities are required, the optimization problem can be easily modified by transforming some of the elements of the cost function into equality constraints.

The input-output asymptotic stability is obtained if it exists u such that a = a , i.e., if the optimal control input is a feedback linearizing control. This implies that a careful choice of a is required. However, the definition of a may not be easy in case the robot has to perform a complex operation in a real environment. Furthermore, the presence of several constraints may prevent to find a solution that guarantees [START_REF] Baizid | Behavioral control of unmanned aerial vehicle manipulator systems[END_REF] for all the components of a. In this case, the solution will privilege the high priority tasks while keeping bounded the the error on lower priority tasks. The priority among tasks, and consequently the behavior of the robot, can be modified by properly choosing W a .

In the following, considering a contact-based application requiring a hybrid position/force control of the end-effector, we define the appropriate set of tasks and the implementation of the inner-and outer-loop controllers.

1) Control Task Definition: For our case study, we define the output as y = (p R , R R , q A , p f , f c , r a ) and the corresponding time-derivatives to be assigned by the outer loop as

a = v R ω R v A v f f c r a .
The tasks p R , R R and q A represent the full aerial manipulator configuration, and can be used to cover several real world objectives, from simple changes of the overall position, to more complex coordinated maneuvers in cluttered environment. The task p f ∈ R 6-n c and its time-derivative v f represent the end-effector positions and velocities in the unconstrained directions of motion. The role of v f and f c is to specify the hybrid force-motion behavior of the aerial manipulator perform, when in contact. Finally, the term r a is a propeller regularization task which is defined as a function of the propeller forces and such that r a = 0 when all the forces are the same. The regularization term is designed as follows:

r a = D r a ω 2
P , where D r a ∈ R p-1×p is a matrix whose elements are 1 along the main diagonal and -1 right above the main diagonal, and all other elements are equal to zero. The goal of this task is to balance the propeller forces in order to avoid energetically unfavorable solutions where some propellers deliver almost zero thrust and others are close to saturation. 6 Notice that the virtual input associated to the tasks f c and r a are the variable themselves (zero-order time-derivative) being such tasks algebraic functions of the input.

2) Inner-Loop (QP-based Optimization): Let us consider the extended input u = [u f c ] ∈ R n+p+n c in which the contact wrench is added to the real control inputs u. In this way, inverting the dynamics (5a) and the time derivative of (4) one can express a as a linear function of u :

a = H(q)u + h(q, v), (8)
where H(q) ∈ R m×(n+p+n c ) and h(q, v) ∈ R m contain all the terms that do not depend on u . More specifically, the matrix H(q) and the bias vector h(q, v) are given by:

H(q) =     M -1 G M -1 J c E J f E M -1 G J f E M -1 J c E 0 (n c ×p) 1 (n c ×n c ) D r a 0 (p-1×n c )     , h(q, v) =     M -1 (J f E f f -c -g) J f E M -1 (J f E f f -c -g) + J f E v 0 0     .
To ensure the satisfaction of the contact constraint the equation (5b) is added to the optimization problem (7) as a constraint. Such input extension avoids the explicit inversion of J c E and the related singularity issues that may arise in some configuration.

For the considered interaction-based scenario, the innerloop control problem (7) may be formulated as

minimize u (a -a ) W a (a -a ) (10a)
subject to: u l ≤ u ≤ u u (10b) 6 This task is particularly important in the case that the number of propellers and their arrangement is redundant for the execution of the remaining tasks. as, e.g., in the case of an underactuated floating base with six or more propellers all pointing in the same direction.

Cf c ≤ b (10c) M v + c + g = Gu + J c E f c + J f E f f (10d) J c E v + J c E v = 0 (10e)
The constraint (10b) takes into account the bounds on the control inputs, such as saturations in the joint torques and propeller velocities, while (10c) ensures the respect of contact stability conditions such as friction cone (approximated with linear inequalities) and positivity of the normal force. Constraints (10e)-(10d) correspond to the dynamics of the aerial manipulator when in contact with the environment.

Observing [START_REF] Rashad | Port-hamiltonian passivity-based control on se (3) of a fully actuated uav for aerial physical interaction near-hovering[END_REF], it is easy to verify that is an instance of a Quadratic Programming (QP) problem. In fact, the cost function and constraints are a quadratic and linear functions of the optimization variable u , respectively. The QP problem allows for a fast and efficient solution that provides online the control inputs u , such that u = [u f c ] is solution of [START_REF] Rashad | Port-hamiltonian passivity-based control on se (3) of a fully actuated uav for aerial physical interaction near-hovering[END_REF].

3) Outer-Loop (Desired Dynamics): Given a desired output trajectory y d (t) the task virtual inputs a are chosen as follows:

a =         vd R -K DR (v R -v d R ) -K PR (p R -p d R ) ωd R -K DRω (ω R -ω d R ) -K PRω e Rω vd A -K DA (v A -v d A ) -K PA (q A -q d A ) vd f -K DF (v f -v d f ) -K PF (p f -p d f ) f d c -K PC (f m c -f d c ) -K IC t 0 (f m c -f d c )dt 0         (11)
where the K * are symmetric and positive definite matrices and the rotation error e Rω ∈ R 3 is given by e

Rω = 1 2 [R R R d R - R d R R R ] ∨ .
Direct feedback from FT sensors measurements is used in the force control task for computing the force error f m c -f d c , with f m c being the measured contact force.

IV. RESULTS

A. Experimental Setup

The control framework presented in Sec. III is tested with the Open Tilted Hexarotor (OTHex) [START_REF] Staub | Towards a flying assistant paradigm: the OTHex[END_REF]. The OTHex is a custom-made aerial vehicle composed of six coplanar-center propellers. The tilted arrangement of the propellers allows the multi-directional thrust property and therefore guarantees the local full actuation of its dynamics. However, despite the local full actuation, the propeller saturation still limits substantially its ability to exert a force sideways, as it will be clearly shown in some phases of the experiments, where tilting of the whole OTHex is also requested by the controller in order to get the needed pushing force.

The OTHex has been equipped with a three degrees of freedom serial manipulator as in Fig. 1. The manipulator's end-effector is composed of a pointed tool rigidly attached to a 6-axis force/torque sensor. The manipulator is controlled with a velocity control loop that commands desired motors velocities to three Dynamixel motors. The reference velocities for the velocity control loop are computed by numerically integrating the commanded joints acceleration v A , that are obtained inverting the system's dynamics [START_REF] Kim | Aerial manipulation using a quadrotor with a two DOF robotic arm[END_REF] when u = u . All experiments are performed in an indoor arena using a Motion Capture (MoCap) system. The Control algorithm is implemented in Matlab-Simulink and runs on an external PC at a frequency of 250 [Hz]. The inner-loop optimization problem in [START_REF] Rashad | Port-hamiltonian passivity-based control on se (3) of a fully actuated uav for aerial physical interaction near-hovering[END_REF] is resolved run-time by means of qpOASES solver [START_REF] Ferreau | qpOASES: A parametric active-set algorithm for quadratic programming[END_REF]. As it often occurs in real world applications, the hard QP equality constraints are softened by moving (10e) into the set of virtual inputs [START_REF] Antonelli | Impedance control of an aerial-manipulator: Preliminary results[END_REF]. This modification helps to reduce the discontinuities in the control input when the contact constraints are activated/deactivated. Contact constraints are then heavily weighted by properly designing matrix W a , to enforce the achievement of the corresponding task in [START_REF] Antonelli | Impedance control of an aerial-manipulator: Preliminary results[END_REF]. We performed three different experiments and a simulation, that will be all detailed in the next paragraphs. The QP weights used for the different tasks during each experiment are listed in Table I. The videos of the experiments are available in the attached multimedia material.

B. Pushing with Disturbances

During this experiment, the robot's end-effector gets in contact with a rigid surface. The robot is then required to push against the surface with a normal force of 5 [N]. After few seconds, a virtual force disturbance of 3.5 [N] is applied at the OTHex base link. The disturbance persists for 5 seconds, and it is removed after. The purpose of the experiment is to understand the benefit of adding direct force feedback from the force/torque sensor when tracking a reference force in presence of external disturbances. To this purpose, we compared two different scenario: in the 'no FT' case, the reference output force from ( 11) is computed as f c = f d c , thus not adding any feedback from the measured contact forces. In the 'with FT' case, the reference output force is computed including feedback terms as in [START_REF] Antonelli | Impedance control of an aerial-manipulator: Preliminary results[END_REF].

Figure 2 describes the behavior of the normal force during the push with disturbance experiment for the two different cases. In particular, the plot shows the measured ( f m c z ) and commanded ( f c z ) normal forces during the interaction task. The dashed black line is the desired normal force. The red region denotes the period of time during which the endeffector is in contact with the surface, and the blue region is the time period when the disturbance is applied.

If feedback from force/torque sensors is used in the control law (top plot of Fig. 2), the commanded vertical force (blue line) increases to 6N when the disturbance is applied. This due to the presence of force feedback, that attempts at compensating for the exernal disturbance. In fact, as a consequence of the new commanded force, the measured force f m c z (red line) remains close to 5N after a short transient phase. When no force feedback is present instead, as in the bottom plot of Fig. 2, the commanded force does not change magnitude and the error between measured and desired force increases up to 1 [N]. We recall that in this second case the force/torque sensor information is only used as ground-truth, but is not actively employed in the control algorithm.

The top plot of Fig. 3 shows the the propeller commanded angular rates ω P during the experiment with FT sensor feedback. When the external force is applied, three propellers reach saturation, which is represented in the figure by the dotted horizontal lines. Therefore, the solution a = a cannot be achieved anymore, and the QP penalizes tasks with lower priority, such as the OTHex orientation, in the attempt of maintaining a small error on the higher priority task. This effect is visible in the bottom plot of Fig. 3, where the error along the pitch angle of the OTHex increases up to 7 [deg] during the saturation phase.

C. Push and Slide

In this experiment, the robot pushes against the surface with a normal force of 2.5 [N], while sliding along the surface following a reference end-effector trajectory. We made use of FT sensors feedback for improving the tracking of the normal force, and the FT sensor information is also used for compensating the viscous friction forces acting on the surface while sliding.

The top part of Figure Fig. 3: Propellers commanded angular rates and base rotation error during pushing with disturbance. when the disturbance is applied, the propellers saturate. The robot error along the pitch direction increases to keep small the error of higher priority tasks, such as the contact force one.

along the y direction and < 0.5[cm] along the x direction). The bottom part of figure Fig. 4 shows the desired and measured normal contact force during sliding. The robot is capable of pushing with the required normal force during the whole task.

As it is possible to see in Table I, during this experiment the number of active tasks is greater than the number of independent inputs. As for the previous experiment, tasks with lower priority are penalized in order to achieve tasks with higher priority. In fact, Fig. 5 shows that the joints position error increases during the sliding task. The reference joints position is a fixed posture q d A which is not related to the end-effector references.

D. Pushing Away

In this experiment the robot performs an aggressive maneuver while hovering. In particular, the OTHex is required to move horizontally of 35 [cm] in 0.5 [s]. The robot performs the fast movement in two scenarios: while hovering with no contact with the environment, and while hovering in contact with a planar surface. In the second case, the contact is also exploited to perform the task. Fig. 11 describes the experiment in the scenario when the robot is in contact.

Fig. 6 points out how the contact is exploited for performing the fast motion: a high normal force is requested by the controller in order to "push away" the robot from the contact. The peak force is achieved by means of the manipulator: in particular, by commanding a high acceleration on the second arm joint (red line), which is absent in the scenario in which the robot is not in contact (blue line). The blue area in the plot indicates the time at which the robot performs the fast movement. At half of the time, the contact constraint equations (10e)-(10c) are removed from the QP to allow the robot to move forward. Fig. 7 is the position tracking Fig. 5: Joints position error during push and slide task. The low-priority task is penalized to allow the achievement of higher priority tasks.

error along the direction of the fast movement. Exploiting the contact allowed to reduce by 6[cm] the peak error and the robot stabilizes on the desired position in a shorter time. Furthermore, Fig. 8 shows that exploiting the contact also helped in reducing the amount of time the propellers angular rates remains saturated.

E. Force Control with Underactuation

To verify if the proposed control framework can be effectively applied also for controlling underactuated aerial systems, we performed a force control task in simulation with an underactuated hexarotor equipped with a three degrees of freedom manipulator. We control the simulated robot with the same Matlab-Simulink environment used for the experiments, while dynamics integration is performed by Gazebo simulator [START_REF] Koenig | Design and use paradigms for gazebo, an open-source multi-robot simulator[END_REF]. A virtual force/torque sensor is simulated inside Gazebo and mounted on the robot's endeffector.

The task is to achieve a desired normal force of 5 [N] while pushing against a rigid surface. The top plot in Fig. 9 shows that the robot is capable of achieving the required force despite the underactuation. The bottom plot depicts the propellers angular rates. While achieving the force task, propellers still remain far from saturation. Fig. 10 depicts instead the error on the base rotation task. Differently from the fully actuated case of Fig. 3, where the rotation error only increased in presence of external disturbances and propellers saturation, because of underactuation the robot anyways needs to tilt of 10 [deg] along the pitch direction in order to be able to execute the force task.

V. CONCLUSIONS

In this work we considered the challenging problem of precise position and force control for an aerial manipulator. The proposed method takes inspiration from whole-body control methods applied to humanoid robots. In particular, our control method is based on a multi-task optimization problem, solved with a QP method. This allows considering different control objectives (e.g., interaction force, position of the end-effector, full pose of the robot, etc.) and hard constraints that should be respected to ensure the stability of the system and the feasibility of the problem solution. The precision of the method during interaction is enhanced by a direct force-feedback exploiting a FT sensor integrated at the end-effector. We performed experimental and simulation test based on fully-and under-actuated aerial platform respectively, for different tasks: 1) push with disturbances, 2) push and slide, and 3) push away, The corresponding result show the great flexibility of the method and the improvement in the forcetracking thanks to the explicit force-feedback.

In the experiments, only the point contact scenario has been considered. In future work we shall also consider other kind of interactions, and consequently design control algorithms that will include full contact wrench feedback. Furthermore, other challenging tasks will be subject of study, such as manipulation and grasping, and multi-contact interaction. Further experiments will also be carried on with underactuated platforms.

Fig. 1 :

 1 Fig. 1: CAD rendering of the aerial manipulator designed and developed at LAAS-CNRS.

Fig. 2 :

 2 Fig. 2: Normal force at the end-effector when the robot is in contact. With FT sensors feedback (top plot), the measured force remains close to the desired value. With no feedback (bottom plot), the force drifts of ±1 [N].

Fig. 4

 4 compares the measured and the desired end-effector trajectory along the contact surface. Despite some noise due to vibrations and compliance of the arm, the tracking error always remains small (< 1[cm]

Fig. 4 :

 4 Fig.4: End-effector measured and reference trajectories on the contact surface (top plot) and measured and reference normal force (bottom plot). The robot achieves good tracking performances while keep pushing with the required force.

Fig. 6 :Fig. 7 :

 67 Fig.6: Joint 2 acceleration (left plot) and normal force (right plot) required by the controller during push away task. The robot exploits the contact to achieve a fast base acceleration.

Fig. 8 :Fig. 9 :

 89 Fig. 8: Propellers angular rates during push away task. Exploiting the contact helped in limiting propellers saturation.

Fig. 10 :Fig. 11 :

 1011 Fig.10: Base rotation error while performing force control task in simulation. Due to the system's underactuation, the robot needs to tilt in order to achieve the required contact force.

TABLE I :

 I Weights of the selected tasks for the QP cost function, during the three experiments and in simulation.

The skew operator S( ) : R 3 → R 3×3. is defined such that for two generic vectors x, y ∈ R 3 , S(x)y = x × y

The planarity assumption is adopted here for simplicity and could be replaced by a less stringent assumption of surface smoothness with small changes in the model and control law.Preprint version, final version at http://ieeexplore.ieee.org/ 2 IEEE Robotics and Automation Letters 2020

From now on, with the aim of compactness, we avoid to report the state dependence of some quantities as the Jacobian and mass matrix, and so on.

For a given variable x ∈ R, x(r) indicates the derivative of order r of x.

As, e.g., in humanoid control.Preprint version, final version at http://ieeexplore.ieee.org/ 3 IEEE Robotics and Automation Letters 2020

Preprint version, final version at http://ieeexplore.ieee.org/ 4 IEEE Robotics and Automation Letters 2020

Preprint version, final version at http://ieeexplore.ieee.org/ 5 IEEE Robotics and Automation Letters 2020

Preprint version, final version at http://ieeexplore.ieee.org/ 6 IEEE Robotics and Automation Letters 2020

Preprint version, final version at http://ieeexplore.ieee.org/ 7 IEEE Robotics and Automation Letters 2020

Preprint version, final version at http://ieeexplore.ieee.org/ 8 IEEE Robotics and Automation Letters 2020

This research was partially supported by the ANR, Project ANR-18-CE33-0001 'The Flying Coworker'.