%\title{A Model-Driven Web Feature Service for Enhanced Semantic Interoperability \\}
\title{Un Service Web orient\'e mod\`ele pour une interop\'erabilit\'e s\'emantique am\'elior\'ee \\}
\author{Peter Staub, traduit par Benoit V\'eler}

\maketitle

\section{Introduction}
\label{sec:introduction}

%This article addresses current research issues in the field of interoperability of heterogeneous GIS. We focus on heterogeneity at the level of conceptual data models.
%The presented research project of a model-driven Web Feature Service aims at enhancing semantic interoperability. The approaches of data interoperability such as OGC web services (OWS) are combined with methods of model interoperability. The model-driven approach of conceptual data modelling allows for keeping data models independent from any particular system.

Cet article traite de la recherche actuelle dans la domaine de l'interop\'erabilit\'e des SIG. Nous portons notre int\'er\^et sur l'h\'et\'erog\'en\'eit\'e au niveau des mod\`eles conceptuels de donn\'ees. 
Le projet de Service web orient\'e mod\`ele pr\'esent\'e ici, vise \`a am\'eliorer l'interop\'erabilit\'e s\'emantique. Les approches de l'interop\'erabilit\'e des donn\'ees telles que les services web OGC (OWS) sont combin\'ees avec des m\'ethodes d'interop\'erabilit\'e. Une approche orient\'ee mod\`ele des mod\`eles de conception de donn\'ees, permet d'\'eloigner les traitements de donn\'ees de tout syst\`eme sp\'ecifique. 

%Interoperability is a crucial capability to deal with in the context of geospatial applications and information communities. The use of web services is well-established and useable in a standardised way due to the efforts of the OGC. However, OWS such as the Web Feature Service (WFS) \cite{wfs:2005} provide data interoperability, but no model interoperability. Conceptual model mappings are a precondition for semantic interoperability but are not supported by OWS.

L'interop\'erabilit\'e est une question cruciale \`a traiter, dans le contexte d'applications g\'eospatiales et de communaut\'es d'informations. L'usage de services web est bien \'etabli, et utilisable de mani\`ere standardis\'ee gr\^ace aux efforts de l'OGC. Cependant, des OWS (?) tels que le Web Feature Service (WFS) \cite{wfs:2005} fournissent de l'interop\'erabilit\'e au niveau des donn\'ees, mais pas au niveau du mod\`ele. La repr\'esentation des mod\`eles conceptuels sont une pr\'econdition pour une interop\'erabilit\'e s\'emantique, mais ne sont pas reconnues par OWS.

%Among European initiatives for geodata infrastructures -- such as INSPIRE\footnote{INSPIRE project website: \tt{\url{http://www.ec-gis.org/inspire/index.cfm}}} -- the need for interoperability not only on the data level, but also on the model level, grows. The research project described in this article was initiated in the context of a project in the Lake Constance region\footnote{Bodensee-Geodatenpool (Lake Constance geodata pool) project website: \tt{\url{http://www.bodensee-geodatenpool.net}}}. The mentioned project aims at creating a cross-border web-based GIS for applications.\\

Parmi les initiatives europ\'eennes sur l'infrastructure des donn\'ees g\'eographiques -- telles que INSPIRE\footnote{ site web du projet INSPIRE:\tt{\url{http://www.ec-gis.org/inspire/index.cfm}}} -- le besoin d'interop\'erabilit\'e augmente, non seulment au niveau des donn\'ees, mais aussi des mod\`eles de donn\'ees. Le projet de recherche d\'ecrit dans cet article a \'et\'e initi\'e dans le contexte d'un projet dans la r\'egion du lac de Constance\footnote{site web du Bodensee-Geodatenpool (Groupe de donn\'ees spatiales du Lac de Constance):\tt{\url{http://www.bodensee-geodatenpool.net}}}. Le projet mentionn\'e vise \`a cr\'eer un Web-SIG transfrontalier pour des applications. 

%In the presented research project, we introduce a {\bf model-driven WFS} ({\bf mdWFS}) which combines both the advantages of OWS for data interoperability and those of the model-driven approach for conceptual data modelling. Furthermore, formalism for establishing conceptual model mappings is developed and a prototype is implemented. Because of this combination, the mdWFS we introduce is an approach that provides enhanced semantic interoperability.

Dans ce projet de recherche, nous introduisons un {\bf WFS orient\'e mod\`ele} ({\bf mdWFS}) qui combine \`a la fois les avantages de l'interop\'erabilit\'e de donn\'ees de l'OWS, et ceux de l'approche mod\`ele utilis\'ee dans les mod\`eles conceptuels de donn\'ees. De plus, le formalisme pour \'etablir la repr\'esentation des md\`eles conceptuels est d\'evelopp\'e, et un prototype est mis en place. Gr\^ace \`a cette combinaison, le mdWFS que nous introduisons est une approche qui fournit une interop\'erabilit\'e s\'emantique \'etendue. 

%\section{Fundamentals of Data Modelling and Semantic Interoperability}
\section{Fondements de mod\'eles de donn\'ees et d'interop\'erabilit\'e s\'emantique}
\label{sec:dataModelling}

%\subsection{The Model-Driven Approach}
\subsection{L'approche orient\'ee mod\`ele}
\label{subsec:MDApproach}

%The main idea of the model-driven approach is to describe (geo-)data models using a conceptual schema language (CSL). The use of a CSL for modelling allows for keeping data structures independent from any particular system or transfer format such as XML or GML. Virtually any transfer format can be derived from the conceptual schema (syn.\ model) automatically -- given an adequate model compiler.

L'id\'ee principale de l'approche orient\'ee mod\`ele est de d\'ecrire des mod\`eles de donn\'ees spatiales en utilisant un sch\'ema de langage conceptuel (CSL). L'usage d'un CSL pour mod\'eliser permet de conserver les structures de donn\'ees ind\'ependantes de tout syst\`eme sp\'ecifique, ou de tout format de tranfert, tel que XML ou GML. Potentiellement tous les formats de transferts peuvent \^etre d\'eriv\'es automatiquement du sch\'ema conceptuel -- \`a condition d'utiliser le compilateur appropri\'e. 

%If you want to reach semantic interoperability, you will have to create conceptual model mappings. A conceptual model mapping is converted into mapping functions ${\mathcal{F}}_M $ from a source schema $A$ to any target schema $B$:

%$$ A \xrightarrow{{\mathcal{F}}_M} B $$

Si l'on souhaite obtenir une interop\'erabilit\'e s\'emantique, il faudra cr\'eer une r\'epr\'esentation des mod\`eles conceptuels. La repr\'esentation d'un mod\`ele conceptuel est convertie en fonctions de repr\'esentation ${\mathcal{F}}_M $ d'un sch\'ema source $A$ vers un sch\'ema cible $B$:

$$ A \xrightarrow{{\mathcal{F}}_M} B $$

%The model-driven approach consists of four steps (see figure \ref{fig:mdasemtrans}):

\begin{figure*}[htbp]
   \centering
   \includegraphics[width=0.85\textwidth]{./proceedings/staub/MDA_SemTrans}
   \caption{Model-driven approach and semantic interoperability}
   \label{fig:mdasemtrans}
\end{figure*}

\begin{enumerate}
%\item Specification of an {\em application domain} (i.~e.\ ``what we are talking about'')
%\item Specification of a {\em CSL} with a coherent UML metamodel
\item Description of the application domain with the chosen CSL $\rightarrow$ {\em conceptual schema}, platform independent model (PIM)
\item Derivation of any format schema (e.~g.\ a GML Application Schema) $\rightarrow$ {\em logical and physical schema}, platform specific model (PSM)
\end{enumerate}

%As mentioned above, we assume that the generation of the logical schema is {\em automatically} carried out by a compiler and the encoding is done by an adequate encoding program.

L'approche ori\'ent\'ee mod\`ele constiste en quatre \'etapes (voir figure \ref{fig:mdasemtrans}):

\begin{figure*}[htbp]
   \centering
   \includegraphics[width=0.85\textwidth]{./proceedings/staub/MDA_SemTrans}
   \caption{Approche orient\'ee mod\`ele et interop\'erabilit\'e s\'emantique}
   \label{fig:mdasemtrans}
\end{figure*}

\begin{enumerate}
\item Specification d'un {\em domaine d'application} (par ex.\ ``de quoi sommes-nous en train de parler'')
\item Specification d'un{\em CSL} avec un m\'etamod\`ele UML coh\'erent
\item Description d'un domaine d'application avec le CSL choisi $\rightarrow$ {\em schema conceptuel}, mod\`ele ind\'ependant d'une plateforme (platform independent model - PIM)
\item Derivation de sch\'emas de tous formats (par ex.\ un Schema d'Application GML) $\rightarrow$ {\em sch\'ema physique et logique}, mod\`ele sp\'ecfique de plateforme (platform specific model - PSM)
\end{enumerate}

%In the presented research project, the (textual) CSL {\em Interlis} is applied for data modelling. Interlis is a Swiss standard \cite{ili:2006} and is widely applied in cadastral and planning applications. Interlis is based on a UML 2 profile and a compiler\footnote{Interlis compiler: see {\tt \url{http://www.interlis.ch}}. The compiler is free and open source.} generates XML schemas (Interlis format) or GML Application Schemas from any given Interlis data model.

Dans le projet de recherche pr\'esent\'e, le CSL (textuel) {\em Interlis}  est appliqu\'e \`a la mod\'elisation des donn\'ees. Interlis est un standard suisse \cite{ili:2006} largement appliqu\'e dans les applications cadastrales et d'am\'enagement. Interlis est bas\'e sur un profil UML 2, et un compilateur\footnote{compilateur Interlis: voir {\tt \url{http://www.interlis.ch}}. Le compilateur est gratuit et opensource.} produit des sch\'emas XML (format Interlis), ou des Sch\'emas d'Application GML pour tout mod\`ele de donn\'ees Interlis.

%According to the Model-Driven Architecture (MDA) specified by the Object Management Group (OMG) \cite{omg:2003}, the generation of a format schema from a conceptual schema is referred to as a PIM--PSM mapping. In terms of mapping directions, the PIM--PSM is also called a ``vertical'' mapping, whereas model mappings for semantic interoperability are ``horizontal'' (i.~e.\ PIM--PIM) mappings (see next section).

A partir d'un Mod\`ele d'Architecture de donn\'ees, sp\'ecifi\'e par le Groupe de Gestion des Objets (Object Management Group - OMG), la production  d'un sh\'ema de format pour un sch\'ema conceptuele est d\'enomm\'ee cartographie PIM--PSM. En termes de direction de cartographie, le PIM--PSM est \'egalement app\'el\'e une cartographlie ''verticale'', alors que les repr\'esentations de mod\`eles pour l'interop\'erabilit\'e s\'emantique est ''horizontale'' (par ex.\ PIM--PIM) cartes (voir prochaine section)

%\subsection{Semantic Interoperability}
\subsection{Interop\'erabilit\'e S\'emantique}
\label{subsec:semInterop}

%Technically, there are two main aspects characterising ``interoperability'': 1) {\em Data interoperability} $=$ the ability of a system or process to exchange datasets using certain data transfer formats. 2) {\em Model interoperability} $=$ the ability to establish conceptual model mappings in order to execute semantic data transformations.

%To achieve semantic interoperability, different data models have to be mapped. A translator then interprets the mapping rules from the conceptual model mapping and executes the instance translation automatically.

Techniquement, il y a deux \'el\'ements principaux caract\'erisant l'interop\'erabilit\'e: 1) {\em Interoperabilit\'e des donn\'ees} $=$ la capacit\'e d'un syst\`eme ou d'un proc\'ed\'e d'\'echanger des bases de donn\'ees en utilisant des formats de transferts d\'efinis. 2) {\em Interoperabilit\'e des Mod\`eles} $=$ la capacit\'e d'\'etablir des mod\`eles conceptuels de cartes dans le but d'ex\'ecuter des transformations s\'emantiques des donn\'ees.

Pour atteindre une interop\'erabilit\'e s\'emantique, diff\'erents mod\`eles de donn\'ees doivent \^etre repr\'esentes. Un traducteur interpr\`ete alors les r\`egles de repr\'esentation \`a partir de la carte du mod\`ele conceptuel et ex\'ecute automatiquement la s\'equence de traductions. 

%Semantic transformation approaches can be classified as follows \cite{donau:2007}:
%\begin{itemize}
%\item {\em Level of abstraction:} Semantic transformation can be performed on different levels of abstraction (on the conceptual level, on the logical level and on the physical (i.~e.\ transfer format) level). A semantic transformation on the conceptual level is platform independent, whereas approaches on the logical or physical level are platform specific.
%\item {\em Orientation:} Horizontal semantic transformation between different schemas on the same level of abstraction (PIM--PIM; PSM--PSM) vs.\ vertical semantic transformation between different levels of abstraction (PIM--PSM).
%\item {\em Level of automation:} Creating mapping rules by hand vs.\ automated schema matching which is only partially practicable.
%\end{itemize}

Les approches de transformation s\'emantique peuvent \^etre classifi\'ees comme suit \cite{donau:2007}:
\begin{itemize}
\item {\em Niveau d'abstraction:} Les transformations s\'emantiques peuvent \^etre r\'ealis\'ees \`a diff\'erents niveaux d'abstractions, (niveau conceptuel, niveau logique, et niveau physique (par ex.\ le format de transfert). Une transformation s\'emantique au niveau conceptuel est ind\'ependante de la plateforme, alors que les approches aux niveaux logiques et physiques sont sp\'ecifiques \`a la plateforme. 
\item {\em Orientation:} Transformation s\'emantique horizontale entre diff\'erents sch\'emas au m\^eme niveau d'abstraction (PIM--PIM; PSM--PSM) contre.\ Transformation s\'emantique verticale entre diff\'erent niveaux d'abstraction (PIM--PSM).
\item {\em Niveau d'automatisation:} Cr\'eer des r\`egles de repr\'esentation \`a la main contre.\ cr\'eer un sch\'ema automatique de correspondance, qui est partiellement utilisable. 
\end{itemize}

\subsection{R\'esum\'es des approches existantes}
\label{subsec:Shortcomings}

%One possibility is to integrate all data into one central system. This is very costly and requires expert knowledge. In order to integrate the data into the central system, 1:1-format conversions have to be carried out. This is often lossy because a data format which is different from the original one is in general not able to express the entire semantics of the original data format. Besides that, the inevitable redundant data storage possibly causes outdated data.

Une possibilit\'e est d'int\'egrer toutes les donn\'ees dans un syst\`eme centralis\'e. C'est tr\`es couteux, et exige un niveau de connaissance expert. Pour int\'egrer les donn\'ees dans le syst\`eme central, 1:1-des conversions de formats doivent \^etre men\'ees \`a bien. C'est souvent au prix de pertes, dans la mesure o\`u un format de donn\'ees qui est diff\'erent de celui d'origine, est en g\'en\'eral incapable de reproduire toute la s\'emantique contenue dans la format de d\'epart. De plus, l'in\'evitable redondance du stockage de donn\'ees peut aboutir \`a la cr\'eation de donn\'ees p\'erim\'ees. 

%Existing OWS such as the WFS have some shortcomings with regard to semantic interoperability: OWS allow for syntactic interoperability (i.~e.\ data interoperability) but not for semantic interoperability (i.~e.\ model interoperability). Conceptual models of source systems are hidden from target systems and semantic transformations are not supported. So, the WFS lacks in the ability to handle conceptual model information aside from data information.

Des OWS existants, tels que WFS, ont des raccourcis concernant les \'echanges s\'emantiques. OWS permet l'interop\'erabilit\'e syntaxique (par ex.\ pour les donn\'ees), mais pas s\'emantique (par ex.\ correspondance des mod\`eles). Les mod\`eles conceptuels des sources, sont cach\'es des syst\`emes cibles, et les transformations s\'emantiques ne sont pas support\'ees. Par cons\'equent, le WFS manque de capacit\'es \`a manipuler des informations sur les mod\`eles conceptuels en plus d'informations sur les donn\'ees.  

%\section{Concept of the Model-Driven WFS}
\label{sec:mdWFSconcept}

\section{Concept de WFS orient\'e mod\`ele}
\label{sec:mdWFSconcept}

%\subsection{Preconditions for a Web-Based Semantic Transformation}
\label{subsec:precond}

\subsection{Preconditions pour une transformation s\'emantique en ligne}
\label{subsec:precond}

%If we want to have a web service that allows for data interoperability {\em and} that is able to store and deliver conceptual schemas, a number of preconditions must be fulfilled. It must be assured that conceptual schemas are described (i.~e.\ modelled) using a textual CSL with its graphic representation in UML 2 (and the respective exchange format XMI). Furthermore, a formal language is needed for expressing schema mapping rules on the conceptual level of abstraction. Finally, we use a standard WFS interface to provide satisfying data interoperability.

Si l'on souhaite avoir un service web qui permette l'interop\'erabilit\'e de donn\'ees {\em et} qui soit capable de stocker et fournir des sch\'emas conceptuels, un certain nombre de pr\'e-conditions doit \^etre respect\'e. Il doit \^etre valid\'e que les sch\'emas conceptuels soient d\'ecrits (c.~\`a.d.\ mod\'elis\'es) en utilisant un CSL en format texte, avec une repr\'esentation graphique en UML 2 (et le format d'\'echange correspondant XMI). De plus, un langage en amont est encore n\'ecessaire pour repr\'esenter le sch\'ema de r\`egles de cartographie, au niveau d'abstraction n\'ecessaire. Finalement, nous utilisons une interface WFS standard pour fournir une int\'erop\'erabilit\'e des donn\'ees satisfaisante. 

\subsection{Besoins de l'application Web}
\label{subsec:webserviceReq}

%Web-enabling semantic transformations means in our case actually designing a web service. This service has to comply with two main requirements:
%\begin{enumerate}
%\item Provide access to geospatial data based on the data's original conceptual schema (source model) and on any user-defined conceptual schema acting as the target model.
%\item Interoperability with existing OWS.
%\end{enumerate}

R\'ealiser des transformations s\'emantiques sur le web signifie dans notre cas imaginer une application web. Cette application doit v\'erifier deux besoins particuliers :
\begin{enumerate}
\item Permettre l'acc\`es \`a des donn\'ees spatiales, depuis le sch\'ema conceptuel des donn\'ees d'origine, vers tout sch\'ema d\'efini pour le mod\`ele cible. 
\item Interop\'erabilit\'e avec l'OWS existant.
\end{enumerate}

\subsection{L'interface mdWFS}
\label{subsec:mdwfsInterface}

% We designed a service called ``model-driven Web Feature Service'' (mdWFS) taking these requirements into account. The mdWFS has the task to store and deliver conceptual schemas and to carry out semantic transformations (PIM--PIM mappings) by means of interpreting transformation models. After a semantic transformation, the mdWFS configures a standard WFS to provide a service for data interoperability. The standard WFS is configured according the target model but delivers transformed feature data from the source model.

Nous avons imagin\'e un service d\'enomm\'e ``model-driven Web Feature Service'' (mdWFS), prenant en compte ces besoins. Le mdWFS a en charge le stockage et le rendu les sch\'emas conceptuels, la conduite des transformations s\'emantiques (cartographies PIM--PIM) en interpr\'etant les mod\`eles de transformation. Apr\`es une transformation s\'emantique, le mdWFS configue un WFS standard, pour proposer un service pour les \'echanges de donn\'ees. Le WFS standard est configur\'e d'apr\`es le mod\`ele cible, mais d\'elivre des donn\'ees modifi\'ees du mod\`ele source. 

\subsection{Extensions du protocole WFS}
\label{subsec:wfsExtd}

% In order to create a WFS that is able to store and deliver conceptual schemas, the OGC WFS specification needs to be extended. In the mdWFS specification, the extensions described below are applied \cite{donau:2007}:
\begin{itemize}
\item To provide a service protocol for the mdWFS, a new request parameter {\tt SERVICE=mdWFS} is implemented.
\item The {\tt GetCapabilities} request is extended to provide a {\tt SchemaList}. This list includes each conceptual schema that is available in the service.
\item The {\tt DescribeFeatureType} request is extended to provide the {\tt XMI} format for transferring model information.
\item Finally, a whole new request {\tt DoTransform} is introduced. This request transfers the conceptual mapping schema to the mdWFS and invokes the semantic transformation.
\end{itemize}

Dans le but de cr\'eer un WFS capable de stocker et de proposer des sch\'emas conceptuels, les sp\'ecifications de l'OGC doivent \^etre \'etendues. Dans les specifications mdWFS, les extensions appliqu\'ees sont les suivantes \cite{donau:2007}:

\begin{itemize}
\item Pour fournir un protocole, un nouveau param\`etre de requ\^ete est mis en place {\tt SERVICE=mdWFS}.
\item La requ\^ete {\tt GetCapabilities} est \'etendue pour obtenir un {\tt SchemaList}. Cette liste contient chaque sch\'ema pr\'esent dans le service. 
\item La requ\^ete {\tt DescribeFeatureType} est \'etendue pour fournir le format {\tt XMI} pour transf\'erer les informations sur les mod\`eles.
\item Finalement, une requ\^ete compl\`etement nouvelle est introduite {\tt DoTransform}. Celle-ci sert \`a transf\'erer les repr\'esentation des sch\'emas conceptuels vers le mdWFS et met en route la transformation s\'emantique.
\end{itemize}


% \section{UMLT, a Conceptual Schema Mapping Language}
\label{sec:UMLT}

\section{UMLT, un Langage de Repr\'esentation de Schemas Conceptuels de Cartographie}
\label{sec:UMLT}

% \subsection{Concept of UMLT}
\label{subsec:conceptUMLT}

\subsection{Concept d'UMLT}
\label{subsec:conceptUMLT}

% We introduce a conceptual mapping language that can be used to create conceptual mapping schemas (syn.\ transformation schemas) for semantic transformations. This formal language must comply with several requirements in order to be useable. Transformation schemas must be comprehensible also for non-computer scientists. Therefore, a UML 2 metamodel as well as syntax for a human useable textual notation (HUTN) is developed. Transformation schemas are represented in visual form (UML activity diagrams), in textual form (derived from Interlis CSL) and XML (i.~e.\ XMI), respectively. Common standards in the field of data modelling are taken into account\footnote{Such as standards from OMG, OGC and ISO}. We also apply an abstraction layer for (geo-)data types.

Nous introduisons un langage conceptuel de repr\'esentation, qui peut-\^etre utilis\'e pour cr\'eer des sch\'emas de transformation s\'emantique. Ce langage doit v\'erifier plusieurs crit\`eres pour \^etre utilis\'e. Les sch\'emas de transformation doivent \^etre compr\'ehensible en dehors de scientifiques de l'informatique. Par cons\'equent, un m\'etamod\`ele UML , ainsi qu'une syntaxe pour de notations textuelles utilisables par l'homme (HUTN) sont d\'evelopp\'es. Les sch\'emas de transformations sont repr\'esent\'es respectivement de mani\`ere visuelle (diagrammes d'activit\'e UML), textuelle, (d\'eriv\'e d'Interlis CSL) et en XML (par ex.\ XMI). Les standards habituels dans le domaine de la mod\'elisation de donn\'ees sont pris en compte\footnote{standard tels que ceux de l'OMG, de l'OGC et ISO}. Nous pla\c{c}ons \'egalement une couche d'abstraction pour les types des donn\'ees spatiales.
 
% Two existing approaches from the OMG were examined. First, the Meta Object Facility Query/Views/Transformations formalism (MOF-QVT) \cite{mofqvt:2005}: this formalism is designed for the transformation of metamodels, e.~g.\ UML$\rightarrow$Java. MOF-QVT models are hard to understand and their visual representation helps little. The standard is complex since it actually consists of three languages: Relations, Core and Operational. Furthermore, the MOF-QVT standard is predominantly applied for PIM--PSM implementation mappings.

Deux approches venant de l'OMG ont \'et\'e examin\'ees. Premi\`erement, le formalisme 'Meta Object Facility Query/Views/Transformations (MOF-QVT)' \cite{mofqvt:2005}: ce formalisme est con\c{c}u pour la transformation de m\'etamod\`eles,  par ex.\ UML$\rightarrow$Java. Les mod\`eles MOF-QVT sont difficiles \`a comprendre, et leur repr\'esentation visuelle aide peu. Le standard est complexe, dans la mesure, o\`u il contient finalement trois langages : relations, operations et racine. De plus, le standard MOF-QVT est surtout appliqu\'e pour les repr\'esentations en PIM--PSM.

% Another approach that was examined is UML 2 Activities. UML 2 activity diagrams can be used to describe transformations in terms of activity sequences. A clear description of the semantics and of the transfer format (XMI 2.1) is provided in the Superstructure for UML models. UML 2 models are comprehensible and a number of implementations and open source APIs are available.

Une autre approche examin\'ee est UML2 Activity. Un diagramme UML 2 activity peut \^etre utilis\'e pour d\'ecrire des transformations en termes de s\'equences d'activit\'es. Une description claire de la s\'emantique et des formats de transferts (XMI 2.1) est fournie dans la superstructure des mod\`eles UML. Les mod\`eles UML 2 sont compr\'ehensibles et un certain nombre d'installations et d'APIs open source sont disponibles. 

% Because of the above considerations, our conceptual mapping language is based on an independent extension of the UML 2 metamodel. To specify the language elements, a UML 2 model is created and the textual notation of the language is defined by a set of EBNF grammar rules. At project stage, we call our conceptual mapping language ``{\bf UMLT}''.

A cause des consid\'erations ci-dessous, notre langage conceptuel de cartographie est bas\'e sur une extension ind\'ependante du m\'etamod\`ele UML 2. Pour sp\'ecifier les \'el\'ements du langage, un mod\`ele UML 2 est cr\'e\'e et la notation textuelle du langage est d\'efinie par un ensemble de r\`egles grammaticales EBNF. A ce stade du projet, nous baptisons notre langage conceptuel de repr\'esentation ``{\bf UMLT}''.

\subsection{El\'ements du langage UMLT}


\label{subsec:languageUMLT}

\begin{figure*}[htbp]
   \centering
   \includegraphics[width=0.85\textwidth]{./proceedings/staub/UMLT_Language}
   \caption{El\'ements du langage UMLT}
   \label{fig:umltlang}
\end{figure*}

% The language elements of UMLT are an inheritance of UML 2 Activities \cite{omguml:2007}. We introduce the following language elements (see figure \ref{fig:umltlang}):
% \begin{itemize}
% \item {\tt StructuredTransformation}
% \item {\tt SelectionCriteria}: selection of input data through a logical expression.
% \item {\tt VirtualAssociation}: manage input objects that are not actually associated with an association object. These input objects may have link attributes or foreign key attributes that are evaluated at runtime in order to get calculated relations\footnote{A different example is a geometry/topology relation: a building {\em on} a parcel}. During a semantic transformation, such objects can be associated {\em in a virtual way} if needed. The {\tt VirtualAssociation} is introduced (in contrary to a common ``derived association'') to provide a means to explicitly specify the join property of the association with the {\tt joinCriteria} expression.
% \item {\tt TransformationAction}: inheritance from a UML {\tt OpaqueAction} providing an activity element which cannot be structured any further. This is a transformation's elementary action.
% \item {\tt AssignmentDefinition}s: address primitive types or expressions as value specification.
% \item {\tt MappingRule}: the actual object mapping. Built as a composition of assignment definitions.
% \item {\tt AssociationBinding}: selecting associated input objects, one may define how these associations are evaluated during input.
% \item {\tt JoinType}: an enumeration type to specify the join type of the association binding.
% \end{itemize}

Les \'el\'ements du langage UMLT sont un h\'eritage de UML 2 Activities \cite{omguml:2007}. Nous introduisons les \'el\'ements suivants (see figure \ref{fig:umltlang}):
\begin{itemize}
\item {\tt StructuredTransformation}
\item {\tt SelectionCriteria}: selection des donn\'ees renseign\'ees avec une expression logique.
\item {\tt VirtualAssociation}: gestion d'objets renseign\'es n'\'etant pas associ\'es avec des objets association. CEs objets import\'es peuvent avoir des attributs ou des cl\'es \'etrang\`eres qui sont \'evalu\'ees en temps r\'eel, de mani\`ere \`a obtenir des relations calcul\'ees \footnote{Un exemple different est une relation geometrie/topologie: un b\^atiment {\em sur} une parcelle}. Durant une transformation s\'emantique, de tels objets peuvent \^etre associ\'es {\em de mani\`ere virtuelle} si n\'ecessaire. La {\tt VirtualAssociation} est introduite (au contraire d'une association d\'eriv\'ee usuelle) pour fournir un moyen  de sp\'ecifier explicitement la propri\'et\'e de jointure de l'association avec l'expression {\tt joinCriteria}.
\item {\tt TransformationAction}: h\'eritage d'une {\tt OpaqueAction} UML, fournissant un \'el\'ement d'activit\'e qui ne peut pas \^etre plus structur\'e. C'est une action \'el\'ementaire de transformation. 
\item {\tt AssignmentDefinition}s: identifie les expression et les type primitifs en tant que sp\'ecifications. 
\item {\tt MappingRule}: L'objet cartographique. Construit comme une composition de d\'efinitions de r\`egles. 
\item {\tt AssociationBinding}: En s\'electionnant des objets associ\'es, on peut d\'efinir comment ces associations sont \'evalu\'ees durant l'input. 
\item {\tt JoinType}: Un type '\'enumeration', pour sp\'ecifier le type de jointure dans le lien d'association.
\end{itemize}

\section{Prototype Implementation}
\section{Installation du prototype}

\label{sec:prototype}

% In the context of the presented research project, a proof-of-concept prototype is implemented. Besides the WFS protocol extension and the UMLT language specification, this prototype consists of a model parser, a mapping model editor and a prototype test bed. The model parser and the editor are developed in the Eclipse environment\footnote{Eclipse: {\tt \url{http://www.eclipse.org}}}. The model parser creates an XMI file from a UML/Interlis data model and also from a UMLT mapping model.

Dans le contexte du projet de recherche pr\'esent\'e, un prototype de v\'erification est install\'e. En dehors de l'extension du protocole WFS, et des sp\'ecifications du langage UMLT, ce prototype est caract\'eris\'e par un 'model parser', un \'editeur de cartographie de mod\`eles, et un prototype 'test bed'. Le model parser et l'\'editeur sont d\'evelopp\'es dans l'environnement Eclipse \footnote{Eclipse: {\tt \url{http://www.eclipse.org}}}. Le model parser cr\'ee un fichier XML \`a partir d'un mod\`ele de donn\'ees et d'un mod\`ele de cartographie UMLT. 

% In the prototype test bed, we use an ORACLE Spatial database and a deegree WFS implementation\footnote{deegree project page: {\tt \url{http://www.deegree.org}}} on which the mdWFS is built upon. Figure \ref{fig:mdwfsproto} shows the steps of a semantic transformation using mdWFS.

Dans le prototype de test bed, nous utilisons une base de donn\'es spatiale Oracle et une installation degree WFS\footnote{page du projet deegree: {\tt \url{http://www.deegree.org}}}, sur laquelle est rajout\'ee mdWFS. La figure \ref{fig:mdwfsproto}  montre les \'etapes d'une transformation s\'emantique utilisant mdWFS. 

\begin{figure*}[htbp]
   \centering
   \includegraphics[width=0.85\textwidth]{./proceedings/staub/mdWFS_proto}
   \caption{Test d'installation du prototype}
   \label{fig:mdwfsproto}
\end{figure*}

% We primarily focused on the WFS extension and on the conceptual mapping language UMLT. We consider ORACLE Spatial as a very suitable RDBMS for our needs, providing powerful spatial features. Therefore, we use the RDBMS we already had at hand although it is not a FOSS solution. Principally, an mdWFS can be applied on any RDBMS with a spatial extension.\\

Nous avons au d\'epart concentr\'e nos efforts sur l'extension WFS and sur le langage conceptuel de cartographie UMLT. Nous consid\'erons Oracle comme un RDBMS tr\`es adapt\'e pour nos besoins, gr\^ace \`a des fonctions spatiales puissantes. Par cons\'equent, nous utilisons le RDBMS que nous avons d\'ej\`a en main, bien que ce ne soit pas une solution FOSS. Surtout, un mfWFS peut \^etre appliqu\'e \`a tout RDBMS avec un extension spatiale. 
% Before you can start working with mdWFS, you need to configure the database according to the source data model $A$. This can be done using an existing FOSS tool called ``ili2ora''\footnote{Source: {\tt \url{http://www.eisenhutinformatik.ch/interlis/ili2ora/}}}. This tool allows to configure an ORACLE Spatial database according an UML/Interlis-data model and to import feature data into this database.

Avant de pouvoir commence \`a utiliser mdWFS, il faut configurer la base de donn\'ees selon la source du mod\`ele de donn\'ees $A$. Cela peut \^etre fait en utilisant un outil FOSS existant, d\'enomm\'e ``ili2ora''\footnote{Source: {\tt \url{http://www.eisenhutinformatik.ch/interlis/ili2ora/}}}. Cet outil permet de configurer une base de donn\'ees ORACLE Spatial, selon un mod\`ele de donn\'ees UML/Interlis, et d'importer des \'el\'ements dans la base de donn\'ees. 

% \begin{enumerate}
% \item Client $B$ sends a model-catalogue request to the mdWFS
% \item The mdWFS provides a catalogue of available data models
% \item Client $B$ chooses a source data model (i.~e.\ model {\em $A$}) and orders the model information
% \item The mdWFS fetches model information $A$ and sends the model (XMI) or a model reference to the client $B$
% \item Client $B$ creates the model mapping $M : A \xrightarrow{{\mathcal{F}}_M} B$ by specifying adequate UMLT mapping rules
% \item The transformation model {\em and} the target model $B$ are parsed and translated into XMI and sent to the mdWFS in a {\tt DoTransform}-request
% \item According to the target model $B$, the mdWFS configures an ORACLE Spatial database using ili2ora again
% \item The mapping rules from the transformation model are translated into SQL statements and Java instructions in order to actually transform feature data from source/server model $A$ into target/client model $B$
% \item The mdWFS configures a standard WFS (deegree) according to the target model $B$. This WFS is connected to the database containing the transformed feature data
% \item After finishing the transformation, the mdWFS sends a {\tt DoTransform}-response to the client $B$
% \item Client $B$ accesses the transformed feature datasets from model/database $A$, transformed into model structure $B$, via standard WFS requests.
% \end{enumerate}

\begin{enumerate}
\item Le client $B$ envoit une requ\^ete au catalogue de mod\`eles de mdWFS
\item Le mdWFS fournit un catalogue des mod\`eles disponibles
\item Le client $B$ choisit un mod\`ele source (par ex.\ le mod\`ele {\em $A$}) et ordonne les informations sur le mod\`ele 
\item Le mdWFS pointe les informations $A$ et envoit le mod\`ele (XMI) ou un mod\`ele r\'ef\'erence au client $B$
\item Le client $B$ cr\'ee le mod\`ele $M : A \xrightarrow{{\mathcal{F}}_M} B$en sp\'ecifiant les r\`egles de repr\'esentation UMLT ad\'equates 
\item Le mod\`ele de transformation {\em et} le mod\`ele cible $B$ sont trait\'es et traduits en XMI et envoy\'es au mdWFS par une requ\^ete{\tt DoTransform}
\item Selon le mod\`ele cible $B$, le mdWFS configure une base de donn\'ees spatiale ORACLE utilisant \`a nouveau ili2ora
\item Les r\`egles de repr\'esentation du mod\`ele de transformation sont traduites en s\'equences SQL et en onstructions Java, dans le but de transformer des donn\'ees depuis le mod\`ele source/serveur $A$ vers le mod\`ele cible/client $B$
\item Le mdWFS configure un WFS standard (deegree) d'apr\`es le mod\`ele cible $B$. Ce WFS est connect\'e \`a la base de donn\'ees contenant la donn\'ee transform\'ee. \item A la fin de la transformation, le mdWFS envoit une r\'eponse {\tt DoTransform}-au client $B$
\item Le client $B$ acc\`ede aux donn\'ees transform\'ees depuis le mod\`ele/base de donn\'ee $A$, transform\'e en mod\`ele $B$, via des requ\^etes standard WFS.
\end{enumerate}

\section{Conclusions}
\label{sec:conclusions}

% The current evolution of GI systems shows that a conceptual schema language is usually applied for geodata modelling. This is a necessary precondition for semantic transformations on the conceptual level.
Any given application domain can be characterised by different data structures. This leads to different data models. Therefore, conceptual model mappings must be established in order to achieve semantic interoperability.

L'\'evolution actuelle des syst\`emes d'IG montre qu'un langage conceptuel est en g\'en\'eral utilis\'e pour les mod\`eles de donn\'ees. C'est une pr\'econdition n\'ecessaire pour des transformations s\'emantiques au niveau conceptuel. Un domaine d'application peut \^etre caract\'erise par plusieurs structures de donn\'ees. Cela conduit \`a diff\'erents mod\`eles de donn\'ees. Par cons\'equent, des mod\`eles de repr\'esentations conceptuelle doivent \^etre \'etablis pour r\'ealiser une interop\'erabilit\'e s\'emantique. 

% The new {\em mdWFS} presented in this article implements the methodology of the semantic transformation at the conceptual level of abstraction what allows for a much enhanced semantic interoperability.

% Potentially, the mdWFS can be integrated in other (OWS based) infrastructures due to the sound basis of GI standards that are applied.

Le nouveau {\em mdWFS} pr\'esent\'e dans cet article met en place la m\'ethodologie de la transformation s\'emantique \`a un niveau conceptuel d'abstraction, qui permet une interop\'erabilit\'e s\'emantique beaucoup plus \'etendue.  
Potentiellement, le mdWFS peut \^etre int\'egr\'e dans d'autres infrastructures bas\'es OWS, gr\^ace aux bases des standards de l'IG qui y sont appliqu\'ees.  

% \section{Acknowledgements}

\section{Remerciements}
\label{sec:acknowledgements}

% I would like to thank my colleagues at the ETH Zurich and at the TU Munich for their company and good collaboration in this research project: Dr.-Ing.\ A.\ Donaubauer, H.~R.\ Gn\"agi, A.\ Morf, F.\ Straub.
% I also appreciate the excellent project lead of Prof.~Dr.\ A.\ Carosio, ETH Zurich and Prof.~Dr.-Ing.\ M.\ Schilcher, TU Munich.

% This project is co-funded by the German Federal Office for Cartography and Geodesy BKG and the Swiss Federal Office for Topography swisstopo.

Je voudrais remercier mes coll\`egues au ETH Zurich et au TU Munich pour leur accompagnement et leur collaboration positive dans ce projet de recherche: Dr.-Ing.\ A.\ Donaubauer, H.~R.\ Gn\"agi, A.\ Morf, F.\ Straub. J'ai \'egalement appr\'eci\'e l'excellent conduite de projet des Prof.~Dr.\ A.\ Carosio, ETH Zurich et Prof.~Dr.-Ing.\ M.\ Schilcher, TU Munich.

Ce projet est co-financ\'e par le BKG, Bureau F\'ed\'eral allemand de Cartographie et de G\'eod\'esie, et Swisstopo, le Bureau F\'ed\'eral Suisse de Topographie. 

\begin{footnotesize}
\begin{thebibliography}{99}

\bibitem{donau:2007}
A.\ Donaubauer, F.\ Straub, M.\ Schilcher (2007)
\newblock mdWFS: A Concept of Web-enabling Semantic Transformation.
\newblock Proceedings of the 10$^{th}$ AGILE Conference on Geographic Information Science, 2007, Aalborg.

\bibitem{gnaegi:2006}
H.~R.\ Gn\"agi, A.\ Morf, P.\ Staub (2006)
\newblock Semantic Interoperability through the Definition of Conceptual Model Transformations.
\newblock Proceedings of the 9$^{th}$ AGILE Conference on Geographic Information Science, 2006, Visegr\'ad.

\bibitem{wfs:2005}
OGC Open Geospatial Consortium (2005)
\newblock Web Feature Service Implementation Specification: 1.1.0.
\newblock OpenGIS implementation specification OGC 04-094.

\bibitem{omg:2003}
OMG Object Management Group (2003)
\newblock MDA Guide Version 1.0.1.
\newblock OMG specification omg/2003-06-01.

\bibitem{mofqvt:2005}
OMG Object Management Group (2005)
\newblock MOF 2.0 Query/Views/Transformations Specification.
\newblock OMG specification ptc/05-11-01.

\bibitem{omg:2005}
OMG Object Management Group (2005)
\newblock MOF 2.0/XMI Mapping Specification, v2.1.
\newblock OMG specification formal/05-09-01.

\bibitem{omguml:2007}
OMG Object Management Group (2007)
\newblock UML Unified Modeling Language: Superstructure, version 2.1.1.
\newblock OMG specification formal/2007-02-05.

\bibitem{ili:2006}
SNV Swiss Association for Standardization (2006)
\newblock INTERLIS Reference Manual, version 2.3.
\newblock Swiss standard SN 612031.

\end{thebibliography}
\end{footnotesize}

\address{Peter Staub\\
  ETH Zurich, Institute of Geodesy and Photogrammetry, GIS Group\\
  \url{http://www.gis.ethz.ch}\\
  \email{peterstaub AT ethz.ch}}
  