source: CMDI-Interoperability/CMD2RDF/trunk/docs/papers/2014-LREC/CMD2RDF.tex @ 4463

\documentclass[10pt, a4paper]{article}
\usepackage{lrec2006}

\usepackage{color}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{framed}
\usepackage{url}

\usepackage{verbatim} % adds environment for commenting out blocks of text & for better verbatim
\usepackage{multicol} 

%\newcommand{\comment}[1]{}
\newcommand{\commentx}[1]{\textcolor{red}{#1}}

%%% PAGE DIMENSIONS
%\usepackage{geometry} % to change the page dimensions
%\geometry{a4paper} % or letterpaper (US) or a5paper or....
%\geometry{margin=2.5cm} % for example, change the margins to 2 inches all round
%\topmargin=-0.6in
%\textheight=700pt
% \geometry{landscape} % set up the page for landscape
%   read geometry.pdf for detailed page layout information

\newcommand{\code}[1]{\texttt{#1}}
\newcommand{\xne}[1]{\textsf{#1}}  % named entity
\newcommand{\furl}[1]{\footnote{\url{#1}}}
\newcommand{\var}[1]{\textrm{\textit{#1}}} % variable, definition

%@{\hspace{-2mm}} 
\newenvironment{example2}
{ \footnotesize
\begin{sffamily} \begin{shaded*} \noindent
 \begin{tabular}{@{\hspace{-1mm}} p{0.3\textwidth}  p{0.7\textwidth} } }
{\end{tabular} \end{shaded*} \end{sffamily} }

\newenvironment{example2a}
{ \footnotesize
\begin{sffamily} \begin{shaded*} \noindent
 \begin{tabular}{@{\hspace{-1mm}} p{0.4\textwidth}  p{0.6\textwidth} } }
{\end{tabular} \end{shaded*} \end{sffamily} }

\newenvironment{example3}
{ \footnotesize
 \begin{sffamily} \begin{shaded*} \noindent
 \begin{tabular}{@{\hspace{-1mm}} p{0.25\textwidth}  p{0.25\textwidth}  p{0.45\textwidth}} 
}
{  \end{tabular} \end{shaded*} \end{sffamily} }

\definecolor{shadecolor}{rgb}{0.95,0.95,1.0}

% xml syntax highlighting
% source http://snipt.org/vngf3
\usepackage{listings}
 
\definecolor{grey}{rgb}{0.4,0.4,0.4}
\definecolor{darkblue}{rgb}{0.0,0.0,0.6}
\definecolor{cyan}{rgb}{0.0,0.6,0.6}


\newenvironment{notex}
{\footnotesize \color{grey} \begin{textit}}
{ \end{textit} \normalsize}

\title{From CLARIN Component Metadata to Linked Open Data}

\name{Matej \v{D}ur\v{c}o, Menzo Windhouwer}

\address{ Institute for Corpus Linguistics and Text Technology (ICLTT), The Language Archive - DANS \\
               Vienna, Austria, The Hague, The Netherlands \\
               matej.durco@oeaw.ac.at, menzo.windhouwer@dans.knaw.nl\\}

\abstract{In the european CLARIN infrastructure a growing number of resources are described with Component Metadata. In this paper we
describe a transformation to make this metadata available as linked data. After this first step it becomes possible to connect the CLARIN Component Metadata with other valuable knowledge sources in the Linked Data Cloud. \\ \newline \Keywords{Linked Open Data, RDF, metadata}}

%
\begin{document}

\maketitleabstract

\section{Motivation}
%
Although semantic interoperability has been one of the main motivations for CLARIN's Component Metadata Infrastructure (CMDI) \cite{Broeder+2010} \furl{http://www.clarin.eu/cmdi/}, until now there has been no work on the obvious -- bringing CMDI to the Semantic Web. We believe that providing the CLARIN CMD records as Linked Open Data (LOD) interlinked with external semantic resources, will open up new dimensions of processing and exploring of the CMD data by employing the power of semantic technologies. In this paper, we lay out how individual parts of the CMD data domain can be expressed in RDF and made ready to be interlinked with existing external semantic resources (ontologies, taxonomies, knowledge bases,  vocabularies). 
%This conversion lays a foundation / is groundwork for providing the original dataset as a \emph{Linked Open Data} nucleus within the \emph{Web of Data}\cite{TimBL2006} as well as for real semantic (ontology-driven) search and exploration of the data.

%
\section{The Component Metadata Infrastructure}\label{CMDI}
%

The basic building blocks of CMDI are components. Components are used to group elements and attributes, which can take values, and also other components (see Figure \ref{fig:CMDM}). Components are stored in the Component Registry (CR), where they can be reused by other modellers. Thus a metadata modeller selects or creates components and combines them into a profile targeted at a specific resource type, a collection of resources or a project, tool or service. A profile serves as blueprint for a schema for metadata records. CLARIN centres offer these CMD records describing their resources to the joint metadata domain. There are a number of generic tools which operate on all the CMD records in this domain, e.g., the Virtual Language Observatory\furl{http://www.clarin.eu/vlo/}. These tools have to deal with the variety of CMD profiles. They can do so by operating on a semantic level, as components, elements and values can all be annotated with links to concepts in various registries. Currently used concept registries are the Dublin Core metadata %elements and 
terms and the ISOcat Data Category Registry. These concept links allow profiles, while being diverse in structure, to share semantics. Generic tools can use this semantic linkage to overcome differences in terminology and also in structure.

\begin{figure*}
\begin{center}
\hspace{-0.1\textwidth}\includegraphics[width=0.8\textwidth]{CMDM}
\end{center}
\caption{Component Metadata Model \cite{ISODIS24622-1_2013}}
\label{fig:CMDM}
\end{figure*}


%
\subsection{Current status of the joint CMD Domain}
%
To provide a frame of reference for the proportions of the undertaking, this section gives a few numbers about the data in the CMD domain.
%, both on the schema level, i.e. with regard to the defined profiles and data categories used, as well as on the instance level, the actual CMD records.

\subsubsection{CMD Profiles }
Currently 146 public profiles and 857 components are defined in the CR.
Next to the `native' ones a number of profiles have been created that implement existing metadata formats, like OLAC/DCMI-terms, TEI Header or the META-SHARE schema. 
%The resulting profiles proof the flexibility/expressi\-vi\-ty of the CMD metamodel.
The individual profiles differ also very much in their structure -- next to simple flat profiles 
%with just one level of components or elements with 5 to 20 fields (\textit{dublincore}, \textit{collection}, the set of \textit{Bamdes}-profiles) 
there are complex ones with up to 10 levels %(\textit{ExperimentProfile}, profiles for describing Web Services) 
and a few hundred elements. 
%The biggest single profile is currently the remodelled maximum schema from the META-SHARE project \cite{Gavrilidou2012meta} for describing corpora, with 117 components and 337 elements. 

\subsubsection{Instance Data}

The main CLARIN OAI-PMH harvester\footnote{\url{http://catalog.clarin.eu/oai-harvester/}}
regularly collects records from the -- currently 58 -- providers, all in all over 600.000 records. 
Some 20 of the providers offer CMDI records, the rest provides around 140.000 OLAC/DC records, that are converted into the corresponding CMD profile. 
%Next to these 81.226 original OLAC records, there a few providers offering their OLAC or DCMI-terms records already converted into CMDI, thus all in all OLAC, DCMI-terms records amount to 139.152.
%On the other hand, some
Some of the comparatively few providers of `native' CMD records expose multiple profiles (e.g. Meertens Institute uses 12 different ones), so that overall instance data for more than 60 profiles is present.
%So we encounter both situations: one profile being used by many providers and one provider using many profiles.

\section{CMD to RDF}
\label{sec:cmd2rdf}
In the following a RDF encoding is proposed for all levels of the CMD data domain: 
\begin{itemize}
\item CMD meta model,
\item profile and component definitions,
\item administrative and structural information of CMD records and
\item individual values in the fields of the CMD records.
\end{itemize}

\subsection{CMD specification}\label{sec:CMDM}

The main entity of the meta model is the CMD component modelled as a \code{rdfs:Class}. A CMD profile is basically a CMD component with some extra features, implying a specialization relation. It may seem natural to translate a CMD element to a RDF property (as it holds the literal value), but given its complexity (e.g., attributes\footnote{Due to space considerations we will not further discuss attributes.}, relation to the containing component)  it too has to be expressed as \code{rdfs:Class}. The actual literal value is a property of given element of type \code{cmdm:ElementValue}. For values that can be mapped to entities defined in external semantic resources, the references to these entities are expressed in parallel object properties of type \code{cmdm:hasElementEntity} (constituting outbound links). The containment relation between components and elements is expressed with a dedicated property \code{cmdm:contains}.

\begin{figure*}
\begin{center}
\label{table:rdf-spec}
\begin{example3}
\multicolumn{3}{l}{@prefix cmdm: \textless http://www.clarin.eu/cmd/general.rdf\#\textgreater . }\\
\\
\multicolumn{3}{l}{\# basic building blocks of CMD Model}  \\
cmdm:Component & a & rdfs:Class . \\
cmdm:Profile & rdfs:subClassOf & cmdm:Component . \\
cmdm:Element & a & rdfs:Class . \\
%cmdm:Attribute & a & rdfs:Class .  \\
\\
\multicolumn{3}{l}{\# basic CMD nesting}  \\
cmdm:contains & a & rdf:Property ; \\
        & rdfs:domain & cmdm:Component ; \\
        & rdfs:range & cmdm:Component , cmdm:Element . \\

%cmdm:containsAttribute & a &rdf:Property;
%          & rdfs:domain & cmdm:Component, cmdm:Element;
%          & rdfs:range & cmdm:Attribute.

\multicolumn{3}{l}{\# values}  \\

cmdm:Value & a & rdfs:Literal .  \\
\\
cmdm:hasElementValue & a & rdf:Property ;  \\
              & rdfs:domain & cmdm:Element ;  \\
              & rdfs:range & cmdm:Value .  \\
 \\
\multicolumn{3}{l}{\# add a parallel separate class/property for the resolved entities}  \\
cmdm:Entity & a & rdfs:Class .  \\
\\
cmdm:hasElementEntity & a & rdf:Property ;  \\
              & rdfs:domain & cmdm:Element ;  \\
              & rdfs:range & cmdm:Entity .   \\
% \\
%\multicolumn{3}{l}{\# analogue for attributes ...}  \\
%cmdm:hasAttributeValue & a & rdf:Property ;  \\
%              & rdfs:domain & cmdm:Attribute ;  \\
 %             & rdfs:range & rdfs:Literal .  \\

%cmdm:hasAttributeEntity & a & rdf:Property ;  \\
%              & rdfs:domain & cmdm:Attribute ;  \\
%              & rdfs:range & cmdm:Entity .  \\
\end{example3}
\end{center}
\caption{The CMD meta model in RDF}
\label{fig:final-example}
\end{figure*}

\subsection{CMD profile and component definitions}
This top-level classes and properties are subsequently used for modelling the actual profiles, components and elements as they are defined in the CR.
For stand-alone components, the IRI is the (future) path into the CR to get the RDF representation for the profile/component\furl{http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/components/clarin.eu:cr1:c\_1271859438125/rdf}. For ``inner'' components (that are defined as part of another component) and elements the identifier is a concatenation of the nearest ancestor stand-alone component's IRI and the dot-path to given component/element (e.g., Actor:\\ \code{cr:clarin.eu:cr1:c\_1271859438197/rdf \#Actor.Actor\_Languages.Actor\_Language}\footnote{For the sake of readability, in the examples we will collapse the component IRIs, refering to them just by their name, prefixed with \code{cmd:}})

\begin{example2}
cmd:collection \\
$\;$ a & cmdm:Profile ; \\
$\;$ rdfs:label & "collection" ; \\
$\;$ dc:identifier & cr:clarin.eu:cr1:p\_1345561703620 . \\
cmd:Actor \\
$\;$ a &cmdm:Component . \\
\end{example2}

\subsubsection{Data Categories}
The primary concept registry in use by CMDI for its concept links is ISOcat. The recommended approach to link to the data categories is via an annotation property \cite{Windhouwer2012_LDL}.

\begin{example2}
dcr:datcat \\
$\;$ a  & owl:AnnotationProperty ; \\
$\;$ rdfs:label  & "data category"@en . \\
% & rdfs:comment  & "This resource is equivalent to  this data category."@en ; \\
% & skos:note  & "The data category should be identified by its PID."@en ; \\
\end{example2}

Consequently, the \code{@ConceptLink} attribute on CMD elements and components referencing the data category can be modelled as: 

\begin{example2}
cmd:LanguageName \\
$\;$ dcr:datcat & isocat:DC-2484 . \\
\end{example2}

%\subsection{RELcat - Ontological relations}
% \commentx{for now we could probably skip all of relcat (although it is the future of semantic mapping ;) - we spare something for the next paper.}
\begin{comment}
Relations between data categories are not stored directly in the \xne{ISOcat} DCR, but rather in the dedicated Relation Registry \xne{RELcat} as RDF triples \cite{WINDHOUWER12.954} with dedicated predicates based on an extensible taxonomy of relation types. In the final paper, we will provide more details on the role of this important building block in the endeavour.


A sample relation from the \xne{CMDI} relation set expressing a number of equivalences between \xne{ISOcat} data categories and \xne{dublincore} terms: 

\begin{example3}
isocat:DC-2538 & rel:sameAs & dct:date
\end{example3}

\noindent
By design, the relations in Relation Registry are not expressed with predicates from known vocabularies like \xne{SKOS} or \xne{OWL}, again with the aim to avoid too strong semantic implications. This leaves leeway for further specialization of the relations in specific applications. The \code{rel:*} properties can be undrestood as an upper layer of a taxonony of relation types, implying a subtyping:

\begin{example3}
rel:sameAs & rdfs:subPropertyOf & owl:sameAs
\end{example3}
\end{comment}

%%%%%%%%%%%%%%%%%%%%%
\subsection{CMD instances}
In the next step, we want to express in RDF the individual CMD instances, the metadata records.

We provide a generic top level class for all resources (including metadata records), the \code{cmdm:Resource} class and the  \code{cmdm:hasMimeType} predicate to type the resources.

\begin{example3}
\textless lr1\textgreater \\
$\enspace \,$ a  & & cmdm:Resource ; \\
\multicolumn{2}{l}{cmdm:hasMimeType } & "audio/wav" . \\
\end{example3}

\subsubsection {Resource Identifier}

\begin{comment}
It seems natural to use the PID of a Language Resource ( \code{<lr1>} ) as the resource identifier for the subject in the RDF representation. While this seems semantically sound, not every resource has to have a PID. (This is especially the case for ``virtual'' resources like collections, that are solely defined by their constituents and don't have any data on their own.) As a fall-back the PID of the MD record ( \code{<lr1.cmd>}  from \code{cmd:MdSelfLink} element) could be used as the resource identifier. 
If identifiers are present for both resource and metadata, \end{comment}
The PID of a Language Resource ( \code{<lr1>} ) is used as the IRI for the described resource in the RDF representation.
The relationship between the resource and the metadata record can be expressed as an annotation using the \xne{OpenAnnotation} vocabulary\furl{http://openannotation.org/spec/core/core.html}.
(Note, that one MD record can describe multiple resources. This can be also easily accommodated in OpenAnnotation.)

\begin{example2a}
\_:anno1  \\
 $\:$ a & oa:Annotation ; \\
 $\:$ oa:hasTarget  & \textless lr1a \textgreater, \textless lr1b\textgreater ; \\
 $\:$ oa:hasBody  & \_:topComponent1 ; \\
 $\:$ oa:motivatedBy & oa:describing . \\
\end{example2a}

\subsubsection{Provenance}

The information from the CMD record \code{cmd:Header} represents the provenance information about the modelled data.

\begin{example2}
\_:topComponent1  \\
 $\:$ dc:identifier  & \textless lr1.cmd \textgreater ;  \\
 $\:$ dc:creator  & "John Doe" ;  \\
 $\:$ dc:publisher  & \textless http://clarin.eu\textgreater  ; \\
 $\:$ dc:created & "2014-02-05"\^{}\^{}xs:date .  \\
\end{example2}

\subsubsection{Collection hierarchy}  % ( Resource Proxy – IsPartOf)} 

In CMD, there are dedicated generic elements -- the \code{cmd:ResourceProxyList} structure -- used to express both the collection hierarchy and to point to resource(s) described by the CMD record. The collection hierarchy can be modelled as an \xne{OAI-ORE Aggregation}\furl{http://www.openarchives.org/ore/1.0/primer#Foundations}. (The links to resources are handled by \code{oa:hasTarget}.)
:

\begin{example3}
\textless lr0.cmd \textgreater  & a   & ore:ResourceMap . \\
\textless lr0.cmd\textgreater & ore:describes & \textless  lr0.agg\textgreater . \\
\textless lr0.agg\textgreater & a   & ore:Aggregation ; \\
& ore:aggregates  & \textless lr1.cmd\textgreater, \textless lr2.cmd\textgreater . \\
\end{example3}

\begin{comment}
Additionally the flat header field \code{cmd:MdCollectionDisplayName} has been introduced to indicate by simple means the collection, of which given resource is part.
This information can be used to generate a separate one-level grouping of the resources, in which the value from the \code{cmd:MdCollectionDisplayName} element would be used as the label of an otherwise undefined \code{ore:ResourceMap}.
Even the identifier/ URI for this collections is not clear. Although this collections should match with the ResourceProxy hierarchy, there is no guarantee for this, thus a 1:1 mapping cannot be expected.

\begin{example3}
\_:mdcoll  & a   & ore:ResourceMap; \\
 & rdfs:label & "Collection 1"; \\
\_:mdcoll\#aggreg & a   & ore:Aggregation \\
 & ore:aggregates  & <lr1.cmd>, <lr2.cmd>; \\
\end{example3}
\end{comment}
        
\subsubsection{Components -- nested structures}
For expressing the tree structure of the CMD records, i.e. the containment relation between the components a dedicated property \code{cmd:contains} is used:

\begin{example3}
\_:actor1  & a & cmd:Actor . \\
\_:actor1lang1  & a  & cmd:Actor.Language . \\
\_:actor1  & cmd:contains & \_:actor1lang1 . \\
\end{example3}

\begin{comment}
\noindent
We use \code{cmdm:describesResource} for if the \code{@res} attribute is used , i.e., one or more references to a resource (via a proxy), on a component

\begin{example3}
\_:coll1 & a & cmd:collection. \\
\_:coll1 & cmdm:describesResource & <lr1> . \\
\end{example3}
\end{comment}


\begin{figure*}
\begin{center}
\begin{example3}
cmd:Person & a & cmdm:Component . \\
cmd:Person.Organisation & a &  cmdm:Element . \\
cmd:hasPerson.OrganisationElementValue  \\
& rdfs:subProperyOf & cmdm:hasElementValue ; \\
        & rdfs:domain & cmd:Person.Organisation ; \\
        & rdfs:range & xs:string . \\ 
cmd:hasPerson.OrganisationElementEntity \\
        & rdfs:subProperyOf & cmdm:hasElementEntity ; \\
        & rdfs:domain & cmd:Person.Organisation ; \\
        & rdfs:range & cmd:Person.OrganisationElementEntity .\\
cmd:Person.OrganisationElementEntity \\
& a & cmdm:Entity . \\
\\
\multicolumn{3}{l}{\# person (mentioned in a MD record) has an affiliation (cmd:Person/cmd:Organisation) } \\
\_:pers  & a & cmd:Person ; \\
        & cmdm:contains & \_:org . \\
\_:org & a & cmd:Person.Organisation ; \\
        & \multicolumn{2}{l}{cmd:hasPerson.OrganisationElementValue \quad 'MPI'\^{}\^{}xs:string ;} \\
        & \multicolumn{2}{l}{ cmd:hasPerson.OrganisationElementEntity  \quad \textless http://www.mpi.nl/\textgreater . }\\

\textless http://www.mpi.nl/\textgreater & a  & cmd:OrganisationElementEnity . 
\end{example3}
\end{center}
\caption{Chain of statements from metamodel to literal value and corresponding semantic entity}
\label{fig:final-example}
\end{figure*}


\subsubsection{Elements, Fields, Values}\label{sec:values}
Finally, we want to integrate also the actual field values in the CMD records into the linked data.
As explained before, CMD elements have to be typed as \code{rdfs:Class}, the actual value expressed as \code{cmds:ElementValue}, and they are related by a \code{cmdm:hasElementValue} property.

While generating triples with literal values seems straightforward, the more challenging but also more valuable aspect is to generate object property triples (predicate \code{cmdm:hasElementEntity}) with the literal values mapped to semantic entities. The example in Figure \ref{fig:final-example} shows the whole chain of statements from metamodel to literal value and corresponding semantic entity. 


\begin{comment}
%%%%%%%%%%%%%%%%%
\section{Mapping field values to semantic entities}
\label{sec:values2entities}

This task is a prerequisite to be able to express also the CMD instance data in RDF. The main idea is to find entities in selected reference datasets (controlled vocabularies, ontologies) matching the literal values in the metadata records. The obtained entity identifiers are further used to generate new RDF triples, representing outbound links.

It involves following steps:

\begin{enumerate}
\item identify appropriate controlled vocabularies for individual metadata fields or data categories (manual task)
\item extract \emph{distinct data category, value pairs} from the metadata records
\item actual \textbf{lookup} of the individual literal values in given reference data (as indicated by the data category) to retrieve candidate entities, concepts 
\item assess the reliability of the match
\item generate new RDF triples with entity identifiers as object properties
\end{enumerate}

This task is basically an application of ontology mapping method, trying to find for our ``anonymous'' concepts semantically equivalent concepts from other semantic resources / vocabularies.
% This is almost equivalent to the definition of ontology mapping function as given by \cite{EhrigSure2004, amrouch2012survey}: ``for each concept (node) in ontology A [tries to] find a corresponding concept (node), which has the same or similar semantics, in ontology B and vice verse''.

\subsubsection{Identify vocabularies}

One generic way to indicate vocabularies for given metadata fields or data categories being discussed in the CMD community is to use dedicated annotation property in the schema or data category definition (tentatively labeled \code{@clavas:vocabulary}, cf: \emph{CMD 1.2}). 

The primary provider of relevant vocabularies is \xne{ISOcat} and \xne{CLAVAS} – a service for managing and providing vocabularies in SKOS format. However, in general we have to assume/consider a number of different sources.

\subsubsection{Extract input data}
Starting from the literal triples as defined in previous section (\code{cmdm:hasElementValue}) we aggregate the elemnt values to retrieve distinct \emph{concept-value pairs}:

\begin{example3}
\_:1 & a  & cmd:OrganisationElementEntity . \\
   & skos:altLabel & "MPI";
\end{example3}

\subsubsection{Lookup}

In abstract terms, the lookup function takes as input the identifier of data category (or CMD element) and a literal string value and returns a list of potentially matching entities, ideally with some confidence score. Before actual lookup, there may have to be some string-normalizing preprocessing.

%\begin{definition}[{signature of the lookup function}]
\begin{equation}
lookup \ ( \ DataCategory \ ,  \ Literal \ )  \quad \mapsto \quad ( \ \textless  Concept \ | \ Entity  ,\ confidenceScore \textgreater \ )*
\end{equation}
%\end{definition}

In the implementation, there needs to be additional initial configuration input, identifying datasets for given data categories, 
which will be the result of the previous step -- identification of vocabularies. \


%\begin{definition}{Required configuration data indicating data category to available }
\begin{equation}
DataCategory \quad \mapsto \quad SemanticResource+
\end{equation}
%\end{definition}


As for the implementation, in the initial setup the system could resort to the \code{find}-interface provided by \xne{OpenSKOS}.
However, in the long term a more general solution is required, a kind of hybrid \emph{vocabulary proxy service} that allows to search in a number of datasets, many of them distributed and available via varying interfaces.

\subsubsection{Candidate evaluation}
The lookup is the most sensitive step in the process, being the gate between ``strings'' and semantic entities. In general, the resulting candidates cannot be seen as reliable matches and should undergo further scrutiny to ensure that the match is semantically correct. In some situation this ambiguities can be resolved algorithmically, but in the end in many cases it will require human curation of the generated data.

%One example: A lookup with the pair \code{<organization, "Academy of sciences">} would probably return a list of organizations, as there is a national Academy of Sciences, in a number of countries. It would require further heuristics, e.g. checking the corresponding department, contact or -- less reliably -- the language of the described resource, to determine which specific Academy of Sciences is meant in given resource description.

\end{comment}

\section{Implementation}

The transformation of profiles and instances into RDF/XML is accomplished by a set of XSL-stylesheets. In the future, when the mapping has been tested extensively, they will be integrated into the CMD core infrastructure, e.g., the CR. A linked data representation of the CLARIN joint metadata domain can then be stored in a RDF triple store and exposed via a SPARQL endpoint.
%The most promising solution seems to be \xne{Virtuoso}, an integrated feature-rich hybrid data store, able to deal with different types of data (``Universal Data Store''). \cite{Haslhofer2011europeana} 

% Although the distributed nature of the data is one of the defining features of LOD and theoretically one should be able to follow the data by dereferencable URIs, in practice it is mostly necessary to pool into one data store linked datasets from different sources that shall be queried together due to performance reasons. This implies that the data to be kept by the data store will be decisively larger, than ``just'' the original dataset.

%
\section{CMDI's future in the LOD Cloud}
%
The main added value of LOD \cite{TimBL2006} is the interconnecting of disparate datasets in the so called LOD cloud \cite{Cyganiak2010}. 

The actual mapping process from CMDI values (see Section \ref{sec:values}) to entities is a complex and challenging task. The main idea is to find entities in selected reference datasets (controlled vocabularies, ontologies) corresponding to the literal values in the metadata records. The obtained entity identifiers are further used to generate new RDF triples, representing outbound links.

In the broader context of LOD Cloud there is the Open Knowledge Foundation’s Working Group on Linked Data in Linguistics, that represents an obvious pool of candidate
datasets to link the CMD data with\footnote{\url{http://linguistics.okfn.org/resources/llod/}}.  Within these \xne{lexvo} seems a most promising starting point, as it features URIs like \url{http://lexvo.org/id/term/eng/}, i.e. based on the ISO-639-3 language identifiers which are also used in CMD records.
\xne{lexvo} also seems suitable as it is already linked with a number of other LOD linguistic datasets like \xne{WALS}, \xne{lingvoj} and \xne{Glottolog}.
Of course, language is just one dimension to use for mapping. 
Step by step we will link other categories like countries, geographica, organisations, etc.
to some of the central nodes of the LOD cloud, like \xne{dbpedia}, \xne{Yago} or \xne{geonames}, 
but also to domain-specific semantic resource like the ontology for language technology \xne{LT-World} \cite{Joerg2010} developed at DFKI.

\section{Conclusions}
In this paper, we sketched the work on encoding of the whole of the CMD data domain in RDF, with special focus on the core model -- the general component schema. In the future we will extend this with mapping element values to semantic entities.

With this new enhanced dataset, the groundwork is laid for a full-blown \emph{semantic search}, i.e., the possibility of exploring the dataset indirectly using external semantic resources (like vocabularies of organizations or taxonomies of resource types) to which the CMD data will then be linked.

\bibliographystyle{lrec2006}
\bibliography{CMD2RDF}

\end{document}s