De fællesoffentlige regler for begrebs- og datamodellering

Indledning

De fællesoffentlige regler for begrebs- og datamodellering - i daglig tale modelreglerne - operationaliserer arkitekturregel 6.2: Anvend fælles regler for dokumentation af data fra Hvidbog om fællesoffentlig digital arkitektur.

Ved at anvende modelreglerne sikres, at begreber og data er beskrevet og dokumenteret grundigt, korrekt og ensartet. Det er en vigtig forudsætning for, at myndigheder og virksomheder kan hente, forstå og anvende data, som stammer fra andre myndigheder. Modelreglerne bygger på nationale og internationale metoder, standarder og erfaringer.

De fællesoffentlige modelregler blev udviklet under styregruppen for data og arkitektur, der var en styregruppe nedsat i regi af den fællesoffentlige digitaliseringsstrategi 2016-2020. De ejes nu af udvalget for arkitektur og standarder.

Hvorfor have fællesoffentlige modelregler?

De fællesoffentlige modelregler bidrager til bedre data og øget deling og genbrug af data på tværs af den offentlige sektor. Modelreglerne har tre helt overordnede formål:

1. At sikre at forretningsviden lægges til grund for datamodellering og udvikling
2. At sikre sammenhængende data på tværs af den offentlige administration
3. At sikre genbrug med det formål at minimere det samlede ressource- og tidsforbrug på udvikling og vedligeholdelse af it-løsninger.

Disse tre formål skal tænkes ind i hele modelleringsprocessen. Særligt i de allerførste trin er det afgørende at holde sig dem for øje. Det er nemlig i forretningsforståelsen og organiseringen af datamodellering, at de væsentligste ændringer skal opnås, for at visionen bliver til virkelighed.

De fælles modelregler skal anvendes af digitaliseringsstrategiens initiativer og anbefales anvendt i den offentlige sektor i øvrigt.

Anvendelsen af modelreglerne skal ske under hensyn til, at en sektor kan være underlagt eventuelle andre bindinger, fx internationale regler og standarder for begrebs- og datamodellering.

Baggrund

Hvad er problemet som modelreglerne er med til at afhjælpe?

Fraværet af fælles retningslinjer for udformning, deling og genbrug af begrebs- og datamodeller er lig med fraværet af et essentielt middel til at nå den fællesoffentlige digitaliseringsstrategis mål om en fælles dataarkitektur, hvor gode data deles og genbruges.

Det, at der ikke eksisterer fælles retningslinjer, kan have flere negative konsekvenser:

• Modeller udstilles, udveksles og genbruges sjældent
• Modeller er uensartede og svære at sammenstille
• Modeller forankres ikke i forretningen
• Der er ikke sammenhæng fra lovgivning til it-system

Hvad er gevinsterne ved modelreglerne?

Gevinsterne ved at anvende modelreglerne er:

• God international praksis for modellering: Modelreglerne er en samling af anerkendte og internationalt forankrede metoder til god begrebs- og datamodellering. Ved at følge modelreglerne bliver det nemmere at modellere godt.
• Begreber og data kan nemmere genbruges: Når modelreglerne anvendes, er begreber og data beskrevet mere ensartet på tværs af myndigheder, så det bliver nemmere at genbruge andre myndigheders beskrivelser af begreber og data.
• Sammenhæng fra lovgivning til it-system: Modelreglerne understøtter, at man stringent og effektivt kan komme fra lovgivningens begreber til it-systemets snitflader, hvilket øger kvalitet og effektivitet i den offentlige digitalisering.
• Fælles sprog, kompetenceudvikling og værktøjer: Ved at have fælles modelregler får modellører et fælles sprog, der fremmer samarbejde, og kompetenceudvikling og fælles værktøjer til modellering muliggøres.
• Bedre forberedt på nye muligheder med data: Mulighederne med anvendelse af data er i hastig udvikling, og det er vanskeligt at forudse, hvordan offentlige data kan anvendes i fremtiden. Ved at bruge modelreglerne holder vi døren åben til fremtiden.

Hvilke erfaringer og metoder bygger modelreglerne på?

Som det metodiske fundament anvendes internationale metoder og standarder for modellering og dataformidling. De fællesoffentlige modelregler er en videreførelse og udbygning af grunddataprogrammets modelregler, som ligeledes bygger på nationale og internationale erfaringer.

Hvad er grundideen i modelreglerne?

Grundideen er at rammesætte en sammenhæng fra lovgivning til it-systemer. Det skal med andre ord være muligt at spore et begreb fra dets definition i lovgivningen, over modelleringen til dets konkrete anvendelse i et datasæt eller et it-system, som illustreret i figuren herunder.

Hvad handler modelreglerne om?

Dette dokument sætter regler for begrebsmodeller og logiske modeller og sikrer at de er velegnede til at indgå i ovennævnte sammenhæng. Der er udarbejdet modelregler inden for en række temaer, som skal sikre:

• at der udarbejdes begrebs- og datamodeller
• at der er sammenhæng mellem modeller på forskellige abstraktionsniveauer
• at der anvendes samme modelleringssprog
• at der er klarhed om modellers ejerskab, versionering og godkendelsesstatus
• at modeller er tilgængelige for anvendere
• at begreber og data er navngivet entydigt og meningsfyldt
• at begreber og data er defineret fyldestgørende

Disse modelregler udgør et bidrag til en fællesoffentlig dataarkitektur og et fælles sprog for modellering. De udgør et redskab for offentlige organisationers ledelse, så de kan være med til at skabe en fælles kultur for god begrebs- og datamodellering, der understøtter målsætningen om gode data og effektiv datadeling.

Der er ingen tvivl om, at denne ambitiøse målsætning vil kræve ressourcer, og at gevinsterne i høj grad høstes på den lange bane, men at tilslutte sig denne dagsorden skal ses som en strategisk og værdifuld investering i gode offentlige data.

Hvad er ambitionerne med modelreglerne

Målsætningen om sammenhæng fra lovgivning til it-systemer er ambitiøs, men denne regelsamling gør det muligt at skabe genbrugelige, sammenhængende modeller som dokumenterer forretningens anvendelse af data på en ensartet og tilgængelig måde.

Tidligere har modelreglerne været organiseret som en serie af trin, som successivt skulle gøre de resulterende modeller og deres elementer frit genbrugelige og selvbeskrivende med det formål at skabe en sømløs total-modellering af de offentlige data. Det har imidlertid vist sig formålstjenligt, at satse på at indarbejde god modelleringspraksis på en række tilgængelige områder frem for at fokusere på en ganske vidtrækkende omorganisering af gængs modelleringspraksis.

Figuren viser, hvordan forskellige egenskaber ved gode modeller trinvist kan gøre modellerne og deres elementer mere tilgængelige og genbrugelige:

En gruppe af egenskaber – så som at sørge for, at modellen er tilgængelig for andre, udtrykker sit ejerskab og sin versionering, dokumenterer forretningsforståelsen af elementerne og er forfærdiget i et ensartet visuelt sprog – tjener (grupperet under ’Formidling’) til, at modellen i det hele taget kan anvendes af andre; at andre bliver opmærksomme på eksistensen og ejerskabet af modellen og de modellerede forretningsobjekter.

En yderligere gruppe af egenskaber (grupperet under ’Genbrug’) sørger for, at modellen kan anvendes af andre idet den kan indlæses i ’fremmede’ modelleringsværktøjer, identificerer de enkelte elementer unikt og dokumenterer deres proveniens samt udstiller forretningsviden på en struktureret måde. Det er dette niveau nærværende regelsamling sigter mod.

Modeller som også besidder den sidste gruppe af egenskaber (grupperet under ’Sammenhæng’) – som altså er organiseret således, at de kan genbruge enkeltdele fra andre modeller ligesom deres enkeltdele selv kan genbruges idet de medbringer deres modelleringskontekst indlejret og således at definitioner og semantik kan gøres tilgængelig via referencer placeret i de formidlede data, hvorfor de muliggør automatisk datafortolkning – kan man læse om i kommende publikationer fra modelsekretariatet.

Modeltyper

På rejsen fra lovgivning, behov og ønsker over begrebs- og datamodellering til kørende it-systemer, kan der være forskellige tilgange til modelleringsarbejdet, hvor modellerne har forskelligt indhold i forhold til hvor de anvendes i et givet forløb. Reglerne vedrører terminologiske begrebsmodeller, informationsmodeller, klassifikationsmodeller og logiske datamodeller - det vil sige de modeller som typisk udarbejdes af forretning og modelleringsspecialister i samarbejde frem mod udviklingen af et it-system, en database eller et udvekslingsformat.

Sprogbrugen vedrørende modeltyper og deres anvendelse er forskelligartet og mangetydig. I det følgende opridses den forståelse og navngivning, som tilstræbes i dette dokument:

Terminologiske begrebsmodeller er vidensorganiserende modeller der beskriver begreber og deres indbyrdes relationer. Formålet med terminologisk begrebsmodellering er at skabe afklaring og enighed om betydningen af begreber og brugen af termer. Bemærk at det ikke nødvendigvis kun er de centrale forretningsobjekter som beskrives på denne måde, men derimod alle de begreber som det er relevant at afklare. Da terminologiske begrebsmodeller er den eneste type begrebsmodeller disse regler beskæftiger sig med vil de også blive refereret til blot som begrebsmodeller. Begrebsmodeller kan repræsenteres på listeform (begrebsliste) eller som et diagram (begrebsdiagram).

 

Informationsmodeller er vidensorganiserende modeller der beskriver forretningsviden og hvor begreber suppleres med forretningslogik. Det vil sige at der er taget stilling til hvordan de forskellige begreber udtrykkes, som fx klasser eller egenskaber, i en given forretningskontekst, samt tilføjet multipliciteter. Informationsmodeller er udarbejdet med henblik på analyse og forretningsafklaring, og kan danne det forretningsmæssige grundlag for logisk datamodellering, men er uafhængige af et eventuelt fremtidigt valg af teknologisk løsning.

 

Logiske datamodeller er datamodeller der beskriver datas logiske sammenhæng uafhængigt af datas fysiske struktur og teknisk implementering. Formålet med logiske datamodeller er at give en forståelse af data, der er gyldig for alle fysiske formater data skal anvendes i.

 

Den væsentlige forskel mellem logiske datamodeller og informationsmodeller er, at logiske datamodeller beskriver, hvordan data er, mens informationsmodeller beskriver hvilke informationer om virkeligheden man arbejder med i forretningen.

Modeller til genbrug

Reglerne er baseret på en række principper om gode modeller og på en modelleringsmetode, som fremmer forretningsafklaring og genbrugelighed.

En del af modelleringsmetoden er, at opdele modelleringsarbejdet på en måde, så selvstændige emneområder modelleres selvstændigt - denne opdeling gør det muligt at genbruge fremmede modeller i egen modellering, og den støtter dialogen om, hvordan den fælles forretning bedst koordineres.

Der findes derfor to indfaldsvinkler til modellering, som adskiller sig fra hinanden i forhold til omfang, altså ved enten at omfatte elementer inden for et bestemt emne eller til en bestemt anvendelse:

1. Kernemodel: genbrugelig model over et emneområde som ikke definerer modelelementer, der er defineret i andre kernemodeller og som typisk har et centralt forretningsobjekt i fokus, Kernemodeller afspejler og afgrænses af et bestemt emneområde; de modellerer kun det, som indgår i emneområdet.
2. Anvendelsesmodel: model som er rettet mod en specifik anvendelsessituation i en afgrænset kontekst Anvendelsesmodeller afspejler og afgrænses af behovet for information i en bestemt anvendelsessituation (dvs. i et bestemt system eller dataintegration) og sammensættes af elementer fra kernemodeller.

 

Eksternt genbrug

En yderligere styrkelse af modellens semantik kan man opnå ved at genbruge enkeltelementer og attributter fra bredt anvendte, oftest internationalt standardiserede modeller som er udformet med det formål at udgøre basismodellering af de allermest generelle ting; betegnelser, tidspunkter, adressering, organisering etc. Denne metodik vil blive behandlet udførligt i regler og vejledning til modellering.

Læsevejledning til regler

Reglerne er opdelt i sektioner, som gør det muligt at skabe sig et overblik over henholdsvis generelle regler, regler som gælder modellen og regler som gælder modellens elementer. Hver enkelt regel beskrives efter samme mønster som forklares herunder.

Navn	Angiver navnet på reglen
Regel	Angiver klart og præcist reglen
Rationale	Beskriver forretningsværdien ved at følge reglen
Implikation	Beskriver de egenskaber som modeller og modelelementer skal have for at overholde reglen. Generelt skal det nævnes at hvor implementeringen i en begrebsliste ofte består af en standardiseret 'overskrift' med en værdi, så vil den i UML-modellerne bestå af udfyldelse af et bestemt tag. Egenskaber af denne type præsenteres i et lille skema, med: Navn: sproglig betegnelse for egenskaben Anvendelsesnote: note beskriver hvordan egenskaben skal anvendes og forstås i kontekst af modelreglerne Implikation: beskrivelse af de værdier egenskaben kan have Kilde: angivelse af det vokabular-element som genbruges
Eksempel	Giver konkrete eksempler på opfyldelse af implikationen

Værktøjsunderstøttelse: Overholdelse af regler lettes væsentligt ved at opsætte den i Bilag A specificerede UML-profil i organisationens eget UML-værktøj. Implementering af den definerede UML-profil vil eksempelvis dels gøre alle definerede stereotyper og tags lettilgængelige for modelløren, dels vil fejl ved manuel indtastning af stereotyper og tags kunne undgås.

Det gennemgående eksempel: Der er konstrueret et fiktivt gennemgående eksempel, som tjener til illustration af implikationerne af de enkelte regler. Eksemplet omhandler el- og varmeforsyning (FORM 56.05) med fokus på ’elproduktionsanlæg’, og selvom den modelansvarlige står anført som Energistyrelsen, er dette blot et konstrueret eksempel, som ikke repræsenterer Energistyrelsens modellering af emnet - og begreberne er ikke afklaret med fageksperter. Alene lovtekster, relevante online datasæt (særligt stamdatasæt for vindmøller) og beskrivelser har dannet grundlag for eksemplet.

UML-elementerne

Reglerne omhandler modellering af klassediagrammer Jf. Unified Modeling Language specifikationen: https://www.omg.org/spec/UML [OMG 2015]. I reglerne anvendes følgende elementer:

• pakke (Package): UML-element som kan indeholde andre UML-elementer, og som karakteriserer disse i sammenhæng. Pakken bliver på denne måde det element, som definerer en model og bærer derfor modellens metadata.
• klasse (Class): UML-element som anvendes til at beskrive en klasse af instanser eller – i begrebsmodeller - et begreb (som beskrevet i ISO 24156-1:2014)

• objekt (Object): UML-element som anvendes til at beskrive en konkret instans af en klasse. Anvendes eksempelvis til at modellere medlemmerne i en klassifikation

• generalisering / specialisering (Generalization): UML-element som anvendes til at relatere en underordnet klasse (subclass) til en overordnet klasse (superclass).

• association (Association): UML-element som anvendes til at relatere klasser til hinanden. Associationen kan betegnes med et navn og beskrives med tagged values. Associationsnavnet kan udstyres med læseretning – se figur

Alternativt kan associationen udstyres med mindst en associationsende (se senere) til beskrivelse af relationen – i så fald behøver selve associationen hverken navn, læseretning eller tagged values

• komposition (Composition): En form for association som anvendes til at beskrive en relation mellem to klasser, som beskriver at instansen af den ene klasse (B) er en del af instansen af den anden klasse (A) og ikke kan eksistere uden denne.

• tilknytningsklasse / associationsklasse (Association class): UML-element som karakteriserer selve relationen mellem to klasser. Ofte anvendt til at angive temporalitet for en association.

• attribut (Attribute): UML-element som anvendes til at beskrive de af en klasses egenskaber, som har et udfaldsrum, der er en enkelt værdi. I særlige tilfælde kan attributter have udfaldsrum som ikke er en enkelt værdi – for eksempel beskrevet ved en struktureret datatype eller en klassifikation.

• associationsende (Association End/Role): UML-element som anvendes til at beskrive klasseegenskaber, som har et udfaldsrum, der beskrives ved en klasse, en struktureret datatype eller en enumeration. Associationsenden karakteriserer udfaldsrummets rolle i forhold til den klasse, som ’har’ associationsenden. Det vil typisk ikke være nødvendigt at angive associationsender i begge ender af en association.

• multiplicitet (Multiplicity): Angivelse af, hvor mange (forskellige) værdier en egenskab kan eller skal have. Angives for attributter og associationsender. Multiplicitet angives med en nedre og øvre grænse:

x..y: Mindst x, højst y værdier skal angives for eksempel:

• x..x: (ofte forkortet til ’x’): Netop x værdier skal angives
• 0..1: Værdien kan være fraværende, højst en værdi kan angives
• 0..*: (ofte forkortet til ’*’): Værdien kan være fraværende, antallet af samtidige værdier er ubegrænset
• 1..1: (ofte forkortet til ’1’): Netop én værdi skal angives
• 1..*: Mindst en værdi skal angives

Bemærk at standard UML fortolkning medfører, at fravær af angivelse af multiplicitet fortolkes som multipliciteten 1..1 (værdien krævet).

Bemærk yderligere, at termen ’kardinalitet’ betegner antallet af elementer der konkret indgår i en samling, hvorimod ’multiplicitet’ betegner rammerne for, hvor mange elementer, der kan indgå.

• datatype: (Data Type) UML-element, som beskriver udfaldsrummet for en attribut eller en association: i reglerne anvendes de følgende:
• primitiv datatype (Primitive Data Type): datatype, som beskriver et udfaldsrum bestående af en enkel værdi. Typisk udfaldsrum for en attribut

• enumeration (Enumeration): Datatype som ved hjælp af UML-elementet Enumeration specificerer en række (tekst)værdier som gyldigt udfaldsrum for en attribut eller associationsende. Dette er en gyldig måde at modellere en klassifikation på.

• struktureret datatype (Structured DataType): UML-element som beskriver et udfaldsrum som en sammenstilling af attributter med datatyper. En struktureret datatype adskiller sig fra en klasse ved kun at være identificeret ved sin værdi. Det vil sige at alle instanser af en datatype med identisk værdi kan betragtes som værende det samme. (instanser af klasser med identiske værdier kan sagtens være forskellige alligevel) En struktureret datatype kan både være udfaldsrum for associationsender og attributter.

Regler

Generelle regler

Et af målene med modelreglerne er at skabe et grundlag for effektiv kommunikation.

• mellem forretning og it i hele udviklingsforløbet fra ide til implementering.
• modellører imellem ved genkendelighed i modeludtryk og standardisering af modelelementer og - metadata.
• mellem it-systemer ved at give et grundlag for direkte genbrug af forretningens definerede begreber og modeldata i konkrete systemdata, der udveksles mellem it-systemer.

Til brug for denne kommunikation benyttes det bredt anvendte modelsprog Unified Modeling Language (UML). Specifikt benyttes diagrammer til modellering med klasser og objekter for at skabe et standardiseret og visuelt forståeligt udtryk.

For at gøre modeller genbrugelige, skal det både være muligt for andre at finde dem, og det skal være muligt for andre at anvende dem i egne UML-modelværktøjer.

Derfor skal modeller deles, og de skal kunne videregives i et standardiseret modeludvekslingsformat.

01 - Brug UML som det visuelle modelsprog

Regel

Alle modeller skal udtrykkes som UML-klassediagrammer udelukkende med brug af UML- elementer i overensstemmelse med standarden Unified Modeling Language™ (UML®) i version 2.0 eller senere versioner [OMG 2015].

Rationale

UMLs klasse- og objektdiagrammer er en standardiseret, tilgængelig og tilstrækkeligt entydig måde at visualisere modeller på, som samtidig er åben for udvidelse og yderligere specificering. Det visuelt enkle udtryk i et UML-diagram kan fungere både som letforståelig repræsentation af forretningens begreber og som kommunikationsmiddel mellem modellører og mellem modellør og programmør. Potentielt vil klassediagrammer kunne anvendes til effektiv kommunikation mellem forretningen og it-leverancen i hele udviklingsprocessen fra idé til løsningsimplementering.

Implikationer

UML-klasse- og objektdiagrammer skal anvendes til visuelle repræsentationer (diagrammer) af begrebsmodeller, informationsmodeller og logiske datamodeller.

NOTE: For klassifikationer med mange elementer er det ikke nødvendigvis fordelagtigt at modellere alle elementer som UML for at kunne indlevere klassifikationen. Andre repræsentationer – fx placering på en klassifikationstjeneste el. i regneark – kan aftales med modelsekretariatet.

NOTE: Begrebsmodeller kan repræsenteres som begrebslister, Jf. Bilag C. Det er en mulighed at repræsentere begrebsmodeller med et UML-klasseklasse- og objektdiagram, men det er ikke et krav.

02 - Brug kun udvalgte UML-elementer

Regel

Alle modeller skal defineres som UML-pakker med klassediagrammer, udelukkende bestående af UML-elementerne ‘Klasse’, ‘Objekt’ ‘Generalisering/Specialisering’, ’Tilknytningsklasse’, ‘Association’, ’Komposition’, ‘Associationsende’, ‘Attribut’, ’Multiplicitet’ samt datatyper herunder ’Primitiv datatype’ , ’Struktureret datatype’ og ’Enumeration’ og anvendelse af disse elementer er afhængig af modellens type. Dertil UML-stereotyper og -tags.

Rationale

For at modeller entydigt skal kunne beskrive de fælles data, og for at de skal være ensartet tilgængelige for anvendere, er det nødvendigt at begrænse hvilke UML-elementtyper der anvendes. Samtidig skal modellernes dele kunne genanvendes frigjort fra deres oprindelige kontekst – således skabes sammenhængende modeller.

Implikationer

Modeller skal bestå af modelementer indeholdt i UML-pakker. UML-klasse- og objektdiagrammer skal anvendes til at udtrykke terminologiske begrebsmodeller, informationsmodeller og logiske datamodeller. Følgende UML-elementer kan anvendes.

• pakke (Package)
• klasse (Class)
• objekt (Object)
• generalisering/specialisering (Generalization)
• association (Association)
• komposition (Composition)
• tilknytningsklasse/associationsklasse (Association class)
• attribut (Attribute)
• associationsende (Association End/Role)
• multiplicitet (Multiplicity)
• primitiv datatype (Datatype)
• enumeration(Enumeration)
• struktureret datatype (Structured DataType)

Begrebsmodeller skal bestå udelukkende af: klasser, generaliseringer/specialiseringer og navngivne associationer.

Informationsmodeller og logiske datamodeller kan bestå af alle de ovennævnte elementer.

Associationer kan udstyres med både navne (inkl. læseretning) og associationsender, dog vil man normalt i informationsmodeller udelukkende anvende associationsnavne og i logiske datamodeller udelukkende anvende associationsender.

03 - Brug UML-stereotyper

Regel

Alle UML-elementer tildeles en UML-stereotype.

Rationale

Ved at anvende stereotyper bliver det muligt at registrere de nødvendige forretnings- og modelleringsmetadata for modeller og modelelementer. Via stereotyper kan elementerne udstyres med tagged values, som indeholder de metadata, som gør dem selvforklarende uden for den model de er defineret i. En stereotype er en udvidelse af specifikationen af et UML-element som specificerer dets anvendelse til en bestemt betydning og kontekst. Stereotypen specificerer et sæt af tagdefinitioner. Disse tagdefinitioner udvider de elementer som har stereotypen med et tilsvarende sæt af tags, som kan bruges til at beskrive elementets forretnings- og modelleringsmetadata. Disse tags kan, for hvert enkelt element, udfyldes med tagged values, der er netop dette elements metadata for den kategori som tagget repræsenterer.

Implikationer

Både modeller og modelelementer udstyres med stereotyper og tags.

Modellens type indikeres ved hjælp af pakkens stereotype og tagget omfang.

Følgende stereotyper anvendes for modeller:

• terminologiske begrebsmodeller - Oprettes som pakker med stereotypen «ConceptModel»
• informationsmodeller - Oprettes som pakker med stereotypen «InformationModel»
• logiske datamodeller - Oprettes som pakker med stereotypen «LogicalDatamodel»
• klassifikationsmodeller - Oprettes som pakker med stereotypen «ClassificationModel»

Følgende stereotyper anvendes for modelelementer:

• «Concept» påføres begreber i terminologiske begrebsmodeller og informationsmodeller
• «ModelElement» påføres elementer i logiske datamodeller

Bemærk at Generalisering/specialisering samt primitive datatyper ikke udstyres med stereotype

04 - Udstil modellen online

Regel

En model skal være offentlig og frit tilgængelig på internettet og have en repræsentation i listeformat eller ved grafisk illustration.

Rationale

Ved at udstille modellerne på internettet, kan man opnå fri og lige adgang til modellerne.

Implikationer

Den modelansvarlige skal sørge for at, at modellen publiceres på internettet, og at brugeren præsenteres for en repræsentation i listeformat eller grafisk format. Det skal ydermere tilstræbes, at URL’en, modellen publiceres fra, er persistent.

NOTE: Ofte vil en model blive reviewet inden den bliver udstillet. I forbindelse med review, betragtes reglen derfor som opfyldt, hvis der medfølger information om hvordan og hvornår modellen planlægges udstillet.

05 - Gør modellen tilgængelig i maskinlæsbart format

Regel

Modellen skal være tilgængelig i et maskinlæsbart format

Rationale

Ved at gøre modellen tilgængelig i et maskinlæsbart format tillades, at modelleringsværktøjer og maskiner kan fortolke modellens indhold. Derudover understøtttes genbrug, idet modelløren ikke manuelt skal kopiere modellens indhold og struktur ved videre anvendelse. Formatet XML Metadata Interchange (XMI), som er udviklet af Object Management Group (OMG), er et anerkendt udvekslingsformat for UML-modeller, og er blevet en de facto standard for interaktion mellem UML-værktøjer. Langt de fleste UML-værktøjer understøtter således eksport og import af en model til en fil i XMI-format.

Implikationer

Modellen skal publiceres i en fil som overholder XMI-standarden [OMG-XMI 2015].

(media type application/vnd.xmi+xml).

NOTE: Der kan forekomme situationer hvor det anvendte modelleringsværktøj ikke understøtter eksport til XMI-format. I sådanne tilfælde bør der lægges en plan for hvordan et maskinlæsbart format opnås, fx ved videreudvikling af værktøjet eller indkøb af nyt værktøj, og denne plan medsendes til review, hvor reglen så kan betragtes som overholdt. Modellen vil i den situation blive gjort tilgængelig i maskinlæsbart format, når det bliver teknisk muligt. NOTE: Ofte vil en model blive reviewet inden den bliver udstillet. I forbindelse med review, betragtes reglen derfor som opfyldt, hvis der medfølger information om i hvilket format modellen planlægges udstillet.

NOTE: For klassifikationer med mange elementer er det ikke nødvendigvis fordelagtigt at modellere alle elementer som UML for at kunne indlevere klassifikationen. Andre repræsentationer – fx placering på en klassifikationstjeneste – kan aftales med modelsekretariatet.

NOTE: Modellen kan - efter aftale med modelsekretariatet - indleveres i et af de følgende RDF serialiseringsformater:

• Turtle (media type text/turtle)
• JSON-LD (media type application/ld+json)
• RDF/XML (media type application/rdf+xml)

Modelsekretariatet vil i så fald bistå med konvertering til XMI.

Eksempler

Modeller udstilles som xmi i det fællesoffentlige katalog over begrebs- og datamodeller.

Regler for modeller

For at kunne vurdere om en eksisterende model er den rette til at blive genbrugt i et nyt modelarbejde, skal en række basale oplysninger om modellen være tilgængelige.

Oplysningerne skal fortælle, hvor i et udviklingsforløb en model er, og hvem der er ansvarlig for udarbejdelsen. Det skal også fremgå, hvilket emne modellen fokuserer på, og eventuelt også hvilket regel- eller lovgrundlag modellen er baseret på.

Desuden vil det være nyttigt, at kunne se modellens proveniens i form af information om, hvilken anden model, eller hvilke andre modeller, der har været udgangspunkt for modellen.

06 - Angiv meningsfyldte navne og beskrivelser for modeller

Regel

Modellen skal forsynes med et meningsfyldt navn samt en kort beskrivelse samt angivelse af modellens primære sprog og modellens scope.

Rationale

Det er hensigtsmæssigt, at modellen gives et meningsfyldt og, for kernemodeller, anvendelsesneutralt navn samt en kort beskrivelse, da det er intentionen, at modellen skal kunne læses, anvendes og genbruges af andre, og det vil lette formidling, fremsøgning og anvendelse. Derudover angives modellens primære sprog, hvilket giver mulighed for at automatisere videre behandling af termer og definitioner.

Implikationer

Modeller skal forsynes med meningsfyldte navne, der refererer til det pågældende emne og/eller det centrale forretningsbegreb. Derudover skal modellen forsynes med en kort beskrivelse af modellens formål og indhold.

Der kan også som kommentar tilføjes en tekstuel beskrivelse om, hvilke bekendtgørelser og love der er relevante for modellen, mens selve henvisningen til disse skal ske ved præcis angivelse af juridisk kilde i form af en HTTP-URI, jf. Regel 13. I forhold til navngivning af kernemodeller anbefales det, at man tager udgangspunkt i det element, der er i fokus for modellen, og som typisk præsenteres grafisk i modellen som det element, der forbinder de øvrige elementer i modellen, og hvorfra relationerne “udspringer”. På samme vis skal en anvendelsesmodel forsynes med et meningsfyldt navn, der refererer til den pågældende anvendelse.

Reglen opfyldes ved at angive modellens navn, beskrivelse og sprog og omfang ved hjælp af egenskaberne ‘modelnavn’, ’beskrivelse’, ’modelsprog’ og 'modelomfang'.

Navn:	modelnavn
Anvendelsesnote:	det eller de ord der betegner en model
Udfaldsrum:	tekst
Kilde:	rdfs:label - "human-readable name for the subject."

 

Navn:	beskrivelse
Anvendelsesnote:	beskrivelse af modellens formål og indhold
Udfaldsrum:	tekst
Kilde:	dct:description - "An account of the resource."

 

Navn:	modelsprog
Anvendelsesnote:	angivelse af modellens primære sprog, som UML-repræsentationen fremhæver
Udfaldsrum:	I henhold til RFC5646 angives sprog eksempelvis med ISO 639-1 (fx, ’da’ og ’en’), eventuelt efterfulgt af regionsangivelse, fx en-US, en-UK
Kilde:	dct:language - "A language of the resource."

For alle modeltyper sættes desuden tagget ’modelScope’ (modelomfang) til enten CoreModel (kernemodel) eller ApplicationModel (anvendelsesmodel) alt efter modellens omfang, altså om modellen er emneorienteret (kernemodel) eller anvendelsesorienteret (anvendelsesmodel).

Navn:	modelomfang
Anvendelsesnote:	angivelse af en models omfang og orientering mod enten et bestemt emne eller en bestemt anvendelse
Udfaldsrum:	CoreModel (kernemodel); ApplicationModel (anvendelsesmodel)
Kilde:	mdl:modelscope - “the scope and orientation of a model”

• Begrebslister: Udfyld 'modelnavn', 'beskrivelse', 'modelsprog' og ’modelomfang’ iht. Bilag C
• UML-modeller: Udfyld taggene 'label (da) (modelnavn)', 'description (da) (beskrivelse)', 'language (modelsprog)' og 'modelscope (modelomfang)'

Eksempler

I UML-model:

label (da) (modelnavn) = Elproduktionsanlæg
description (da) (beskrivelse) = Model over typer af elproduktionsanlæg anvendt i Danmark og de begreber der bruges til at beskrive dem
language(modelsprog) = da
modelscope (modelomfang) = kernemodel

07 - Angiv identifikation af modeller

Regel

Modeller gives entydig identifikation ved brug af en HTTP-URI udformet i overensstemmelse med ‘Retningslinjer for stabile HTTP-URIer’.

Rationale

Ved at anvende en unik HTTP-URI som identifikator for en model kan HTTP-URIen samtidigt fungere både som entydig identifikator (~entydigt navn) og potentielt som entydig URL (~entydig adresse), hvilket gør den egnet både til entydig identifikation af elementer og til efterfølgende at kunne finde yderligere oplysninger om elementet. Ved at anvende retningslinjerne øges URIerne uafhængighed af organisatoriske omlægninger.

Implikationer

Reglen overholdes ved at angive den valgte HTTP-URI i tagget 'namespace'. Den valgte HTTP-URI fungerer både som entydig identifikator for selve pakken og som det namespace, pakkens egendefinerede elementer er tilknyttet. HTTP-URIer bør overholde Retningslinjer for stabile HTTP-URIer [Digitaliseringsstyrelsen 2018] og specifikt et af følgende URI-mønstre: 

URI-mønster	Beskrivelse
https://data.gov.dk/model/core/{reference}	Bruges til URIer der identificerer en logisk datamodel når denne er en kernemodel.
https://data.gov.dk/model/profile/{reference}	Bruges til URIer der identificerer en logisk datamodel når denne er en anvendelsesmodel.
https://data.gov.dk/concept/core/{reference}	Bruges til URIer der identificerer en begrebsmodel når denne er en kernemodel.
https://data.gov.dk/concept/profile/{reference}	Bruges til URIer der identificerer en begrebsmodel når denne er anvendelsesorienteret, oftest i form af: et klassifikationssystem et terminologisk begrebssystem en informationsmodel sammensat af elementer fra en kernebegrebsmodel.

Mønstrets {reference}-del foreslås udgjort af et beskrivende ord der dækker modellens indhold.

Navn:	namespace
Anvendelsesnote:	logisk område, indenfor hvilket elementer navngives unikt, og som tjener som overordnet reference til de navngivne elementer
Udfaldsrum:	HTTP-URI
Kilde:	vann:preferredNamespaceURI

Det er også muligt at angive et præfiks som kan anvendes som en forkortet betegnelse for et namespace fulde URI.

Navn:	namespacepræfiks
Anvendelsesnote:	forkortet betegnelse for et namespace
Udfaldsrum:	string
Kilde:	vann:preferredNamespacePrefix

For UML-modeller: Udfyld tagget ‘namespace’ på modelpakken

Eksempler

I UML-model: 'namespace' = https://data.gov.dk/model/core/energysupplyfacility/

08 - Angiv den modelansvarlige organisation

Regel

Ansvar for modellen og dens elementer skal være klart og tydeligt.

Rationale

For at en bruger kan se, om en model er relevant og kan anvendes, skal det fremgå, hvilken organisation der er ansvarlig for modellen, det vil sige, er ansvarlig for, at den er blevet udarbejdet og står inde for at modellens indhold og struktur er retvisende på udgivelsestidspunktet.

Ejer af data er ikke nødvendigvis ansvarlig for den anvendte model. Der kan for nogle emneområder være adskillelse mellem ejerskab til data og ‘specifikationsansvar’ for de modeller, som beskriver data. For eksempel inden for emneområderne personregistrering og adresseregistrering. Her er ansvaret for specifikation af data fastsat til ansvarlige ministerier (Indenrigsministeriet og Energi-, Forsynings- og Klimaministeriet) jf. bekendtgørelser. Data er imidlertid sammenstillet og kvalitetssikret af kommunerne. Information om modelansvar er således meget relevant, når modelløren skal vurdere, om et givet modelelement er det korrekte/gældende udtryk for et forretningsbegreb, som ønskes modelleret.

Implikationer

Reglen opfyldes ved at angive den modelansvarlige organisation med modelegenskaben ‘modelansvarlig’.

Navn:	modelansvarlig
Anvendelsesnote:	organisation der står inde for modellens indhold og struktur på udgivelsestidspunktet
Udfaldsrum:	Ejerskabet skal på sigt udtrykkes som en reference til en struktureret organisationsoversigt. Indtil da kan ejerskabet angives med et navn på organisationen.
Kilde:	frbr:responsibleEntity - "An entity in some way responsible for an endeavour"

• UML-modeller: Udfyld tagget ‘responsibleEntity (modelansvarlig)’ på modellens pakke
• Begrebslister: Udfyld oplysningen ‘'modelansvarlig’ iht. Bilag C

Eksempler

I UML-model: responsibleEntity (modelansvarlig) = Energistyrelsen

Den modelansvarlige angives her med et navn - Energistyrelsen - da det endnu ikke er muligt at angive en reference til en struktureret organisationsoversigt.

09 - Angiv emne for modellen

Regel

Angiv emne for modellen.

Rationale

Ved at klassificere modellerne efter emne, i henhold til en fællesoffentlig referencemodel, lettes fremsøgning, genbrug og anvendelse af udstillede modeller. Det giver brugeren mulighed for at bruge emnerne som indgang til at finde den ønskede model eller det ønskede modelelement uden nødvendigvis at kende et specifikt søgeord.

Implikationer

Reglen opfyldes ved at angive modellens emneområde som modelegenskaben ‘emne’.

Navn:	emne
Anvendelsesnote:	oplysning som klassificerer en ressource i en tematisk kategori
Udfaldsrum:	tilstrækkelig præcis reference til en relevant offentligt tilgængelig klassifikation, såsom et link til forvaltningsopgaven i den FællesOffentlige ReferenceModel (FORM), KL Emnesystematik (KLE) eller - hvis emneområdet ikke er en klassificeret , offentlig opgave - med en anden tilstrækkeligt standardiseret referencemodel.
Kilde:	dcat:theme - "The main category of the dataset"

• Begrebslister: Udfyld oplysningen ‘emne iht. Bilag C
• UML-modeller: Udfyld tagget ‘theme (emne) på modellens pakke

Eksempler

I UML-model: ' theme (emne)' = https://data.gov.dk/model/classification/form#ElOgVarmeforsyning

Note: Emnet kan evt angives med tekst, hvis det er nødvendigt at anvende en referencemodel, der ikke har HTTP-URI-identifikatorer

10 - Angiv modellens version

Regel

Modellens versionsnummer og seneste opdateringsdato skal angives.

Rationale

Ved at modellen forsynes med oplysninger om versionering og seneste opdateringsdato, bliver det lettere for brugeren at vurdere, om en given model eller elementer herfra kan anvendes til et bestemt formål. Brugeren kan blandt andet let afgøre, hvilken version af en specifik model, der er den nyeste, og hvornår der sidst er sket ændringer i modellen. Det er desuden god skik at give en kort beskrivelse af hvilke ændringer, der er sket siden sidste version.

Implikationer

Reglen opfyldes ved at angive modellens opdateringsdato og versionsnummer som modelegenskaberne hhv. ‘opdateringsdato’ og ‘versionsnummer’. Ændringen siden sidste version kan beskrives med egenskaben ‘ændringshistorik’.

Navn:	seneste opdateringsdato
Anvendelsesnote:	den dato hvor der senest blev foretaget ændringer
Udfaldsrum:	dato (Date) - Udfaldsrum opbygget iht. xsd:date (YYYY-MM-DD)
Kilde:	dct:dateModified - "Date on which the resource was changed"

 

Navn:	versionsnummer
Anvendelsesnote:	unik identifikation af en specifik version
Udfaldsrum:	Udfaldsrum opbygget med Semantic Versioning - (MAJOR.MINOR.PATCH fx: 1.0.0)
Kilde:	owl:versionInfo -"The annotation property that provides version information for an ontology or another OWL construct"

 

Navn:	ændringshistorik
Anvendelsesnote:	beskrivelse af de ændringer de ændringer der er sket i denne version af modellen i forhold til den seneste version.
Udfaldsrum:	Tekst
Kilde:	adms:versionNotes- "A description of changes between this version and the previous version of the Asset"

• Begrebslister: Udfyld oplysningen ’versionsnummer’, ‘seneste opdateringsdato’ og evt. ’ændringshistorik’ iht. Bilag C
• UML-modeller: Udfyld taggene ‘versionInfo (versionsnummer), 'modified' (seneste opdateringsdato) og evt. 'versionNotes (da)' (ændringshistorik) (på modellens pakke)

Eksempler

I UML-model: 'versionInfo (versionsnummer )' = 1.1.0

'modified' (seneste opdateringsdato) ' = 2017-02-02

'versionNotes (da)' (ændringshistorik) = i version 1.1.0 er der tilføjet begrebet 'rotordiameter'

11 - Modellen skal forretningsgodkendes

Regel

Modellen skal godkendes af et relevant forum

Rationale

Et væsentligt element i skabelsen af en sammenhængende offentlig forretning, er den forretningsafklaring som blandt andet består af, at de enkelte organisationer identificerer hvilke forretningsobjekter de, qua lovgivning og andre aftaler, har specifikationsansvaret for.

Afklaringen implicerer således en ‘grænsedragning’ mellem de enkelte kernemodeller, hvor hvert emneområde eller forretning tager ejerskab til de forretningsobjekter som er inden for dets ressort. Samtidig fralægger forretningen sig specifikationsansvar for alle andre objekter - men kan naturligvis stadig anvende dem til at kontekstualisere, udvide og kvalificere sin modellering.

Implikationer

I forhold til det faglige emneområde, som modellen beskriver, skal et relevant forum med beslutningskompetence og viden om emneområdet identificeres, og disse interessenter skal stå inde for en godkendelsesproces. Dette kræver at modellens semantiske indhold findes i en repræsentation som er målrettet dette forum og at det er det semantiske indhold og ikke det modelleringstekniske som forummet skal tage stilling til. Reglen opfyldes ved at angive modellens forretningsgodkendelsesstatus ved hjælp af modelegenskaben ‘godkendelsesstatus’, og modellen betragtes først som færdig og klar til udgivelse når den er blevet godkendt og i denne forbindelse skal det forum som har godkendt modellen også angives.

NOTE: Til modelreview medsendes information om det planlagte godkendelsesforløb.

Navn:	godkendelsesstatus
Anvendelsesnote:	status som angiver hvorvidt en model er accepteret og erklæret som gældende i et - for emneområdet - relevant forum
Udfaldsrum:	not relevant (ikke relevant) : status som angiver at en model ikke skal gennemgå et godkendelsesforløb awaiting approval (afventer godkendelse): status som angiver at en model afventer et godkendelsesforløb approved with remarks (godkendt med anmærkninger): status som angiver at en model er accepteret og erklæret som gældende, men at der er fremhævet bemærkninger der er relevante i forhold til godkendelsen approved (godkendt): status som angiver at en model er accepteret og erklæret som gældende
Kilde:	voag:hasApprovalStatus - "An object property that referes to an enumerated value that denotes the state of an approval"

 

Navn:	godkendt af
Anvendelsesnote:	angivelse af det emnespecifikke forum som har accepteret og erklæret modellen som gældende.
Udfaldsrum:	Udtrykkes med navn på forummet eller som en reference til en struktureret organisationsoversigt
Kilde:	voag:isApprovedBy- "References to which parties approve an entity"

• Begrebslister: Udfyld ‘godkendelsesstatus’ og ’godkendt af’ iht. Bilag C
• UML-modeller: Udfyld tagget ‘approvalStatus (godkendelsesstatus)’ og ’isApprovedBy (godkendt af) på modelpakken

Eksempler

I UML-model:

'approvalStatus (godkendelsesstatus)' = approved (godkendt)

’isApprovedBy (godkendt af)= Teknisk forum for vindenergi

12 - Angiv modellens modelstatus

Regel

Det skal angives hvor komplet og færdig og dermed anvendelig modellen er.

Rationale

For at brugerne af en given model skal kunne forvisse sig om en models potentielle anvendelse og relevans, skal det være muligt at kunne tilgå udsagn om modellens status.

Implikationer

Reglen opfyldes ved at angive modellens status ved hjælp af modelegenskaben ‘modelstatus’:

Navn:	modelstatus
Anvendelsesnote:	status som angiver modellens gyldighed, her forstået som hvor komplet og færdig og dermed anvendelig modellen er
Udfaldsrum:	development (under udvikling): modelstatus som indikerer, at modellen har en foreløbig og ukomplet udformning (adms:UnderDevelopment) completed (endelig): modelstatus som indikerer, at modellen er komplet, stabil og taget i brug (adms:Completed) deprecated (forældet): modelstatus som indikerer, at modellen tidligere har været gældende, men at den er blevet erstattet af en anden model eller overflødiggjort (adms:Deprecated) withdrawn (trukket tilbage): modelstatus som indikerer, at modellen tidligere har været gældende, men at den ikke vurderes at være anvendelig længere da den er fejlbehæftet eller mangelfuld (adms:Withdrawn)
Kilde:	adms:status- "The status of the Asset in the context of a particular workflow process"

• Begrebslister: Udfyld oplysningen ‘modelstatus’ iht. Bilag C.
• UML-modeller: Udfyld tagget ‘modelStatus (modelstatus)’ på modellens pakke

Eksempler

I UML-model: ' modelStatus (modelstatus)' = development (under udvikling)

13 - Angiv modellens lovgrundlag

Regel

Sammenhængen mellem lovgrundlag og modeller skal dokumenteres ved at anføre referencer til lovgrundlag og standarder på området.

Rationale

Ved at synliggøre og dokumentere sammenhængen mellem lovgrundlag og forretningsmæssige modeller fremmes juridisk og organisatorisk interoperabilitet.

Implikationer

Man skal undersøge om der findes lovmæssige rammer omkring modellen, og i så fald skal disse beskrives. Reglen opfyldes ved at specificere henvisninger til love og bekendtgørelser med egenskaben 'juridisk kilde' på modelniveau ved angivelse af ELI-URI-referencer (European Legislation Identifier) som præsenteres på Retsinformation.dk. Andre henvisninger til nationale og internationale standarder samt øvrige kilder kan beskrives med egenskaben 'kilde'.

Navn:	juridisk kilde
Anvendelsesnote:	reference til lovgrundlag som danner grundlag for modellen
Udfaldsrum:	Overordnet tekstuel beskrivelse af de lovmæssige rammer eller angivelse af ELI-URI-referencer
Kilde:	cv:hasLegalResource - "It indicates the Legal Resource (e.g. legislation) to which the Public Service [red:resource] relates, operates or has its legal basis"

 

Navn:	kilde
Anvendelsesnote:	reference til ressource hvorfra modellen er afledt
Udfaldsrum:	Overordnet tekstuel beskrivelse af nationale og internationale standarder samt øvrige kilder
Kilde:	dct:source - "A related resource from which the described resource is derived"

• Begrebslister: Udfyld ‘juridisk kilde’ og ’kilde’ for modellen iht. Bilag C
• UML-modeller: Udfyld tagget hasLegalResource (juridisk kilde)’ med ELI-URI-reference og ’dct:source (kilde)’ på pakken således at der er et tag per kilde

14 - Etablér sammenhæng mellem modeller

Regel

Såfremt der udarbejdes modeller til forskellige målgrupper eller formål inden for samme emne, skal der være sammenhæng mellem dem

Rationale

Ved at sikre sammenhæng mellem terminologiske begrebsmodeller, informationsmodeller og logiske datamodeller muliggøres juridisk, organisatorisk og semantisk interoperabilitet. Ved den logiske datamodellering overføres forretningsmodelleringen til en logisk datamodel, så ved at relatere logiske datamodeller og deres elementer til terminologiske begrebsmodeller og informationsmodeller sikres sammenhængen fra forretning til datamodellering. Ligeledes skal informationsmodeller relateres til den terminologiske begrebsmodel hvis begreber suppleres med forretningslogik.

Implikationer

1. Terminologiske begrebsmodeller, informationsmodeller og logiske datamodeller skal dele betegnelser og definitioner. Det vil sige, at eksisterer der en terminologisk begrebsmodel eller informationsmodel, som fagkyndige har bidraget med viden til, så skal der være en sammenhæng med den logiske datamodel. Den logiske datamodel skal i så fald implementere den terminologi og semantik, som den terminologiske begrebsmodel eller informationsmodellen indeholder ved at lade henholdsvis klasser, associationsender og egenskaber realisere den terminologiske begrebs- eller informationsmodels indhold.
2. For det andet skal det dokumenteres, når en model er afledt af en anden model, fx når en informationsmodel eller en logiske kernemodel er afledt af en terminologisk begrebsmodel. Dette gøres ved hjælp af modelegenskaben ‘er afledt af’, der på den afledte model udfyldes med HTTP-URIen for den model den er afledt af. Egenskaben ‘er afledt af’ kan også anvendes på elementniveau, hvis man fx ønsker at henvise til det specifikke begreb en given klasse er afledt af.

Navn	Er afledt af
Anvendelsesnote	relation som angiver at en entitet har dannet basis for oprettelse af en ny entitet
Udfaldsrum	Udtrykkes som reference ved en HTTP-URI
Kilde	prov:wasDerivedFrom

Eksempler

For at opfylde implikationens første del, så kan begrebet ’vindkraftanlæg’ eksempelvis være defineret i en begrebsliste med definitionen ’kraftværk som omdanner vindenergi til elektricitet’. Begrebet kan også have en identifikator fx https://data.gov.dk/model/concept/energysupplyfacility#windpowerplant. I den logiske datamodellering anvendes samme term og definition til klassen Vindkraftanlæg (WindPowerPlant), og derudover kan der oprettes en reference fra denne klasse til det bagvedliggende begreb ved at udfylde tagget ’wasDerivedFrom’ med begrebets identifikator.

For at opfylde implikationens anden del, så angives det at den logiske kernemodel ’Energiforsyningsanlæg’ er baseret på en terminologisk begrebsmodel med tagget 'wasDerivedFrom’=https://data.gov.dk/model/concept/energysupplyfacility

15 - Modeller klassifikationer til genbrug

Regel

Klassifikationer skal modelleres selvstændigt, så de kan genbruges i forskellige modeller.

Rationale

Klassifikation er i denne sammenhæng anvendelse af en kontrolleret mængde af veldefinerede klassifikationsemner. Det er vigtigt at det bliver muligt entydigt at referere til et klassifikationsemne (en instans) i en klassifikation ligesom man bør kunne få tilstrækkelig information om klassifikationsemnet og skabe relationer mellem emner på tværs af modeller og systemer.

Klassifikationer skal modelleres til genbrug og derfor bør disse kontrollerede udfaldsrum også løftes ud af modellerne og fremstå som selvstændige modeller. Det vil betyde at flere modeller kan referere til samme klassifikation og at klassifikationen kan udvides eller indsnævres uden behov for revision af de refererende modeller. 

Implikationer

Når klassifikationer modelleres med UML kan klassifikationsemnerne optræde som enten instanser af en klassifikationsklasse eller som værdierne i en enumeration, og disse skal placeres i en selvstændig pakke med stereotypen 'ClassificationModel'.

For klassifikationer med mange elementer er det ikke nødvendigvis fordelagtigt at modellere alle elementer med UML (Se Note i Regel 1) for at kunne indlevere klassifikationen. Andre repræsentationer – fx placering på en klassifikationstjeneste el. i regneark – kan aftales med modelsekretariatet.

Regler for modelelementer

De modelelementer, der udarbejdes efter modelreglerne, skal have informationer, der gør det muligt både for mennesker og for maskiner at genbruge dem og fortolke dem. Derfor gives en række regler for navngivning, udformning af definitioner og beskrivelser, så elementerne bliver forståelige for både fagkyndige, modellører og it-udviklere. Der gives også regler for, hvordan elementer kan identificeres entydigt på tværs af modeller og systemer.

Genbrug er også et fællesanliggende for alle elementer og alle modeller. Derfor gives der også her regler for genbrug og for, hvordan det enkelte elements historie eller proveniens skal formidles.

16 - Angiv meningsfyldte UML-navne for modelelementer

Regel

Modelelementers betegnelser skal understøtte genbrug. Modelelementer skal forsynes med betegnelser, der afspejler den anvendte terminologi på området.

Rationale

Det er hensigtsmæssigt, at modellens elementer får meningsfyldte betegnelser, da det er intentionen, at modellen skal kunne læses, anvendes og genbruges af andre. Det vil med andre ord sige, at selvom man principielt kan betegne et element med et navn, som ikke i sig selv er meningsgivende, fx KA00045, så bør man vælge en betegnelse, som afspejler den i emneområdet anvendte term, som udpeger det begreb, som elementet faktisk skal repræsentere, fx ‘Vindkraftanlæg’ [Allemang 2008:310].

Implikationer

Modelelementer, herunder klasser, associationer, associationsender og attributter skal forsynes med UML-navne, der afspejler anvendt terminologi inden for emneområdet.

Eksempler

• Byggesagsnummer er et bedre attributnavn end sag001 (i forhold til byggesager)
• Folkekirketilknytningsforhold er et bedre klassenavn end Folkekirke (i forhold til personer)
• Personoplysningsbeskyttelse er et bedre klassenavn end Beskyttelse (i forhold til personer)
• Strandbeskyttelsesområde er et bedre klassenavn end Strandbeskyttelse i (i forhold til jordstykker)

17 - Giv alle modelelementer en identifikator

Regel

Alle modelelementer skal have en fuldt kvalificeret HTTP-URI som identifikator.

Rationale

Sporbarhed af modelelementers udvikling, fra begrebsmodel frem til teknisk implementering, kræver entydig identifikation af elementerne.

Et middel til sammenhæng mellem modeller og mellem data opnås ved brug af unikke, entydige identifikatorer. W3C anbefaler brug af HTTP-URI, jf. Data on the Web Best Practices (W3C 2017).

En HTTP-URI har både funktion som entydig identifikator (~entydigt navn) og potentielt som entydig URL (~ entydig adresse), hvilket gør den egnet både til entydig identifikation af elementer og til efterfølgende at kunne finde yderligere oplysninger om elementet.

Implikationer

Identifikatorer dannes alene i forbindelse med modellering af kernemodeller ved at danne en fuldt kvalificeret HTTP-URI som en sammensætning af:

• Det namespace der identificerer den model elementet tilhører (Jf. Regel 7).
• Fragmentnavn som placeres efter skilletegnet, og som udgør det enkelte elements navn – som er unikt inden for namespacet

Da anvendelsesmodeller anvender elementer fra kernemodeller vil disse elementer allerede være forsynet med identifikatorer.

Navn:	URI
Anvendelsesnote:	entydig identifikation af en ressource, (en klasse, en instans, en egenskab, datatype eller en værdi)
Udfaldsrum:	HTTP-URI
Kilde:	W3C Linked Data Glossary - Uniform Resource Identifier

NOTE: UML-elementet Generalization (Generalisering) forsynes, som eneste UML-element, ikke med dette tag.

NOTE: Flere forhold gør sig gældende med hensyn til valg af sprog for fragmentnavnet: Navnet bør naturligvis afspejle den forhåndenværende modellering bedst muligt, så hvis modellen i øvrigt er udfærdiget på dansk, kan der være gode grunde til at også fragmentnavnet er på dansk.

På den anden side er det væsentligt, at kunne opnå internationalt forståelige HTTP-URIer hvorfor fragmenter optimalt navngives på engelsk. Dermed gøres elementet væsentligt lettere både at genkende og forstå for ikke-dansksprogede, internationale anvendere. Ved at bringe genanvendelsesmuligheden op på et internationalt niveau øges værdien af det udførte kernemodelarbejde væsentligt. Jo mere udbredt og anvendt en kernemodel er, jo mindre sandsynligt vil det være at der efterfølgende vil blive foretrukket andre kernemodeller med samme funktion. HTTP-URIer skal derudover være persistente. Derfor er det ikke en mulighed på et senere tidspunkt at ændre HTTP-URIen og anvende et engelsk fragment i stedet for et dansk.

Eksempler

Modelpakken for modellen over energiforsyningsanlæg har URI:
https://data.gov.dk/model/core/energysupplyfacility#

Fragmentnavnet et element (en klasse) er: EnergySupplyFacility

Som en kombination af disse to dannes den fulde HTTP-URI for elementet: 

https://data.gov.dk/model/core/energysupplyfacility#EnergySupplyFacility

18 - Angiv termer i et naturligt sprog

Regel

Modelelementer skal forsynes med termer i et naturligt sprog

Rationale

Ved at forsyne modelelementer med termer i et naturligt sprog afspejles terminologien i emneområdet, og dermed understøttes fremsøgning og genbrug af modelelementer. Med naturligt sprog skal forstås skriftsprog der følger det pågældende sprogs retskrivning og ikke programmeringskonventioner såsom CamelCase og sammensætningen af ord med understregning eller bindestreg. Termerne skal altså ikke yderligere behandles for at kunne indgå og forstås som termer i en traditionel ordliste.

Implikationer

Termerne, som de i skriftsproget naturligt anvendes i emneområdet, skal registreres. Term skal i denne sammenhæng forstås som et udtryk eller en betegnelse der sprogligt udpeger et begreb, og som dermed har en specifik betydning i et fagsprog.

Som minimum registreres den foretrukne term, men såfremt et begreb kan udtrykkes ved flere synonyme accepterede eller frarådede termer, så anbefales det at disse også registreres, selvom det ikke er et krav. Termer registreres ved hjælp af elementegenskaberne ‘foretrukken term’, accepteret term’ og ‘frarådet term’.

Navn:	foretrukken term (prefLabel)
Anvendelsesnote:	term som vurderes at være det bedste af flere synonyme udtryk for et givet begreb
Udfaldsrum:	tekst
Kilde:	skos:prefLabel - "The preferred lexical label for a resource, in a given language"

 

Navn:	accepteret term
Anvendelsesnote:	term hvis anvendelse godtages men ikke foretrækkes
Udfaldsrum:	tekst
Kilde:	skos:altLabel - "An alternative lexical label for a resource"

 

Navn:	frarådet term (deprecatedLabel)
Anvendelsesnote:	term som ikke bør anvendes fordi den er uønsket, forkert eller forældet
Udfaldsrum:	tekst
Kilde:	mdl:deprecatedLabel - "term that should not be used because it is undesirable, wrong or outdated"

Hver af disse tre egenskaber findes for hvert sprog man ønsker at registrerer termer for,fx. prefLabel (da) for danske termer og prefLabel (en) for engelske termer. Man kan angive termer for et sprog, eller for så mange som man har brug for. Til sprogangivelsen anvendes sprogkoder fra RFC4646 (se også regel 6). Termen registreres, som termen forekommer i emneområdet og skal følge det pågældende sprogs retstavning.

Begrebslister: Udfyld ‘foretrukken term’ og eventuelt ‘accepteret term’ og ‘frarådet term’ iht. Bilag C. Termer, som de naturligt anvendes i emneområdet, skal registreres i begrebslisten. I begrebslisten vil den foretrukne term fremgå som indgang til det pågældende begreb. Angives accepterede og frarådede termer skal disse anføres separat herefter.

UML-modeller: Udfyld tagget ‘prefLabel’ og evt. ‘altLabel’ og ‘deprecatedLabel' på modelelementet med termer som de naturligt anvendes i emneområdet. Modeller udtrykt i UML opfylder denne regel, når modelelementer udover deres UML-navne er forsynet med labels implementeret ved tagged values, der dokumenterer modellen i et naturligt sprog. Tilføj så mange labels til et element som nødvendigt. I forbindelse med tilføjelse af disse labels bør standardiserede konventioner for angivelse af navne følges. At labels anvendes til dokumentation af kernemodeller i et naturligt sprog foreslås også af Tim Berners-Lee [Gómez-Pérez 2011:113] og anbefales af W3C [W3C 2014e]. Den generelle tag label kan anvendes hvis der ikke er taget stilling til, hvilken term der foretrækkes.

Eksempler

I begrebsliste:

Foretrukken term	vindkraftanlæg
Accepteret term	vindmølle; vindkraftværk
Frarådet term	vindmølle
Definition	kraftværk der producerer elektrisk effekt ved hjælp af vind
Eksempel
Kommentar	IEC 60050-415-01-01
Juridisk kilde	ikke defineret i VE-loven, men af internationale standarder
Kilde	IEC 60050-415-01-02
Tilhørere emneområde	ja

Egenskaber for UML-modelelement esf:WindPowerPlant (Vindkraftanlæg)

prefLabel (da) (foretrukken betegnelse )= vindkraftanlæg

altLabel (da) (alternativ betegnelse)= vindmølle

19 - Brug standardiserede konventioner for angivelse af navne

Regel

Modellen, og de elementer den består af, skal forsynes med UML-navne og termer der er angivet efter standardiserede konventioner og best practices.

Rationale

Modelelementers betegnelser skal understøtte genbrug. En ensartet navnekonvention giver modellen et ensartet udtryk og gør det nemmere at identificere og skelne de forskellige elementer fra hinanden.

Implikationer

Generelle implikationer:

• Anvend et almindeligt udbredt tegnsæt (Unicode)
• Anvend substantiver i ubestemt entalsform for begreber/klasser jf. [Allemang 2008:311] og [Ambler 2005:51]

Terminologiske begrebsmodeller

• Termer og associationsnavne angives med lille begyndelsesbogstav jf. [ISO 704]
• Termer og associationsnavne angives efter gældende retstavning
• Anvend mellemrum til adskillelse af ord
• Navngiv klasser og associationer i et naturligt sprog (kun begrebsdiagrammer)
• Anvend verbalfraser i nutidsform for associationer i terminologiske begrebsmodeller jf. [Europa-Kommissionen ISA 2011:35]

Informationsmodeller og logiske datamodeller

• Vedrørende UML-modelelementer: jf. [Allemang 2008:311] og [Europa-Kommissionen ISA 2011:35]
  • Navne på klasser og objekter angives med med “UpperCamelCase” - dvs. stort begyndelsesbogstav i både første ord og alle eventuelle efterfølgende ord i navnet og uden anvendelse af mellemrum i navnet.
  • Navne på associationer, associationsender og attributter angives med “lowerCamelCase” - dvs. lille begyndelsesbogstav i første ord og stort begyndelsesbogstav i eventuelle efterfølgende ord og uden angivelse af mellemrum.
• Vedrørende termer som angives som tagværdier gælder det jf. regel ‘Angiv termer i et naturligt sprog’:
  • Angiv termer og relationer med lille begyndelsesbogstav [ISO 704]
  • Angiv termer og relationer efter gældende retstavning
  • Anvend mellemrum til adskillelse af ord

Eksempler

Eksempler fra begrebsmodel: vindkraftanlæg, navngiven vej, identificeres ved

Eksempler fra logisk datamodel: Vindkraftanlæg, NavngivenVej, identificeresVed

20 - Udarbejd definitioner eller beskrivelser af modellens elementer

Regel

Betydningen af modellens navngivne elementer skal beskrives fyldestgørende og i et letforståeligt dansk.

Rationale

For at sikre at elementer anvendt i en model forstås på samme måde ved alle anvendelser, er det nødvendigt at gøre rede for betydningen ved fyldestgørende beskrivelse. Dette er grundlaget for en bred anvendelse og for minimering af fejltolkninger.

Implikationer

Reglen opfyldes ved at tilknytte en beskrivelse eller definition på dansk til alle navngivne modelelementer. Supplerende bemærkninger eller oplysninger kan eventuelt tilføjes som en kommentar, og ligeledes kan eksempler eventuelt angives.

Bemærk at denne regel sætter krav om tilstedeværelsen af en definition, og at regel 21 og 22 supplerer denne regel ved at sætte krav til selve udformningen af definitionen.

Elementegenskaberne 'definition', 'kommentar' og 'eksempel' anvendes:

Navn:	definition
Anvendelsesnote:	beskrivelse af betydningen af et begreb (7)
Udfaldsrum:	tekst
Kilde:	skos:definition- "a statement or formal explanation of the meaning of a concept"

 

Navn:	kommentar
Anvendelsesnote:	supplerende bemærkning eller oplysning vedrørende begrebet
Udfaldsrum:	tekst
Kilde:	rdfs:comment - "an instance of rdf:Property that may be used to provide a human readable description of a resource"

 

Navn:	eksempel
Anvendelsesnote:	typisk forekomst der beskrives for at forklare eller anskueliggøre
Udfaldsrum:	tekst
Kilde:	skos:example - "supplies an example of the use of a concept"

• Begrebslister: Udfyld 'definition' og evt. 'kommentar' og 'eksempel' iht. Bilag C
• UML-modeller: Udfyld tagget 'definition (definition) og evt. 'comment' (kommentar)' og 'example (eksempel)' på modelelementet

I anvendelsesmodeller hvor man genbruger kernemodelelementer, har disse allerede en definition, som ikke må ændres eller tilrettes. Man kan dog, hvis der er behov for det, supplere med en 'anvendelsesnote' om hvordan elementet skal forstås netop i et pågældende datasæt eller det it-system hvor det skal anvendes.

Begrebsmodeller kan i nogle sammenhænge anvende helt ganske almensproglige begreber på en mere specifik måde – her kan anvendelsesnoten også skærpe modelleringen

Navn:	Anvendelsesnote
Anvendelsesnote:	Note som beskriver hvordan et modelelement skal anvendes og forstås i en bestemt anvendelseskontekst
Udfaldsrum:	tekst
Kilde:	mdl:applicationNote - "note which describes how a vocabulary element should be applied and comprehended in a specific application context"

• Begrebsmodeller og anvendelsesmodeller: Angiv oplysning om 'anvendelsesnote/applicationNote' på modelelementet såfremt der er behov for det

Eksempler

I begrebsliste: 'definition' = kraftværk som omdanner vindenergi til elektricitet

21 - Udarbejd strukturerede definitioner på en standardiseret måde

Regel

Definitioner af modelelementer bør struktureres på en standardiseret måde. Definitioner bør udarbejdes som indholdsdefinitioner, dvs. at definitionen angiver nærmeste overbegreb samt karakteristiske træk. Definitionen skal beskrive betydningen af et begreb således, at det klart afgrænses fra andre begreber.

Rationale

Ved at udarbejde indholdsdefinitioner får man korte, klare og korrekte definitioner, som på entydig og robust vis formidler betydningen af et begreb, men nok så vigtigt undgår man en række uhensigtsmæssigheder, som andre definitionstyper har (se eksempler på andre definitionstyper under afsnittet ‘eksempler’ herunder)

Implikationer

Kort fortalt skal man tilstræbe at definere et begreb ved at angive nærmeste overbegreb samt karakteristiske træk. dvs. man skal anføre, hvad begrebet er for “en slags” og hvad det, der er karakteristisk ved netop denne slags i forhold til andre begreber med samme direkte overbegreb.

Ved definition af elementer skal man udtrykke sig så kort, klart og korrekt som muligt. Se vejledningen for yderligere indføring i udformning af definitioner i overensstemmelse med gældende standarder og best practices på området [ISO 704, ISO 1087, Madsen 2007].

I henhold til reglen om sammenhæng mellem lovgrundlag og modeller, bør det undersøges om gældende lovgivning på området definerer det relevante begreb, og hvis dette umiddelbart kan anvendes, er det ikke nødvendigt at opfylde dette krav om en struktureret form.

Eksempler

• God: vindkraftværk: kraftværk som omdanner vindenergi til elektricitet (Indholdsdefinition hvor overbegrebet “kraftværk”, og det der karakteriserer en vindmølle i forhold til andre kraftværker er, at den “omdanner vindenergi til elektricitet”)
• Dårlig: vindkraftværk: vindmølle (Definition ved angivelse af synonym - giver ingen yderligere forklaring)
• Dårlig: vindkraftværk: fx havvindkraftanlæg, vindkraftlanlæg i landzone (Definition opremsning af underbegreber - er alle med? Hvad er betydningen af disse?)
• Dårlig: vindkraftværk: kraftværk som ikke omdanner kemisk, elektrisk, varme-, kerne-, beliggenheds- eller strålingsenergi (Negativ definition idet begrebet er defineret ved hvad det “ikke” er).
• Dårlig: vindkraftværk: består af tårn, nav og vinger (Definition opremsning af bestanddele - er alle dele med? Kan de evt. sættes sammen til noget andet?)

22 - Udarbejd anvendelsesneutrale definitioner

Regel

Modellens elementer skal defineres anvendelsesneutralt, så de også kan anvendes i andre kontekster. Definitioner skal være fagligt forsvarlige og alment anvendelige.

Rationale

Hvis man lader anvendelseskonteksten indsnævre definitionen af elementet risikerer man, at udelukke genbrug eller man risikerer uhensigtsmæssig brug af elementet i andre modeller.

Implikationer

Definitionen må ikke indeholde elementer, som udtrykker en uhensigtsmæssig indsnævring af begrebet ved for eksempel at beskrive tekniske, organisatoriske eller politiske afhængigheder. Supplerende kontekstafhængige kommentarer eller eksempler skal ikke indgå i definitionen, da disse oplysninger eventuelt ikke er relevante for definitionen og kan være begrænsende for bred anvendelse af begrebet.

Eksempler

• God: vindkraftanlæg: kraftværk som omdanner vindenergi til elektricitet
• Dårlig: sagsoprettelsesdato: Den dato en sag oprettes i styrelsens sagsbehandlingssystem (ved at indsnævre sagsbehandlingssystemet til en bestemt organisatorisk enhed (‘styrelsens’) reduceres genbrugspotentialet).
• Dårlig: sagsoprettelsesdato: Dato udtrykt som YYYY-MM-DD (ved at indsnævre det tekniske format reduceres genbrugspotentialet).
• Dårlig: seværdighed: bygningsværk af interesse for turister (ved at anføre bygningsværk som overbegreb udelukkes seværdigheder som ikke udgøres af en konstruktion af denne type).

23 - Angiv modelelementers lovgrundlag

Regel

Sammenhængen mellem lovgrundlag og modelelementer kan dokumenteres ved at anføre referencer til lovgrundlag og standarder på området på elementniveau.

Rationale

Ved at synliggøre og dokumentere sammenhængen mellem lovgrundlag og modelelementer fremmes juridisk og organisatorisk interoperabilitet. I modelleringsarbejdet bør begreber fra lovgrundlag anvendes så vidt muligt. I lovgivningsarbejdet bør tilsvarende anvendes begreber defineret i begrebsmodeller og logiske modeller.

Implikationer

Definitionen må ikke indeholde elementer, som udtrykker en uhensigtsmæssig indsnævring af begrebet ved for eksempel at beskrive tekniske, organisatoriske eller politiske afhængigheder. Supplerende kontekstafhængige kommentarer eller eksempler skal ikke indgå i definitionen, da disse oplysninger eventuelt ikke er relevante for definitionen og kan være begrænsende for bred anvendelse af begrebet.

Termer og definitioner der indgår i modeller, skal, i det omfang det er muligt, hentes fra gældende lovgivning på området, og kildehenvisninger bør angives for begrebet.

Det bør altså undersøges om gældende lovgivning på området definerer det relevante begreb, og hvis dette umiddelbart kan anvendes, er det ikke nødvendigt at opfylde reglen om en struktureret form (jf. Regel 21). Hvis lovgivningens definition af et givet begreb derimod vurderes at være uanvendelig udarbejdes en ny definition samtidigt med at lovgivningens definition medtages i kommentar (rdfs:comment) med en forklaring af hvorfor den er uanvendelig. Det anbefales, at lovgivning baseres på dokumenterede, aftalte og ikke-redundante begreber - svarende til en terminologisk begrebsmodel, der fremmer genbrug.

Reglen opfyldes ved at specificere henvisninger (med HTTP-URIer) til love og bekendtgørelser med egenskaben 'juridisk kilde' og henvisninger til nationale og internationale standarder samt øvrige kilder med egenskaben 'kilde'.

Navn:	juridisk kilde
Anvendelsesnote:	reference til lovgrundlag hvorfra begrebet er afledt
Udfaldsrum:	Udtrykkes på elementniveau som reference til lovtekst ved den mest præcise henvisning til det pågældende begreb i en given lov (fx ved angivelse af ELI URI-reference (European legislation identifier) som præsenteres på Retsinformation.dk
Kilde:	cv:hasLegalResource - "It indicates the Legal Resource (e.g. legislation) to which the Public Service [red:resource] relates, operates or has its legal basis"

 

Navn:	kilde
Anvendelsesnote:	reference til ressource hvorfra begrebet er afledt
Udfaldsrum:	Udtrykkes på elementniveau ideelt set med en URI, men kan også være kildens navn
Kilde:	dct:source -"A related resource from which the described resource is derived"

• Begrebslister: Udfyld ‘juridisk kilde’ og 'kilde' på begrebsniveau iht. Bilag C
• UML-modeller: Udfyld tagget ‘legalSource (juridisk kilde)’ og 'source (kilde)' på modelelementet

Eksempler

I UML-model:

'legalSource (juridisk kilde)' = http://www.retsinformation.dk/eli/lta/2015/1736

'source (kilde)' = http://www.electropedia.org (IEC 60050-415-01-02)

24 - Definér kun nye modelelementer når det er nødvendigt

Regel

Definition af et nyt element i en model må kun foretages, hvis et tilsvarende element ikke allerede findes.

Rationale

For at effektivisere deling og sammenstilling af data er det vigtigt, at forretningsansvaret for specifikationen af et givet dataelement er afklaret og dokumenteret. Derfor bør et modelelement kun forekomme én gang i den samlede modellering af data. Forskellige dele af den offentlige forretning kan håndtere data baseret på det samme modelelement, hvorved forståelsen af data bliver entydig. Hvis der i nye modeller ny-defineres klasser, egenskaber eller objekter, som overlapper med i forvejen eksisterende elementer, så reduceres genbrugeligheden generelt, både i modelarbejdet og i de implementerede dataanvendende it-systemer. Derfor skal modelleringen baseres på elementer, som enten ikke har været defineret før, eller som anvendes fra andre modeller. Udover øget interoperabilitet, opnår man reduktion af det merarbejde, der ligger i, at der udarbejdes definitioner af forskellige elementer der repræsenterer det samme.

Implikationer

Man bør undersøge eksisterende modellering, og kun hvis et anvendeligt element ikke kan findes, skal et nyt element defineres. Restriktioner på hvilke typer af elementer der kan genbruges kan eventuelt defineres lokalt. Vejledningen til modellering efter modelreglerne giver en uddybende behandling af, hvordan egnede elementer kan findes i eksisterende modellering.

25 - Sammensæt anvendelsesmodeller af elementer fra kernemodeller

Regel

Et element i en anvendelsesmodel skal entydigt identificere, hvilket element i en kernemodel, det genbruger.

Rationale

Anvendelsesmodeller er lavet til et specifikt formål og er baseret på elementer som defineres i kernemodeller. Det, at et givet kernemodelelement kan genanvendes af mange i flere forskellige anvendelsesmodeller er med til at skabe sammenhæng mellem modeller, mellem datasæt og mellem data. Det er væsentligt, entydigt at kunne identificere elementers oprindelse andre steder end i den forhåndenværende model, og derfor skal genbruget dokumenteres ved brug af de entydige identifikatorer der defineres i kernemodellerne.

Implikationer

Anvendelsesmodeller skal bestå af genbrugte elementer, defineret i kernemodeller.

Genbruget specificeres ved at elementerne i anvendelsesmodellen har samme identifikation – tagget URI – som de elementer de er genbrug af. En anvendelsesmodel kan i visse tilfælde anvende et genbrug element på en mere specialiseret måde en det oprindelig var defineret. I disse tilfælde tilføjes elementet i anvendelsesmodellen – jævnfør regel 20 – en anvendelsesnote ved anvendelse af tagget applicationNote

Bemærk, at forskellige modelleringsværktøjer er i stand til at håndtere genbrug på forskellige måder – se vejledningen. I forhold til reglerne er genbruget fyldestgørende dokumenteret, hvis den angivne identifikator kan anvendes til at fremfinde den originale definition af elementet.

Bemærk også, at selv om en anvendelsesmodel ikke eksplicit har følgeskab af en række kernemodeller, vil identifikationen af de enkelte elementer udgøre tilstrækkelig dokumentation for den logiske tilstedeværelse af kernemodeller – hvert af modellens unikke namespaces udgør logisk en kernemodel – se eksemplet.

Eksempler

I anvendelsesmodellen for et datasæt om elforsyningsanlæg indgår elementer, som er udarbejdet i regi af energiforsyningsanlægsmodelleringen samt genbrugte, allerede eksisterende elementer fra andre modeller.

Namespaces, som indgår i de enkelte elementers identifikatorer er for nemheds skyld angivet som præfiks før elementnavnet. Således ser vi, at modellen indeholder elementer fra følgende kernemodeller:

• Energiforsyningsanlæg (esf ~ https://eksempel.dk/model/energysupplyfacility#) Virksomhed (biz ~ https://eksempel.dk/model/business#)
• Registered organisation (rov ~ http://www.w3.org/ns/regorg#) (https://www.w3.org/TR/vocab-regorg/)
• Schema.org (schema ~ https://schema.org/)

Note: I regi af grunddatamodellering bestemmes det i et for grunddata relevant forum hvilke kernemodeller der skal udarbejdes og genbruges.

26 - Angiv om begrebet tilhører modellens emne

Regel

Angiv om begrebet tilhører modellens emne

Rationale

Nogle begreber opfattes som ’tilhørende’ modellens emne, dvs. er centrale for det modellen skal formidle, hvor andre ’fremmede’ begreber, hvis primære funktion er at skabe sammenhæng til relaterede emner, indlånes fra disse emneområder. Ved at tydeliggøre dette forhold understreges det at modelementerne er genbrugte for at bringe dem i sammenhæng med emnets egne og på den måde at skabe sammenhængende modellering af de offentlige data.

Implikationer

Reglen opfyldes ved at begreber i begrebsmodeller forsynes med en markering af, om de tilhører modellens emne eller ej. Fremmede begreber er dannet i et (for modellens fokus) eksternt emne.

• Begrebslister: Udfyld oplysningen ‘tilhører emnet’ iht. Bilag C, (udfaldsrum ja/nej – eller præcis reference til den model hvor begrebet er defineret)
• UML-modeller: Giv modelelementer der ikke tilhører emnet en visuel markering og udfyld desuden tagget ’isDefinedBy’ (er defineret af). Her angives det hvor, dvs. i hvilken model, begrebet er defineret. For begreber der tilhører emnet angives begrebsmodellen selv. Ved at angive dette eksplicit lettes genbrug af begrebet i andre modeller. For begreber genbrugt andre steder fra angives den model, hvor begrebet er hentet.

Eksempler

Eksempler på ’tilhørende’ og ’fremmede’ begreber i energiforsyningsbegrebsliste:

Foretrukken term	Definition	Juridisk kilde	Tilhører emne
havvindkraftanlæg	vindkraftanlæg der er opstillet på søterritoriet eller i den eksklusive økonomiske zone, og hvor vindmøllens fundament ikke er syligt ved normal vandstand	https://www.retsinformation.dk/eli/lta/2015/1115	ja
kraftværk	energiforsyningsanlæg som alene producerer elektricitet		ja
rotordiameter	diameter på vindmøllens rotor målt fra vingespids til omdrejningscentrum ganget med to		ja
systemansvarlig virksomhed	virksomhed, der har det overordnede ansvar for at opretholde forsynings- sikkerhed og en effektiv udnyttelse af et sammenhængende elforsyningssystem	http://www.retsinformation.dk/eli/lta/2016/418	ja
systemfabrikant	virksomhed der har produceret et givet system		ja
virksomhed	juridisk enhed der har erhvervsdrivende eller arbejdsgiver	https://www.retsinformation.dk/eli/lta/2006/653	nej
vindkraftanlæg	kraftværk der producerer elektrisk effekt ved hjælp af vind		ja
vindkraftanlæg i landzone	vindkraftanlæg som er beliggende i en landzone		ja

I UML-model:

tilhører emneområde: ’isDefinedBy’=

https://data.gov.dk/model/concept/energysupplyfacility/

hentet fra anden model: ’isDefinedBy’ =

https://data.gov.dk/model/profile/cvr/

27 - Brug standardiserede primitive datatyper

Regel

Brug standardiserede primitive datatyper.

Rationale

Logiske datamodeller bliver først udtømmende beskrivelser af data, når de angiver datatyper for attributter. Datatyperne udtrykker på en konsistent måde det udfaldsrum, som egenskaben har. Datatyper skal dog være platforms- og systemneutrale for at kunne anvendes i definition af fælles logiske modeller.

Først og fremmest er det væsentligt, at de anvendte datatyper kan forstås og fortolkes, hvorfor deres definition skal være entydig og publiceret. Yderligere gælder det, at genkendelighed og genbrugelighed øges, hvis de anvendte datatyper tages fra et så lille udvalg af publicerede typer som muligt.

Implikationer

Standardiserede primitive datatyper i modellen skal hentes fra XSD/RDFS, eller ISO/TC 211. Note: I forbindelse med Grunddatamodellering skal ISO/TC211-datatyperne anvendes.

• XSD/RDFS Datatypes: Datatyperne kan tilgås fra W3Cs specifikationerne XML Schema 1.1 Part 2: Datatypes og RDF 1.1 Concepts and Abstract Syntax XSD/RDFS datatyperne kan også ses i bilag B.
• ISO/TC 211 Harmonized Model er en samling af datatyper, som primært anvendes af geografi-relaterede modelleringsprojekter - fx INSPIRE. ISO/TC 211 Datatyperne kan tilgås fra ISO/TC211 Harmonized Model Management Group GitHub-repositorium (HMMG) 

Sammenhængen mellem de to typesæt findes i ISO TC 211 GOM Harmonized Ontology 

Denne mapping er tilvejebragt af ISO/TC 211 Group for Ontology Management og er i regi af INSPIRE-projektet ’informative’, dvs. uden formel gyldighed. I forhold til harmonisering af modeller inden for modelreglernes virkeområde kan den betragtes som værende fyldestgørende og gældende.

28 - Modellér klassifikationsemner som instanser

Regel

Klassifikationsemner skal modelleres som entydige instanser, og i UML erklæres klassifikationsemner som instanser af relevant klassifikationsklasse eller værdier i en enumeration.

Rationale

Ved at håndtere et klassifikationsemne som en instans - i stedet for blot en tekststreng - bliver det ikke alene muligt at foretage en præcis og utvetydig identifikation af et klassifikationsemne, det bliver også muligt at tilføje beskrivende egenskaber på emnerne, samt at anvende klassifikationsemnet i mange, indbyrdes uafhængige modeller eller datasæt uden at miste entydig identifikation og information om betydning.

Implikationer

I UML kan klassifikationer modelleres på to måder:

1. med klassifikationsemner defineret som instanser af en veldefineret klassifikationsemneklasse
2. med enumerationer (her udgøres instanserne af værdierne i enumerationen).

I begge tilfælde skal instanserne (værdierne) udstyres med stereotypen ModelElement og gives metadata som andre modelelementer.

Bemærk at klassifikationsemneklasse og dens instanser eller enumerationen skal placeres i en separat pakke jf. Regel 15.

For klassifikationer med mange elementer er det ikke nødvendigvis fordelagtigt at modellere alle elementer med UML (Se Note i Regel 1) for at kunne indlevere klassifikationen.

Andre repræsentationer – fx placering på en klassifikationstjeneste el. i regneark – kan aftales med modelsekretariatet.

Eksempler

Typer af vindkraftanlæg erklæres eksempelvis som instanser af klassen WindPowerPlantType eller som instanser i en enumeration.

Bilag A: FDA-profilen

I modelleringsarbejdet anvendes en række UML-stereotyper med tilhørende tag-definitioner.

FDA-profilen beskrives her indholdsmæssigt og vil således kunne implementeres i et UML- værktøj. Modelregelprojektet vil sørge for at danne en profil, som kan importeres og anvendes til modellering.

Del 1 af FDA-profilen: modellens metadata 
I højre side af diagrammet herunder vises Model stereotypen med specialiseringerne ConceptModel, InformationModel, LogicalDatamodel og ClassificationModel. Stereotyperne er udvidelser af metaklassen Package (UML-pakker). Det er de fire specialiseringer - som arver tags fra den overordnede stereotype - som i praksis anvendes på pakker indeholdende de forskellige typer af modeller.

 

Del 2 af FDA-profilen: modelelementernes metadata 
På samme måde får modellens elementer genbrugelige metadata ved hjælp af stereotyper som vist i venstre side af nedenstående diagram.

Tabeller med beskrivelser af FDA-profilens stereotyper og tags

Del 1: FDA-profilens stereotyper

Stereotype	Anvendelsesnote	Tags
Model	objekt, der repræsenterer en entitet ved at besidde en ægte delmængde af dennes egenskaber	title (da), title (en), description (da), description (en), wasDerivedFrom publisher, responsibleEntity versionInfo modified theme, modelStatus, approvalStatus, modelScope source, legalSource, namespacePrefix, namespace, language
ConceptModel	vidensorganiserende model der beskriver begreber og deres indbyrdes relationer
InformationModel	vidensorganiserende model som beskriver forretningsviden og som supplerer begreber med forretningsregler.
LogicalDatamodel	datamodel som beskriver data elementernes logiske sammenhænge
ClassificationModel	vidensorganiserende model der kategoriserer og ordner entiteter i emneklasser
ModelElement	element som indgår i en model	URI prefLabel (da) prefLabel (en) altLabel (da) altLabel (en) label (da) label (en) deprecatedLabel (en), deprecatedLabel (da), definition (da), definition (en), comment (da), comment (en),  example (da), example (en),, legalSource, source, applicationNote (da), applicationNote (en) wasDerivedFrom, isDefinedBy
Concept	mental forestilling om et bestemt fænomen med dettes karakteristiske træk

Del 2: FDA-profilens Tags

Tagsene er her angivet alfabetisk med deres RDF-egenskab, anvendelsesnote, udfaldsrum (som enten er en værdi eller et objekt) samt den stereotype de defineres på.

Tags er vist i alfabetisk rækkefølge her:

Tag	Definerede stereotype	Anvendelsesnote	Udfaldsrum
altLabel (da) (skos:altLabel)	ModelElement / Model	dansk betegnelse som accepteres anvendt for en ressource NOTE - An alternative lexical label for a resource. (skos:altLabel)	string
altLabel (en) (skos:altLabel)	ModelElement / Model	engelsk betegnelse som accepteres anvendt for en ressource NOTE -An alternative lexical label for a resource. (skos:altLabel)	string
applicationNote (da) (mdl:ApplicationNote)	ModelElement	dansk note som beskriver hvordan et vokabularelement skal anvendes og forstås i en bestemt anvendelseskontekst	string
applicationNote (en) (mdl:ApplicationNote)	ModelElement	engelsk note som beskriver hvordan et vokabularelement skal anvendes og forstås i en bestemt anvendelseskontekst	string
approvalStatus (voag:hasApprovalStatus)	Model	angivelse af hvorvidt en model er accepteret og erklæret som gældende i et - for emneområdet - relevant forum NOTE - An object property that refers to an enumerated value that denotes the state of an approval. [voag]	approvalStatus (se tabel nedenunder)
approvedBy (voag:approvedBy)	Model	angivelse af det emnespecifikke forum som har accepteret og erklæret modellen som gældende.	string
comment (da) (rdfs:comment)	ModelElement	supplerende bemærkning eller oplysning vedrørende modelelementet på dansk	string
comment (en) (rdfs:comment)	ModelElement	supplerende bemærkning eller oplysning vedrørende modelelementet på engelsk
definition (da) (skos:definition)	ModelElement	dansk beskrivelse af betydningen af et begreb NOTE - 'supplies a complete explanation of the intended meaning of a concept.' - Bemærk at ‘definition’ her anvendes til registrering af både beskrivelser og strukturerede definitioner	string
definition (en) (skos:definition)	ModelElement	engelsk beskrivelse af betydningen af et begreb NOTE - 'supplies a complete explanation of the intended meaning of a concept.' - Bemærk at ‘definition’ her anvendes til registrering af både beskrivelser og strukturerede definitioner	string
deprecatedLabel (da) (mdl:deprecatedLabel)	ModelElement	dansk term som ikke bør anvendes fordi den er uønsket, forkert eller forældet	string
deprecatedLabel (en) (mdl:deprecatedLabel)	ModelElement	engelsk term som ikke bør anvendes fordi den er uønsket, forkert eller forældet	string
description (da) (dct:description)	ModelElement / Model	dansk beskrivelse af modellens formål og indhold NOTE - description of the purpose and contents of the model	string
description (en)  (dct:description)	ModelElement / Model	engelsk beskrivelse af modellens formål og indhold NOTE - description of the purpose and contents of the model	string
example (da) (skos:example)	ModelElement	typisk forekomst der beskrives på dansk for at forklare eller anskueliggøre – på dansk	string
example (en) (skos:example)	ModelElement	typisk forekomst der beskrives på dansk for at forklare eller anskueliggøre – på engelsk	string
isDefinedBy (rdfs:isDefinedBy)	ModelElement	angivelse af URIen for den model elementet er defineret i.	HTTP-URI
label (da) (rdfs:label)	ModelElement	dansk betegnelse for elementet	string
label (en) (rdfs:label)	ModelElement	engelsk betegnelse for elementet	string
language (dct:language)	Model	angivelse af modellens primære sprog, som en UML-repræsentationen fremhæver	string
legalSource (cv:hasLegalResource)	ModelElement / Model	reference til lovgrundlag hvorfra ressourcen er afledt Udfaldsrum: Udtrykkes som reference til lovtekst ved den mest præcise henvisning til det pågældende begreb i en given lov (f.eks ved angivelse af ELIreference (European legislation identifier) som præsenteres på Retsinformation.dk).	HTTP-URI
modelScope (mdl:modelScope)	Model	angivelse af en models omfang og orientering mod enten et bestemt emne eller en bestemt anvendelse	modelScope (se tabel nedenunder)
modelStatus (adms:status)	Model	status som angiver hvor komplet og færdig og dermed gyldig modellen er NOTE - The status of the Asset in the context of a particular workflow proces [adms]	modelStatus (se tabel nedenunder)
modified (dct:modified)	Model	den dato hvor der senest blev foretaget ændringer NOTE - Date on which the resource was changed [dct]	date
namespace (vann:preferredNamespaceUri)	Model	logisk område, indenfor hvilket elementer navngives unikt, og som tjener som overordnet reference til de navngivne elementer	HTTP-URI
namespacePrefix (vann:preferredNamespacePrefix)	Model	forkortet betegnelse for et namespace NOTE - Se http://prefix.cc).	string
prefLabel (da) (skos:prefLabel)	ModelElement	dansk betegnelse som foretrækkes anvendt for en given ressource NOTE - en ressource kan kun have én foretrukken dansk betegnelse. The preferred lexical label for a resource, in a given language [skos]	string
prefLabel (en) (skos:prefLabel)	ModelElement	engelsk betegnelse som foretrækkes anvendt for en given ressource NOTE - en ressource kan kun have én foretrukken engelsk betegnelse.	string
publisher (dct:publisher)	Model	En entitet som er ansvarlig for at gøre ressourcen tilgængelig. NOTE - 'an entity responsible for making the resource available.'	HTTP-URI
responsibleEntity (frbr:responsibleEntity)	Model	organisation der står inde for modellens indhold og struktur på udstillingstidspunktet	string
source (dct:source)	ModelElement / Model	reference til ressource hvorfra en given ressource er afledt NOTE: A related resource from which the described resource is derived.[dct] Udfaldsrum: Udtrykkes ideelt med en resolverbar URI eller URL, men hvis en sådan ikke findes kan det også udtrykkes ved navnet på kilden.	HTTP-URI eller string
title (da) (dct:title)	Model	dansk betegnelse for modellen (rdfs:label)	string
title (en) (dct:title)	Model	engelsk betegnelse for elementet (rdfs:label)	string
theme (dcat:theme)	Model	emneområde som forvaltes af en given forretning NOTE - Udfaldsrum: tilstrækkelig præcis reference til den FællesOffentlige ReferenceModel (FORM). 'The main category of the dataset'	HTTP-URI
URI	ModelElement	entydig identifikation af en ressource, (en klasse, en instans, en egenskab eller en værdi/literal) ved brug af en HTTP-URI	HTTP-URI
versionInfo (owl:versionInfo)	Model	unik identifikation af en specifik version NOTE -The annotation property that provides version information for an ontology or another OWL construct Udfaldsrum: opbygget med en major-version, minor-version og revision adskilt med punktum, f.eks.:1.0.0	string
versionNotes (adms:versionNotes)	Model	Beskrivelse af de ændringer de ændringer der er sket i denne version af modellen i forhold til den seneste version.	string
wasDerivedFrom (prov:wasDerivedFrom)	ModelElement / Model	angivelse af model eller det modelelement, som den aktuelle ressource er afledt af	HTTP-URI

FDA-profilens klassifikationer

Udfaldsrum for klassifikationen: ApprovalStatus (godkendelsesstatus)

Se evt. mere her: https://data.gov.dk/model/core/approvalstatus.rdf

Værdi	RDF-element	Definition
awaiting approval	mapp:AwaitingApproval	status som angiver at en model afventer et godkendelsesforløb
approved	mapp:Approved	status som angiver at en model er accepteret og erklæret som gældende
approved with remarks	mapp:ApprovedWith Remarks	status som angiver at en model er accepteret og erklæret som gældende, men at der er fremhævet bemærkninger der er relevante for godkendelsen
not applicable	mapp:NotApplicable	status som angiver at en model ikke skal gennemgå et godkendelsesforløb

Udfaldsrum for klassifikationen: ModelStatus (modelstatus)

Se evt. mere her: https://data.gov.dk/model/core/modelstatus.rdf

Værdi	RDF-element	Definition
development	adms:UnderDevelopment	modelstatus som indikerer, at modellen har en foreløbig og ukomplet udformning
completed	adms:Completed	modelstatus som indikerer, at modellen er komplet, stabil og taget i brug
deprecated	adms:Deprecated	modelstatus som indikerer, at modellen tidligere har været gældende, men at den er blevet erstattet af en anden model eller overflødiggjort
withdrawn	adms:Withdrawn	modelstatus som indikerer, at modellen tidligere har været gældende, men at den ikke vurderes at være anvendelig længere da den er fejlbehæftet eller mangelfuld

Udfaldsrum for klassifikationen: ModelScope (modelomfang)

Værdi	RDF-element	Definition
CoreModel	mdl:CoreModel	genbrugelig model over et emneområde som ikke definerer modelelementer som er defineret i andre kernemodeller og som typisk har et centralt forretningsobjekt i fokus
ApplicationModel	mdl:ApplicationModel	model som er rettet mod en specifik anvendelsessituation i en afgrænset kontekst

 

Bilag B: Datatyper fra XSD/RDFS

Nedenstående er en hierakisk oversigt over datatyper fra XSD/RDFS baseret på W3C's liste:

En detaljeret beskrivelse af datatyperne gives i efterfølgende tabel:

Gruppering	Datatype	Værdirum /udfaldsrum (informativ)
Universel datatype	rdfs:Literal	Angiver foreningsmængden af alle øvrige datatyper
XML Literaler	rdf:XMLLiteral	Datatype for repræsentation af XML-indhold.
Reelle tal, Decimaltal og heltal	owl:real	Reelle tal
	owl:rational	Rationale tal
	xsd:decimal	Decimaltal
	xsd:integer	Heltal
	xsd:long	- 9223372036854775808…+922337203685477580 7 (64 bit)
	xsd:int	-2147483648…+2147483647 (32 bit)
	xsd:short	-32768…+32767 (16 bit)
	xsd:byte	-128…+127 (8 bit)
	xsd:nonNegativeInteger	Heltal ≥0
	xsd:nonPositiveInteger	Heltal ≤0
	xsd:positiveInteger	Heltal >0
	xsd:negativeInteger	Heltal <0
	xsd:unsignedLong	0…18446744073709551615 (64 bit)
	xsd:unsignedInt	0…4294967295 (32 bit)
	xsd:unsignedShort	0…65535 (16 bit)
	xsd:unsignedByte	0…255 (8 bit)
Flydende tal	xsd:double	64-bit flydende tal inclusive ±Inf, ±0, NaN
	xsd:float	32-bit flydende tal inclusive ±Inf, ±0, NaN
Tekststrenge	rdf:PlainLiteral	En tekststreng med en optionel anvendt tag for angivelse af det anvendte sprog.
	xsd:string	Tekststreng
	xsd:normalizedString	Whitespace-normaliseret tekststreng
	xsd:token	Tokenized tekststreng
	xsd:language	Sprogangivelse som defineret ved [BCP47]
	xsd:Name	XML Names
	xsd:NCName	XML NCNames
	xsd:NMTOKEN	XML NMTOKENs
	rdf:langString	Datatypen for tekststrenge med sprogangivelse
Boolske værdier	xsd: boolean	sand, falsk
Binære data	xsd:hexBinary	Hexadecimal-kodet binære data
	xsd:base64Binary	Base64-kodet binære data
IRIer	xsd:anyURI	Absolutte eller relative URIer og IRIer
Tidsangivelser	xsd:dateTime	Dato og time med eller uden tidszoneangivelse
	xsd:dateTimeStamp	Dato og time med tidszoneangivelse
	xsd:date	Dato (yyyy-mm-dd) med eller uden tidszoneangivelse
	xsd:time	Time (hh:mm:ss.sss…) med eller uden tidszoneangivelse

Bilag C: Begrebsmodellens oplysningstyper

En begrebsmodel kan udformes som en begrebsliste eller et begrebsdiagram - eller begge dele. Repræsenteres begrebsmodellen som en begrebsliste udtrykkes den i tabelformat eller efter ISO 10241. Repræsenteres begrebsmodellen med et begrebsdiagram i en UML-pakke udtrykkes det som et UML-klasse- og objektdiagram iht. regel 1.

Dokumentationen af en begrebsmodel består af to dele: For det første skal modellen forsynes med forretningsmetadata. For det andet beskrives hvert begreb med dækkende definitioner og termer, som afspejler forretningens sprogbrug.

De obligatoriske felter i markeres med en asterisk (*)

Første del: Metadata (på hver model):

• Namespace (namespace) - logisk område, angivet ved HTTP-URI indenfor hvilket begreber navngives unikt, og som tjener som overordnet reference til de navngivne elemente
• Modelnavn (label)* - betegnelse for modellen
• Beskrivelse (comment)* - beskrivelse af modellens formål og indhold
• Modelsprog (language) * - angivelse af modellens primære sprog
• Modelomfang (modelScope) * - angivelse af en models omfang og orientering mod enten et bestemt emne eller en bestemt anvendelse
• Emne (theme) *- emneområde som forvaltes af en given forretning
• Godkendelsesstatus (approvalStatus) * - angivelse af hvorvidt en model er accepteret og erklæret som gældende i et - for emneområdet - relevant forum
• Godkendt af (ApprovedBy) - angivelse af det emnespecifikke forum som har accepteret og erklæret modellen som gældende
• Modelansvarlig (responsibleEntity) * - organisation der står inde for modellens indhold og struktur på udstillingstidspunktet
• Modelstatus (modelStatus) *- status som angiver hvor komplet og færdig og dermed gyldig modellen er
• Versionnummer (versionInfo) * - unik identifikation af en specifik version
• Seneste opdateringsdato (dateModified) * - den dato hvor der senest blev foretaget ændringer
• Ændringshistorik (versionNotes) - beskrivelse af de ændringer de ændringer der er sket i denne version af modellen i forhold til den seneste version
• Juridisk kilde (hasLegalResource) - reference til lovgrundlag hvorfra ressourcen er afledt
• Kilde (source) - reference til ressource hvorfra en given ressource er afledt
• Afledt af (wasDerivedFrom) - angivelse af model eller det modelelement, som den aktuelle ressource er afledt af

Anden del: Oplysninger (for hvert begreb)

• Foretrukken term (prefLabel) * - betegnelse som foretrækkes anvendt for et givent begreb
• Accepterede termer (altLabel) - betegnelse som accepteres anvendt for et givent begreb
• Frarådede termer (deprecatedLabel) - betegnelse som ikke bør anvendes fordi den er uønsket, forkert eller forældet
• Definition (definition) *- beskrivelse af betydningen af et begreb
• Eksempel (example) - typisk forekomst der beskrives for at forklare eller anskueliggøre
• Kommentar (comment) - supplerende bemærkning eller oplysning vedrørende begrebet
• Anvendelsnote - note som beskriver hvordan et begreb skal anvendes og forstås i en bestemt anvendelseskontekst
• Juridisk kilde (hasLegalResource) - reference til lovgrundlag hvorfra ressourcen er afledt
• Kilde (source) - reference til ressource hvorfra en given ressource er afledt
• Tilhører emne (isDefinedBy) * - angivelse af om begrebet er defineret i den aktuelle model eller en anden
• Relationer - se nedenfor

Bemærk at oplysninger i tekstform angives med en sprogkode i parentes, og at blokken kan gentages for hvert sprog.

Relationer repræsenteres visuelt i et begrebsdiagram, men kan eventuelt beskrives tekstuelt i en begrebsliste. Denne udvidelse er mulig, men ikke påkrævet. Selvom begrebslisten typisk ikke favner relationer (deres navne og definitioner) kan begrebslisten suppleres af en relationsliste, som beskriver relationerne med samme sæt af oplysninger som begreber beskrives med, med tilføjelse af angivelse af hvilke to begreber relationen forbinder og i hvilken retning relationen skal forstås. Det er også muligt at udvide begrebslisten således at man i forbindelse med et begreb, til sidst beskriver hvilke relationer der forbinder det pågældende begreb med andre begreber.

Specifikation af begrebsliste i tabelformat

Første del med metadata om modellen opsættes som en tabel med oplysningens navn i første kolonne, og oplysningens værdi i anden kolonne. Disse oplysninger skal i øvrigt præsenteres i førnævnte rækkefølge. Anden del med selve begreberne opsættes også som en tabel således at hver række beskriver ét begreb. Tabellen opsættes med kolonneoverskrifter i den førnævnte rækkefølge.

Oplysninger markeret med stjerne (*) SKAL udfyldes. Der vil også være felter, hvor man har behov for at angive mere end én værdi, og i det tilfælde bør man anvende semikolon som separator. F.eks. Accepteret term (da) = vindmølle; vindturbine; vindkraftværk.

En begrebsliste orienteret mod international sammenhæng gentager blot kolonneoverskrifterne for begreber i forlængelse af de danske med en angivelse af det pågældende sprog, fx (en)

Man kan downloade et regneark der indeholder en skabelon til begrebslister i tabelformat via /node/566. Bemærk at kolonner der ikke er obligatoriske kan skjules.

Specifikation af begrebsliste efter ISO-standard 10241

Sektionen med metadata om modellen opsættes som en liste med oplysningens navn efterfulgt af værdien. Disse oplysninger skal i øvrigt præsenteres i førnævnte rækkefølge. Bemærk at kommentarer samt angivelse af om begrebet er “ejet eller fremmed”, og eventuelt beskrivelse af begrebets relationer til andre begreber efter denne standard bør angives som kommentarer med ‘NOTE -’.

Begrebslisten struktureres efter international terminologistandard ISO 10241:2011 som publiceres og markedsføres af den internationale standardiseringsorganisation ISO.

Begrebsmodel repræsenteret ved begrebsdiagram i UML

Repræsenteres begrebsmodellen med et begrebsdiagram i en UML-pakke udtrykkes som et UML-klasse- og objektdiagram iht. regel 1.

Bilag D: Ordliste

Foretrukken term (da)	Accepteret term (da)	Definition (da)	Kilde	Foretrukken term (en)
anvendelsesmodel		model, som er rettet mod en specifik anvendelsessituation i en afgrænset kontekst.	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	application model
begreb		mental forestilling om et bestemt fænomen med dettes karakteristiske træk	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	concept
begrebsdiagram		repræsentation af en begrebsmodel udtrykt som et diagram	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	concept diagram
begrebsliste		repræsentation af en begrebsmodel udtrykt på listeform	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	concept list
begrebsliste i tabelformat		begrebsliste som er udtrykt i en tabelstruktur defineret af modelreglerne	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	tabular concept list
datamodel		model som beskriver de data, der indgår i en afgrænset kontekst	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	data model
datatypeegenskab		egenskab, hvor udfaldsrummet er en værdi	https://www.w3.org/TR/owl-ref/	datatype property
egenskab		svarer til UML's Property og udtrykkes enten som associationsender eller attributter.	https://www.w3.org/TR/rdf11-concepts/	RDF property
fysisk model		datamodel som beskriver datas fysiske struktur rettet mod teknisk implementering	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	physical data model
informationsmodel		vidensorganiserende model som beskriver forretningsviden og som supplerer begreber med forretningsregler	https://www.kombit.dk/sites/default/files/user_upload/documents/Vidensce...	information model
ISO-begrebsliste		begrebsliste som er udtrykt i en tabel struktureret efter international terminologistandard ISO 10241:2011	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	ISO concept list
kernemodel		genbrugelig model over et emneområde som ikke definerer modelelementer, der er defineret i andre kernemodeller	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	core model
logisk datamodel		logisk model som er udarbejdet med henblik på dataudveksling eller lagring af data.	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	logical data model
model		objekt der repræsenterer en entitet ved at besidde en ægte delmængde af dens egenskaber	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	model
modelkatalog	katalog over begrebs- og datamodeller	platform til indsamling og udstilling af begrebsmodeller, informationsmodeller, klassifikationsmodeller og logiske datamodeller der er udarbejdet og/eller kan genbruges i offentligt regi	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	model catalogue
modellering		dét at lave en model af noget	http://arkitekturguiden.digitaliser.dk/	modeling
objektegenskab		egenskab, hvor værdien er et objekt	https://www.w3.org/TR/owl-ref/	object property
ressource		klassen der omfatter alt: alle andre klasser, alle instanser, alle datatyper og alle egenskaber	https://www.w3.org/TR/rdf-schema/	RDFS resource
terminologisk begrebsmodel	begrebsmodel; begrebssystem	vidensorganiserende model der beskriver begreber og deres indbyrdes relationer	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	terminological concept model
UML navngivet element	navngivet element	UML-element i en UML-model som kan gives en betegnelse	http://www.omg.org/spec/UML/2.5/PDF/	UML named element
UML-association	association	UML-element som anvendes til at relatere klasser til hinanden	http://www.omg.org/spec/UML/2.5/PDF/	association
UML-associationsende	associationsende, associationsrolle	UML-element som anvendes til at beskrive de af en klasses egenskaber som har et udfaldsrum, der er et (forretnings)objekt	http://www.omg.org/spec/UML/2.5/PDF/	association end
UML-attribut	attribut	UML-element som anvendes til at beskrive de af en klasses egenskaber som har et udfaldsrum, der er en værdi	http://www.omg.org/spec/UML/2.5/PDF/	attribute
UML-diagram	diagram	repræsentation af hele eller dele af en UML-model, hvor hvert grafisk symbol repræsenterer elementer i UML-modellen	http://www.omg.org/spec/UML/2.5/PDF/	UML diagram
UML-egenskab	egenskab	egenskab som udtrykkes enten som en UML-associationsende eller UML-attribut	http://www.omg.org/spec/UML/2.5/PDF/	UML property
UML-element	element	element som indgår i en UML-model		UML element
UML-generalisering	generalisering; ISA-relation; nedarvningsrelation	UML-element som anvendes til at relatere en underordnet klasse til en overordnet klasse	http://www.omg.org/spec/UML/2.5/PDF/	generalization
UML-instansspecifikation	instanspecifikation	specifikation som anvendes til at repræsentere instanser af klasser i en UML-model	http://www.omg.org/spec/UML/2.5/PDF/	UML instance specification
UML-klasse	klasse	UML-element som anvendes til at beskrive en mængde af objekter	http://www.omg.org/spec/UML/2.5.1/PDF	UML class
UML-klasse- og objektdiagram	klasse- og objektdiagram	et UML-diagram hvor der indgår både klasser og objekter		UML class and object diagram
UML-klassediagram	klassediagram	UML-diagram hvor de primære symboler er klasser	http://www.omg.org/spec/UML/2.5/PDF/	UML class diagram
UML-komposition	komposition	associationsende som indikerer at det ene element tilhører det andet og ikke kan eksistere uden dette		UML composition
UML-model	model	model som består af UML-elementer, herunder pakker, klasser og associationer	http://www.omg.org/spec/UML/2.5.1/PDF	UML model
UML-multiplicitet	multiplicitet; kardinalitet	begrænsning på antallet af forekomster af de pågældende UML-elementers deltagelse i en association ved angivelse af øvre og nedre grænseværdi	http://www.omg.org/spec/UML/2.5/PDF/	multiplicity
UML-navn	UML-elementnavn	betegnelse som navngiver et konkret UML-element	http://www.omg.org/spec/UML/2.5/PDF/	UML name
UML-objekt	objekt	UML-element som anvendes til at beskrive en konkret forekomst af noget (instansspecifikation)	http://www.omg.org/spec/UML/2.5/PDF/	object
UML-pakke	modelpakke	UML-element som kan indeholde andre UML-elementer, og som karakteriserer disse i sammenhæng	http://www.omg.org/spec/UML/2.5/PDF/	UML package
UML-profil	profil	forhåndsdefineret sæt af stereotyper og tag-definitioner som tilsammen specialiserer UML til en bestemt anvendelse	http://www.omg.org/spec/UML/2.5/PDF/	UML profile
UML-profilfil	profilfil	XML-dokument (xmi) der implementerer en UML-profil til anvendelse i et UML-modelleringsværktøj	http://www.omg.org/spec/UML/2.5/PDF/	UML profile file
UML-stereotype	stereotype	udvidelse af specifikationen af et UML-element, som specificerer dens anvendelse til en bestemt betydning og kontekst	http://www.omg.org/spec/UML/2.5/PDF/	stereotype
UML-tag	tag, tag definition	udvidelse af specifikationen af et UML-element ved tilføjelse af egenskaber ved UML-modelelementer	http://www.omg.org/spec/UML/2.5/PDF/	tag
UML-tagged value	tagged value	værdi for egenskab (tag) som tilknyttes et modelelement	http://www.omg.org/spec/UML/2.5/PDF/	tagged value
UML-tilknytningsklasse	UML-associationsklasse	UML-element som er både en klasse og en association og som karakteriserer selve relationen mellem to klasser	http://www.omg.org/spec/UML/2.5/PDF/	UML association class
vidensorganiserende model	vidensorganiserende system; KOS	model der organiserer viden om den virkelige verden	https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/mo...	knowledge organization model

Centrale forkortelser:

Kortform	Fuldform	Definition
ELI	European Legislation Identifier	identifikator som udpeger en given EU-lovgivning eller nationale lovtekst på en harmoniseret og stabil måde
FORM	Fælles Offentlig Reference Model	klassifikation over det offentliges opgaver, både i forhold til borgere og virksomheder, vedrørende internationale relationer og samfundsforhold, og endelig vedrørende de interne administrative opgaver
RDF	Resource Description Framework	international standardmodel og beskrivelsesramme, der giver entydig definition af data
RDFS	Resource Description Framework Schema	udvidelse af det basale RDF-vokabular som tilføjer elementer til vokabulardefinition i form af klasse, datatype og specialisering.
RDFS-Plus	RDF Schema plus selected terms from OWL	subset af OWL som er mindre komplekst end OWL, men mere ekspressivt end RDFS
OWL	Web Ontology Language	OWL er en gruppe af videnrepræsentations- og vokabulardefinerende sprog for skabelse af ontologier baseret på RDF.
UML	Unified Modelling Language	en standard for udseende af diagrammer til beskrivelse af strukturer og forløb i objekt-orienterede softwaresystemer, udviklet af Object Management Group (OMG).
XML	Extensible Markup Language	tekstbaseret format til dataudveksling iht. standarden https://www.w3.org/TR/xml/

Litteraturliste

Allemang, Dean (2008): “Semantic Web for the Working Ontologist", Morgan Kaufmann Publishers

Ambler, Scott (2005): “The Elements of UML (TM) Style”, Cambridge University Press

Dublin Core Metadata Initiative Usage Board (2014): "DCMI Metadata Terms (dct)" [Online]. (Senest tilgået 12-03-2019).

Digitaliseringsstyrelsen (2015): ”Grunddata Modelregler”, [Online]. (Senest tilgået 09-07-2021).

Digitaliseringsstyrelsen (2018): Retningslinjer for stabile HTTP-URIer, [Online].(Senest tilgået 12-03-2019).

Europa-Kommissionen INSPIRE (2007): The INSPIRE Directive - Infrastructure for spatial information in Europe, [Online] . (Senest tilgået 12-03-2019).

Europa-Kommissionen IDABC (2010): "European Interoperability Framework (EIF) for European public services", Annex 2 to the Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Regions 'Towards interoperability for European public services', [Online] . (Senest tilgået 12-03-2019).

Europa-Kommissionen ISA (2011): “D3.1 –PROCESS AND METHODOLOGY FOR CORE VOCABULARIES”, [Online].(Senest tilgået 12-03-2019)

Europa-Kommissionen ISA (2015): “Core vocabularies”, [Online].(Senest tilgået 12-03-2019).

Gómez-Pérez et al. (2011): "Style Guidelines for Naming and Labeling Ontologies in the Multilingual Web", Proc. Int’l Conf. on Dublin Core and Metadata Applications 2011, [Online]. (Senest tilgået 12-03-2019).

INSPIRE (2016): “Data Specifications”, [Online]. (Senest tilgået 12-03-2019).

ISO 639-1:2002 Language codes Part 1, [Online]. (Senest tilgået 12-03-2019).

ISO 704 Terminology Work - Principles and methods, [Online]. (Senest tilgået 12-03-2019).

ISO 1087-1 Terminology Work -- Vocabulary -- Part 1: Theory and application, [Online]. (Senest tilgået 12-03-2019).

ISO 10241 International terminology standards – Preparation and layout [Online]. (Senest tilgået 12-03-2019).

ISO 24156-1:2014 Graphic notations for concept modelling in terminology work and its relationship with UML -- Part 1: Guidelines for using UML notation in terminology work, [Online]. (Senest tilgået 12-03-2019).

Madsen, Bodil Nistrup (2007), ”Terminologi 1 - Principper og metoder”, Hans Reitzels Forlag.

OMG (2005): “OMG Unified Modeling Language TM (OMG UML) - version 2.0”, [Online] . (Senest tilgået 12-03-2019).

OMG-ODM: “Ontology Definition Metamodel, version 1.1” , [Online]. (Senest tilgået 12-03-2019).

OMG-XMI (2015): “XML Metadata Interchange”, [Online]. (Senest tilgået 12-03-2019).

Udbetaling Danmark, KL og KOMBIT (2015): ”Metodehåndbog - Begrebsmodeller, Informationsmodeller og Begrebsdefinitioner”. [Online]. (Senest tilgået 12-03-2019).

W3C (2002): "The OWL 2 Schema vocabulary (OWL 2)", [Online]. (Senest tilgået 12-03-2019).

W3C (2004): "Simple Knowledge Organization System (skos)", [Online]. (Senest tilgået 12-03-2019).

W3C (2012): “Web Ontology Language (OWL)”, [Online]. (Senest tilgået 12-03-2019).

W3C (2013a): "Asset Description Metadata Schema (ADMS)", [Online]. (Senest tilgået 12-03-2019).

W3C (2013b): "PROVenance Interchange (prov)", [Online] . (Senest tilgået 12-03-2019).

W3C (2014a): “Resource Description Framework (RDF)”, [Online] . (Senest tilgået 12-03-2019).

W3C (2014b): “RDF 1.1 Concepts and Abstract Syntax”, [Online]. (Senest tilgået 12-03-2019).

W3C (2014c): “RDF Schema 1.1”, [Online]. (Senest tilgået 12-03-2019).

W3C (2014d): “RDF 1.1 Turtle”, [Online].(Senest tilgået 12-03-2019).

W3C (2014e): “Best Practices for Publishing Linked Data” [Online]. (Senest tilgået 12-03-2019).

W3C (2014f):"Data Catalog Vocabulary (DCAT)", [Online]. (Senest tilgået 12-03-2019).

W3C (2015): “RDF vocabularies Current Status”, [Online]. (Senest tilgået 12-03-2019).

W3C (2017): "Data on the Web Best Practices", [Online] . (Senest tilgået 12-03-2019).