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

%\documentclass{article}
\documentclass{llncs}
\usepackage{llncsdoc}
\usepackage{color}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{framed}

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

%\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{ttfamily} \begin{shaded*} \noindent
 \begin{tabular}{p{0.4\textwidth}  p{0.6\textwidth} } }
{\end{tabular} \end{shaded*} \end{ttfamily} }

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

\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}


%
\begin{document}

\title{Component Metadata to Linked Open Data}

\author{Matej Durco\inst{1} \and Menzo Windhouwer\inst{2}}

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

\maketitle
%
\begin{abstract}
The hype/trend to Web of Data...

Although semantic interoperability has been one of the main motivation for CLARIN Component Metadata Infrastructure, until now there has been no work on the obvious -- bringing CMDI to Semantic Web. We believe that providing the whole of CMD data  as Linked Open Data linked with external semantic resources, will allow to fully exploit the power of semantic technologies and opens a new level of processing and exploring of CMD data. In this paper, we propose an expression of the whole of the CMD data domain (from meta model to individual metadata records) in RDF.

\commentx{Menzo: I don't think we can express CMD data automatically as an ontology. For that too many semantics are still hidden in CMDI. We are building blocks (e.g., RR/CLAVAS) that might enable us to do so in the future, but I think its better now to go for CMD as LOD linked into the LOD cloud ...}

\end{abstract}
%
\begin{keywords}
Linked Open Data, RDF, metadata
%metamodel, research infrastructure
\end{keywords}
%
\section{Introduction}
%
\commentx{Not sure how much of the introduction, CMD explain + Status of the data domain we want, may and need to reuse between the two papers...}


The hype/trend to Web of Data...

In this paper, we lay out how individual parts of the CMD framework can be expressed in RDF interlinked with existing external semantic resources (ontologies, 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}
%
? 

%
\subsection{Current status of the joint CMD Domain}
%
To provide a frame of reference for the proportions of the undertaking in the following section, 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 }
In the CR 133\footnote{All numbers are as of 2013-09 if not stated otherwise} public Profiles and 696 Components are defined. Table \ref{table:dev} shows the development of the CR and DCR population over time.

Next to the `native' CMD profiles 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 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 profiles 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/}}
collects records from 69 providers on daily basis. The complete dataset amounts to over half a million records.
16 of the providers offer CMDI records, the other 53 provide OLAC/DC records\label{info:olac-records}, that are being converted into the corresponding CMD profile after harvesting. 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 of the comparatively few providers of `native' CMD records expose multiple profiles (e.g. Meertens Institute uses 12 different profiles.) So we encounter both situations: one profile being used by many providers and one provider using many profiles.


%
\section{LOD -- Linked Open Data}
%
Linked Data\cite{TimBL2006}, RDF\cite{RDF2004}

dbpedia, Yago - huge compiled knowledgebases to link to...

Ontology for Language Technology: LT-World \cite{Joerg2010}

LOD cloud Cyganiak and Jentzsch\cite{Cyganiak2010}.


\section{CMD to RDF}
\label{sec:cmd2rdf}
In this section, RDF encoding is proposed for all levels of the CMD data domain: 

\begin{itemize}
\item CMD meta model
\item profile definitions
\item the administrative and structural information of CMD records
\item individual values in the fields of the CMD records
\end{itemize}

\subsection{CMD specification}

The main entity of the meta model is the CMD component modelled as \code{rdfs:Class}. 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, relation to the containing component)  it too has to be a \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 vocabularies/ semantic resources, the references to these entities are expressed in parallel properties of type \code{cmdm:ElementEntity}. The attributes are modelled analogously with \code{cmdm:Attribute, cmdm:AttributeValue, cmdm:AttributeEntity}. 

The containment relation between components and elements is expressed with a dedicated property \code{cmdm:contains}, again analogously for attributes of individual components and elements \code{cmdm:containsAttribute}.

\label{table:rdf-spec}
\begin{example3}
@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 nexting}  \\
cmdm:contains & a & rdf:Property ; \\
        & rdfs:domain & cmdm:Component ; \\
        & rdfs:range & :Component , :Element . \\

%cmdm:containsAttribute & a &rdf:Property;
%          & rdfs:domain & :Component, :Element;
%          & rdfs:range & :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 & :Element ;  \\
              & rdfs:range & :Entity .   \\
 \\
%cmdm:hasAttributeValue & a & rdf:Property ;  \\
%              & rdfs:domain & cmdm:Attribute ;  \\
 %             & rdfs:range & rdfs:Literal .  \\

%cmdm:hasAttributeEntity & a & rdf:Property ;  \\
%              & rdfs:domain & :Attribute ;  \\
%              & rdfs:range & :Entity .  \\
\end{example3}

\noindent
This entities are used for modelling the actual profiles, components and elements as they are defined in the Component Registry.
For stand-alone/top components, the IDs as issued by Component Registry can be used as entity IRIs. For ``inner'' components (that are defined as part of another component) and elements the identifier is a concatenation of the parent top component and dot-path to given component/element (Actor: \code{cr:clarin.eu:cr1:c\_1271859438197/rdf\#Actor\_Languages.Actor\_Language}).

\commentx{Matej: shouldn't we add the name of the component in the IRI for human-readability?
similar to how it is generated in profile XSDs: \textless xs:simpleType name="simpletype-MimeType-clarin.eu.cr1.c\_1290431694511"\textgreater }

\commentx{Menzo: the IRI is the exact path into the CR to get the RDF representation for the profile/component. I think it should stay like that because you need to be able to fetch it to get, for example, the dcr:datcat mappings. Actually the profile/component name is there as its (in general) the first component name after the '\#'.}

\label{table:rdf-cmd}
\begin{example3}
cmd:collection & a & cmdm:Profile; \\
 & rdfs:label & "collection"; \\
 & dcterms:identifier & cr:clarin.eu:cr1:p\_1345561703620. \\
cr:clarin.eu:cr1:c\_1271859438197\#Actor  \\
& a &cmdm:Component. \\
\end{example3}

\commentx{Menzo: we need more context for inner components. In the example LanguageName looks well defined, but take a Component/Element like Title. Is it the title of a book or the title of a person. Only when the semantics are clear, e.g., with a dcr:datcat, one can ignore the context and collapse all Components/Elements to a single RDF class/property.}
\commentx{Matej: wouldn't that be remedied by cmdm:contains? or is it too much inferencing?}

\begin{notex}
Menzo: inner components don't have IDs so I propose a path build from the context up to a shareable component (we need some nice term for that, in the TDS I called it a top notion so maybe a top component. The cmd prefix also needs to be bound to a component specific URI. This URI contains the top component ID, e.g., \furl{http://catalog.clarin.eu/ds/ComponentRegistry/rest/registry/components/clarin.eu:cr1:c\_1271859438125/rdf}.
\end{notex}

\subsection{Data Categories}
Windhouwer \cite{Windhouwer2012_LDL} proposes to use the data categories as annotation properties
so as to avoid too strong semantic implications.

\begin{example3}
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{example3}

That implies that the \code{@ConceptLink} attribute on CMD elements and components as used in the CMD profiles to reference the data category would be modelled as: 

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

\begin{comment}
Encoding data categories as annotation properties is in contrast to the common approach seen with dublincore terms
used usually directly as data properties:

\begin{example3}
<lr1> & dc:title & "Language Resource 1"
\end{example3}

However, e argue against direct mapping of complex data categories to data properties and in favour of modelling data categories as annotation properties, 
In a specific (OWL 2) application the relation with the data categories can be expressed as \code{owl:equivalentClass} for classes, \code{owl:equivalentProperty} for properties or \code{owl:sameAs} for individuals:

\begin{example3} 
\#myPOS & owl:equivalentClass & isocat:DC-1345. \\
\#myPOS & owl:equivalentProperty & isocat:DC-1345. \\
\#myNoun & owl:sameAs & isocat:DC-1333. \\
\end{example3}
 
\end{comment}

\subsection{RELcat - Ontological relations}
As described in \ref{CMDI}, relations between data categories are not stored directly in the \xne{ISOcat} DCR, but rather in a dedicated module the Relation Registry \xne{RELcat}. The relations here are grouped into relation sets and stored as RDF triples\cite{SchuurmanWindhouwer2011}. 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}

\commentx{Menzo: I would use owl:sameAs rdfs:subPropertyOf rel:sameAs. I see the rel:* properties as an upper layer of a taxonony of relation types. The RELcat types are loose and the OWL ones specific, hence the subtyping. In RELcat you might also query multiple graphs with multiple vocabularies various 'same-as' properties then still need to be distinguishable but the general rel:sameAs need to be created.}

\commentx{Matej: strip this stipulations - rest of the subsection or just short referrer to SPIN rules ?}
\begin{comment}
Is this correct:
?? That means, that to be able to infer that a value in a CMD element also pertains to a given data category, e.g.:

\begin{example2}
 cmd:PublicationYear = 2012 $\rightarrow$ & dc:created = 2012 
\end{example2}

\commentx{Menzo: yes. I do have some of the SPIN rules somewhere to generate those. My idea is that one takes a dcr:datcat annotated graph. This can be using OWL or SKOS or any other RDF vocabulary. This base graph should have been expanded depending on the reasoning one uses, i.e., all entailments are in place. The dcr:datcat can then be translated into rel:sameAs and all equivalences get expanded, so one can also query using ISOcat DCs.}

\noindent
following facts need to be present in the ontology :

\begin{example3}
<lr1> & cmd:PublicationYear & 2012\^{}\^{}xs:year \\
cmd:PublicationYear &  owl:equivalentProperty & isocat:DC-2538 \\
isocat:DC-2538 & rel:sameAs & dc:created \\
owl:sameAs & rdfs:subPropertyOf &  rel:sameAs \\
$\rightarrow$ \\
<lr1> & dc:created & 2012\^{}\^{}xs:year \\
\end{example3}
\end{comment}


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

\subsubsection {Resource Identifier}

\commentx{Matej: I still yearn for something like cmdm:Resource and cmdm:MDRecord}
\begin{example3}
<lr1> & a  & cmdm:Resource; \\
<lr1.cmd> & a & cmdm:MDRecord;
\end{example3}

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, 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\#Motivations}.
(Note also, that one MD record can describe multiple resources, this can be also easily accommodated in OpenAnnotation:

\commentx{Menzo: also there can be multiple resource proxies. Maybe we can use an RDF list?} 

\begin{example3}
\_:anno1  & a & oa:Annotation ; \\
 & oa:hasTarget  & <lr1a>, <lr1b> ; \\
 & oa:hasBody  & <lr1.cmd> ; \\
 & oa:motivatedBy  & oa:describing . \\
\end{example3}

\subsubsection{Provenance}

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

\begin{example3}
<lr1.cmd> & dcterms:identifier  & <lr1.cmd> ;  \\
 & dcterms:creator  & \var{\{cmd:MdCreator\}} ;  \\
 & dcterms:publisher  & <http://clarin.eu> ; \\
 & dcterms:created & \var{\{cmd:MdCreated\}} .  \\
\end{example3}

\subsubsection{Hierarchy ( Resource Proxy – IsPartOf)}
In CMD, the \code{cmd:ResourceProxyList} structure is used to express both collection hierarchy and point to resource(s) described by the MD record. This can be modelled as \xne{OAI-ORE Aggregation}\furl{http://www.openarchives.org/ore/1.0/primer\#Foundations}
:

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

\commentx{Matej: Should both collection hierarchy and resource-pointers (collection and resource MD records) be encoded as ore:Aggregation?}

\begin{comment}
This is rather complicated: skip this?:
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 . \\
?? <lr1> ? & cmd:contains & \_:actor1 . \\
?? <lr1.cmd> ? & cmd:contains & \_:actor1 . \\
\end{example3}

\subsection{Elements, Fields, Values}
Finally, we want to integrate also the actual field values in the CMD records into the ontology.
As explained before, CMD elements have to be typed as \code{rdfs:Class}, the actual value expressed as \code{cmds:ElementValue} property and the corresponding data category expressed as annotation property.

While generating triples with literal values seems straightforward, the more challenging but also more valuable aspect is to generate object property triples with the literal values mapped to semantic entities. Following example show the whole chain of statements from metamodel to literal value. The mapping process is detailed in \ref{sec:values2entities}.

\begin{example3}
cmd:Person & a & cmdm:Component . \\
cmd:Person.Organisation & a &  cmdm:Element . \\
cmd:hasOrganisationElementValue  \\
& rdfs:subProperyOf & cmdm:hasElementValue ; \\
        & rdfs:domain & cmd:Organisation ; \\
        & rdfs:range & xs:string . \\ 
cmd:hasOrganisationElementEntity \\
        & rdfs:subProperyOf & cmdm:hasElementEntity ; \\
        & rdfs:domain & cmd:Organisation ; \\
        & rdfs:range & cmd:OrganisationElementEntity .\\
\\
\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:hasOrganisationElementValue \quad 'MPI'\^{}\^{}xs:string ;} \\
        & \multicolumn{2}{l}{ cmd:hasOrganisationElementEntity  \quad <http://mpi.nl> . }\\

<http://mpi.nl> & a  & cmd:OrganisationElementEnity . 
\end{example3}

\begin{comment}
\begin{example3}
cmd:timeCoverage  & a   & cmds:Element \\
cmd:timeCoverageValue & a & cmds:ElementValue \\
cmd:timeCoverage  & dcr:datcat  & isocat:DC-2502 \\
<lr1> & cmd:contains & \_:timeCoverage1 \\
\_:timeCoverage1 & a & cmd:timeCoverage \\
\_:timeCoverage1 & cmd:timeCoverageValue & "19th century" \\
\end{example3}

\commentx{Menzo: no need to repeat dcr:datcat in the instance.}

\begin{example3}
\var{cmds:Element} & \var{cmds:ElementValue\_?} & \var{xsd:anyURI}\\
\_:organisation1 & cmd:OrganisationValue\_? & <org1> \\
\end{example3}

\begin{notex}
Don't we need a separate property (predicate) for the triples with object properties pointing to entities, 
i.e. \code{cmd:Organisation\_} additionally to \code{cmd:Organisation} 
\end{notex}
\end{comment}


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

\commentx{this is probably definitely too much for one abstract  - so we could just anounce the need for this mapping process.}

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. It involves following steps:

\begin{enumerate}
\item identify appropriate controlled vocabulares 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''.

The transformation of the data has been partly described in previous section. It can be trivially automatically converted into RDF triples as :

\begin{example3}
\_:organisation1 & \multicolumn{2}{l}{cmd:hasOrganisationElementValue \quad 'MPI'\^{}\^{}xs:string ;} \\
\end{example3}

However for the needs of the mapping task we propose to reduce and rewrite to retrieve distinct concept-value pairs:

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

\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{Lookup}

In abstract term, 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. 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 ( \ Concept \ | \ Entity \ )*
\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 \


%\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 different 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.

\section{Implementation}

The transformation of profiles and instances into RDF/XML is accomplished by a set of XSL-stylesheets.
Once the data is available it has to be stored and published in a RDF triple store. The most promising solution seems to be \xne{Virtuoso}, a 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{Conclusions and Future Work}
In this paper, we proposed an encoding of the whole of the CMD data domain in RDF, with special focus on the core model the general component schema. Additionally, some technical considerations were discussed regarding exposing this dataset as Linked Open Data and the implications for real semantic ontology-based data exploration. 
In the near future, a test with the whole CMD dataset will be performed.
And work on mapping values to entities.

With this new enhanced dataset, the groundwork is laid for the full-blown semantic search as proposed in the original goals, i.e. the possibility of exploring the dataset using external semantic resources.
The user can access the data indirectly by browsing external vocabularies/taxonomies, with which the data will be linked like vocabularies of organizations or taxonomies of resource types.



\bibliographystyle{splncs}
\bibliography{CMD2RDF}

\end{document}