| 53 | | === Comments/concerns === |
| 54 | | The proposed solution allows abuse to a certain degree, and it is vital to describe and motivate for good practices before bad practice proliferates. The main concern is connected to the possibility for ''importing vocabularies as controlled value ranges for CMD_Element and Attribute''. |
| 55 | | |
| 56 | | ==== Avoiding multiplication of large vocabularies in CR ==== |
| 57 | | Since imported vocabularies are to be part of elements, and elements are not reusable, great care must be taken so that large enumeration lists are not duplicated across components. One way of achieving this is |
| 58 | | 1. to consider which vocabularies are likely to be relevant ''as a closed vocabulary'' in many profiles |
| 59 | | 2. for each concept property that is relevant as !ValueProperty for some element in CR, define a component in CR containing one element only and import the property values of the vocabulary concepts as its closed value domain. |
| 60 | | * Example: The component [http://catalog.clarin.eu/ds/ComponentRegistry?item=clarin.eu:cr1:c_1271859438110 iso-language-639-3] contains one element only - iso-639-3-code - taking values from a controlled vocabulary of language codes. (With the proposed 1.2 model, and given the CLAVAS vocabulary of langauges, !ValueProperty would have been set to "notation"). Some modelers may prefer to store the ''language names'' instead of or in addition to ''codes''. To make sure this can be reused independently of language codes, another component containing a language name element (with !ValueProperty=prefLabel) should be defined. |
| 61 | | |
| 62 | | Note: If the same effect is to be obtained for Attributes, they also will have to be wrapped separately in a component. |
| 63 | | * Example: Consider the component [http://catalog.clarin.eu/ds/ComponentRegistry?item=clarin.eu:cr1:c_1349361150621 OLAC-DcmiTerms]. Here all elements have similar attributes !DcmiType with the entire value list enumerated for each occurrence. If this is to be avoided in the proposed 1.2 model, elements and attributes must be wrapped separately into components throughout. |
| 64 | | |
| 65 | | ==== Importing partial vocabularies hampers reuse ==== |
| 66 | | The proposed model does not force the modeller to import entire vocabularies only, - it is possible to import only subsets from a larger vocabulary. For example, in a specific ''language'' element, the component creator may choose to import only the languages relevant in his/her user community. Such practice should be discouraged, as it renders the component unusable for anyone who needs access to more/other languages, event though the component otherwise might be perfectly suitable. |
| 67 | | |
| 68 | | Not supporting partial imports while retaining the external vocabulary reference in the Component Registry should however drastically limit the number of such occurrences. |
| 69 | | |
| 70 | | |
