Changes between Version 231 and Version 232 of CMDI 1.2/Specification


Ignore:
Timestamp:
10/04/16 08:42:47 (8 years ago)
Author:
Twan Goosen
Comment:

Transferred change in intro, glossary

Legend:

Unmodified
Added
Removed
Modified

  • CMDI 1.2/Specification

    v231 v232  
    33}}}
    44
    5 {{{#!div class="notice system-message"
     5{{{#!comment
     6#!div class="notice system-message"
    67This document ([[.@231|revision 231]]) is currently under review at [https://docs.google.com/document/d/1pMc1wUuXTX180nR8WNJJ_5plLyJ60x_Oy1uGd6Ba-wE/edit?usp=sharing]
    78}}}
    … …  
    1415'''Version 1.2'''
    1516[Date]
    16 {{{#!comment
     17{{{#!div class="notice system-message"
    1718TODO: footnote about versioning of spec and toolkit implementation and how they relate
    1819}}}
    … …  
    2324Many researchers, from the humanities and other domains, have a strong need to study resources in close detail. Nowadays more and more of these resources are available online. To be able to find these resources, they are described with metadata. These metadata records are collected and made available via central catalogues. Often, resource providers want to include specific properties of a resource in their metadata to provide all relevant descriptions for a specific type of resource. The purpose of catalogues tends to be more generic and address a broader target audience. It is hard to strike the balance between these two ends of the spectrum with one metadata schema, and mismatches can negatively impact the quality of metadata provided. The goal of the Component Metadata Infrastructure (CMDI) is to provide a flexible mechanism to build resource specific metadata schemas out of shared components and semantics (Broeder ''et al'', [#REF_Broeder_2010 2010] and [#REF_Broeder_2012 2012]).
    2425
    25 In CMDI the metadata lifecycle starts with the need of a metadata modeller to create a dedicated metadata profile for a specific type of resources. The modeller can browse and search a registry for components and profiles that are suitable or come close to meet her requirements. A component groups together metadata elements that belong together and can potentially be reused in a different context. Components can also group other components. A component registry, e.g. the ''[#REF_COMP_REG CLARIN Component Registry]'', might already contain any number of  components. These can be reused as they are or be adapted by modifying, adding or removing some metadata elements and/or components. Also completely new components can be created to model the unique aspects of the resources under consideration. All the needed components are combined into one profile specific for the type of resources. Components, elements and values in such a profile are linked to a semantic description - a concept - to make their meaning explicit (Durco ''et al'', [#REF_Durco_2013 2013]). These semantic descriptions can be stored in a semantic registry, e.g. the ''[#REF_CCR CLARIN Concept Registry]''. In the end metadata creators can create records for specific resources that comply with the profile relevant for the resource type, and these records can be provided to local and global catalogues (Van Uytvanck ''et al'', [#REF_Uytvanck_2012 2012]).
     26In CMDI the metadata lifecycle starts with the need of a metadata modeller to create a dedicated metadata profile for a specific type of resources. The modeller can browse and search a registry for components and profiles that are suitable or come close to meeting her requirements. A component groups together metadata elements that belong together and can potentially be reused in a different context. Components can also group other components. A component registry, e.g., the ''[#REF_COMP_REG CLARIN Component Registry]'', might already contain any number of  components. These can be reused as they are or be adapted by modifying, adding or removing some metadata elements and/or components. Also completely new components can be created to model the unique aspects of the resources under consideration. All the needed components are combined into one profile specific for the type of resources. Components, elements and values in such a profile are linked to a semantic description - a concept - to make their meaning explicit (Durco ''et al'', [#REF_Durco_2013 2013]). These semantic descriptions can be stored in a semantic registry, e.g., the ''[#REF_CCR CLARIN Concept Registry]''. In the end metadata creators can create records for specific resources that comply with the profile relevant for the resource type, and these records can be provided to local and global catalogues (Van Uytvanck ''et al'', [#REF_Uytvanck_2012 2012]).
    2627
    2728=== History ===
    … …  
    5758   * A reference from a __CMD profile__, __CMD component__, __CMD element__, __CMD attribute__ or a value in a __controlled vocabulary__ to an entry in a __semantic registry__ via a URI, typically a __persistent identifier__.
    5859 * '''concept registry'''
    59    * A  __semantic registry__ maintaining __concepts__, e.g. the ''[#REF_CCR CLARIN Concept Registry]'' as used in the __CLARIN infrastructure__.
     60   * A  __semantic registry__ maintaining __concepts__, e.g., the ''[#REF_CCR CLARIN Concept Registry]'' as used in the __CLARIN infrastructure__.
    6061 * '''controlled vocabulary''', closed/open vocabulary
    6162   * A set of values that can be used either to constrain the set of permissible values or to provide suggestions for applicable values in a given context.
    … …  
    105106   * A schema definition by which the correctness of a __CMD instance__ with respect to the __CMD profile__ it pertains to can be evaluated. May be expressed as __XML Schema__ but also in other XML schema languages.
    106107 * '''CMD root component'''
    107    * '''[TODO]'''
     108   * The __CMD component__ that is defined at the highest level within a __CMD profile__ that may have one or more child __components__ but no siblings. In the __CMD instance payload__, it is instantiated exactly once.
    108109 * '''CMD specification''', component specification/definition, profile specification/definition
    109110   * The representation of a __CMD component__ or __CMD profile__, expressed using the constructs of __CCSL__.
    … …  
    180181 * `@prefix:attr` \\ An XML attribute with the name ''attr'' that is bound to an XML namespaces denoted by the prefix ''prefix''.
    181182 * `string` \\ The literal ''string'' must be used either as element content or attribute value.
    182  * `xs:{type}` \\ The XML schema type with name ''type''.
     183 * `xs:type` \\ The XML schema type with name ''type''.
    183184
    184185The following XML namespace names and prefixes are used throughout this specification. The column "Recommended Syntax" indicates which syntax variant `SHOULD` be used by the toolkit and other creators of CMDI related documents.