| 18 | | 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 [[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]). |
| | 18 | 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]). |
| 682 | | The transformation `MAY` make use of embedded component identifiers in the CMD component definition to derive (complex) types that can be reused throughout the schema definition. |
| 683 | | |
| 684 | | The schema `MUST` declare a profile specific payload namespace in addition to the fixed, global namespaces that are used (in particular `cmd` and `cue`). This namespace, with `RECOMMENDED` prefix `cmdp`, `MUST` have the following format: `http://www.clarin.eu/cmd/1/profiles/{profileId}`, where `{profileId}` refers to the identifier of the profile from which the schema is derived in the Component Registry. All XML elements and XML attributes derived from CMD components, CMD elements and CMD attributes `MUST` be declared in this namespace. |
| | 682 | The transformation `MAY` make use of component references in the CMD component definition to derive (complex) types that can be reused throughout the schema definition. |
| | 683 | |
| | 684 | The schema `MUST` declare a profile specific payload namespace in addition to the fixed, global namespaces that are used (in particular `cmd` and `cue`). This namespace, with `RECOMMENDED` prefix `cmdp`, `MUST` have the following format: `http://www.clarin.eu/cmd/1/profiles/{profileId}`, where `{profileId}` refers to the identifier of the profile from which the schema is derived in a Component Registry. All XML elements and XML attributes derived from CMD components, CMD elements `MUST` be qualified and declared in this namespace. XML attributes derived from CMD attributes follow the convention that unprefixed attributes belong to their elements, which do belong to the profile specific payload namespace. |
| 751 | | If a CMD element or CMD attribute in the CCSL has a `@ValueScheme` XML attribute, its value `MUST` be interpreted as the name of the XML Schema Datatype (declared in the `@type` attribute of the XML element or attribute declaration in XML Schema) that defines the allowed value range of the XML element/attribute derived from the CMD element/attribute. |
| 752 | | |
| 753 | | '''Otherwise''', if a CMD element or CMD attribute in the CCSL has a descendant XML element `<ValueScheme>` that contains an XML element `<pattern>`, then its text value `MUST` be interpreted as the XML Schema Regular Expressions that defines the allowed value range of the XML element/attribute derived from this CMD element/attribute. |
| 754 | | |
| 755 | | '''Otherwise''', if a CMD element or CMD attribute in the CCSL has a descendant XML element `<ValueScheme>` that contains an XML element `<Vocabulary>`: |
| 756 | | * The XML attribute `@URI` of the XML element `<Vocabulary>`, if present, `SHOULD` be transformed into an attribute `cmd:Vocabulary` of the same value on the XML element or attribute declaration in the schema. |
| | 751 | If a CMD element or CMD attribute in the CCSL has a `@ValueScheme` XML attribute, its value `MUST` be interpreted as the name of the XML Schema datatype (declared in the `@type` attribute of the XML element or attribute declaration in XML Schema) that defines the allowed value range of the XML element/attribute derived from the CMD element/attribute. |
| | 752 | |
| | 753 | ''Otherwise'', if a CMD element or CMD attribute in the CCSL has a descendant XML element `<ValueScheme>` that contains an XML element `<pattern>`, then its text value `MUST` be interpreted as the XML Schema Regular Expressions that defines the allowed value range of the XML element/attribute derived from this CMD element/attribute. |
| | 754 | |
| | 755 | ''Otherwise'', if a CMD element or CMD attribute in the CCSL has a descendant XML element `<ValueScheme>` that contains an XML element `<Vocabulary>`: |
| | 756 | * The XML attribute `@URI` of the XML element `<Vocabulary>`, if present, `SHOULD` be transformed into an attribute `cmd:Vocabulary` of the same value on the XML element or attribute declaration in the schema. The XML element declaration should always allow a `@cmd:ValueConceptLink` to retain a link to a specific vocabulary entry. |
