Standarden skal angive primære use cases

[aidig]

Afsender: KL

Standarden skal angive primære use cases. (Kravniveau er afhængig af anvendelsen)

[aidig]

Det vil bestemt gavne det videre arbejde at fastlægge og beskrive de primære forventede anvendelser af specifikationen.

a) I EU Kommissionens titel "DCAT-AP" ligger der jo allerede en del betydning ("DCAT Application Profile for data portals in Europe") og den danske profil - DCAT-AP-DK - lyder vel noget i retningen af "Anvendelsesprofil til beskrivelse af datakataloger i Danmark".

Altså vil anvendelsesprofilen kunne danne rammen for et nationalt datasætkatalog, men jo i princippet også myndighedsspecifikke/domænespecifikke datasætkataloger.

Hvad tænker I om disse to anvendelser?

b) DCAT blev født ud fra et behov om udstilling af metadata om åbne data på nettet, men anvendelsen er ikke begrænset til denne brug. I DCAT beskrives det således: "Deling af dataressourcer mellem forskellige myndigheder, virksomheder, forskere og borgere kræver tilvejebringelsen af metadata. Dette er uanset om dataene er åbne eller ej. DCAT er et RDF-vokabular til udstilling af datakataloger på nettet, som oprindeligt blev udviklet i forbindelse med nationale dataportaler såsom det amerikanske data.gov og og det britiske data.gov.uk, men det er også anvendeligt og er blevet brugt i andre sammenhænge". Derfor vil man også kunne anvende DCAT til myndighedsinterne datasætoversigter eller -kataloger.

Hvad tænker I om denne anvendelse?

[heidivanparys]

Jeg er enig i, at de primære use cases skal angives. Evt. også hvad man ikke vil bruge DCAT-AP-DK til. Se fx SEMICeu/DCAT-AP#123 og w3c/dxwg#1221.

[aidig]

Afsender: Kombit

Ad a)

KOMBIT/KDI vedligeholder pt. et datasætkatalog ved anvendelse af den oprindelige DCAT-standard. Dette er gjort af interne hensyn for at kunne holde styr på en myriade af forskellige registreringer af referencedata og metadata, og ikke mindst hvordan de forskellige referencedatasæt leverer data til hinanden i kæder. Der har været en overhængende fare for at man mistede overblikket og her har DCAT været et nyttigt rammeværk til dette arbejde. En myndighedsspecifik/domænespecifik anvendelsesprofil for den nye DCAT ligger derfor i helt naturlig forlængelse af hvad vi allerede benytter, og har sin berettigelse. Vi melder os også gerne som use case på en sådan anvendelse hvis der er behov for det.

Vores anvendelse af DCAT har bygget meget på datasættets sammenhæng med et skos:theme, således at det er dette skos:theme der definerer hvad der betragtes som en del af/ikke en del af et datasæt. Vi kalder også dette for et ”dataområde”. Derfor hænger datasætkataloget nøje sammen med KDI/KOMBITs overordnede begrebsmodellering, idet de modellerede begreber fungerer som de dataområder/skos:themes der afgrænser datasættene. Dette fungerer rigtig godt internt. Konceptet ”dataområde” er allerede veletableret i KOMBIT, og de forskellige services der tilbydes af Serviceplatformen relaterer sig til et eller flere dataområder. Og det fungerer godt så længe man har en tværgående opfattelse af hvilke dataområder/skos:themes man har i spil, og dermed hvilke datasæt der indeholder sammenlignelige data.

Hvis man ønsker at etablere et nationalt datasætkatalog, så er den helt store udfordring nok at sikre, at man bruger de samme skos:themes på tværs af de forskellige registreringer, hvis øvelsen skal give værdi. Hvis man ikke gør det, så vil man ende med en helt masse øer af datasætregistreringer, hvor der kun lokalt er konsensus om hvordan datasættene skal forstås, mens det som tværgående katalog vil være svært at bruge. Så introduktionen af en national anvendelsesprofil skal kombineres med fastlæggelse af en tværgående taksonomi der kan sætte katalogets skos:themes i system, i bedste bibliotekstradition. Det er det der vil give et nationalt katalog værdi. Det er jo en stor øvelse, men formentlig nødvendig.

Ad b)

Som sagt ovenfor er det helt relevant at anvende DCAT til interne datasætkataloger. Det er måske i virkeligheden en nemmere use case at praktisere end den store tværgående, da det er nemmere at opnå enighed om de anvendte taksonomier internt.

[aidig]

De fire use cases som indgår i hhv. a) og b) i det ovenstående har vi lavet en plads til i specifikationsdokumentet, men disse skal drøftes yderligere:

https://digst.github.io/DCAT-AP-DK/releases/v.2.0/docs/#standardens-anvendelse-og-afgrnsning

[laers]

Use case: At gøre data mere søgbare på tværs af grænser og sektorer - fordelen ved at anvende fælles standard og snitflade er, at de danske DCAT-AP metadata er tilgængelig i europæisk dataportal.

Figur fra https://www.unece.org/fileadmin/DAM/stats/documents/ece/ces/ge.58/2017/mtg3/2017-UNECE-topic-i-EC-StatDCAT-ap-paper__1_.pdf

[aidig]

Ovenstående use case er drøftet i følgegruppen og foreslås tilføjet specifikationen.

[aidig]

Følgegruppen har drøftet et genbesøg af kravniveauer ift. disse fem use cases, og at eventuelle specifikke afvigelser fra "basisprofilen" DCAT-AP-DK beskrives.

[aidig]

Se også: W3Cs Working Group Note "Dataset Exchange Use Cases and Requirements": https://www.w3.org/TR/dcat-ucr/#UseCases for baggrundsmateriale om opdateringen af DCAT.

[pebran]

Seks "use cases" - nu kaldet 'anvendelsesscenarier'' - er tilføjet specifikationen. Kan udbygges og ændres efter konkrete input fra følgegruppe.

[aidig]

Seks "use cases" - nu kaldet 'anvendelsesscenarier'' - er tilføjet specifikationen. Kan udbygges og ændres efter konkrete input fra følgegruppe.

Behandlet på følgegruppemøde og lukkes.