Asghar Sadeghi

Ecotoxicity of Selected Solvents: A Comparative Study between Conventional and Non-Conventional Candidates

Keywords: Solvent, Toxicity, Aquatic organisms, ionic liquids

Solvent extraction is a common chemical process in which a compound is exploited to extract the undesired substances from a feed stream. One of the main drawbacks of industrial solvents is that they pose short and long term environmental impacts due to their high toxicity and persistent in the ecosystem once released. In this study, aquatic toxicity data for two common industrial solvents as well as two ionic liquids, as non-conventional solvents, were collected and compared. The results undermine the importance of the selection of solvents not only based on their toxicity data but also based on their physical properties.

Introduction

Solvent extraction is one of the widely-used chemical processes in which compounds will be withdrawn from a feed stream by means of a chemical solvent whose solubility is high towards the component of interest, but not towards other compounds in the solution. [START_REF] Nelson | Petroleum Refining Engineering[END_REF][START_REF] Mcketta | Encyclopedia of Chemical processing and design[END_REF][START_REF] Otsuki | Oxidative desulfurization of light gas oil and vacuum gas oil by oxidation and solvent extraction[END_REF][START_REF] Dunford | Pressurized solvent extraction of wheat germ oil[END_REF][START_REF] Marinsky | Ion exchange and solvent extraction[END_REF][START_REF] De | SOLVENT EXTRACTION OF METALS[END_REF][START_REF] Wilson | Solvent extraction: the coordination chemistry behind extractive metallurgy[END_REF] As an example, in oil refineries, heavy aromatic compounds must be extracted from the oil to improve the quality of final products. Daily, a large amount of solvent from all different categories are being used in industrial plants worldwide, [START_REF] Singh | Solvent refining of medium viscosity distillate and changes in group chemical composition[END_REF][START_REF] Vakili-Nezhaad | Solvent extraction of aromatic components from lube-oil cut by n-methylpyrrolidone (NMP)[END_REF] pointing towards the need for paying attention to the adverse environmental impacts these compounds can carry with themselves. One of the issues with industrial solvents comes from their incomplete recycling and regenerating after each cycle of use, increasing the chance of their release into the aquatic environment such as freshwater bodies. Furfural and Sulfolane are two widely used organic solvents, [START_REF] Coto | A model to predict physical properties for light lubricating oils and its application to the extraction process by furfural[END_REF][START_REF] Mehrkesh | Effect of Operating Conditions of the Extraction Process on the Physical Properties of Lubricating Oil[END_REF][START_REF] Otsuki | Oxidative desulfurization of light gas oil and vacuum gas oil by oxidation and solvent extraction[END_REF][START_REF] Fakhrhoseini | Mathematical modeling of RDC column in extraction of base oil and computing of the energy saving[END_REF][START_REF] Hatamipour | An energysaving opportunity in producing lubricating oil using mixed-solventin simulated Rotary Disc Contacting (RDC) extraction tower[END_REF][15][START_REF] Fakhr Hoseini | Experimental Liquid-Liquid Equilibrium of (Lube Cut+ Furfural+ 2, 2, 4-tri-Methyl Pentane) Ternary System from T=[END_REF][START_REF] Mehrkesh | Artificial Neural Network for modeling the extraction of aromatic hydrocarbons from Lube oil cuts[END_REF][START_REF] De Lucas | Extraction of aromatic compounds from heavy neutral distillate lubricating oils by using furfural[END_REF][START_REF] Mehrkesh | A generalized correlation for characterization of lubricating base-oils from their viscosities[END_REF][START_REF] Habaki | Liquid-liquid equilibrium extraction of aromatic compounds from model hydrocarbon mixtures for separation of cracked oils[END_REF] being well-known for their high selectivity towards aromatic compounds. These solvents are mostly used in aromatic-aliphatic separation processes since their solubility towards aliphatic hydrocarbons is not as high, sothey almost selectively dissolve only aromatic compounds. Relatively higher boiling points of these solvents, compared to that of more volatile solvents such as acetone, makes their regeneration process through distillation quite challenging. Both compounds are -to some extent-soluble in water making their existence in water bodies more likely.

On the other side,two Ionic liquids with high solubility towards aromatic compounds, due to the high polarity of these compounds, were selected. Ionic liquids are complex organic salts, usuallyin liquid state,which can be customized to have good solvent properties. Ionic liquids with low melting point and acceptable viscosity can be good candidates for liquid-liquid extraction processes. [START_REF] Mehrkesh | Optimization-based design and analysis of tailor-made ionic liquids[END_REF][START_REF] Arce | Separation of benzene and hexane by solvent extraction with 1-alkyl-3-methylimidazolium bis {(trifluoromethyl) sulfonyl} amide ionic liquids: effect of the alkyl-substituent length[END_REF][START_REF] Larriba | Separation of toluene from nheptane, 2, 3-dimethylpentane, and cyclohexane using binary mixtures of [4empy[END_REF]

Methods

To study the environmental impacts arising from the use of industrial solvents, two common solvents, namely Sulfolane and Furfural,and two non-conventional compounds, n-butylpyridinium chloride, [BPy] Cl, and 1-butyl-3-methylimidazolium tetrafluoroborate, [Bmim] BF 4 ionic liquids were studied for their impacts on aquatic organisms. Aquatic toxicity data as well as bioaccumulation factor, BCF, were used as indices to compare the greenness of these compounds. BCF factor shows thatto which extent a chemical gets into the body of living organisms in water, biota, especially on fish.

Results and discussions

The important physical properties of solvents affecting their long-term environmental impacts are listed in Table 1. As it can be observed from Table 1, all the solvents selected, have high boiling points and negligible vapor pressures,lowering the risk of air pollution, significantly.

To study the impacts of solvents in this study, their toxicity data towards aquatic organisms, namely fish, Daphnia Magna and a green algae (PKS) were collected from the literature as listed in Table 2. [START_REF] Mehrkesh | Optimization-based design and analysis of tailor-made ionic liquids[END_REF][START_REF] Bernot | Acute and chronic toxicity of imidazolium-based ionic liquids on Daphnia magna[END_REF][START_REF] Cho | Toxicity of imidazolium salt with anion bromide to a phytoplankton Selenastrum capricornutum: Effect of alkyl-chain length[END_REF][START_REF] Bernot | Effects of ionic liquids on the survival, movement, and feeding behavior of the freshwater snail, Physa acuta[END_REF][START_REF] Pretti | Acute toxicity of ionic liquids to the zebrafish (Danio rerio)[END_REF] It can be seen from Table 2 that ionic liquids can be more toxic than their organic counterparts, as [BPy] Cl in this study is considerably more toxic towards Daphnia Magna compared to sulfolane. However, much lower values for the bioaccumulation factor, BCF, of ionic liquids point towards this fact that their exposure to biota can be significantly lower than organic solventsmaking them better candidates for this purposes. Studies show that the solvent power of ionic liquids which good solvent properties, are very much comparable to that of conventional solvents meaning that, approximately, same amount of solvent would be needed to accomplish an extraction task.

Conclusions:

 Ionic liquids are not always greener than their organic solvents counterparts when they are compared to one another based on same application.

 Large size of cations and anions in ionic liquids is probably the reason of them not diffusing into the bodies of freshwater organisms, making their bioaccumulation factors meaningfully small.

 Ionic liquids are less likely to pose a risk to fish population since although their high toxicity values, their exposure can be negligible.

References:

Table 1 :

 1 Physical properties of selected solvents

	Solvents	Boiling Point ( o C)	Vapor Pressure @ 25 o C [kPa]	Water solubility @ 25 o C [g/l]
	Furfural	162	0.3	83
	Sulfolane	285	Negligible	Miscible
	[BPy] Cl	>400	Negligible	43.2
	[BMIM] BF 4	>400	Negligible	Miscible

Table 2 :

 2 Toxicity and bioaccumulation factor of selected solvents

		LC50 (Fish, fresh	EC50 (Daphnia,	EC50:	Bioconcentration
	Solvents	water, 96 h)	fresh water, 48 h)	(PKS green algae)	factor (BCF)
		[mg/l]	[mg/l]	[mg/l]	[L/kg]
	Furfural	10.5	13	45	1.41
	Sulfolane	100	852	500	1.3
	[BPy] Cl	≥ 100	20	63.9	6.04 × 10 -4
	[BMIM] BF 4	≥ 100	10.7	568	8.94 × 10 -4


domain: chim sde

text:
Asghar Sadeghi

On the Biodegradability of Industrial Solvents: A Comparative Analysis

Keywords: Biodegradability, Industrial solvents, Ionic liquids, Freshwater organisms

Solventsare widely-used in allaspects of chemical sciences.One of the disadvantages of conventional solvents is attributed tothe adverse impacts they pose on human health and ecological systems. Emerging class of solvents such as ionic liquids have been proposed to alleviate this problem. In this study, aquatic toxicity and biodegradability of two common industrial solvents are compared to those of two ionic liquids. Results from this study highlight the importance of solvent selection considering the information on thetoxicity, biodegradability and fate and transport properties of selected solvents altogether.

Introduction

Liquid-liquid extraction processes, which are normally carried out by the means of optimal solvents, are extensively used in petroleum refining as well as petrochemical and chemical industries. In these processes,undesired compounds will be removed from feed by solvents whose solubility are high towards the compounds which should be extracted out of the system, but low towards the components which should remain in the solution. [START_REF] Nelson | Petroleum Refining Engineering[END_REF][START_REF] Mcketta | Encyclopedia of Chemical processing and design[END_REF][START_REF] Otsuki | Oxidative desulfurization of light gas oil and vacuum gas oil by oxidation and solvent extraction[END_REF][START_REF] Dunford | Pressurized solvent extraction of wheat germ oil[END_REF][START_REF] Marinsky | Ion exchange and solvent extraction[END_REF][START_REF] De | SOLVENT EXTRACTION OF METALS[END_REF][START_REF] Wilson | Solvent extraction: the coordination chemistry behind extractive metallurgy[END_REF] Inlubricating oil manufacturing facilities, it is conventional to remove aromatic substances from the feed to enhance the desired properties of the final product. Every day, large amounts of industrial solvents are used in different industrial plants, [START_REF] Singh | Solvent refining of medium viscosity distillate and changes in group chemical composition[END_REF][START_REF] Vakili-Nezhaad | Solvent extraction of aromatic components from lube-oil cut by n-methylpyrrolidone (NMP)[END_REF] this fact furthermore shows that the adverse impacts coming from these chemicals should addressed accordingly. Sulfolane and furfural are industrial solvents which are widely exploited in industrial plants all over the world, [START_REF] Coto | A model to predict physical properties for light lubricating oils and its application to the extraction process by furfural[END_REF][START_REF] Mehrkesh | Effect of Operating Conditions of the Extraction Process on the Physical Properties of Lubricating Oil[END_REF][START_REF] Otsuki | Oxidative desulfurization of light gas oil and vacuum gas oil by oxidation and solvent extraction[END_REF][START_REF] Fakhrhoseini | Mathematical modeling of RDC column in extraction of base oil and computing of the energy saving[END_REF][START_REF] Hatamipour | An energysaving opportunity in producing lubricating oil using mixed-solventin simulated Rotary Disc Contacting (RDC) extraction tower[END_REF][15][START_REF] Fakhr Hoseini | Experimental Liquid-Liquid Equilibrium of (Lube Cut+ Furfural+ 2, 2, 4-tri-Methyl Pentane) Ternary System from T=[END_REF][START_REF] Mehrkesh | Artificial Neural Network for modeling the extraction of aromatic hydrocarbons from Lube oil cuts[END_REF][START_REF] De Lucas | Extraction of aromatic compounds from heavy neutral distillate lubricating oils by using furfural[END_REF][START_REF] Mehrkesh | A generalized correlation for characterization of lubricating base-oils from their viscosities[END_REF][START_REF] Habaki | Liquid-liquid equilibrium extraction of aromatic compounds from model hydrocarbon mixtures for separation of cracked oils[END_REF] These solvents have high selective solubility of aromatic components, therefore can be used for aromatic-aliphatic extraction processes.For these solvents, the higher boiling pointsmakethe process of regenerating the process solventchallenging. These solvents are both soluble inwater the very fact that makes their presence in water compartments likely.

In this study, also two organic salts (i.e. Ionic liquids) which also have high solubility of aromatic materials were chosen. These multi-atomic salts can be made to beliquid at room temperature and to have high solubility toward a component of interest. Ionic liquids with low viscosity and melting point are proved to be promising candidates for use in liquid-liquid extraction (LLE) processes. [START_REF] Mehrkesh | Optimization-based design and analysis of tailor-made ionic liquids[END_REF][START_REF] Arce | Separation of benzene and hexane by solvent extraction with 1-alkyl-3-methylimidazolium bis {(trifluoromethyl) sulfonyl} amide ionic liquids: effect of the alkyl-substituent length[END_REF][START_REF] Larriba | Separation of toluene from nheptane, 2, 3-dimethylpentane, and cyclohexane using binary mixtures of [4empy[END_REF]

Methods

In this study, to evaluate the adverse impacts that industrial solvents may have on the human health and ecosystem, long-term persistent of four solvents are studied based on their biodegradability in the water bodies by the aquatic organisms. Thus, two conventionalsolvents, sulfolane and furfural,and two non-conventional compounds, 1butylpyridinium chloride, [BPy] Cl, and 1-butyl-3-methylimidazolium tetrafluoroborate, [Bmim] BF 4 ionic liquids were considered in the current endeavor.

Results and discussions

The key physical propertiesof the selected solvents,which affect their long-term impacts on the environment,are listed in Table 1. From Table 1, it is observablethat all the selected solventshave relatively higher boiling points(i.e. lower vapor pressures) this fact by itself decreases the risk of air pollution arising from these compoundsdramatically.

In our previous study, [START_REF] Sadeghi | Ecotoxicity of Selected Solvents: A Comparative Study between Conventional and Non-Conventional Candidates[END_REF] we studied the toxicity of these selected solvents towards freshwater organisms including green algae (PKS), fish, and Daphnia Magna using the data collected from the literature. [START_REF] Mehrkesh | Optimization-based design and analysis of tailor-made ionic liquids[END_REF][START_REF] Bernot | Acute and chronic toxicity of imidazolium-based ionic liquids on Daphnia magna[END_REF][START_REF] Cho | Toxicity of imidazolium salt with anion bromide to a phytoplankton Selenastrum capricornutum: Effect of alkyl-chain length[END_REF][START_REF] Bernot | Effects of ionic liquids on the survival, movement, and feeding behavior of the freshwater snail, Physa acuta[END_REF][START_REF] Pretti | Acute toxicity of ionic liquids to the zebrafish (Danio rerio)[END_REF] Next, we looked at the chemical structures of the solvents of interest to rationalize their persistent in the ecosystem.

Chemicalstructures of the selected solvents are shown in Figure 1. As it can be seen from Figure 1,furfural has a more spread out structure with a hydrogen atom relativelyloosely connected to the (-C=O) group, so it is easier for aquatic microorganisms (bacteria, algae, etc.) to decompose the solvent and therefore it has a higher rate of biodegradation in water. On the contrary, sulfolane has a more compact structure with two oxygen atoms strongly connected to the 'S' atom making it harder for microorganisms to degrade the compound. For the ionic liquids, case is even worse since the large structure of cations and anions and the strong ionic bonds between the charged particles makes the chance of biodegradation less likely.Table 2 lists the biodegradation rate of the selected solvents.  Although ionic liquids are generally considered as the greener alternative of conventionalsolvents, due to their negligible volatility, they can be persistent in the freshwater bodies once they are released.

 Vapor pressure of studied ionic liquids confirms that they mostly have negligiblevapor pressure and higher tendency towards being in the liquid phase.

Figure 1 :

 1 Figure 1: Chemical strcutures of the selected solvents: a) furfural b) sulfolane c) [BMIM] BF 4 d) [BPy] Cl

Table 1 :

 1 Physical properties of selected solvents

	Solvents	Boiling Point ( o C)	Vapor Pressure @ 25 o C [kPa]	Water solubility @ 25 o C [g/l]
	Furfural	162	0.3	83
	Sulfolane	285	Negligible	Miscible
	[BPy] Cl	>400	Negligible	43.2
	[BMIM] BF 4	>400	Negligible	Miscible

Table 2 :

 2 Biodegradability of selected solvents[START_REF] Mehrkesh | Optimization-based design and analysis of tailor-made ionic liquids[END_REF][START_REF] Rivard | Degradation of furfural (2-furaldehyde) to methane and carbon dioxide by an anaerobic consortium[END_REF]

	Solvents	Biodegradability
		46% ThOD
	Furfural	Readily biodegradable in water
		2380 mg L -1 d -1
	Sulfolane	8 mg L -1 d -1
		<< 1 mg L -1 d -1
	[BPy] Cl
		Not readily biodegradable
	[BMIM] BF 4	1.17 mg L -1 d -1
		Slightly Biodegradable


N Briquet-Kerestedjian
email: nolwenn.briquet-kerestedjian@centralesupelec.fr

M Makarov

P Rodriguez-Ayerbe

M Grossard
email: mathieu.grossard@cea.fr

Quantifying the Uncertainties-Induced Errors in Robot Impact Detection Methods

In the context of human-robot collaboration, an efficient impact detection is essential for safe operation. Residualbased collision detection relies on the difference between the estimated and actual motor torques. However, in these modelbased methods uncertainties affect the residual in the same structural way as a collision does, leading to potential false alarms. This paper proposes to quantify the influence of uncertainties on residual generation methods based on the inverse dynamic model for both rigid and elastic-joint robots. These uncertainties-induced errors are investigated depending on their origin (parameters estimation or numerical differentiation). Boundaries of these errors are determined along a given trajectory and account as the minimum threshold of detectability of a collision. These results are illustrated in simulation.

I. INTRODUCTION

In industrial or service applications, human-robot interaction to perform tasks in cooperation involves sharing the same workspace. In this context, appropriate regulations and technologies must ensure safety and minimize the risk of injury for the operator in case of collision with the robot [START_REF] Haddadin | Safety evaluation of physical human-robot interaction via crash-testing[END_REF], [START_REF] Vasic | Safety issues in human-robot interactions[END_REF].

To prevent a collision, exteroceptive sensors and supervisions systems (such as computer vision [START_REF] Martinez-Martin | Visual people detection for safe human-robot interaction[END_REF], 3D-simulation, etc.) can be used to detect any unexpected presence in the robot area and adapt its trajectory accordingly. In case of failure of these techniques (e.g. obstruction of the field of vision or breakdown) or to furthermore enhance security, a certain number of methods are proposed to detect rapidly, sensitively and reliably a collision. To obtain a fast detection, robot capabilities can be extended by the use of additional sensors such as skin sensors [START_REF] Phan | Capacitive skin sensors for robot impact monitoring[END_REF] or proximity and contact force sensors [START_REF] Cirillo | A proximity/contact-force sensor for human safety in industrial robot environment[END_REF], however often at the expense of cost and integration constraints. Other collision detection approaches use only proprioceptive sensors, e.g. motor and joint position sensors or joint torque sensors [START_REF] Lee | Novel collision detection index based on joint torque sensors for a redundant manipulator[END_REF]. Their reliability, essential for the operator safety, is directly related to the sensitivity of the selected impact detection method.

Collision detection approaches are often derived from fault diagnostic methods, since collisions can be viewed as faulty behaviours that introduce changes in the state variables or parameters of a static or dynamic system as described in [START_REF] Venkatasubramanian | A review of process fault detection and diagnosis: Part I: Quantitative model-based methods[END_REF]. The diagnostic is composed of two steps : the residual generation followed by its evaluation. A classical residual generation method for collision detection is based on the difference between the actual applied motor torque and the estimated motor torque obtained from the robot dynamic model in the absence of any external force. To estimate the motor torque, a basic approach uses the inverse dynamic model based on the estimated parameters and configuration coordinates without any external disturbance as in [START_REF] Morinaga | Collision detection system for manipulator based on adaptive impedance control law[END_REF] and [START_REF] Geravand | Human-robot physical interaction and collaboration using an industrial robot with a closed control architecture[END_REF]. Another widely used method relies on the generalized momentum of the robot [START_REF] Luca | Collision detection and safe reaction with the DLR-III lightweight manipulator arm[END_REF], [START_REF] Haddadin | Collision detection and reaction: A contribution to safe physical human-robot interaction[END_REF], [START_REF] Wahrburg | Cartesian contact force estimation for robotic manipulators using kalman filters and the generalized momentum[END_REF]. This method has the advantage of avoiding the measure or computation of motor and joint accelerations that generate measurement noise and delay. As part of this study, only the basic method based on the inverse dynamic model of the robot will be studied at first.

These residual generation approaches are model-based methods which are affected by uncertainties if the model is not exactly known or is not properly adapted to the operational conditions (e.g. varying payload or temperature). Consequently, the estimated motor torque contains errors which affect the residual generation in the same structural way as an external force. Several approaches propose to account for uncertainties in the detection method. A Kalman filter with friction uncertainties is designed in [START_REF] Wahrburg | Cartesian contact force estimation for robotic manipulators using kalman filters and the generalized momentum[END_REF] to increase the robustness of the generalized momentum observer method. For the same method, an adaptive fault and detection isolation scheme has been proposed in [START_REF] De Luca | An adapt-and-detect actuator FDI scheme for robot manipulators[END_REF] to deal with parametric uncertainties. In a similar perspective, a new residual evaluation approach has been developed in [START_REF] Makarov | Adaptive filtering for robust proprioceptive robot impact detection under model uncertainties[END_REF] based on a dynamic statedependent threshold and an online estimated filter to adapt the algorithm to different operating conditions but without dealing explicitly with uncertainties.

This paper proposes to quantify the influence of uncertainties on the residual for both rigid and elastic-joint backdrivable robots with only motor and joint positions sensors. Indeed, despite the absence of force/torque sensor, robots with good backdrivable properties can achieve a very sensitive collision detection using only motor-side measurements, as in [START_REF] Makarov | Adaptive filtering for robust proprioceptive robot impact detection under model uncertainties[END_REF], since external forces are accurately reflected on motor shafts. This approach is derived for basic residual generation methods using the inverse dynamic model of the robot. Uncertainties are expressed as a contribution of both parameters estimation and numerical differentiation errors. The total uncertaintiesinduced errors are investigated and boundaries are determined along the trajectory, which allows to quantify the minimum threshold of detectability of a collision, that is the sensitivity of the collision detection method. Simulation results on a 6 degrees-of-freedom (DOF) manipulator robot highlight the influence of each type of uncertainties on the residual depending on the trajectory and illustrate the level of sensitivity of the method. These results give an estimate of the uncertaintiesinduced errors that can be expected online and allow to choose the method that will generate the least errors on the detection. The proposed approach can be extended to other model-based detection methods.

Section II recalls the inverse dynamic model of both rigid and elastic-joint serial robot manipulators and investigates the potential sources of uncertainties. In Section III, after a description of the problem of residual generation in presence of uncertainties, induced errors are derived using the inverse dynamic model for both rigid and elastic-joint cases and boundaries on each type of uncertainties are proposed. Section IV is devoted to the presentation of the simulation results.

Mathematical notations: In the following, def = means "by definition", a denotes the measured or estimated value of any matrix or vector variable a, and δa is defined as the difference between the measured or estimated value a and the exact value a. z and s denote respectively the complex zdomain variable and the Laplace-domain variable. In discrete time, T s is the sampling time. The notation a ∼ N (µ, σ 2 ) means that a follows a normal distribution with mean µ and variance σ 2 .

II. MODEL DESCRIPTION

For serial robot manipulators which dynamic models are briefly recalled, uncertainties may be at least of two types: parametric uncertainties due to an imperfect knowledge of the robot parameters and uncertainties due to numerical differentiation with respect to time (speed and acceleration estimations).

A. Dynamic model for serial robot manipulators

The dynamic behaviour of a serial robot manipulator with n-rigid links and joints can be described by its inverse dynamic model [START_REF] Khalil | Modeling, identification and control of robots[END_REF] as follows

Mrig(q)q + C(q, q) q + G(q) + τ f ( q) = τm + τext def = τ (1)
where q ∈ R n is the joint position vector, M rig (q) = M (q) + J mot where M ∈ R n×n is the robot inertia matrix and J mot ∈ R n×n is the constant diagonal motor inertia matrix after the reduction stage, C(q, q) q ∈ R n captures the Coriolis and centrifugal torques, G(q) ∈ R n represents the contribution of the gravity torque, τ f ( q) ∈ R n is the friction torque which is expressed by τ f ( q) = F v q+F s sign( q) in case of viscous and Coulomb friction with F v and F s respectively the viscous and Coulomb friction coefficients, τ m ∈ R n denotes the applied motor torque after the reduction stage and τ ext ∈ R n expresses the external torque vector. τ is the global motion torque. For DC motors, the motor torque τ m is related to the motor currents i m by τ m = R T red K em i m with R red the reduction matrix and K em the diagonal matrix of torque constants of the involved motors. In case of backdrivable robots, the external forces are accurately reflected on the motor shafts, which allows their detection without any additional joint torque sensor. If an external force F ext ∈ R n collides with the i th link of the robot, then F ext is related to τ ext by τ ext = J T (q)F ext where J (q) is the Jacobian matrix of the i th link.

For the purpose of human-robot collaboration, lightweight robot manipulators can be suitable because of their lower inertia which reduces the maximal torque in case of impact. The elastic-joint model (2-3) accounts for the elasticity of the transmissions :

M (q)q + C(q, q) q + G(q) + τ f a ( q) + K(q -θ) = τext (2) Jmot θ + τ f m ( θ) -K(q -θ) = τm (3)
where θ ∈ R n is the motor position vector after the reduction stage, K ∈ R n×n is the stiffness matrix assumed to be constant and diagonal in this study, τ f a ( q) ∈ R n and τ f m ( θ) ∈ R n are respectively the joint and motor friction torques which are, considering viscous and Coulomb friction, τ f a ( q) = F va q + F sa sign( q) at joint level and τ f m ( θ) = F vm θ+F sm sign( θ) at motor level, with (F va ,F vm ) the viscous friction coefficients and (F sa ,F sm ) the Coulomb friction coefficients. Summing ( 2) and ( 3) it follows

M (q)q + C(q, q) q + G(q) + τ f a ( q) + Jmot θ + τ f m ( θ) = τm + τext def = τ (4)
Let us note that when the robot is considered as completely rigid (K → ∞), θ = q and we obtain (1).

B. Model uncertainties

For model-based approaches, robot dynamic parameters can be obtained from the nominal CAD data or identified experimentally as they can slightly differ from one robot to another or for different operating conditions. Their experimental identification [START_REF] Khalil | Modeling, identification and control of robots[END_REF] uses the fact that the inverse dynamic model ( 1) of an n-degrees of freedom rigid serial robot can be written as a linear regression with respect to the n b rigid base parameters τ m = ϕ rig (q, q, q)χ rig [START_REF] Cirillo | A proximity/contact-force sensor for human safety in industrial robot environment[END_REF] where ϕ rig ∈ R n×n b is the rigid regression matrix and χ rig ∈ R n b is the vector of rigid base parameters (i.e. the minimal set of identifiable parameters). For each link, the latter are obtained by linear combinations of the 6 components of the inertia tensor, the 3 components of the first moment and the mass, the total inertia moment for rotor actuator and gears, and the viscous and Coulomb friction coefficients. For an elasticjoint robot, the linear regression can be written with respect to the n b + n f rigid and flexible base parameters [START_REF] Lightcap | Dynamic identification of a mitsubishi pa10-6ce robot using motion capture[END_REF] as follows

0 n×n τ m = ϕ f l (q, q, q, θ, θ, θ)χ f l (6)
where ϕ f l ∈ R 2n×(n b +n f ) is the flexible regression matrix and χ f l ∈ R n b +n f is the vector of the rigid and flexible base parameters. It is composed of the base parameters distinguishing rigid and flexible parameters, such as viscous and Coulomb friction at motor and joint levels, and including the stiffness parameters.

After evaluating the identification model ( 5) or ( 6) respectively in the rigid or elastic-joint case at a sufficient number of points on several exciting trajectories, the vector χ of the identified base parameters can be obtained by least squares minimization of the 2-norm of the residual errors vector. We denote δχ the vector of estimation errors defined by

δχ def = χ -χ (7)
For the following, we assume that δχ is Gaussian with zeromean and standard deviation σ χ which can be obtained from the estimation of the standard deviation of the errors vector resulting from the identification. The relative standard deviation %σ χ ,i of the i th identified parameter is defined as

%σ χ ,i = 100 σ χ ,i |χ ,i | (8)
%σ χ ,i is used as a criterion to measure the quality of the identification of the i th base parameter. Generally, we consider that the identification is acceptable if the relative standard deviation of a parameter is less than ten percent. The resulting model errors are obtained by difference between the matrices evaluated with the identified parameters and with the exact parameters. For example for the inertia matrix,

δM rig (q) def = M rig (q) -M rig (q) (9)
with M rig and M rig denoting the inertia matrix evaluated respectively with the identified parameters and with the exact parameters. Calculating the difference between the inverse dynamic model evaluated with the identified and the exact parameters, an equivalent linear regression with respect to the estimation errors is obtained. In the rigid case, we obtain δMrig(q)q + δC(q, q) q + δG(q) + δFv q + δFs sign( q) = ϕrig(q, q, q)δχrig (10)

C. Numerical differentiation errors

Another origin of the errors comes from the numerical differentiation. Indeed, when only position sensors are integrated into the robot, in an industrial context velocities and accelerations are often rather approximated by finite differences from Taylor series than estimated by observers. For this study, we will consider the example of two common numerical differentiation methods and study the corresponding errors.

• Method D 1 : Fourth-order backward finite difference

G 1 (z) = 2 + z -1 -z -3 -2z -4 10T s . ( 11
)
• Method D 2 : First-order low-pass filtered derivative G 2 (z). Fig. 1 compares the two numerical derivation scheme in the frequency domain. For both approaches, the approxiis significantly deteriorated at high frequencies since the signal is low-pass filtered and the phase shifted.

G 2 (z) = α 1 -z -1 1 -βz -1 (12
More generally, regardless of the chosen numerical differentiation filter, when derivatives are estimated from noisy measurements, the error with respect to the exact derivative of the signal is twofold: it contains an error term due to the derivative approximation, and an error term due to filtered measurement noise. We denote q the measured joint positions and define q and q respectively the joint velocities and accelerations obtained by numerical differentiation of q (and similarly for the measured motor positions θ ). We also define δ q the vector of errors due to numerical differentiation of joint velocities as δ q def = qq (13)

Similarly we obtain δ q, δ θ and δ θ respectively for the joint accelerations and the motor velocities and accelerations. Let q = q + ξ be the noisy position measurement affected by a white bounded noise ξ due for instance to quantization. In the Laplace-domain, the error δ qj due to numerical differentiation on the j th axis velocity is given by

∆Q j d (s) = [H(s) -s]Q j (s) approximated velocity-induced error + H(s)ξ j (s)
filtered noise [START_REF] Makarov | Adaptive filtering for robust proprioceptive robot impact detection under model uncertainties[END_REF] where ∆Q j d (s), Q j (s) and ξ j (s) are respectively the Laplace transforms of δ qj , q j and ξ j for the j th axis. Similarly we obtain the error δ qj on the acceleration of axis j in the Laplace domain

∆Q j dd (s) = H 2 (s) -s 2 Q j (s) + H 2 (s)ξ j (s) (15)
with ∆Q j dd (s) the Laplace transform of δ qj for the j th axis. We obtain similar expressions for δ θ and δ θ.

From Equations ( 14) and ( 15) the errors due to derivative approximation and the errors due to the filtered noise can be quantified and bounded (see Section III-C).

III. QUANTIFICATION OF THE INFLUENCE OF UNCERTAINTIES ON THE RESIDUAL A. Problem statement

For collision detection, a basic residual generation method can be based on the difference between the estimated global motion torque τ and the applied motor torque τ m

r def = τ -τ m (16)
The estimated global motion torque τ is obtained from the inverse dynamic model with the matrices evaluated with the estimated parameters and coordinates, that is using (1) in the rigid case τ = Mrig (q )q +C (q , q ) q +G (q )+Fv q +Fs sign( q ) (17)

For the elastic-joint case we can use either (2-3) or ( 4) to estimate the global motion torque τ .

In the ideal case when the estimated parameters and coordinates are equal to the exact values, then

τ = ideal τ = τ m + τ ext ⇒ r = ideal τ ext (18)
However in the general case the inverse dynamic model (17) contains errors denoted δτ such that

τ = τ + δτ ⇒ r = τ ext + δτ (19)
Therefore in the general case (19), even in the absence of external torque the residual is non-zero due to the presence of uncertainties that depend on the robot's state and affect the residual in the same structural way as a collision. Thus bounding the errors due to the uncertainties along the trajectory allows to predict in the minimum threshold of detectability of a collision. Then an adaptive detection threshold can be set equal or above this level in order to avoid false alarms due to uncertainties.

B. Influence of the uncertainties on the residual

In this section, we give an explicit formulation of the term δτ in (19) that represents all the errors induced by the uncertainties. For both rigid and elastic-joint cases, it is given by the difference between the estimated and the exact global motion torques. For the sake of simplicity, Coulomb frictions will be neglected here.

For the rigid case, we obtain from ( 1) and ( 19) δτrig = [Mrig (q )q + C (q , q ) q + G (q ) + Fv q ] -[Mrig(q)q + C(q, q) q + G(q) + Fv q] (20)

In (20) the exact matrices will be expressed by the difference between the matrices evaluated with the identified parameters and their error estimation term using [START_REF] Geravand | Human-robot physical interaction and collaboration using an industrial robot with a closed control architecture[END_REF]. It is assumed that M rig (q ) ≈ M rig (q), C (q , q ) ≈ C (q, q) and G (q ) ≈ G (q) since small variations in q or q induce small variations in the trigonometric functions of M rig , C and G . Thus the error terms due to numerical differentiation appear using [START_REF] De Luca | An adapt-and-detect actuator FDI scheme for robot manipulators[END_REF]. We finally obtain the theoretical expression of δτ for the rigid case

δτ rig = δτ p rig + δτ d rig ( 21
)
with δτ p rig = δM rig (q)q + δC(q, q) q + δG(q) + δF v q δτ d rig = M rig (q )δ q + C (q , q )δ q + F v δ q

The term δτ p can be rewritten in a linear form with respect to δχ rig using [START_REF] Luca | Collision detection and safe reaction with the DLR-III lightweight manipulator arm[END_REF]. A similar expression can also be derived for the elastic-joint case with the same method using the notations f l 1 and f l 2 respectively for the expressions ( 2) or ( 4) of the motion torque in the elastic-joint case. In the first case, we obtain

δτ f l1 = δτ p f l1 + δτ d f l1 (22)
with δτ p f l1 = δM (q)q + δC(q, q) q + δG(q) + δF va q + δK(qθ) δτ d f l1 = M (q )δ q + C (q , q )δ q + F va δ q

In the second case, we obtain

δτ f l2 = δτ p f l2 + δτ d f l2 (23)
with δτ p f l2 = δM (q)q + δC(q, q) q + δG(q) + δF va q

+ δJ mot θ + δF vm θ δτ d f l2 = M (q )δ q + C (q , q )δ q + F va δ q + J mot δ θ + F vm δ θ
Expressions ( 22) and (23) of the errors in both methods f l 1 and f l 2 allow to select the method that minimizes the effect of uncertainties, depending on which flexible parameters generate less error between stiffness or motor inertia and friction. Finally, in both the rigid case (21) or in the elastic-joint case (22-23), the different expressions of δτ are all composed of a term δτ p due to parametric uncertainties and a term δτ d due to numerical differentiation errors. Thus, these formulations allow to evaluate if the parameters estimation errors prevail or if the numerical differentiation errors are predominant (e.g. in case of trajectory with rapid changes). They also give a quantitative evaluation of the influence of uncertainties that can be expected online for a given trajectory.

C. Bounding the estimation errors

From the expression of uncertainties in both the rigid (21) and elastic-joint (22-23) cases, the uncertainties-induced errors on the detection method can be bounded. In the following, dependencies in motor and joint coordinates are removed in the notations for the sake of simplicity. a) Errors δτ p due to parametric uncertainties: It is assumed in II-B that δχ is Gaussian such that δχ ∼ N (0, σ 2 χ ) with σ 2 χ the diagonal covariance matrix of χ . Thus, the errors δτ p are also Gaussian with δτ p rig = ϕ rig δχ rig ∼ N (0, ϕ rig σ 2 χrig ϕ T rig ) in the rigid case, or

δτ p f l = ϕ f l δχ f l ∼ N (0, ϕ f l σ 2 χ f l ϕ T f l ) in the elastic- joint case. We denote σ p = (ϕ rig σ 2 χrig ϕ T rig ) or (ϕ f l σ 2 χ f l ϕ T f l
) the resulting standard deviation of δτ p in both cases. Consequently, provided a reference trajectory along which ϕ rig or ϕ f l can be determined, for a given standard deviation σ χ of the parameters estimates, and in accordance with the normal law, confidence intervals can be computed for the errors δτ p due to parametric uncertainties. For example, the probability that δτ p belongs to the interval [-3σ p , 3σ p ] is 99,7%. b) Errors δτ d due to numerical differentiation: In Section II-C, the errors due to the numerical differentiation were separated in two components, one due to the derivative approximation, and one due to filtered measurement noise. Let us first consider the term due to the derivative approximation in velocities estimates, corresponding to the transfer function [H(s) -s] between the exact position input and its filtered derivative error output. For a given position trajectory characterized by velocities bounded by v max and accelerations bounded by a max , the input trajectory can be approximated for analysis purposes by an equivalent sinusoidal signal of amplitude E eq = v 2 max /a max and pulsation ω eq = a max /v max . Therefore the term due to the derivative approximation in velocities estimates can be bounded by A d = |H(jω eq ) -jω eq |E eq . The term due to the derivative approximation in accelerations estimates is similarly bounded by A dd = |H(jω eq ) 2 -jω 2 eq |E eq . Let us now consider the term due to filtered measurement noise in velocities estimates for the j th axis. In discrete time, if the input noise ξ j is white of variance σ 2 ξj (e.g. quantization noise), the output noise filtered by G(z) (of impulse response

g[k]) is Gaussian of variance σ 2 dj = σ 2 ξj ∞ k=-∞ g 2 [k] = σ 2 ξj 1/2 -1/2 |G(ν)| 2 dν
. For the two considered numerical differentiation method, we obtain

• Method D 1 : σ 2 dj = σ 2 ξj 2(a 2 + b 2 ) with a = 2 10T s , b = 1 10T s (24)
• Method D 2 :

σ 2 dj = σ 2 ξj 2α 2 1 + β with α, β defined in (12) (25)
We proceed similarly for the accelerations estimates to find the output noise variance σ 2 ddj . Similarly than in the previous analysis of δτ p , it is therefore possible, in accordance with the normal law, to define confidence intervals for the part of the errors δτ d due to filtered noise. For the 99,7%-confidence interval, the upper bound would be 3σ d .

Finally, δ q can be bounded by ±(A d + 3σ d ) and δ q can be bounded by ±(A dd + 3σ dd ). Thus, knowing the bounds on δ q and δ q, the expression of δτ d detailed in (21) can be bounded for a given trajectory along which the matrices M and C are evaluated.

IV. SIMULATION RESULTS

The previously detailed results on the quantification of errors induced by parametric and numerical differentiation uncertainties were tested in simulation in the rigid case to compare their respective contributions to the error torque δτ in different situations. The case study concerns a 6-DOF robot manipulator where motor positions are available from encoders on motor shafts. The structure of the robot is presented in Fig. 2. I). They are composed of trajectories with different dynamics (amplitude E 0 , frequency f 0 ) and with varying accuracy in parameters estimation or numerical differentiation schemes. While velocities and accelerations of the sinusoidal trajectory will be sinusoidal, the triangular trajectory is more unfavorable since the acceleration peaks will excite the errors due to the uncertainties of the inertia matrix. We consider first favorable identification results where for each parameter i, %σ χ ,i ∈ [-5%, 5%] and then an unfavorable case with %σ χ ,i ∈ [-20%, 20%]. For this purpose, each %σ χ ,i is fixed randomly and independently within these ranges. Noise on the position measurement is modeled by a white noise with zero-mean and variance equal to κ 2 /12 where κ is the position sensor resolution.

TABLE I: Simulated configurations

From all combinations of [T i , U j , D k ], i, j, k = 1..2, the maximum error between the exact expression (20) of δτ and the expression (21) due to the approximation explained in III-B is = 10 -2 [2.16; 1.66; 1.03; 0.87; 0.57; 0.34] Nm which is negligible with respect to the applied motor torques. Results are presented for axis 1 which is the most inertial axis but the least subject to the effects of gravity and for axes 3 and 4 which are more affected by gravity-related uncertainties, with axis 4 belonging to the robot wrist.

First, the contribution of each type of uncertainties is examined without any collision. Simulation results on uncertaintiesinduced and numerical differentiation errors are presented in Fig. 3 for T 1 and in Fig. 4 for T 2 . All the simulations are realized with the same sets of randomly and normally distributed parametric uncertainties according to U 1 or U 2 . Results are presented for numerical differentiation scheme D 1 as it filters more high frequencies due to noise than D 2 for the chosen ω c (see Fig. 1). For both T 1 and T 2 trajectories, the [-3σ p , 3σ p ]-envelop and the [δτ d rig,min , δτ d rig,max ]-envelop with δ q bounded by ±(A d + 3σ d ) and δ q bounded by ±(A dd + 3σ dd ), both determined along the trajectory, represent the worst case of errors respectively due to parametric uncertainties and to numerical differentiation and give a reliable boundary of these errors. The effect of uncertainties on the residual generation is then studied in presence of an impact for the configuration [T 1 , U 1 , D 1 ]. To simulate a collision, an external torque of 1 Nm during 0,5 seconds is applied on each axis one after the other in order to emphasize the effects on each axis. Results are illustrated in Fig. 5. Parameters and numerical differentiation uncertainties significantly affect the residual which is not only the external torque as in the ideal case. Boundaries on δτ rig are also represented on Fig. 5 as the sum rig,min , δτ d rig,max ]envelop with δ q bounded by ±(A d + 3σ d ) and δ q bounded by ±(A dd + 3σ dd ), where both envelops are determined for the configuration [T 1 , U 1 , D 1 ] along the trajectory with collision. For axes 1 and 3, given that the boundaries on the uncertainties-induced errors are above 1 Nm at the moment of the collision, the impact can not be detected on these axes, while on axis 4 the boundaries are smaller than the amplitude of the collision, which means that the detection method is sensitive enough to detect the collision. Thus simulating these boundaries allows to predict the minimum amplitude of the collision that can be detected, depending on the accuracy of the parameter estimation and the selected numerical differentiation scheme. The sensitivity of the detection can be increased by reducing the width of the envelopes (e.g. considering [-2σ p , 2σ p ] instead of [-3σ p , 3σ p ]) but at the expense of increasing the risk of false alarms due to uncertainties.

V. CONCLUSION AND PERSPECTIVES

In this paper, an evaluation of the errors due to uncertainties has been derived for a basic collision detection method using the inverse dynamic model of both rigid and elasticjoint robots. These uncertainties-induced errors have been decomposed into a combination of parameters estimation and numerical differentiation errors and a method to obtain their boundaries has been proposed. This approach allows to quantify the influence of the uncertainties on the collision detection, to evaluate which uncertainties source will generate more errors and to determine in simulation the expected sensitivity of the collision detection method depending on the uncertainties.

This method can be extended to other model-based collision detection approaches (e.g. collision detection methods based on the generalized momentum) in order to compare their performance in presence of uncertainties in a quantified way and determine the favorable cases for each method.

Fig. 1 :

 1 Fig. 1: Frequency responses of continuous exact derivative, first-order backward finite difference and first-order filtered derivative methods with ω c = 2π110 rad/s and T s = 1 ms

Fig. 2 :

 2 Fig. 2: Kinematics model of the serial robot manipulator with associated frames by Denavit-Hartenberg convention For the simulations, each axis is controlled in position with a proportional-integral-derivative (PID) control law. The sample time is 1 ms. The studied configurations are the combinations of [T i , U j , D k ] with i, j, k = 1..2 (see TableI). They are composed of trajectories with different dynamics (amplitude E 0 , frequency f 0 ) and with varying accuracy in parameters estimation or numerical differentiation schemes. While velocities and accelerations of the sinusoidal trajectory will be sinusoidal, the triangular trajectory is more unfavorable since the acceleration peaks will excite the errors due to the uncertainties of the inertia matrix. We consider first favorable identification results where for each parameter i, %σ χ ,i ∈ [-5%, 5%] and then an unfavorable case with %σ χ ,i ∈ [-20%, 20%]. For this purpose, each %σ χ ,i is fixed randomly and independently within these ranges. Noise on the position measurement is modeled by a white noise with zero-mean and variance equal to κ 2 /12 where κ is the position sensor resolution.

Trajectory T 1 :D 1 :• 10 10 σ 2 ξ j differentiation D 2 :

 112 scheme of cut-off frequency ωc = 2π110 rad/s σ 2 d j = 3.55 • 10 5 σ 2 ξ j ; σ 2 dd j = 1.48 • 10 11 σ 2 ξ j

  For favorable identification results (e.g. for the configurations[T 1 , U 1 , D 1 ] or [T 2 , U 1 , D 1 ]), the errors due to model-uncertainties and numerical differentiation are of the same order of amplitude. However when model parameters are poorly identified (e.g. for the configurations[T 1 , U 2 , D 1 ] or [T 2 , U 2 , D 1 ]), for each axis the error term due to model-uncertainties becomes dominant over the numerical differentiation error.

Fig. 3 :

 3 Fig. 3: Uncertainties-induced errors on trajectory T 1

Fig. 4 :

 4 Fig. 4: Uncertainties-induced errors on trajectory T 2 of the [-3σ p , 3σ p ]-envelop and the [δτ drig,min , δτ d rig,max ]envelop with δ q bounded by ±(A d + 3σ d ) and δ q bounded by ±(A dd + 3σ dd ), where both envelops are determined for the configuration [T 1 , U 1 , D 1 ] along the trajectory with collision. For axes 1 and 3, given that the boundaries on the uncertainties-induced errors are above 1 Nm at the moment of the collision, the impact can not be detected on these axes, while on axis 4 the boundaries are smaller than the amplitude of the collision, which means that the detection method is sensitive enough to detect the collision. Thus simulating these boundaries allows to predict the minimum amplitude of the collision that can be detected, depending on the accuracy of the parameter estimation and the selected numerical differentiation scheme. The sensitivity of the detection can be increased by reducing the width of the envelopes (e.g. considering [-2σ p , 2σ p ] instead of [-3σ p , 3σ p ]) but at the expense of increasing the risk of false alarms due to uncertainties.

Fig. 5 :

 5 Fig. 5: Residual generated in presence of a collision on each axis separately with the configuration [T 1 , U 1 , D 1 ]


Olga Kovalenko
email: olga.kavalenko@tuwien.ac.at

Jérôme Euzenat
email: jerome.euzenat@inria.fr

Semantic matching of engineering data structures

Keywords: ontology matching, correspondence, alignment, mapping, ontology integration, data transformation, complex correspondences, ontology mapping languages, procedural and declarative languages, EDOAL

An important element of implementing a data integration solution in multi-disciplinary engineering settings, consists in identifying and defining relations between the different engineering data models and data sets that need to be integrated. The ontology matching field investigates methods and tools for discovering relations between semantic data sources and representing them. In this chapter we look at ontology matching issues in the context of integrating engineering knowledge. We first discuss what types of relations typically occur between engineering objects in multi-disciplinary engineering environments taking a use case in the power plant engineering domain as a running example. We then overview available technologies for mappings definition between ontologies, focusing on those currently most widely used in practice and briefly discuss their capabilities for mapping representation and potential processing. Finally, we illustrate how mappings in the sample project in power plant engineering domain can be generated from the definitions in the Expressive and Declarative Ontology Alignment Language (EDOAL).

Introduction

Ontology and data matching tasks are key steps for semantic data integration [START_REF] Breslin | Semantic web computing in industry[END_REF] and therefore they often surface in real-world applications that have the need to exploit relations between the concepts and instances of two data sources. Ontology alignments express these relations explicitly in order to be processed as mappings for various applications, e.g., for data transformation or query rewriting [START_REF] Shvaiko | Ontology matching: state of the art and future challenges[END_REF].

Postprint of Chapter 6 of Stefan Biffl, Marta Sabou (eds.), Semantic web technologies for intelligent engineering applications, Springer, 2016[DOI: 10.1007/978-3-319-41490-Although much work has been done on ontology schema matching and defining data level mappings, it is not obvious, especially for non Semantic Web experts, which of the provided tools and technologies will be well-suited in a specific real-life application case and how to apply them [START_REF] Vyatkin | Software engineering in industrial automation: State-of-the-art review[END_REF]. For engineering practitioners, it might be challenging to understand a) which technologies can be used to represent the relations between their data models and datasets; and b) how to use these for a specific application. On the other hand, Semantic Web researchers might lack insight on (1) what are the needs (in terms of mappings) of real-world applications in engineering; and (2) how well existing mapping technologies can support defining such mappings. In this chapter we aim to address these gaps for the benefit of practitioners and Semantic Web researchers alike. Therefore, we formulated the following research questions for the chapter: (Q1) What kind of relations are expected to occur often between the engineering data models and data sets? (Q2) What are the available mapping languages developed by Semantic Web community and what are their characteristics? (Q3) How well the existing mapping languages can support defining and representing the relations identified for Q1?

In order to answer Q1 we synthesized our experiences from a) implementing semantic integration in the real-life application scenario from our industry partner, a power plant systems integrator; and b) literature analysis in the fields of ontology matching and schema matching. As a result, we derive a catalog of schema and data correspondences that are expected to arise often in ontology mediation applications (see Section 6.4 for details). We focus on complex correspondence types that are not obvious with respect to their representation, i.e., those that go beyond simple one-to-one mapping (like owl:sameAs) between the entities. These are already well-explored and supported by existing ontology matching solutions. For more information about existing matching techniques, systems and tools please see a comprehensive review by [START_REF] Otero-Cerdeira | Ontology matching: A literature review[END_REF] or [START_REF] Euzenat | Ontology matching[END_REF].

Our application scenario, a power plant engineering project, belongs to the automation system engineering domain where mappings between ontologies are used to support data integration. The intended application in this case is enabling data transformation from the local ontologies of the different engineering disciplines involved in a project into a common ontology in order to allow the project-level integration (see Section 6.3 for the detailed description). As in the presented use case ontology mapping is used for data transformation, we will use it as default application for the sake of coherence across the chapter. Therefore, when speaking about mappings in this chapter, it can be assumed that they are done for data transformation.

In Section 6.5 we overview available technologies for mappings definition, representation and processing and briefly discuss their main usages in current practice and potential strengths and limitations w.r.t. representing correspondences identified in Section 6.4 (therefore, addressing Q2 and Q3). Finally, Section 6.6 introduces the EDOAL language, gives the examples of how the identified correspondence types can be implemented in this language and show how they can be used for data transformation. We chose EDOAL because, contrary to other languages, it combines the features of both declarative and procedural languages: a) it has been designed for expressing correspondences (conforms to declarative languages); b) but at the same time those correspondences can be interpreted to perform linking, i.e., primitive Silk scripts [START_REF] Volz | Silk: A link discovery framework for the web of data[END_REF], SPARQL1 queries, SPARQL+SPIN2 can be generated to perform data transformation for instance.

Our main contributions therefore are:

1. A catalog of complex correspondence types with the examples of those in real-world application scenario in the automation systems engineering domain; 2. A succinct overview of existing mapping languages, their principal features and capabilities; 3. A detailed analysis of EDOAL capabilities to support identified correspondences types.

Ontology matching: background information and definitions

In this section we provide background information on ontology matching and give the definitions of the important terms, which will be used across the chapter. We will follow the terminology from the "Ontology Matching" book [START_REF] Euzenat | Ontology matching[END_REF] and from [START_REF] Scharffe | Ontology alignment design patterns[END_REF]:

Ontology matching is the process of finding relations between the entities of different ontologies, e.g., identifying the entities that represent the same (or similar) semantics in these ontologies. Correspondence is the expression of a relation holding between entities (classes, properties or individuals) of different ontologies. Correspondences express the essence of how the entities are related independently from any application or implementation details in a specific mapping language. Alignment is a set of correspondences between two ontologies. The alignment is the output of the ontology matching process. Mapping specifies the connection between ontology entities in enough details to process or execute them for a certain task. Execution in this case means using a specific engine/tool that can read the mapping, understand its semantics and run it according to the intended application. The output of the execution will vary depending on specific application. For instance, for data transformation it will be data set conforming to the target ontology); and for query rewriting the initial query (formulated in the source ontology vocabulary) will be transformed into the query in the one formulated according to the target ontology vocabulary. A mapping, therefore, is a correspondence expressed in a specific mapping language with a certain exploitation in mind.

Both correspondences and mappings can be specified on the data (ontology instances) or schema (ontology classes and properties) level.

The main terms defined above as well as possible articulation between these terms (for the data transformation scenario) are illustrated in Fig. 6.1. Three main dimensions may be distinguished in the ontology matching area Noy (2004): a) alignments discovery, i.e., ontology matching, b) alignments representation, and c) applying of them as mappings.

The majority of works in the area is dedicated to ontology matching, which is a challenging and complex problem. Although many tools have been developed using different approaches, e.g., language-based, structure-based or contextbased, discovery processes tend to be highly iterative and cannot be fully automated in the majority of cases [START_REF] Bernstein | Model management 2.0: manipulating richer mappings[END_REF]. Interested reader can find the detailed description of various alignments discovery approaches in [START_REF] Euzenat | Ontology matching[END_REF].

Another important issue in the ontology matching area is the application of mappings, i.e., to be applied for a specific task alignments should be implemented in some mapping language; and then the obtained mappings can be processed for an application at hand. The precise type of application will for a large part determine the choice of a language to express mappings. Typically applications aim to reduce semantic heterogeneity. The often reported applications are ontology merging, data translation and ontology integration.

Finally, the third dimension of the ontology matching area is dedicated to defining and representing alignments and mappings. Different languages may be used for that purpose with various characteristics (see Section 6.5 for more details). At the same time, there is a lack of guidelines (especially for non Semantic Web experts) on how to select a language for specific application and what are the important features of these languages that will influence the choice.

In this chapter we focus on the representation problem, in particular when this involves complex relations between entities. As we see in next sections, this is the case in the engineering domain.

Running example: the power plant engineering project

Power plant engineering projects represent complex environments where participants from different disciplines (e.g., mechanical, electrical and software engineering), have to collaborate to deliver high quality end products while satisfying tight timeframes [START_REF] Mordinyi | Engineering object change management process observation in distributed automation systems projects[END_REF]. This application scenario is based on a case study implemented in a power plant engineering project of our industry partner, an automation system solution provider. Initially, different disciplines within the project applied isolated engineering processes and workflows: a) isolated data sets stored in various proprietary data formats and discipline-specific relational databases; and b) tools were loosely coupled with limited capabilities for cross-disciplinary data exchange or/and data analysis. The goal of the case study was to implement an ontologybased integration solution in order to allow cross-disciplinary data exchange and data analysis for advanced applications, such as change propagation and consistency checking across the discipline boundaries.

Local (Discipline-Specific)

Data Sources (e.g. Databases)

Local Ontologies

Common Concepts Ontology

Fig. 6.2. Hybrid ontology integration (adapted from [START_REF] Wache | Ontology-based integration of information-a survey of existing approaches[END_REF]).

After analyzing the project requirements the hybrid ontology approach for integration according to [START_REF] Wache | Ontology-based integration of information-a survey of existing approaches[END_REF] (see Fig. 6.2) has been chosen for the final system. According to this approach, a local ontology is built for each engineering discipline, gathering discipline-specific data models, knowledge and constraints, and finally, data. Then an additional integrating layer is introduced -a common knowledge base -that contains only concepts, which are important on the project level. These concepts are called common concepts [START_REF] Biffl | Risk assessment in multi-disciplinary (soft-ware+) engineering projects[END_REF], because they are typically relevant within at least two engineering disciplines. For more detailed description of common concepts please see Chapter 4 "The Engineering Knowledge Base Approach". The final system can be implemented following one of the two basic approaches: a) the CC ontology defines the structure of the common knowledge base and data is stored in database(s); or b) the CC ontology is populated with instances and serves itself as a common knowledge base for a project. In both cases the advantage is that the CC ontology defines a common vocabulary on the top of the engineering project and provides a single access point for data analysis across the disciplines. Within the case study the second approach was chosen. In the application scenario, mappings are defined between the local discipline-specific ontologies and the CC ontology to serve as a basis for data transformation from the local level into the CC ontology.

We present the part of the ontological system developed for the case study as the running example in this chapter. In this example, the two domains are integrated: a) mechanical engineering (ME), responsible for designing the physical structure of devices and connections between them, and b) project management (PM), responsible for managing the information about past and current projects, and people involved in the development. To construct and populate the CC ontology, it is necessary to transform data from the domain models into the integrated model according to specified mappings between the domain ontologies and the CC ontology. Fig. 6.3 illustrates the constructed ontological system. Each domain is represented by its local ontology. The ME ontology comprises entities related to the physical topology of a power plant, and the PM ontology includes entities related to personnel involved in the development and project organization aspects. The CC ontology includes only those entities that are relevant on the project level. For the sake of simplicity, the set of objects and properties (shown in the running example) is limited to the minimal set necessary to illustrate all the correspondences types that are introduced further in Section 6.4 (see Fig. 6.3). These correspondences specify the various relations between the entities of local ontologies and the CC ontology and, when implemented as mappings, can define data transformations from the local storages to the integrated storage.

Representing relations between engineering objects

In this section, we overview what kind of correspondences and mappings between ontology entities may occur while capturing relations between the engineering data models and data (though the described ones are not strictly specific to the engineering domain and may arise in other domains as well).

In order to identify the presented correspondences we followed a bottom-up approach. First, we analysed what types of relations occur often in the engineering data, summarizing our experiences with implementing semantic integration in the multi-disciplinary engineering projects of the industry partner. Secondly, we performed a literature analysis in the ontology mediation, ontology matching and schema matching fields, in order to verify that identified correspondences are not specific to our scenarios, but are indeed widespread and recognised by researchers and practitioners from different domains and can be found in a wide range of application scenarios. Besides describing the correspondences in general, we provide concrete examples of those from the application scenario presented in Section 6.3. To better position the identified correspondences in the ontology matching field we link them to the ontology alignment design patterns3 and the work of F. Scharffe on correspondence patterns [START_REF] Scharffe | Correspondence patterns representation[END_REF].

The presented correspondences can be expected to occur frequently in various ontology mediation tasks. At the same time, they require the use of an expressive formalism in order to be properly defined. We proceed with the detailed description of these correspondences in general and examples for those from the real-life application scenario.

Value processing (M1-M4)

Often, the relation between values of two entities can be represented by some function that takes a value on one side as an input and returns a value on another side as an output, i.e., some processing is needed to map the entities. The complexity of this processing varies from simple string operations to sophisticated mathematical functions. This type of correspondences is considered in [START_REF] Scharffe | Correspondence patterns representation[END_REF] as the "Property value transformation" pattern, where the author distinguishes between the string-based, operations on numbers and unit conversion transformations. In the following, several types of such correspondences are described in detail.

String processing (M1)

Description. As string values are widely used for data representation, the processing of string values is often needed while transforming data from one ontology into another. Expressing such correspondences requires using special functions on string values, e.g., "concat", "substring", or "regex". An example of this cor-respondence for the "concat" function can be found in [START_REF] Scharffe | Correspondence patterns representation[END_REF] under the name of "Class Attribute to Attribute Concatenation Pattern". Example. In the ME ontology, each physical component's location is defined via the hasLocation property, whose value is a string combining sector and region (defines location within a specific sector) information for a specific component. In the CC ontology the location information of a physical component is explicitly divided into two separate properties. The correspondence specifies that the initial string must be split into two parts, which then will be used to construct values for the hasSectorLocation and the hasRegionLocation properties in the CC ontology (see Fig. 6.4).

Data type transformation (M2)

Description. It can happen that in a proprietary data model the data type of a certain property was not modeled in an optimal way, e.g., the date can be represented in the format of "string", instead of "Date" or "DateTime". This type of correspondence encodes, therefore, how the value of one type in source ontology can be transformed into value of a different type in a target ontology.

Generally, the data types can be compatible, partially compatible or incompatible [START_REF] Legler | A classification of schema mappings and analysis of mapping tools[END_REF]. For instance, "integer" and "string" are compatible data types (although only uni-directionally); "date" and "string" are partially compatible (the compatibility will depend on a specific value); and "DateTime" and "integer" are incompatible data types. For the compatible data types there is also a possibility to specify correspondence in a more general way, i.e., specifying how these data types can be transformed into each other. For the example above it could be defining how any "Date" value should be transformed into a "string" value. In this case, the inverse mapping cannot be defined in a general way.

Example. All values of the hasStartingDate property in the PM ontology are strings in the following format "DD/MM/YYYY". But because the data type of the corresponding property in the CC ontology is "Date", a data type transformation correspondence takes place between these two properties (see Fig. 6.5).

Math functions (M3)

Description. In this case, value processing involves some mathematiical operations or is specified by a formula representing mathematical, physical, or other natural laws. This, for an instance, can be such simple mathematical operations as addition or multiplication, or more complex functions such as finding an integral or logarithm. However, capturing the relation in this case is done by the means of the used mapping language.

Example. The value of the hasDuration property in the CC ontology is equal to substracting hasStartingDate from hasEndingDate in the PM ontology (see Fig. 6.6).

User-defined functions (M4)

Description. For this type of correspondences, the relation is expressed by functions that are not supported by the used mapping language/technology, but must be additionally implemented. Therefore, it must be possible to call an external function, e.g., implemented in Java, that will generate a property value or an entity in a target ontology.

Example. The concept MechatronicComponent in the CC ontology captures information regarding complex composite components, which consist of many physical components and basically can represent a plant itself. The anticipated amortization value can be an important characteristic for such objects. The exact value will depend on the location, price and installation date of a specific mechatronic component (see Fig. 6.7).

Structural differences (M5-M6)

A frequent situation is that two ontologies, covering the same or similar knowledge area, were designed by different people and in different time, following different modeling approaches and not aware of each other. In this case, the same semantics can be modeled very differently. This type of correspondences serves to smooth such kind of differences.

Granularity (M5)

Description. In this case, the same real life object is modeled at a different level of detail in the two ontologies.

Example. In the ME ontology the concept Physical component is used to represent both single devices, e.g., a specific sensor, and complex objects that comprise many devices, e.g., a part of a production plant or the plant itself.

In the CC ontology, there are two objects that distinguish between composite and single devices, i.e., a single device is represented by PhysicalComponent and composite objects are represented by MechatronicComponent. To encode this connection between the ME and CC ontologies, one has to properly classify specific physical components in ME ontology. This is usually done by encoding a specific conditioning into the defined correspondence.

For instance, for the presented example one can perform filtering of the mechatronic components based on property value, i.e., saying that those physical components, which weight more than a specific threshold, are mechatronic components (see Fig. 6.8).

Another option could be to filter based on property occurence, i.e., saying that mechatronic components are those physical components that contain other devices. To check that one can use the existense of containsComponent property for a specific physical component in the ME ontology (see Fig. 6.9).

One more example of filtering could be checking whether a physical component also belongs to a specific type, e.g., saying that mechatronic components Similar types of correspondences and examples for them are reffered in [START_REF] Scharffe | Correspondence patterns representation[END_REF] as the "Class Correspondence by Path attribute Value", "Property Correspondence by Value", "Class by Attribute Occurence Correspondence" patterns. Similar patterns are also described by the "Class by attribute occurence", "Class by attribute type", "Class by attribute value" and "Class by path attribute value" ontology design paterns4 .

Schematic differences (M6)

Description. In this case, there are substantial differences in the way the same semantics is represented in the two ontologies. Example 1. Each employee in the PM ontology is represented by a string value of the hasParticipants property, while in the CC ontology the concept Person serves the same purpose. The correspondence captures this relation between a property value and a class instance (see Fig. Example 2. A connection between physical devices in the ME ontology is represented by the Connection concept with the sourceComponent and targetComponent properties, while in the CC ontology the same semantics is expressed with the connectedWith property of the PhysicalComponent concept (see Fig. 6.12). The correspondences with similar semantics and corresponding examples can be found in [START_REF] Scharffe | Correspondence patterns representation[END_REF] denoted as the "Class Relation Correspondence", "Property-Relation Correspondence" and "Class Instance Correspondence" and also within the ontology design patterns ("Class correspondence defined by relation domain").

Grouping and aggregation (M7)

Description. In some cases it is important to use grouping or/and aggregation of entities in one or several ontologies in order to set the relation to another ontology. This type of correspondence is also presented in [START_REF] Scharffe | Correspondence patterns representation[END_REF] as the "Aggregation" pattern. Example. In order to calculate a value of the property hasWeight for a specific MechatronicComponent in the CC ontology, values of the hasWeight property of all devices from the ME ontology, which are contained in this component, should be summed up (see Fig. 6.13).

Mapping Directionality

When speaking about mappings, an important characteristic is that they can be directional [START_REF] Ghidini | On relating heterogeneous elements from different ontologies[END_REF], i.e., can be specified in a direction from source to target and the data flow cannot occur in the opposite direction. However, for some applications, such as for a data transformation, it could be beneficial to define bidirectional mappings between the engineering objects. It would help to reduce the total amount of mappings, thus facilitating their maintenance. However, in some cases, it may be impossible to specify a bidirectional mapping -e.g., in the example for mapping type M3 it will not be possible to specify the specific values for start and end dates based only on the duration of a specific project.

Example. Examples for M1 and M2 (if specified in a specific mapping language) can also serve as examples of bidirectional mappings.

Languages and technologies for mapping definition and representation

This section provides a description of languages and technologies that can be applied ontology mapping. Even though many initiatives exist to map heterogeneous sources of data to RDF such as XSPARQL Akhtar et al (2008) to transform XML into RDF and RML [START_REF] Dimou | RML: a generic language for integrated rdf mappings of heterogeneous data[END_REF] to map CSV, spread sheets and XML to RDF, we will only examine those languages that allow expressing mappings between different ontologies. Although the languages described below are of very different nature for the sake of uniformity hereafter we will call them "mapping languages". For this chapter, we focus on those languages which are already well known and/or widely used. This means that these languages already have implementations and tool support and, therefore, would be the most probable and convenient choice for practitioners.

All mapping languages can be divided into the two categories: declarative and procedural languges. A language is declarative, if it expresses something independently from the way it is processed. Therefore, one should use external tools to process the defined correspondences for an application at hand. A pro-cedural language, on the other hand, expresses how mappings are processed (for a specific or various applications).

Another important characteristic of a mapping language is whether it is suited to express correspondences at schema (classes and properties) or data (ontology instances) level. Below we provide a brief description of existing mapping languages. Table 6.1 position them them with respect to these categories. The Web Ontology Language (OWL) is an ontology language where one can declare relations between concepts such as equivalence, subsumption, etc. and allows one to infer additional information about instances by reasoning over the properties of classes and relations. Although one can define one-to-one correspondence between the ontology entities using owl:equivalentClass, owl:equivalentProperty and owl:sameAs for classes, properties and individuals correspondingly, OWL itself has no means to define more complex correspondences as those described in Section 6.4. Also, as OWL is a knowledge representation language, it by itself possesses no means for data transformation between ontologies. One will need to use additional tools for that, such as OWL reasoners to infer additional triples5 from an OWL file. Thus, reasoners could be used in combination with SPARQL CONSTRUCT queries to create a "reasoner-enabled" mapping.

The Semantic Web Rule Language, (SWRL) 6 is a W3C submission for a Semantic Web rule language, combining OWL DL -a decidable fragment of OWL -with the Rule Markup Language 7 . Rules are thus expressed in terms of OWL concepts. Rules are of the form of an implication between an antecedent (body) and consequent (head). The intended meaning is: whenever the conditions specified in the antecedent hold, then the conditions specified in the consequent must also hold. Note that SWRL rules are not intended for defining mappings, but to infer additional information from an ontological system, i.e., if the intended application is instance translating, they should be used in combination with SPARQL CONSTRUCT queries for instance to create a target RDF graph out of a source graph.

One way to define mappings is to use a SPARQL CONSTRUCT 8 query, which returns an RDF graph created with a template for generating RDF triples based on the results of matching the graph pattern of the query. To use this construct, one needs to specify how patterns in one RDF graph are translated into another graph. The outcome of a CONSTRUCT query depends on the reasoner and rule engine used. A SPARQL endpoint not backed by an OWL reasoner will only do simple graph matching for returning triples. A software agent that needs to compute these inferences will therefore have to consume all the necessary triples and perform this computation itself. The same holds for inferring additional information via business rules. SPARQL CONSTRUCT, however, is not a rule language and "merely" allows one to make a transformation from one graph match to another graph, i.e., a one-step transformation.

Another option to define mappings is using rules that can be declared on top of OWL ontologies. Apache Jena 9 includes a rule-based inference engine called Jena Rules 10 for reasoning with RDF and OWL data sources based on a Datalog implementation. Datalog is a declarative logic programming language that is popular for data integration tasks [START_REF] Huang | Datalog and emerging applications: an interactive tutorial[END_REF].

SPARQL Inference Notation (SPIN) 11 is currently submitted to W3C and provides -amongst others -means to link class definitions with SPARQL queries (ASK and CONSTRUCT) to infer triples. An implementation of SPIN is available from TopBraid 12 . It is built on top of the Apache Jena framework, and therefore inherits its properties.

Silk Volz et al ( 2009) is a link discovery framework for RDF datasets available as a file or via SPARQL endpoints. It allows one to declare how different RDF datasets relate to each other by specifying so-called linkage rules. These linkage rules are used to identify which resources are related to generate, for instance, owl:sameAs predicates. One is also able to define correspondences using other predicates, which depend on the use case. These linkage rules can make use of aggregates, string metrics, etc. SILK allows describing how resources in two existing datasets relate to each other, but does not possess means to process them for a certain application, e.g., to perform the transformation.

Two systems for expressing relations between entities worth mentioning are SKOS Miles et al (2005) and the Alignment format [START_REF] David | The Alignment API 4.0[END_REF]. How-ever, they can only express correspondences between pairs of named entities of two ontologies, so they are not suited to address the requirements in Section 6.4.

Another language to define mappings was developed by the SEKT project. This language is designed to be independent from any ontology language, thus, it can be used for ontologies written in different languages. Several syntaxes are available -verbose human readable syntax and RDF and XML syntaxes. A Java API is also available allowing parsing and serializing to and from the object model of the mapping document. This mapping language is quite expressiveit allows specifying mappings between classes, properties and instances of an ontology (also across) using a set of operators, which have a cardinality, an effect and some related semantics. One can also specify conditions, annotations, direction info (bidirectional or unidirectional mapping) and extend the defined constructs with arbitrary logical expressions [START_REF] Scharffe | Ontology mediation patterns library v2[END_REF].

The EDOAL13 (Expressive and Declarative Ontology Alignment Language) David et al ( 2011) is a language for expressing alignments which is supported by the Alignment API. The Alignment API allows to generate and parse alignments, to manipulate them and to render these alignments in different languages, eventually executable. EDOAL can express correspondences between more precise and complex terms than the named entities. EDOAL also supports expressing transformations on property values, which is of particular interest in our context. Table 6.2 summarises the level of support of the mapping languages listed above for defining and representing complex relations between the ontologies described in Section 6.4. The evaluation was done based on a) checking the specification documents each language; b) authors' practical experiences with implementing ontology-based integration solutions; and c) knowledge obtained during authors' involment in the language development (for some languages). Due to space limits we cannot provide a detailed analysis for each of the described mapping languages. From Table 6.2, it is clear that everything can be written directly with SWRL or SPARQL CONSTRUCT. Such languages have enough expressivity and can be considered, at least for SPARQL, to have efficient implementations. However, they lack declarativity. For instance, they define oriented rules and changing the orientation requires rewriting the rules. A language like EDOAL allows to express declaratively the relations between two ontologies and can generate SPARQL CONSTRUCT (or eventually SWRL in simple cases) to implement the transformations in one way or the other. Therefore, we decided to focus on EDOAL. We continue with detailed analysis of the EDOAL's capabilities for representing complex correspondences and the examples of those identified in the use case scenario (see Section 6.3).

Representing complex relations with EDOAL

Expressive and Declarative Ontology Alignment Language (EDOAL) is an extension of the Alignment format supported by the Alignment API [START_REF] David | The Alignment API 4.0[END_REF]. It offers the capability to express correspondences that go beyound putting in relation named entities. In EDOAL correspondences may be defined between compound descriptions, which allow to further constrain those entities that are put in correspondences. Compound descriptions may be combination of concepts, e.g., a Physical component that is also a Composite device, or restriction of concepts, e.g., a Physical component whose weight is over 125 pounds. Compound descriptions are defined through a description language similar to that of description logics. This is possible through:

Construction that constrains the object put in correspondence with classical Boolean operators (disjunction, conjunction, complement) or property construction operators (inverse, composition, reflexive, transitive and symmetric closures); Restriction that restrains the values of objects put in correspondence (through domain, range, cardinality and value restrictions). This is typically achieved by requesting all or some values of a property to be in some domain (weight is above 1025) or class (some member being a senior manager).

These constraints can be composed together to obtain more elaborate correspondences. For instance, the meaning of some of the correspondences in Section 6.4 can be simply expressed as EDOAL correspondences.

The snippet below combines M5a and M5c examples in one correspondence (M5b can be treated in the exact same way). The first part (within the "and") is a class construction, while the AttributeValueRestriction part is a class restriction:

<align:Cell rdf:about="#M5"> <align:entity1> <Class> <and rdf:parseType="Collection"> <Class rdf:about="&me;PhysicalComponent" /> <Class rdf:about="&me;CompositeDevice" /> <AttributeValueRestriction> <onAttribute><Relation rdf:about="&me;hasWeight" /></onAttribute> <comparator rdf:resource="&edoal;greater-than" /> <value><Literal edoal:type="&xsd;decimal" edoal:string="1025.00"/></value> </AttributeValueRestriction> </and> </Class> </align:entity1> <align:entity2> <Class rdf:about="&cc;MechatronicComponent" /> </align:entity2> <align:relation>=</align:relation> <align:measure rdf:datatype="&xsd;float">1.0</align:measure> </align:Cell>

The Alignment API offers EDOAL alignment manipulation and rendering. So, the correspondence above can be automatically transformed into the following SPARQL CONSTRUCT query, which can be used for transforming data: The same can be achieved with the M6b correspondence example that connects an object and a relation between objects: <align:Cell rdf:about="#M6b"> <align:entity1> <Relation> <compose rdf:parseType="Collection"> <Relation> <inverse><Relation rdf:about="&me;sourceComponent" /></inverse> </Relation> <Relation> <and rdf:parseType="Collection"> <Relation rdf:about="&me;targetComponent" /> <RelationDomainRestriction> <class><Class rdf:about="&me;Connection" /></class> </RelationDomainRestriction> </and> </Relation> </compose> </Relation> </align:entity1> <align:entity2><Relation rdf:about="&cc;connectedWith" /></align:entity2> <align:relation>=</align:relation> <align:measure rdf:datatype="&xsd;float">1.0</align:measure> </align:Cell>

In addition to expressing the usual correspondences between two entities, EDOAL correspondences are extended to support two types of information:

Transformations that specify how to transform an instance of the related entities into the other; Link keys that define under which conditions two individuals must be considered the same Atencia et al (2014).

For this chapter we are mostly concerned with transformations. As it can be seen in the snippet above, the same EDOAL correspondence can support several transformations as, for two objects in the correspondence, there may be several properties to be transformed.

The example for M7 can be expressed in a similar way (alternatively, the transformation here could have been added to the previous M5 example): <align:Cell rdf:about="#M1extended"> <align:entity1><Class rdf:about="&me;PhysicalComponent" /></align:entity1> <align:entity2><Class rdf:about="&cc;MechatronicComponent" /></align:entity2> <align:relation>=</align:relation> <align:measure rdf:datatype="&xsd;float">1.0</align:measure> <transformation> <Transformation edoal:direction="-o"> <entity1> <Aggregate edoal:operator="&fn;sum"> <arguments rdf:parseType="Collection"> <Property> <compose rdf:parseType="Collection"> <Relation rdf:about="&me;component" /> <Property rdf:about="&me;hasWeight" /> </compose> </Property> </arguments> </Aggregate> </entity1> <entity2><Property rdf:about="&cc;hasWeight" /></entity2> </Transformation> </transformation> </align:Cell> With regard to directionality, EDOAL correspondences are in general not oriented: they express a relation between two terms and not a function from one term to another. However, when generating a mapping from a correspondence, this may direct the use of the correspondence, e.g., the SPARQL query above. Moreover, transformations may be oriented. This is specified by the direction attribute: indeed, it is possible to compute a duration from the dates or a total weight of the compound component from its component part weights but not the other way around.

Although EDOAL can express such transformations, it cannot process them. These transformations are rendered in other languages that can be processed, such as SPARQL. Transformations often rely on external functions, most of the time identified by XPath URIs. Hence, a renderer using them should be able to interpret such operations as SPIN functions or SPARQL built-in functions, for instance.

One type of correspondences that is difficult to represent in EDOAL, are those, like M6a, which introduce some new resources that have no counterpart in the initial data set. In M6a, the Person in the CC ontology does correspond to John/Smith/078-05-1120, which is a simple string. Sometimes this can be easily expressed, like for M6b, because the connectedWith relation relates two existing resources. But in general, this requires more information.

Conclusion

In this chapter, we described what types of complex relations between engineering objects may need to be captured, while implementing ontology-based integration solutions. We presented a catalogue of complex correspondences between the ontologies and illustrated each correspondence type with an example from the real-life power-plant engineering project. We also provided an overview on available mapping languages and technologies that can be used to define, represent and sometimes also process the correspondences between the different ontologies and briefly explained their key characteristics and capabilities w.r.t. the complex relations capturing. As space limitations do not allow us to perform the detailed analysis of each mapping language, we decided to focus on EDOAL, because of its interesting quality to combine the features of both declarative and procedural languages (contrary to other mapping languages). We therefore explained in detail what are the EDOAL's capabilities for representing complex relations and gave the examples of how the correspondences identified for the power-plant engineering project can be implemented with EDOAL.

As future work we would like to explore what languages and techniques are currently applied by engineers to link different models and data structures (especially across the engineering disciplines and tools) during the engineering process and to compare their representational capabilities with those provided by the Semantic Web community. Another interesting direction for the future work will be analysing languages to define relations and constraints on different data models and data sets developed within the Model-Driven engineering field and compare their application aspects with the languages discussed in this chapter.

  Fig. 6.1. Ontology matching for data transformation. Ontology matching generates an alignment A between ontology o and o . This alignment can be interpreted as a set of mappings M , which can be used for transforming data expressed in ontology o into ontology o .

Fig. 6 . 3 .

 63 Fig. 6.3. Ontology-based integration in the power plant engineering project.

Fig. 6

 6 Fig. 6.4. M1: String processing correspondence example.

  Fig. 6.5. M2: Transforming a string into xsd:date.

  Fig. 6.6. M3: Computing the duration of a project.

  Fig. 6.7. M4: Computing the amortization of a component based on its properties.

  Fig. 6.8. M5a: Defining mechatronic components by property value.

  Fig. 6.11. M6a: Correspondence between the property value in ME ontology and instance in CC ontology.

  Fig.6.12. M6b: Correspondence between class in ME ontology and property in CC ontology.

  Fig. 6.13. M7: Aggregation of property values to get the weight of a mechatronic device.

Table 6 .

 6 1. Mapping languages and their characteristics: = compliant; = non compliant.

	Declarative Procedural Schema Data
	OWL
	SWRL
	SPARQL CONSTRUCT
	Jena rules
	SPIN
	SILK
	SKOS
	SEKT
	Alignment Format
	EDOAL

Table 6

 6

	.2. Support for the complex relations definition and repesentation in various
	mapping languages: -supported; -partially supported; -no support; * -vendor
	dependent.
		M1 M2 M3 M4 M5a M5b M5c M6a M6b M7
	SWRL
	SPARQL CONSTRUCT
	Jena rules	*
	SPIN	*
	SILK
	SKOS
	SEKT
	Alignment Format
	EDOAL

6]

https://www.w3.org/TR/sparql11-query/

http://www.w3.org/Submission/spin-overview/

http://ontologydesignpatterns.org/wiki/Category:AlignmentOP

Mentioned design patterns can be found under http://ontologydesignpatterns. org/wiki/Submissions:#pattern_name

RDF triple:https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ #section-triples

http://www.w3.org/Submission/SWRL/

http://wiki.ruleml.org/index.php/RuleML_Home

http://alignapi.gforge.inria.fr/edoal.html

Acknowledgements

Olga Kovalenko has been supported for this work by the Christian Doppler Forschungsgesellschaft and by the Erasmus Mundus Action 2 Programme of the European Union.