\title{A Generic Approach to Manage Metadata Standards}
\author{Julien Barde, Duane Edgington and Jean-Christophe Desconnets}

\maketitle

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

Informational Resources\footnote{An \textit{informational resource} (IR) is the whole of data, information, knowledge produced, needed or treated by users (regardless of their format: hardcopy or digital\dots). According to the users, this term covers a report, a map, a picture, a video, a dataset, a data series, a database, a model\dots.} (IR) management is a crucial part of environmental resources management. Indeed, the improvement of data processing and decision-making is strongly related to the ability to locate the relevant IR.

However, the exhaustive locating of relevant IR is a challenge for users as they face the following constraints:
\begin{itemize}
	  \item IR are \textit{heterogeneous} (\textit{language}, \textit{semantic}, \textit{syntax/formats}, \textit{metadata}, \textit{access constraints} because of their \textit{rarity} and \textit{cost}\dots),
	  \item IR are \textit{distributed} into \textit{heterogeneous Information Systems (IS)} whose interoperability first involves syntactic and semantic/spatial matching issues (answers to a natural language query often require its translation into as many queries as different kinds of IS).
\end{itemize}
 
Thus, the key issue to improve data retrieval is a better management of the \textit{\{metadata element, value\}} pairs, which constitute any metadata sheet. Once aware of existing IS, the priority to locate the relevant IR is the management of the matching between the \textit{heterogeneous metadata elements (syntactic)}, as well as between their \textit{heterogeneous values (semantic)}. The global scale of environmental domains and the multidisciplinary context of related studies strongly increase these constraints and the need of \textit{semantic and spatial referentials} management. 

\begin{figure*}
\centering
\includegraphics[width=0.8\textwidth]{proceedings/barde/approche_archis.pdf}
\caption{Benefits of a generic approach for multi-standards management}
\label{fig:approche_archis}
\end{figure*}

\section{Metadata management}
\label{sec:MetadataService}

\textit{Metadata management} is thus a priority before considering any data processing. Nevertheless, metadata management still faces the lack of referentials to homogenize: (i) the terminology of \textit{metadata elements}, (ii) their \textit{relationships} as well as (iii) their \textit{values}. As a consequence, the quality of metadata management tools leans as much on the compliance with the reference standards specifications (syntactic: structure of metadata elements) as on the ability to use values from semantic referentials to edit instances. 

The \textit{heterogeneity of standardized metadata elements sets} interferes with \textit{IS syntactic interoperability}: 
					\begin{itemize}
						\item standards often use similar \textit{core metadata elements}, designating the same \textit{concepts} by using different \textit{terms}. These elements answer the following questions: \textit{Where}? \textit{What}? \textit{When}? \textit{Who}?\dots and are essential to retrieve IR,
						\item moreover, standards with \textit{redundant scopes} generate wider \textit{matching issues} since the same kind of IR could be described with different standards (like \textit{FGDC} and \textit{ISO 19115}),
						\item setting up new \textit{international metadata standards} makes the previous national/local standards obsolete and brings \textit{archiving issues} (potentially related to the previous \textit{matching issues}), 
						\item the recent use of \textit{XML Schemas} to standardize their implementations decreases the redundancy of standards scopes and prevent wrong interpretations of their implementations \cite{W3CT0:2004}. Standards can be used as referential types libraries (e.g. the case of \textit{OGC} standards like the update of \textit{ISO 19115} with \textit{ISO 19139}, \textit{SensorML} \dots). 
					\end{itemize}
					
The \textit{heterogeneity of metadata element values} interferes with \textit{IS semantic interoperability} if values are not controlled (regardless of the chosen standard): the use of additional referentials is a key issue to improve IR descriptions and their retrieval by managing the \textit{core metadata element values} (which are used in priority in most of the queries). Among them, the management of the following descriptions are crucial as they are the most complicated and ambiguous: 
	\begin{itemize}
					\item \textit{terminologic description} management with common (multilingual) controlled vocabularies/semantic referentials to valuate \textit{``keyword'' like metadata elements}. Moreover, these referentials help to set up \textit{shared vocabularies} in \textit{pluridisciplinary} contexts,
    			\item \textit{spatial description} management with shared geographic / spatial referentials facilitated by friendly GUIs improves the complex use of geographic information (\textit{GI}) (in particular the use of formats like \textit{GML}, \textit{WKT}\dots). 
			\end{itemize}


\begin{figure*}
\centering
\includegraphics[width=0.8\textwidth]{proceedings/barde/fig2.pdf}
\caption{Generic expression of any metadata standard specifications}
\label{fig:fig2}
\end{figure*}


The need of multi-standards metadata management tools is increasing. Indeed, even a single institute or project often has to manage more than one kind of IR.

Moreover, by considering users' and software engineers' tasks and needs to manage metadata, it appears that most of them are similar regardless of the standard implemented.

\subsection{User's needs and tasks}
\label{sec:UserSNeedsAndTasks}

According to their roles (administrator\dots), regardless of tools, \textit{users tasks} to manage a metadata standard usually consists of:
\begin{itemize}
  \item \textit{profiling} the metadata standards for their specific uses,
  \item \textit{editing} standards instances to describe their IR (by relating values to metadata elements of the chosen profile), 
	\item \textit{locating} (and eventually \textit{acquiring} according to access rights) the relevant IR for a given work by using a single \textit{multi-criteria search engine} which allows sophisticated \textit{spatial queries},
	\item \textit{import}/\textit{export} metadata standards instances (usually XML),
\end{itemize}
 
\textit{Users need} assistance to perform these tasks easily with friendly tools which are currently lacking. Most of the time, users express the need for single centralized access and tools with GUIs whose ergonomy is friendly and homogeneous from one standard to another (since tasks are similar). Indeed, heterogeneous software/IS implementing different or similar standards strongly increase user's accommodation efforts (as users have first to become familiar with each software to perform these tasks and then consider they are wasting their time). Finally, users need complementary components for any complex valuation process (\textit{Web mapping tool}, \textit{controlled vocabularies}, \textit{calendar}\dots) with complicated format (like \textit{GML}\dots). These use cases are illustrated with a UML diagram in the related slideshow (\href{http://www.foss4g2007.org/presentations/viewattachment.php?attachment_id=46}{here}).\footnote{See UML diagram in slideshow: \url{http://www.foss4g2007.org/presentations/viewattachment.php?attachment_id=46}}

\begin{figure*}
	\centering
	\includegraphics[width=0.6\textwidth]{proceedings/barde/lienconcepts.pdf}
	\caption{Properties and relationships of spatial and thematic concepts}
	\label{fig:lienconcepts}
\end{figure*}


\subsection{Software engineer's needs and tasks}
\label{sec:SoftwareEngineerSNeedsAndTasks}

In the same way, software engineer's main tasks and needs remain similar from one standard to another.

\textit{Software (engineers) tasks} consist of:
  \begin{itemize}
  \item \textit{satisfying user needs} by \textit{complying with standards},
	\item managing the \textit{matching between core metadata elements} of different standards to answer basic queries efficiently,
	\item integrating and managing existing \textit{semantic and spatial referentials} to warranty the quality of IR descriptions and to manage query expansion process. Indeed, an efficient data retrieval involves the management of as many queries as existing IS. Answers to these queries are all more difficult since terms and geographic objects used are heterogeneous, 
	\item providing a rich \textit{spatial data infrastructure} to manage and eventually process related IR thereafter.
 \end{itemize}

\textit{Software engineers need} to \textit{minimize their development efforts} to implement metadata standards \cite{Bernstein:2000}. They want to do so by answering similar user needs in the same (automated) way: by reusing a single script set and the same components (WMS\dots). This requires a generic approach (regardless of implemented standards) \cite{bardephd:2005}. 


\subsection{Generic approach vs. specific approach}
\label{sec:GenericApproachVsSpecificApproach}


Traditional specific implementations lead to heterogeneous data storage systems by translating directly specifications into physical heterogeneous data models and thus require specific scripts sets to process them (see illustration in figure~\ref{fig:approche_archis}).\\
For example, by using (manually or automatically) generated SQL from UML or XSD standards specifications, the resulting physical data models are going to be highly heterogeneous (as table and column names will match the metadata element names). Scripts to process their contents have therefore to be adapted to these specific terms set to answer similar tasks. Script sets are thus heterogeneous from one standard to another.

According to the previous lists of tasks and needs, the figure~\ref{fig:approche_archis} illustrates the benefit of a generic approach for both users and software engineers. 


So far, existing tools don't cover these different needs as they mainly lean on specific approaches.


\section{Generic models to manage efficiently \{metadata element, value\} pairs}
\label{sec:GenericModelsToManageEfficientlyMetadataElementValuePairs}

We present in this section the ongoing generic models we are currently implementing to set up both a multi-standard metadata management tool and additional components which control the values of metadata elements by assisting the users at the same time. In particular these models will focus on the most crucial core metadata element values which are related to thematic and spatial descriptions.

\subsection{A generic model to manage heterogeneous metadata standards}
\label{sec:AGenericModelToManageHeterogeneousMetadataStandards}

The goal is to design a generic pattern (or conceptual model as shown in figure~\ref{fig:fig2}) to describe any metadata standard and then set up a generic metadata management system which allows the control of essential values. We suggest expressing a standard as an \textit{inventory of structured metadata elements} with potential additional tools to fill their \textit{content} with controlled \textit{values} (according to standards specifications and/or software engineer's will).\\
This approach is close to DOM's\footnote{Document Object Model} goal which involves similar concepts to manage \textit{nodes} and their \textit{relationships} as well as their \textit{content} in any kind of document. However, we only focus on the specific case of metadata standards.


Nevertheless, a standard rarely aims to control the potential values of the core metadata elements, and even more rarely relationships between values (in particular terms and geographic objects, date/period\dots). The control of such values is ruled by other specific standards. It is thus the role of the software engineer to integrate these standards by setting up complementary tools to manage these specific values.

\begin{figure*}
	\centering
	\includegraphics[width=0.8\textwidth]{proceedings/barde/bigsynthese.pdf}
	\caption{Summarization of the suggested generic approach}
	\label{fig:bigsynthese}
\end{figure*}

We will thereafter focus on the specific case of the management of spatial and thematic values. We suggest a new model to manage their relationships.

\subsection{A generic model to manage heterogeneous (thematic and spatial) values}
\label{sec:AGenericModelToManageHeterogeneousThematicAndSpatialValues}

The different kinds of \{Metadata element, value\} pairs are more or less crucial for data retrieval. In particular, certain values are especially difficult to control. Among them, \textit{thematic} and \textit{spatial descriptions} are both crucial as they are related to core metadata elements, involved in most of the users queries (related to \textit{Where}? and \textit{What}? criteria). We aim to manage them in a generic way by focusing on the user's intention: by focusing on the management of underlying \textit{spatial} and \textit{thematic concepts} (by using a formalization of their properties and relationships, see figure~\ref{fig:lienconcepts}).


Indeed, the use of terms as values related to core metadata elements is often ambiguous:
  \begin{itemize}
 		 \item users often formalize their IR descriptions or queries by using such \textit{terms}: \textcolor{blue}{``\textit{swordfish}, \textit{sea temperature}, \textit{Madagascar}, \textit{spring}''},
 		 \item semantic relationships management allows the system to relate different terms to expand these kinds of queries. For example by collecting other IR described with (\textcolor{blue}{``\textit{Xiphias gladius\dots}''}) which is a \textit{synonym} of \textcolor{blue}{``\textit{swordfish\dots}''}) as it designates the same \textit{concept} (in the same way as a picture and an image),
 		 \item the case of a \textit{toponym} brings a new problematic as this kind of term could be both considered as a keyword or a geographical description. In fact, the geographic object related to the term/toponym \textcolor{blue}{\textit{``Madagascar''}} could as well be designated graphically in a Web Mapping tool\dots.
  \end{itemize}
  

As illustrated in the figure~\ref{fig:lienconcepts}, we suggest managing both \textit{semantic and spatial relationships} between \textit{thematic and spatial concepts} as well as \textit{geographic objects} in the following way: ``\textit{a spatial concept as a kind of thematic concept whose instances are geographic objects}'' \cite{barde:2006}. However it is important to consider that a \textit{geographic object} is not necessarily related to a \textit{term} or \textit{toponym}.


The figure~\ref{fig:bigsynthese} summarizes the content of the previous generic models and give additional details to improve the management of both metadata elements and their values.


This model has been set up to be compliant with current reference standard implementations, for metadata, semantic and spatial information: standardized implementations of metadata standards (such as \textit{XML Schemas}, \textit{DTD}), (Web) Semantic standards (\textit{SKOS} - related to \textit{ISO 2788} and \textit{5964} standards- /\textit{RDF}/\textit{OWL}) and main GI standard formats. This generic model allows one to set up in a single architecture a \textit{physical link between metadata elements and ontologies} to control their values (including spatial descriptions) and expand the queries efficiently.

In the same way, it is possible to set up additional controls for other crucial values: in particular \textit{temporal} and \textit{contacts descriptions} which answer the questions \textit{When} and \textit{Who}? Such control tools are usually \textit{calendar} or \textit{contacts directory} components (they manage date/period and human resources descriptions related to the IR). 

The management of these additional referentials could be done independently of the metadata standards implemented. However, we aim to calculate the values of heterogeneous core metadata elements of the different metadata standards implemented in such a tool by using the same inventories of objects (managed in these referentials) as a basis for any standard. The management of these referentials in the same architecture facilitates the process. Thereafter by keeping track of objects used to describe IR in a dedicated \textit{generic common index table} which duplicates the main descriptions (\textit{What}, \textit{Where}, \textit{Who}, \textit{When}\dots), it will be possible to answer efficiently most of the users' requests, independently of the metadata standards used, by querying its records using richer values than standardized metadata element values (concepts URI instead of \textit{terms}, 2D/3D geographic objects instead of \textit{bounding boxes}\dots).


\section{Model implementation with open source software}
\label{sec:ModelsImplementationWithOpenSourceSoftware}

We present in this last section an implementation based on open source software.

\subsection{Underlying technical choices}
\label{sec:UnderlyingTechnicalChoices}

\textit{\href{http://www.mdweb-project.org/}{MDWeb}} is an open source product which is itself based on other open source software and standards. It implements this kind of architecture to set up a generic metadata management system. MDWeb:
\begin{itemize}
	\item is a multistandard and multilingual metadata cataloging tool implementing a generic approach (like \textit{M3Cat}, \textit{MetaCat}\dots),
	\item is using a \textit{three-tier} (client-server) architecture with:
			\begin{enumerate}
				\item friendly \textit{GUIs} (in Web browsers) with additional components (pop-ups) to assist metadata editing and searching:
			 		 \begin{itemize}
				  	 \item \textit{the spatial description} with Web Mapping tools which can be used as well to display the related GI: \textit{Mapserver / Mapbuilder},
				  	 \item \textit{the thematic description} with Controlled vocabularies management GUIs to set up and browse of thesaurus / ontology: home made component.
			  	 \end{itemize}	
		 	\item \textit{applications scripts} (PHP/Javascript/XML with Apache Http server),
		 	\item \textit{data storage}: \textit{RDBMS} to manage metadata standards \& spatial IR \& related metadata \& controlled vocabularies: \textit{Postgres} with \textit{PostGIS} (WMS for remote GI\dots). Import of \textit{SKOS} files into Postgres by using \textit{JENA} Java API. \textit{XML} repositories. 
		\end{enumerate}			
\end{itemize}

Additional details on the main characteristics of the suggested three-tier architecture for the physical data infrastructure can be found in the related presentation (\href{http://www.foss4g2007.org/presentations/viewattachment.php?attachment_id=46}{here}).\footnote{See presentation online at: \url{http://www.foss4g2007.org/presentations/viewattachment.php?attachment_id=46}}

\subsection{Examples of a possible generic GUIs set}
\label{sec:ExamplesOfAPossibleGenericGUIsSet}


By using \textit{MDWeb} as a basis to implement this approach, it is thus possible to meet users and software engineer's needs, in particular by having a single set of homogeneous GUIs, regardless of the implemented standard \cite{Radha:2005}:

  \begin{itemize}
  \item \textit{Import of any new metadata standard} by translating formal specifications into the PDM\footnote{Physical Data Model} (for now only XML Schemas specifications import is automated),
  \item Set up of \textit{profiles} of imported standards, 
  \item \textit{Metadata sheet edition} with additional GUIs to assist (automation, control\dots) thematic and spatial descriptions of IR (as shown in figure~\ref{fig:GUI_profile}),
	\item Generic/\textit{multi-standard search engine}, 
	\item \textit{Import/export} of standardized (usually XML) metadata sheet.
 \end{itemize}

  
\begin{figure}
    \centering
		\includegraphics[width=0.8\textwidth]{proceedings/barde/gui_edition.pdf}
		\caption{GUI to edit a metadata sheet}
		\label{fig:GUI_profile}
\end{figure}


\section{Conclusion and outlook}
\label{sec:ConclusionAndOutlook}

Data retrieval can be highly improved by managing metadata elements and their values in a better way. By implementing a generic approach (GUIs, scripts set, database) it is possible to manage into a single architecture : 
\begin{itemize}
	\item \textit{heterogeneous metadata standards} (import, profiles, edition\dots), 
	\item \textit{heterogeneous values}: in particular \textit{controlled terms} and \textit{spatial descriptions} to describe \textit{core metadata elements},  
	\item a \textit{common index table} duplicating core metadata elements by using homogeneous values which can be used more efficiently by the \textit{search engine} (no wrapper needed), especially to expand queries,
	\item \textit{spatial IR described by metadata} can then be processed after being retrieved: either locally or remotely by using interoperable protocols or/and rich clients (\textit{WMS}, \textit{QGIS}, \textit{uDig}\dots).
\end{itemize}

This kind of architecture is crucial to satisfy both \textit{user's and software engineer's tasks and needs} by \textit{minimizing adaptation and developments efforts} and by integrating the complementary tools to control crucial core metadata elements values.  

\textit{Data retrieval} is thus improved. In particular, by managing standardized semantic and spatial descriptions and their relationships in a common architecture, data retrieval can use \textit{queries expansion} processes. It is thus possible to focus on specific use cases involving semantic and spatial relationships management like ``find all the IR less than one mile of this geographic object (platform, sensor\dots) measuring the following physical parameter (temperature\dots)'' by leaning on rich concepts, 2D or 3D geographic objects\dots. Moreover by using standardized semantic or spatial relationships (\textit{W3C}, \textit{OGC}\dots) the different kinds of queries can be exported and used in any kind of similar tool. 

Generally, this implementation with an extensive use of \textit{OGC standards and open source software} increases its ability to interoperate with external IS. 
  
\input{proceedings/barde/publications} % Bibliography entries in external file

\address{Barde Julien\\
  Monterey Bay Aquarium Research Institute (MBARI)\\
  \url{http://www.mbari.org/staff/julien/}\\
  \email{julien AT mbari.org}}
  