| | 182 | Oddrun: Some issues: |
| | 183 | |
| | 184 | '''SKOS or SKOS++?''' |
| | 185 | I find the above a bit confusing. According to my understanding, OpenSKOS provides APIs specifically to SKOS, and I take this to mean that the vocabularies we are trying to integrate with CMDI are all represented in SKOS. As you know, SKOS (plain version) has 3 types of labels, prefLabel, altLabel and hiddenLabel. Still, in the above examples additional label elements seem to be anticipated, like "name" and "organisation-name". So apparently, openSKOS.org allows for richer descriptions than SKOS? Does openSKOS.org have preferances for other ontologies, like FOAF, for instance? |
| | 186 | |
| | 187 | '''Open vs. closed vocabularies''' |
| | 188 | As far as I understand, whether a vocabulary is open or closed represents - in this context at least - merely a ''mode of application'',- it is not a feature of the vocabulary as such. Maybe I am missing something, but I fail to see the sense in treating open and closed vocabularies differently in the way proposed here. More specifically. I question the wisdom of snapshotting (possibly huge) vocabularies into the components and profiles. After all, the vocabularies are not static, and how do we make sure that the vocabulary copies are kept updated? My guess is that this - after a time - will result in as many vocabulary variants as there are components using it. So why not referring to closed vocabularies the same ways as open? The we probably need to encode in another way whether the vocabulary is to be used in a closed or open way. |
| | 189 | Another thing: Would it be useful to be able to select from a ''union of vocabularies'', instead of just one? True, such a need could be satisfied by choosing one vocabulary and declaring it open. But if all the additional items are to selected from another vocabulary, it would be nice to be able to say so. |
| | 190 | |
| | 191 | '''Multilingual vocabularies''' |
| | 192 | You say: "Notice that there currently is no way to represent multilingual vocabularies, so the language will have to be specified in the vocabulary URI with a fallback to the default language of the vocabulary". Do you mean "no way to represent in CMDI?" If closed vocabularies are handled "by reference", as the open ones, there is no need to represent multilinguality in CMDI components, at least in the cases where multilingual SKOS vocabularies are realised by generating one prefLabel per language, (e.g. "French"@en), retaining one single URI for the whole vocabulary. If prefLabel is to be used as default VocabValueProperty, CMDI 1.2 must be able to handle multilingual prefLabel sets from the start. |
| | 193 | |
| | 194 | |
| | 195 | |
| | 196 | |
| | 197 | |
| | 198 | |
