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:
- At sikre at forretningsviden lægges til grund for datamodellering og udvikling
- At sikre sammenhængende data på tværs af den offentlige administration
- 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:
- 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.
- 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:
|
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:
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: |
|
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: |
|
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
- 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.
- 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:
- med klassifikationsemner defineret som instanser af en veldefineret klassifikationsemneklasse
- 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 |
|
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 |
|
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)
|
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).