| 142 | | |
| 143 | | |
| 144 | | ---- |
| 145 | | |
| 146 | | '''.......................TBC..............................''' |
| 147 | | |
| 148 | | |
| 149 | | ---- |
| 150 | | |
| 151 | | |
| 152 | | == Solution description (old) == |
| | 143 | === Impact on tools === |
| | 144 | * Metadata editors must facilitate vocabularuy lookup. Arbil, as the most generic editor - should be prioritized. |
| | 145 | * Component Registry must facilitate import of vocabularies. Interface for specifying value domains for elements and Attributes must be updated. |
| | 146 | * Discovery services (VLO a.o.) could provide assistance for users through vocabularies. E.g. vocabulary-based browsing. |
| | 147 | |
| | 148 | === Comments/concerns === |
| | 149 | 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''. |
| | 150 | |
| | 151 | ==== Avoiding multiplication of large vocabularies in CR ==== |
| | 152 | 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 |
| | 153 | 1. to consider which vocabularies are likely to be relevant in many profiles |
| | 154 | 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. |
| | 155 | * 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. |
| | 156 | |
| | 157 | ==== Importing partial vocabularies hampers reuse ==== |
| | 158 | 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 languages, event though the component otherwise might be perfectly suitable. |
| | 159 | |
| | 160 | |
| | 161 | == Solution description (old) == and autocompletion |
