aidig
commented
3 years ago Kommentarer modtaget fra KL ifm. den offentlige kommentering af DCAT-AP-DK 2.0
Kommenteringsskema Dokumentet/dokumenter der kommenteres på: DCAT-AP-DK 2.0: Dansk anvendelsesprofil til beskrivelse af datasæt og datakataloger (UDKAST) Organisationen der kommenterer: KL
Kommentarer: 1.4 De anvendte usecases i dokumentet beskriver de forskellige organisatoriske scenarier hvor datakataloger kan være relevante. Det er godt at det er medtaget i dokumentet da det er vigtigt at få synliggjort de brede anvendelsesmuligheder der knytter sig til datakataloger. Der kunne med fordel også udfoldes yderligere omkring hvad selve anvendelsen (usecases) omfatter, altså hvordan kataloger anvendes, til hvad, hvornår o.l. I den sammenhæng kan førnævnte usecases evt. sondre mellem de forskellige organisatoriske scenarier såfremt der eksisterer forskellige anvendelser af katalogerne. Designvalg af egenskaber for et datakatalog knytter sig særligt til de aktuelle usecases. Usecasen med det fælles-/tværoffentlige scenarie må umiddelbart være det primære scenarie for denne profilering og de valgte kravniveauer bør derfor læses i den sammenhæng. Sammenhæng mellem usecases, organisatoriske scenarier og kravniveauer kan med fordel tydeliggøres yderligere i dokumentet.
Der sættes lighed mellem datatjeneste og API under ”Adgang til data”. I praksis er det tvivlsomt om der er tale om synonymer for det samme. Det er det eneste sted at begrebet ”API” anvendes.
1.5 KL anbefaler at der indgår en UML visualisering af minimumsmodellen – se i øvrigt eksisterende issue.
Distribution indgår ikke i minimumsmodellen, men er medtaget i overbliksmodellen. Det kan forvirre læseren.
4.4 Det bør overvejes om begrebet "datarepræsentation" kan træde i stedet for "distribution". "Datarepræsentation" er tættere på definitionen under pkt. 4.4.
Afsender: KL
Vi oplever i flere sammenhænge at der efterspørges standarder der ikke er alt for åbne. Standarder må gerne fokusere og ”stramme” til i forhold til hvordan de skal anvendes - rummet for fortolkning skal indsnævres. Endvidere efterspørges der få-, men udvalgte metadata. Dette udkast giver i nuværende form både en lang række muligheder jf. eu-profilen, men dertil også en række tilføjelser jf. de danske behov. Samlet set bliver mængden af metadata relativ stor. Der er i sagens natur et behov for at kunne modtage og forstå datasæt fra øvrige lande hvilket gør hele eu-profilen relevant. Her kunne det dog være hensigtsmæssigt at fremhæve de centrale (obligatoriske/anbefalede) dele af dk-modellen og lade øvrige elementer træde mere i baggrunden. Eventuelt kunne der udarbejdes en mere anvendelsesnær model som den primære model for at lette formidlingen.
En af de helt centrale problemstillinger, som allerede er i proces, omhandler definitionen af begrebet Datasæt. Som det fremgår i det nuværende materiale er det uklart på hvilket niveau et datasæt skal forstås, fx meta, logisk, fysisk. Det er i den sammenhæng også uvist hvordan det er relateret til øvrige beskrivelsesmodeller af data. I modelreglerne er hele livscyklus fra begreber til fysiske data illustreret i en række modeller der er indbyrdes forbundne. De nuværende modelregler fokuserer særligt på de forretningsmæssige modeller og i mindre grad på beskrivelser af de fysiske data. I dette arbejde med datasæt samt i standarden for it-system bliver nogle af de mere implementeringsnære beskrivelser foldet mere ud. Som en del af introduktionen i dette udkast, kunne der med fordel være et afsnit der illustrerer og beskriver hvordan sammenhængen er til de øvrige modeller.
Derudover kunne man evt. understøtte en sporbarhed til øvrige modeller (objekter, begreber, attributter) i selve metadata/data for datasættet. Altså hvordan dokumenterer man hvor metadata/data fra datasættet kommer fra – kilde.
UML-modellen gør ikke brug af blå objekter hvilket gør det sværere at orientere sig i hvad der er centralt, nyt og genstand for standardisering og vedligeholdelse samt hvad der er genbrug fra andre (kerne)modeller.
Aktør er en abstrakt klasse i den fælleskommunale rammearkitektur og vi læser ligeledes Aktør i denne model som abstrakt. I den fælleskommunale rammearkitektur indeholder Aktørmodellen dog også en række konkrete aktører som Organisation, Virksomhed, Person mv. Pointen er at det giver god mening at anvende aktør som abstrakt klasse i relation til Datasæt da der eksisterer en række forskellige roller som kan adressere forskellige aktørtyper. Dog er det uklart hvilke konkrete aktørtyper der er tale om i dette udkast. I standarden for it-system, er rolle/relationer udført med brug af de konkrete aktørtyper. Dette resulterer i en model med flere gentagne roller/relationer der i en anvendelse kun kan optræde enten som den ene eller den anden aktørtype. Modelteknisk kunne disse problemstillinger med fordel løses ensartet på tværs modeller/standarder.