Changes between Version 6 and Version 7 of CmdiClavasIntegration

Timestamp:

05/22/13 15:12:40 (11 years ago)

Author:

twagoo

Comment:

subsections for specification in cmdi instances: open/closed

CmdiClavasIntegration

@@ -5 +5 @@
 <h3>Contents</h3>
 }}}
-[[PageOutline(1-4, , inline)]]
+[[PageOutline(1-5, , inline)]]
 
 == Introduction ==
@@ -39 +39 @@
 ==== Specifying vocabularies in CMDI instances ====
 
-Each concept within a vocabulary is identified by an OpenSKOS specific URI and optionally has a reference to a 'source' URI (e.g. ISOCat). For fields that link to vocabularies as '''open vocabularies''', we want to store one of these URIs as an attribute in CMDI metadata '''instances''', e.g.:
+===== Open vocabularies =====
+
+Each concept within a vocabulary is identified by an OpenSKOS specific URI and optionally has a reference to a 'source' URI (e.g. ISOCat). For fields that link to vocabularies as open vocabularies, we want to store one of these URIs as an attribute in CMDI metadata '''instances''', e.g.:
 
 {{{
@@ -52 +54 @@
 The value that serves as the text content should come from one of the child elements of the concept definition. Typically this will be the preferred label as specified in the vocabulary item returned from the API but it could also come from another element (e.g. a notation element that has a language code). Which path to use should be determined in the component specification (possibly part of the vocabulary URI).
 
-'''Closed vocabularies''' will be no different from standard CMDI closed vocabularies on the instance level. All required information will be available from the schema (see below).
+
+===== Closed vocabularies =====
+
+Closed vocabularies will be no different from standard CMDI closed vocabularies on the instance level. All required information will be available from the schema (see below).
 
 ==== Specifying vocabularies in CMDI component specifications ====