Closed GeertThijs closed 6 years ago
Contra:
Modelleringsregel: attributen voor datatypes, associaties voor klassen. Hoewel toegelaten in UML om ook een attribuut te maken voor een verwijzing naar een klasse kiezen we ervoor om dit niet te doen. Zie ook https://bellekens.com/2011/08/10/uml-best-practice-attribute-or-association/.
Is niet platformonafhankelijk maar ingegeven door implementatie in RDF waar een enumeratiewaarde een skos:Concept wordt wat een klasse is. In RDF is alles een klasse, vandaar. Of een codelijst nu wordt voorgesteld dmv een enumeratie of niet maakt voor vocabularia niets uit, sowieso wordt een enumeratiewaarde op skos:Concept gemapt.
In andere modellen modelleren we codelijsten als enumeratie = modelleringsregel. Dat de enumeratie ook een taxonomie of thesaurus kan zijn doet daarbij niet terzake. De codelijst zelf wordt uiteindelijk toch niet beschreven in het UML-diagram maar daarbuiten dmv skos:Concept.
Pro:
Conclusie: we zetten Code en ook de andere genoemde codelijsten om in enumeraties.
Dag Geert,
Waarschijnlijk heb je hierover gediscussieerd in een werkgroep. Maar ik begrijp niet wat het verschil is tussen een enumeratie en codelijst? Gaat deze beslissing enkel over terminologie?
mvg,
Bert
Met codelijst bedoelen we bij OSLO een lijst waaruit kan of moet gekozen worden om een attribuut een waarde te geven. De codelijst kan verschillende vormen aannemen: lijst, lijst met synoniemen, taxonomie, thesaurus, ontologie (zie ook https://www.slideshare.net/TriviumRLG/from-taxonomies-to-ontologies?next_slideshow=1). Maar in een UML klassediagram heb je enkel enumeratie als mogelijkheid om een codelijst aan te geven. LBLOD echter heeft enumeraties gewoon geschrapt en de waarde zelf ipv de codelijst gemodelleerd, vandaar Code als datatype. Waarbij Code mapt op skos:Concept. Probleem is dat 1) wie het UML diagram bekijkt zo niet weet dat het eigenlijk om een waarden uit een codelijst gaat en 2) een modelleringsregel is dat we associeren met klassen en ze niet als datatype ve attribuut gebruiken (zie ook https://bellekens.com/2011/08/10/uml-best-practice-attribute-or-association/). Daarom heb ik van Code in LBLOD alsnog een enumeratie gemaakt, generiek bruikbaar ook voor wie geen naam voor zijn codelijst kan bedenken, gewoon dus om aan te geven dat het een waarde uit een codelijst betreft.
Verder moet ik toegeven dat het feit dat we dit een codelijst noemen historisch gegroeid is. Stamt uit het tijdperk dat INSPIRE het grote standaardisatievoorbeeld was. Zij waren niet tevreden met Enumeration omdat ze een uitbreidbare lijst wilden en (ik heb dat nooit gechecked) enumeraties zijn niet uitbreidbaar, je kan er geen waarden aan toe voegen indien nodig. En dus vond INSPIRE het nodig om een Codelist in te voeren, een uitbreidbare enumeratie ahw. Zit in het INSPIRE UML-profiel. Is achterliggend een Class overigens, terwijl Enumeration volgens UML een specialisatie is van Datatype. Wat dan weer beter klopt met de hierboven genoemde modelleringsregel.
Voor codelijsten verwijst LBLOD naar klassen ipv naar enumeraties: