Changeset 3665 for SMC4LRT/chapters/Design_SMCinstance.tex

Timestamp:

10/02/13 19:52:31 (11 years ago)

Author:

vronk

Message:

rework of Results, Definitions, appendix, added Conclusion,
smaller changes to Design, Data

File:

• SMC4LRT/chapters/Design_SMCinstance.tex (modified) (4 diffs)

SMC4LRT/chapters/Design_SMCinstance.tex

@@ -1 @@
-\chapter{Mapping on instance level, CMD as LOD}
+\chapter{Mapping on instance level,\\ CMD as LOD}
 \label{ch:design-instance}
 
@@ -15 +15 @@
 \end{quotation}
 
-As described in previous chapters (\ref{ch:infrastructure},\ref{ch:design_schema}), semantic interoperability is one of the main motivations for the CMD infrastructure. However, this machinery pertains mostly to the schema level, the actual values in the fields of CMD instances reman ``just strings''. This is the case even though the problem of different labels for semantically equivalent or even identical entities is even more so virulent on the instance level. While for a number of metadata fields the value domain can be enforced through schema validation, some important fields (like \concept{organization} or \concept{resource type})  have a constrained value domain that yet cannot be explicitly exhaustively enumerated. This leads to a chronically inconsistent use of labels for referring to entities (as the instance data shows, some organizations are referred to by more than 20 different labels, or spelling variants.) prompting an urgent need for better means for harmonizing the constrained-field values. 
+As described in previous chapters (\ref{ch:infra},\ref{ch:design}), semantic interoperability is one of the main motivations for the CMD infrastructure. However, the established machinery pertains mostly to the schema level, the actual values in the fields of CMD instances remain ``just strings''. This is the case even though the problem of different labels for semantically equivalent or even identical entities is even more so virulent on the instance level. While for a number of metadata fields the value domain can be enforced through schema validation, some important fields (like \concept{organization} or \concept{resource type})  have a constrained value domain that yet cannot be explicitly exhaustively enumerated. This leads to a chronically inconsistent use of labels for referring to entities (as the instance data shows, some organizations are referred to by more than 20 different labels, or spelling variants.) prompting an urgent need for better means for harmonizing the constrained-field values. 
 
 One potential remedy is the use of reference datasets -- controlled vocabularies, taxonomies, ontologies and such. In fact, this is a very common approach, be it the authority files in libraries world, or domain-specific reference vocabularies maintained by practically every research community. Not as strict as schema definitions, they cannot be used for validation, but still help to harmonize the data, by offering preferred labels and identifiers for entities.
@@ -312 +312 @@
 \end{figure*}
 
-\subsubsection{Identify vocabularies  – CLAVAS}
+\subsubsection{Identify vocabularies}
 
 \todoin{Identify related ontologies, vocabularies? - see DARIAH:CV}
@@ -403 +403 @@
 \label{semantic-search}
 
-With the new enhanced dataset, as detailed in section \ref{ch:cmd2rdf}, the groundwork is laid for the full-blown semantic search as proposed in the original goals, i.e. the possibility for ontology-driven or at least `semantic resources assisted' exploration of the dataset.
+With the new enhanced dataset, as detailed in section \ref{sec:cmd2rdf}, the groundwork is laid for the full-blown semantic search as proposed in the original goals, i.e. the possibility for ontology-driven or at least `semantic resources assisted' exploration of the dataset.
 
 Namely to enhance it by employing ontological resources.