Changeset 4833 for CMDI-Interoperability

Timestamp:

03/28/14 09:39:11 (10 years ago)

Author:

Menzo Windhouwer

Message:

M 2014-LREC/CMD2RDF.bib

• added Thorsten's paper

M 2014-LREC/CMD2RDF.tex

• fixed some minor issues
• replace <lr0.agg> by _:agg0
• extended section 5

Location:

CMDI-Interoperability/CMD2RDF/trunk/docs/papers/2014-LREC

Files:

• CMD2RDF.bib (modified) (1 diff)
• CMD2RDF.tex (modified) (12 diffs)

CMDI-Interoperability/CMD2RDF/trunk/docs/papers/2014-LREC/CMD2RDF.bib

@@ -619 +619 @@
 }
 
+@incollection{Zinn+2012,
+year={2012},
+isbn={978-3-642-30283-1},
+booktitle={The Semantic Web: Research and Applications},
+volume={7295},
+series={Lecture Notes in Computer Science},
+editor={Simperl, Elena and Cimiano, Philipp and Polleres, Axel and Corcho, Oscar and Presutti, Valentina},
+doi={10.1007/978-3-642-30284-8_26},
+title={The ISOcat Registry Reloaded},
+url={http://dx.doi.org/10.1007/978-3-642-30284-8_26},
+publisher={Springer Berlin Heidelberg},
+author={Zinn, Claus and Hoppermann, Christina and Trippel, Thorsten},
+pages={285-299}
+}
+
 @comment{jabref-meta: selector_publisher:}
 

CMDI-Interoperability/CMD2RDF/trunk/docs/papers/2014-LREC/CMD2RDF.tex

@@ -72 +72 @@
 
 \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}}
+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, component metadata}}
 
 %
@@ -107 +107 @@
 
 \subsubsection{CMD Profiles }
-Currently 146 public profiles and 857 components are defined in the CR.
+Currently\footnote{All numbers are as of 2014-03.} 153 public profiles and 859 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 
+The individual profiles also differ 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) 
@@ -119 +119 @@
 
 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. 
+regularly collects records from the -- currently 56 -- providers, all in all over 600.000 records. 
+Some 20 of the providers offer CMDI records, the rest provides around 44.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.
+Some of the 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.
 
@@ -138 +138 @@
 \subsection{CMD specification}\label{sec:CMDM}
 
-The main entity of the meta model is the CMD component modelled as a \code{rdfs:Class} (see Figure \ref{fig:CMDM-RDF}). 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{Although the encoding has been done, 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}.
+The main entity of the meta model is the CMD component modelled as a \code{rdfs:Class} (see Figure \ref{fig:CMDM-RDF}). 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, i.e., attributes,\footnote{Although the modelling work has been done, due to space considerations, we will not further discuss attributes.} it too has to be expressed as a \code{rdfs:Class}. The actual literal value is a property of given element of type \code{cmdm:hasElementValue}. 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*}
@@ -192 +192 @@
 \subsection{CMD profile and component definitions}
 These 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:}})
+For stand-alone components, the IRI is the (future) path into the CR to get the RDFS 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}
@@ -204 +204 @@
 
 \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}.
+The primary concept registry in use by CMDI is ISOcat. The recommended approach to link to the data categories is via an annotation property \cite{Windhouwer2012_LDL}.
 
 \begin{example2}
@@ -221 +221 @@
 \end{example2}
 
+Lateron, this information can be used, e.g., in combination with ontological relationships for these data categories available in the RELcat Relation Registry \cite{WINDHOUWER12.954}, to map to other vocabularies.
+
 %\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.}
@@ -289 +291 @@
 \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 ; \\
+\textless lr0.cmd\textgreater & ore:describes & \_:agg0 . \\
+\_:agg0 & a   & ore:Aggregation ; \\
 & ore:aggregates  & \textless lr1.cmd\textgreater, \textless lr2.cmd\textgreater . \\
 \end{example3}
@@ -308 +310 @@
         
 \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:
+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}
@@ -359 +361 @@
 
 \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.
+Finally, we want to integrate also the actual fvalues 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{cmdm: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. 
@@ -442 +444 @@
 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
+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. Within CMDI the SKOS-based vocabulary service CLAVAS,\furl{https://openskos.meertens.knaw.nl/} which will be supported in the upcoming new version of CMDI, can be used as a starting point, e.g., for organisations. 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.\furl{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}.
@@ -452 +452 @@
 but also to domain-specific semantic resource like the ontology for language technology \xne{LT-World} \cite{Joerg2010} developed at DFKI.
 
+Next to entities also predicates can be shared across datasets. The CMD Infrastructure already provides facilities in the form of ISOcat and RELcat. RELcat, for example, has already sets to relate data categories to Dublin Core terms. This can be extended with the ontology for metadata concepts described in \cite{Zinn+2012}, which does not provide common predicates but would allow to do more generic or specific searches. 
+
 \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.