Kapitel 1. Introduktion

Dette er Modelregler for grunddata version 2. Reglerne er udarbejdet af en arbejdsgruppe nedsat af Grunddata Arkitekturforum og reglerne er godkendt af Styregruppen for Grunddata den 18. marts 2022.

Grunddata er data om personer, ejendomme, adresser, virksomheder, geografi samt vand og klima. De er vigtig fællesoffentlig digital infrastruktur, som leverer datafundamentet til den offentlige forvaltning og private virksomheder.

Grunddata effektiviserer forvaltningen ved, at registreringer foregår i ét register og genbruges i et andet. Det stiller krav til, at data er standardiserede og i høj kvalitet, samt at samarbejdet mellem registre og anvendere er tæt for, at der også i fremtiden skabes værdi hos anvenderne.

Data udstilles samlet på én platform, Datafordeleren, og er organiseret i en fællesoffentlig governance med både registre og anvendere.

Grunddata omhandler forskellige forretningsdomæner, der er relateret til hinanden og på visse områder overlappende. De enkelte forretningsdomæner er således dokumenteret ved egne domænemodeller. For at kunne skabe en samlet datamodel for grunddata, bestående af de enkelte domænemodeller, som fremstår sammenhængende for interessenterne, er det vigtigt at sikre, at man har en fælles tilgang til modelleringsopgaven. Modelreglerne sikrer, at modelleringen af domænemodeller sker ud fra et fælles sæt retningslinjer, og at hele grunddatamodellen bygger på fælles grundegenskaber.

Den samlede grunddatamodel består derfor af de sammensatte domænemodeller. Grunddatamodellen kan bruges til, at:

  • få overblik over grunddata og de informationer de enkelte domænemodeller indeholder

  • se hvordan data hænger sammen på tværs af forretningsdomænerne

Erfaringer med modellering af grunddata efter reglerne i version 1.2, og erfaringer med faktisk brug af grunddata er opnået. Samtidigt er de fællesoffentlige regler for begrebs- og datamodellering kommet til, som har til formål at sikre, at begreber og data modelleres og dokumenteres med henblik på genbrug. Disse to forhold gav behov for opdatering af modelreglerne til version 2.

Opdateringen til version 2 indbefatter indarbejdning af modelleringserfaringerne samt en ensretning (profilering) i forhold til de fælles offentlige regler for begrebs- og datamodellering.

Endelig har kravet om, at grunddata skal understøtte bitemporalitet skabt forvirring hos både registerejere og anvendere. Særligt i de tilfælde hvor grunddataregistre ikke har et forretningsbehov for at understøtte virkningshistorik. Her har kravet om bitemporalitet ikke givet mening i en forretningskontekst. SDFE nedsatte en arbejdsgruppe i efteråret 2020 til at belyse problemet nærmere og komme med anbefalinger til løsninger. Nærværende opdaterede modelregler for grunddata tager hånd om de anbefalinger, som vedrører datamodelleringen af grunddata.

Modelreglerne sikrer, at modelleringen af dataobjekter sker ud fra et fælles sæt retningslinjer, at hele modellen bygger på fælles grundegenskaber samt, at grunddata hentet i Datafordeleren er dokumenteret på en ensartet måde.

Kapitel 2. Læsevejledning

2.1. Formatet på reglerne

Reglerne i dette dokument er i høj grad opstillet i lighed med de Fællesoffentlige regler for begrebs- og datamodellering (FDA-reglerne) version 2.1. Dette er gjort for at skabe en større genkendelighed mellem reglerne for dem, der arbejder med datamodellering.

Hver regel i disse grunddatamodelregler har et tilhørende unikt nummer angivet før hvert regelnavn. Under den specifikke regel følger et afsnit med rationale og implikationer af den pågældende regel. Derefter ses konkrete eksempler, der illustrerer opfyldelsen af reglen.

Slutteligt vil det være angivet, hvis den pågældende regel kommer fra FDA-reglerne og i så tilfælde, hvilken FDA-regel grunddatamodelreglen baserer sig på.

2.2. Notation

Reglerne følger en standardiseret notation for at skabe en entydig forståelse af hvilke krav, der er til regelopfyldelsen.

Hver regel følger nedenstående notation:

  • skal indikerer, at noget er påkrævet

  • må ikke indikerer, at noget ikke er tilladt

  • må kun eller må kun…​hvis…​ indikerer, at noget er tilladt i tilfælde af en fremsat betingelse

  • må (godt) eller kan (godt) indikerer, at noget er tilladt men ikke påkrævet

  • behøver ikke eller behøves ikke indikerer, at noget ikke er påkrævet

  • bør indikerer, at noget er anbefalet men ikke påkrævet

2.3. Tre typer af regler

Grunddatamodelreglerne er opdelt i tre sektioner med hvert deres kapitel. Denne opdeling er lavet for at skabe overskuelighed i læsningen og skelnen mellem reglerne. Det drejer sig om nedenstående:

  1. Regler for modeller, som har til formål at sikre at domænemodeller dokumenteres grundigt og ensartet via en række metadata på modelniveau.

  2. Regler for modelelementer, som har til formål at sikre, at modelelementer (klasser, egenskaber og relationer mm.) dokumenteres grundigt og ensartet via en række metadata på modelelementniveau.

  3. Regler for grunddataegenskaber, som har til formål at sikre interoperabilitet på tværs af domænemodeller ved at en række fælles generelle og standardiserede egenskaber skal anvendes i modelleringen.

2.4. Kapitelbeskrivelse

Dokumentet har følgende indhold:

Kapitel 1 - Introduktion

Her beskrives baggrunden for revisionen og formålet med reglerne.

Kapitel 2 - Læsevejledning

Her beskrives indholdet af reglerne, og hvordan de læses.

Kapitel 3 - Anvendelse af de Fællesoffentlige regler for begrebs- og datamodellering

Her forklares anvendelsen af FDA reglerne i tilblivelsen af denne version af grunddatamodelreglerne.

Kapitel 4 - Regler for modeller

I dette kapitel opstilles alle modelreglerne, som har fokus på datamodellens udformning, dokumentation og læsbarhed. Her opstilles regler for bl.a. modelleringssprog, ejerskab, sprog og anden dokumentation mv.

Kapitel 5 - Regler for modelelementer

I dette kapitel opstilles alle modelelementreglerne, som har fokus på de enkelte elementers udformning og dokumentation.

Kapitel 6 - Regler for grunddataegenskaber

I dette kapitel opstilles regler, som har fokus på indhold i domænemodellen, og som sætter rammer for dataindhold i forretningsobjekterne. Her opstilles regler med betydning for bl.a. grunddataobjekters identifikation og historik. Reglerne udmøntes i specificering af generelle egenskaber for alle modelentiteter.

Kapitel 3. Anvendelse af Fællesoffentlige regler for begrebs- og datamodellering

De Fællesoffentlige regler for begreb- og datamodellering (FDA-reglerne) har til formål at højne kvaliteten og fremme genbrug af begreber og datamodeller på tværs af den offentlige sektor.

Det er ønskeligt for såvel registerejere, modellører, udviklere og anvendere, at modelleringen af grunddata er sammenhængende med den øvrige datamodellering i det offentlige. Dels for at lette brugen af grunddata i flest mulige situationer, dels for at modellører og andre datakyndige i det offentlige ikke skal forstå og anvende unødigt mange forskellige regelsæt.

For at sikre grunddatamodellens særligt høje grad af sammenhæng, er det dog nødvendigt med enkelte tilføjelser og præciseringer, hvorfor denne profil er udarbejdet. Eksempelvis fokuserer disse regler for modellering af grunddata mere snævert på anvendelsesmodeller og stiller krav til logiske datamodeller.

Størstedelen af reglerne i dette dokument er en tilpasning af FDA-reglerne ud fra betragtningen om, hvad der er behov for i udformningen af domænemodellerne for grunddata. Yderligere indeholder dokumentet regler for grunddataegenskaber, som FDA-reglerne ikke beskæftiger sig med.

I nærværende modelregler vil man således opleve, at nogle regler fra FDA-reglerne er udeladt, andre er overført mere eller mindre direkte, mens de fleste er tilpasset til grunddata.

De Fællesoffentlige regler for begrebs- og datamodellering version 2.1 er tilgængelige på http://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering

Kapitel 4. Regler for modeller

4.1. 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:

UML’s klassediagrammer 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-klassediagrammer skal anvendes til visuelle repræsentationer (diagrammer) af logiske modeller.

Tilpasset fra FDA version 2.1 regel nummer 1.

4.2. Brug kun udvalgte UML-elementer

Regel:

Alle modeller skal defineres som UML-pakker med klassediagrammer, udelukkende bestående af UML-elementerne ‘Klasse’, ‘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.

Associationer skal udstyres med både navne (inkl. læseretning) og mindst én associationsende.

Datatyper skal angives for alle egenskaber.

Multiplicitet skal angives for alle egenskaber (associationsender og egenskaber).

Rationale:

For at modeller entydigt skal kunne beskrive de fælles grunddata, 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-klassediagrammer skal anvendes til at udtrykke logiske datamodeller. Følgende UML-elementer kan anvendes:

  • pakke (Package)

  • klasse (Class)

  • generalisering/specialisering (Generalization)

  • association (Association)

  • komposition (Composition)

  • tilknytningsklasse/associationsklasse (Association class)

  • attribut (Attribute)

  • associationsende (Association End/Role)

  • multiplicitet (Multiplicity)

  • enumeration (Enumeration)

  • primitiv datatype (PrimitiveType) (en datatype uden attributter), se tilladte typer i 'Brug standardiserede primitive datatyper'

  • struktureret datatype (DataType) (kaldet en struktureret datatype er en datatype med attributter)

  UML typer 5 med ano1

Tilpasset fra FDA version 2.1 regel nummer 2.

4.3. Brug UML-stereotyper

Regel:

Følgende stereotyper skal angives for modeller:

  • logiske datamodeller - Oprettes som pakker med stereotypen «DKDomænemodel»

  • klassifikationsmodeller - Oprettes som pakker med stereotypen «DKKlassifikationsmodel»

Følgende stereotyper skal anvendes for modelelementer:

  • «DKObjekttype» påføres klasser i logiske datamodeller

  • «DKDatatype» påføres strukturerede datatyper i logiske datamodeller

  • «DKEgenskab» påføres egenskaber i logiske datamodeller

  • «DKEnumeration» påføres enumerationer i klassifikationsmodeller

  • «DKKodeliste» påføres kodelister i klassifikationsmodeller

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, der gør dem selvforklarende udenfor 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 skal udstyres med stereotyper og tags.

Modellens type indikeres ved hjælp af pakkens stereotype.

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

Eksempler:

UML typer 5 med stereotyper

Domænemodeller for Grunddata er logiske datamodeller som har til formål at beskrive indhold og struktur af Grunddata som bl.a. er tilgængelig på Datafordeleren. Bagved de enkelte grunddataregistre er der ofte en grundlæggende begrebs- og/eller informationsmodel, der beskriver de forretningsmæssige informationer. Ofte vil der være en en-til-en relation mellem forretnings- og dataobjekttyperne i hhv. informationsmodellen og den logiske datamodel. Dog er det ikke et krav, at der skal være en en-til-en sammenhæng. Tilfældet kan også være, at en egenskab i en informationsmodel bliver et selvstændigt dataobjekt i den logiske datamodel og omvendt kan et forretningsobjekt modelleres som en egenskab på et dataobjekt.

Eksempelvis kan en persons efternavn være modelleret som en forretningegenskab til et forretningsobjekt mens det i den logiske datamodel vil være repræsenteret ved sin egen objekttype med tilhørende grunddataegenskaber.

Tilpasset fra FDA version 2.1 regel nummer 3.

4.4. Angiv meningsfyldte navne og beskrivelser for modeller

Regel:

Modellen skal forsynes med et meningsfyldt navn og angivelse af dansk som modellens primære sprog.

Modellen skal forsynes med en beskrivelse.

Modellens scope skal angives.

Rationale: 

Det er hensigtsmæssigt, at modellen gives et meningsfyldt og anvendelsesneutralt navn samt en kort beskrivelse, da det er intentionen, at modellen skal kunne læses, anvendes og genbruges af andre. Det vil ligeledes 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 emneområde og/eller det centrale forretningsbegreb. Derudover skal modellen forsynes med en kort beskrivelse af modellens formål og indhold.

Der kan også, som en 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 en juridisk kilde i form af en HTTP-URI, jf. 'Angiv modellens lovgrundlag og kilde'. Til et meningsfyldt navn, anbefales at tage udgangspunkt i det element, der er i fokus for modellen.

Reglen opfyldes ved at angive modellens navn, beskrivelse, modelsprog og modelomfang ved hjælp af ‘modelnavn’, ’kommentar’, ’modelsprog’ og ’modelScope’ (skal angives til ApplicationModel (anvendelsesmodel)).

Modelegenskab: modelnavn

Modeltag:

title (da/en)

Definition:

det eller de ord, der betegner en model

Udfaldsrum:

tekst

Kilde:

http://www.w3.org/2000/01/rdf-schema#label 24 human-readable name for the subject.

Modelegenskab: beskrivelse

Modeltag:

description (da/en)

Definition:

beskrivelse af modellens formål og indhold

Udfaldsrum:

tekst

Kilde:

https://dublincore.org/specifications/dublin-core/dcmi-terms/#description 5 An account of the resource.

Modelegenskab: modelsprog

Modeltag:

language (=da)

Definition:

angivelse af modellens primære sprog, som UML-repræsentationen fremhæver

Udfaldsrum:

I henhold til RFC5646 angives sprog med ISO 639-1 (’da’) RFC5646

Kilde:

http://purl.org/dc/terms/language [6]_A language of the resource._

Modelegenskab: modelomfang

Modeltag:

modelScope

Definition:

angivelse af en models omfang og orientering mod enten et bestemt emne eller en bestemt anvendelse

Udfaldsrum:

application model (anvendelsesmodel)

Kilde:

https://data.gov.dk/model/core/modelling#modelscope The scope and orientation of a model.

Eksempel:

title (da) = Elproduktionsanlæg

description (da) = Model for elproducerende kraftværk

language = da

modelScope = application model

Tilpasset fra FDA version 2.1 regel nummer 6.

4.5. Angiv identifikation af modeller

Regel: 

Modeller skal gives entydig identifikation.

Logiske datamodeller for grunddata skal tilhøre domænet https://data.gov.dk/model/profile.

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.

Implikationer: 

Reglen overholdes dels ved at angive den valgte HTTP-URI i tagget 'namespace' og dels ved at angive et prefix (kort betegnelse for modellen) i tagget 'namespacePrefix'. Den valgte HTTP-URI fungerer både som entydig identifikator for selve pakken og som det namespace, pakkens egendefinerede elementer er tilknyttet.

Logiske datamodeller for grunddata skal tilhøre domænet https://data.gov.dk/model/profile. Domænets opbygning overholder 'Retningslinjer for stabile http-URIer' 4.

Modelegenskab: model identifikation

Modeltag:

namespace

Definition:

logisk område, indenfor hvilket elementer navngives unikt, og som tjener som overordnet reference til de navngivne elementer

Udfaldsrum:

HTTP-URI

Kilde:

Modelegenskab: namespacepræfiks

Modeltag:

namespacePrefix

Definition:

forkortet betegnelse for et namespace

Udfaldsrum:

tekst

Kilde:

https://vocab.org/vann/#preferredNamespacePrefix
(preferred namespace prefixe)

For UML-modeller: Udfyld tags ‘namespace’ og ‘namespacePrefix’ på modelpakken

Eksempler: 

namespacePrefix = ensupplfac

Tilpasset fra FDA version 2.1 regel nummer 7.

4.6. 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.

Ejeren 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 (Indenrigs- og Boligministeriet og Klima-, Energi- og Forsyningsministeriet) 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’.

Modelegenskab: modelansvarlig

Modeltag:

responsibleEntity

Definition:

organisation der står inde for modellens indhold og struktur på udgivelsestidspunktet

Udfaldsrum:

Navn på organisation i klar tekst

Kilde:

http://purl.org/vocab/frbr/core#responsibleEntity# 15 An entity in some way responsible for an endeavour

Eksempler:

 I UML-model:  responsibleEntity (modelansvarlig) = Energistyrelsen

Tilpasset fra FDA version 2.1 regel nummer 8.

4.7. Angiv emneområde for modellen

Regel: Et emneområde skal angives til modellen.

Rationale: 

Ved at klassificere modellerne efter emneområde, i henhold til en fællesoffentlig referencemodel, lettes fremsøgning, genbrug og anvendelse af udstillede modeller. Det giver brugeren mulighed for at bruge emneområderne 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’.

Modelegenskab: emne

Modeltag:

theme

Definition:

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:theme25 The main category of the dataset

  • UML-modeller: Udfyld tagget 'theme' (emne) på modellens pakke

Eksempel: 

Tilpasset fra FDA version 2.1 regel nummer 9.

4.8. Angiv modellens version

Regel:

Modellens seneste opdateringsdato og versionsnummer skal angives.

Ændringshistorik må kun være angivet, såfremt modellens version ikke er den første godkendte version.

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. Ændringshistorik skal angives, når der er sket en ændring ift. seneste godkendte version. Ændringshistorikken er en kort beskrivelse af versionen og evetuelle ændringer, der er sket siden sidste version.

Implikationer: 

Reglen opfyldes ved at angive modellens versionsnummer, seneste opdateringsdato og ændringshistorik.

Modelegenskab: seneste opdateringsdato

Modeltag:

modified

Definition:

den dato hvor der senest blev foretaget ændringer

Udfaldsrum:

dato (Date)

Udfaldsrum opbygget iht. xsd:date 26 (YYYY-MM-DD)

Kilde:

dct:dateModified 7 Date on which the resource was changed

Modelegenskab: versionsnummer

Modeltag:

versionInfo

Definition:

unik identifikation af en specifik version

Udfaldsrum:

Udfaldsrum opbygget med en:

* MAJOR-version,

* MINOR-version og

* PATCH adskilt med punktum, fx: 1.0.0

Udfaldsrum opbygget iht. semver.org 23

Kilde:

owl:versionInfo 30 The annotation property that provides version information for an ontology or another OWL construct

Modelegenskab: ændringshistorik

Modeltag:

versionNotes (da/en)

Definition:

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 27 A description of changes between this version and the previous version of the Asset

Eksempler: 

modified = 2021-06-03

versionInfo = 2.3.0

versionNotes = Egenskaben "fabrikat" tilføjet klassen "Nacelle".

Tilpasset fra FDA version 2.1 regel nummer 10.

4.9. Modellen skal godkendes

Regel:

Alle nye domænemodeller skal godkendes af Grunddata Arkitekturforum.

Alle ændredede domænemodeller med MAJOR1 eller MINOR2 ændringer skal godkendes af Grunddata Arkitekturforum.

Ændredede domænemodeller med PATCH3 ændringer skal godkendes af Modelsekretariatet.

Rationale: 

Et vigtigt element for domænemodellerne er, at de kan sammenholdes på tværs af domæneområder. For at en sammensætning kan ske med succes, er det vigtigt, at modellerne er ensartede og kombinerbare. Grunddatamodelregler skal sikre dette. Det er Grunddata Arkitekturforums opgave at kontrollere om reglerne er overholdt. At en offentliggjort domænemodel er kvalitetssikret af Grunddata Arkitekturforum er en væsentlig oplysning for brugeren af domænemodellerne. Derfor denne regel om, at oplysning om Grunddata Arkitekturforums godkendelse skal fremgå af modellen.

En godkendelse omfatter dels den modeltekniske godkendelse ift. modelreglerne samt den forretningsmæssige godkendelse. Forretningsgodkendelsen skal sikre at domænemodellen repræsenterer den forretning, som modellens grunddata indgår i. En godkendelse er derfor betinget af, at registerejer kan dokumentere over Grunddata Arkitekturforum, at der i forbindelse med modellens tilblivelse eller ændring, er inddraget relevante forretningsmæssige overvejelser bl.a. hensyn til aktører såsom anvenderne.

Implikationer: 

Nedenstående informationer skal angives til modellen.

Modelegenskab: godkendelsesstatus

Modeltag:

approvalStatus

Definition:

status som angiver hvorvidt en model er godkendt og erklæret som gældende af Grunddata Arkitekturforum

Udfaldsrum:

approved (godkendt): status som angiver at en model er godkendt og erklæret som gældende

Kilde:

voag:hasApprovalStatus

Modelegenskab: godkendt af

Modeltag:

approvedBy

Definition:

angivelse af Grunddata Arkitekturforum som har godkendt 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

Eksempler: 

approvalStatus = approved

approvedBy = Grunddata Arkitekturforum

approvedBy = Grunddata Modelsekretariatet

Tilpasset fra FDA version 2.0 regel nummer 11.

1 Opdatering af tjenester er nødvendig

  • Gamle tjenester kan ikke ”finde” nødvendige model-elementer i opdateret model

  • En ikke-bagud-kompatibel ændring

  • Indstilling til afgørelse laves af modelsekretariatet, indstillingen vurderes af Grunddata Arkitekturforum og Grunddata Arkitekturforum foretager den endelige beslutning.

2 Opdatering af tjenester er mulig men ikke nødvendig

  • Der er kun tilføjet model-elementer i modellen

  • En bagud-kompatibel ændring

  • Gamle tjenesteversioner kan vedblive at eksistere

  • Modelsekretariatet indstiller en beslutning til Grunddata Arkitekturforum, der foretager den endelige beslutning.

3 Tjenester uændrede

  • Fx opdateret dokumentation

  • Godkendes af modelsekretariatet, der orienterer Grunddata Arkitekturforum.

4.10. Angiv modellens modelstatus

Regel: Det skal angives, hvor komplet og færdig, og dermed hvor 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: 

Godkendte og udstillede domænemodeller kan kun have modelstatus stabil ("stable"). Forslag til domænemodeller, som sendes til Modelsekretariatet til konformanstjek, skal have angivet modelstatus som 'under udvikling' ("development"). Når modellen er godkendt ændrer Modelsekretariatet modelstatus til 'stabil' ("stable").

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

Modelegenskab: modelstatus

Modeltag:

modelStatus

Definition:

status som angiver modellens gyldighed, her forstået som hvor komplet og færdig, og dermed hvor anvendelig modellen er

Udfaldsrum:

  • development (under udvikling): modelstatus som indikerer, at modellen har en foreløbig og ukomplet udformning

  • stable (stabil): modelstatus som indikerer, at modellen er komplet, stabil og taget i brug

Kilde:

adms:status 28 The status of the Asset in the context of a particular workflow process

Eksempler: 

modelStatus = stable

Tilpasset fra FDA version 2.1 regel nummer 12.

4.11. Angiv modellens lovgrundlag og kilde

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

Rationale: 

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

Ved at synliggøre kilder, som modellen tager udgangspunkt i, fremmes ensartethed mellem modeller, der bygger på samme kilder.

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'.

Modelegenskab: juridisk kilde

Modeltag:

legalSource

Definition:

reference til lovgrundlag som danner grundlag for modellen

Udfaldsrum:

Angivelse af ELI-URI-referencer

Kilde:

http://data.europa.eu/m8g/hasLegalResource 11 It indicates the Legal Resource (e.g. legislation) to which the Public Service (red:resource) relates, operates or has its legal basis

Modelegenskab: kilde

Modeltag:

source

Definition:

reference til ressource som modellen baserer sig på

Udfaldsrum:

Overordnet tekstuel beskrivelse af nationale og internationale standarder samt øvrige kilder

Kilde:

http://purl.org/dc/terms/source A related resource from which the described resource is derived

Eksempler:

Tilpasset fra FDA version 2.1 regel nummer 13.

4.12. Modeller klassifikationer til genbrug

Regel: Klassifikationer skal enten:
  1. modelleres selvstændigt, så de kan genbruges i andre modeller eller

  2. referere til en online, maskin1- og menneskelæsbar2 klassifikation i et klassifikationsregister

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 optræder klassifikationsemnerne som værdier i en enumeration med stereotypen «DKEnumeration», og disse skal placeres i en selvstændig pakke med stereotypen «DKKlassifikationsmodel».

Hvis klassifikationen findes i et klassifikationsregister, skal en kodeliste med stereotypen «DKKodeliste» anvendes. Der skal henvises til den eksterne kodeliste.

Tilpasset fra FDA version 2.1 regel nummer 15.

1 f.eks. CSV, SKOS, XML

2 f.eks. PDF, html

4.13. God diagrammeringsskik

Regel:
  1. Nedarvning skal læses oppefra og ned

  2. Tekster (associationsender, tekster på associationer) skal være læsbare

  3. Følgende farver skal anvendes til de forskellige modelelementer:

    • Klasser: Sandfarvet (RGB: 254,250,247)

    • Indlånte klasser: Blå (RGB: 135,205,235)

    • Strukturerede datatyper: Gul (RGB: 251,249,198)

    • Enumerationer: Grøn (RGB: 232,253,227)

  4. Diagrammer bør ikke have mere indhold end, at det kan læses på en A4 side

  5. Relationer bør ikke krydse hinanden

  6. Relationer bør være vandrette eller lodrette linjer

Rationale:

Domænemodellerne (UML datamodeller) tjener to formål:

  1. At være grundlag for dannelsen af artefakter til fysisk implementering (databaseskema, xml-skema mm.)

  2. At udgøre dokumentation for registrets data med hensyn til indhold såsom struktur, relationer og egenskaber.

For at en domænemodel via dens diagrammer kan skabe en god kommunikation mellem registerejer og anvender er det vigtigt, at UML diagrammerne er læsbare og forståelige. Derfor oplistes i denne regel nogle basale konventioner for, hvordan diagrammer bør opstilles, så god kommunikation understøttes.

Implikationer:

Lav diagrammer til domænemodeller efter disse konventioner:

Nedarvning skal læses oppefra og ned
  • Rigtigt: specialisering

  • Forkert: specialisering forkert

Tekster (associationsender, tekster på associationer) skal være læsbare
  • Rigtigt: tekstergod

  • Forkert: teksterrod

Teksterne skal være frie fra klasser etc.

Diagrammer bør ikke have mere indhold end, at det kan læsespå en A4 side

Del op i flere diagrammer hvis indholdet ikke kan være i et diagram

Relationer bør ikke krydse hinanden
  • Rigtigt: relationer

  • Forkert: relationerX

Ofte er det muligt at omrokere klasser, så man undgår krysende relationer

Relationer bør være vandrette eller lodrette linjer
  • Rigtigt: relationer

  • Forkert: relationer ikkerette3

Ofte er det muligt at omrokere klasser, så relationer er vand- eller lodrette

Det er vigtigt at diagrammer i en model er sat op, så de er letlæselige, og understøtter forståelsen af indhold og sammenhænge i domænemodellen.

Kapitel 5. Regler for modelelementer

5.1. Angiv meningsfyldte UML-navne for modelelementer

Regel: 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 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, der afspejler den i emneområdet anvendte term, og udpeger det begreb, som elementet faktisk skal repræsentere, fx ‘Vindkraftanlæg’ [Allemang 2008:310].

Implikationer:

Modelelementer, herunder klasser, associationer, associationsender og egenskaber 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)

Tilpasset fra FDA version 2.1 regel nummer 16.

5.2. 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. W3C 2017 36.

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 som en fuldt kvalificeret HTTP-URI ved en sammensætning af:

  • Det namespace der identificerer den model elementet tilhører, jf. 'Angiv identifikation af modeller'.

  • Fragmentnavn som placeres efter skilletegnet (/), og som udgør det enkelte elements navn – som er unikt inden for namespacet.

Modelelementegenskab: URI

Modelelementtag:

URI

Definition:

entydig identifikation af en ressource, (en klasse, en instans, en egenskab, datatype eller en værdi)

Udfaldsrum:

HTTP-URI

Kilde:

https://www.w3.org/TR/ld-glossary/#uniform-resource-identifier 35
 

Notér at UML-elementet Generalisering (Generalization), som eneste UML-element, ikke forsynes med dette tag.

Eksempler: 

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

Fragmentnavnet for 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

Tilpasset fra FDA version 2.1 regel nummer 17.

5.3. 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 dermed ikke yderligere behandles for at kunne indgå og forstås som termer i en traditionel ordliste.

Implikationer: 

Det er de termer, som naturligt anvendes i emneområdet, der 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’.

Modelelementegenskab: foretrukken term

Modelelementtag:

prefLabel (da/en)

Definition:

term som vurderes at være det bedste af flere synonyme udtryk for et givet begreb

Udfaldsrum:

tekst

Kilde:

skos:prefLabel [31]

 

Modelelementegenskab: accepteret term

Modelelementtag:

altLabel (da/en)

Definition:

term hvis anvendelse godtages, men ikke foretrækkes

Udfaldsrum:

tekst

Kilde:

skos:altLabel [32]

 

Modelelementegenskab: frarådet term

Modelelementtag:

deprecatedLabel (da/en)

Definition:

term som ikke bør anvendes, fordi den er uønsket, forkert eller forældet

Udfaldsrum:

tekst

Kilde:

mdl:deprecatedLabel

UML-modeller: Udfyld tagget ‘prefLabel’ og evt. ‘altLabel’ og ‘deprecatedLabel' på modelelementet med termer som de naturligt anvendes i emneområdet.

Eksempler: 

prefLabel (da): vindkraftanlæg

altLabel (da): vindturbine

deprecatedLabel (da): vindmølle

Tilpasset fra FDA version 2.1 regel nummer 18.

5.4. 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:

  • Anvend et almindeligt udbredt tegnsæt (Unicode)

  • Anvend substantiver i ubestemt entalsform for klasser jf. Allemang 2008:311 og Ambler 2005:51

Logiske datamodeller:

  • Navne på klasser og objekter angives med med “UpperCamelCase” - dvs. med 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 egenskaber angives med “lowerCamelCase”, dvs. med 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. '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:

  • NavngivenVej (klassenavn)

  • Vindkraftanlæg (klassenavn)

  • identificeresVed (attributnavn)

Navne på associationer, associationsender og egenskaber angives med “lowerCamelCase” kan fraviges, hvis navnet på objektet i virkeligheden er navngivet og kendt under en term, som alene indeholder store bogstaver - eksempel CPR-nummer, CVR-nummer. I sådanne tilfælde bør modelelementet skrives med store bogstaver.
Tilpasset fra FDA version 2.1 regel nummer 19.

5.5. 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 reglen 'Udarbejd strukturerede definitioner på en standardiseret måde' og 'Udarbejd anvendelsesneutrale definitioner' supplerer denne regel ved at sætte krav til selve udformningen af definitionen.

Elementegenskaberne 'definition', 'kommentar' og 'eksempel' anvendes som vist herunder. Man kan, 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 i det it-system, hvor det skal anvendes.

Modelelementegenskab: definition

Modelelementtag:

definition (da)

Definition:

beskrivelse af betydningen af et begreb

Udfaldsrum:

tekst

Kilde:

skos:Definition 33  

Modelelementegenskab: kommentar

Modelelementtag:

comment (da)

Definition:

supplerende bemærkning eller oplysning vedrørende begrebet

Udfaldsrum:

tekst

Kilde:

rdfs:comment 29

Modelelementegenskab: eksempel

Modelelementtag:

example (da)

Definition:

typisk forekomst der beskrives for at forklare eller anskueliggøre

Udfaldsrum:

tekst

Kilde:

skos:example 34

Modelelementegenskab: anvendelsesnote

Modelelementtag:

applicationNote (da)

Definition:

note som beskriver, hvordan et modelelement skal anvendes og forstås i en bestemt anvendelseskontekst

Udfaldsrum:

tekst

Kilde:

Regel 20

Eksempler: 

definition (da) = kraftværk som omdanner vindenergi til elektricitet

comment (da) = vindkraftanlæg er typisk opført efter 1970

example (da) = vindmøllen i Tvind

applicationNote (da) = kun vindkraftanlæg på land indgår

Tilpasset fra FDA version 2.1 regel nummer 20.

5.6. Udarbejd strukturerede definitioner på en standardiseret måde

Regel:

Definitionen skal beskrive betydningen af et begreb således, at det klart afgrænses fra andre begreber.

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.

Rationale: 

Ved at udarbejde indholdsdefinitioner får man korte, klare og korrekte definitioner, som på entydig og robust vis formidler betydningen af et begreb, ligeledes undgås 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.

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 definition: 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 definition: vindkraftværk: vindmølle
    Definition ved angivelse af synonym - giver ingen yderligere forklaring

  • Dårlig definition: vindkraftværk: fx havvindkraftanlæg, vindkraftlanlæg i landzone
    Definition opremsning af underbegreber - er alle med og hvad er betydningen af disse?

  • Dårlig definition: 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 definition: vindkraftværk: består af tårn, nav og vinger
    Definition opremsning af bestanddele - er alle dele med?

Tilpasset fra FDA version 2.1 regel nummer 21.

5.7. 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).

Tilpasset fra FDA version 2.1 regel nummer 22.

5.8. Angiv modelelementers lovgrundlag

Regel: Sammenhængen mellem lovgrundlag og modelelementer skal dokumenteres ved at anføre referencer til lovgrundlag på elementniveau.

Sammenhængen mellem standarder på området og modelelementer kan dokumenteres ved at anføre referencer til relevanter standarder 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.

Implikationer: 

Termer og definitioner af begreber 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 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. 'Udarbejd strukturerede definitioner på en standardiseret måde'. 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 på, hvorfor den er uanvendelig.

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'.

Modelelementegenskab: juridisk kilde

Modelelementtag:

legalSource

Definition:

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 (https://www.retsinformation.dk/eli/about) 22

Kilde:

It indicates the Legal Resource (e.g. legislation) to which the Public Service (red:resource) relates, operates or has its legal basis

Modelelementegenskab: kilde

Modelelementtag:

source

Definition:

reference til ressource hvorfra begrebet er afledt

Udfaldsrum:

Udtrykkes på elementniveau ideelt set med en URI, men kan også være kildens navn

Kilde:

A related resource from which the described resource is derived 6

Eksempler: 

Tilpasset fra FDA version 2.1 regel nummer 23.

5.9. Brug standardiserede primitive datatyper

Regel: Standardiserede primitive datatyper fra ISO/Dansk Standard (DS) skal bruges.

Rationale: 

Logiske modeller bliver først udtømmende beskrivelser af data, når de angiver datatyper for egenskaber. 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 ISO/Dansk Standard (DS)

  • ISO/TC 211 Harmonized Model er en samling af datatyper, som er udviklet i forbindelse med håndtering af geografiske data - fx INSPIRE. Datatyperne kan tilgås fra https://github.com/ISO-TC211/HMMG [12]

En ikke-udtømmende liste over ISO og danske standarder, som kan anvendes til grunddata:

  1. DS/ISO 19103:2015 Geografisk information – Konceptuelt modelleringssprog

  2. DS/EN ISO 19107:2019 Geografisk information – Geometrimodel

  3. DS/ISO 639-2:2000 Sprogkoder - Del 2: Alfa-3 kode

  4. DS/EN ISO 3166-1:2020 Koder for navne på lande og deres underinddelinger – Del 1: Landekoder [21]

Tilpasset fra FDA version 2.1 regel nummer 27.

5.10. Angiv historikmodel for grunddataobjekttyper

Regel: Historikmodel skal angives til modelelementer af stereotypen DKObjekttype.

Rationale: 

Til grunddataregistre er der brug for differentiering af håndtering af historik. Der skelnes mellem tre typer:

  1. ingen historik

  2. registreringshistorik

  3. bitemporalitet

Nogle forretninger er opbygget sådan, at de indsamler og registrerer data med bestemte mellemrum, f.eks. indsamling af geodata vha. flyfotos. Det gør, at det ikke er muligt at fastslå, hvornår en ændring i virkeligheden har fundet sted. I sådanne registre har man heller ikke mulighed for at registrere data om fortiden. Man kan f.eks. ikke registrere i dag, at et hus så sådan og sådan ud fra 1980 til 1995. Andre typer forretninger er opbygget sådan, at noget først eksisterer, når det er registreret. Man er f.eks. først forsikret, når ens oplysninger står i it-systemet. I nogle forretninger er der m.a.o. ikke et forretningsbehov for virkningshistorik, eller muligheden for virkningshistorik er bevidst valgt fra. I disse tilfælde angives objekttypens historikmodel til "registreringshistorik".

I andre forretninger er det nødvendigt at kunne håndtere virkningshistorik for forretningsobjekterne, dvs. at forretningen skal kunne holde styr på både, hvordan deres forretningsobjekter var i fortiden, og på hvordan de er lige nu (og evt. også på hvordan de vil være i fremtiden, hvis relevant). I disse tilfælde angives objekttypens historikmodel til "bitemporalitet".

Der kan være tilfælde, hvor et register ikke håndterer historik. En objekttype med ingen historik er dog ikke en option for grunddata. Her vil som minimum registreringstiden forventes at være angivet.

Implikationer: 

Reglen opfyldes ved at angive historikmodel som modelelement egenskab. Opfyldelse af regel 'Grunddataobjekttyper bør understøtte virkningstid' skal ske i overensstemmelse med den angivne historikmodel.

Modelelementegenskab: historikmodel

Modelelementtag:

historikmodel

Definition:

model som anvendes til objekttypens historik.

Udfaldsrum:

  • registreringshistorik

  • bitemporalitet

Kilde:

Grunddata Arkitekturforum

Eksempler: 

historikmodel: bitemporalitet

Kapitel 6. Regler for egenskaber

6.1. Alle grunddataobjekttyper skal modelleres med persistent, unik identifikation

Regel: Alle grunddataobjekttyper af stereotypen DKObjekttype skal modelleres med persistent, unik identifikation.

Rationale: 

Alle dataobjekter, skal have et globalt unikt id, som ikke ændres i data-objektets levetid. Det er nødvendigt at have en unik identifikation af et dataobjekt på tværs af Grunddatamodellen, for at sikre en fælles høj datakvalitet.

Ofte vil dataobjektet, ud over den unikke identifikation, have en eller flere forretningsnøgler, for eksempel har en matrikel et matrikelnummer. Men forretningsnøglerne kan ikke stå alene, da Grunddatamodellen generelt skal understøtte historik, hvilket betyder, at dataobjektet kan have forskellige forretningsnøgler over tid, ligesom den samme forretningsnøgle løbende kan indgå i flere forretningsobjekter.

Derfor er det essentielt, at objektets identifikation er persistent i hele dataobjektets levetid.

Implikationer:

Hver UML-klasse med stereotypen DKObjekttype skal modelleres med følgende attribut:

Grunddataegenskab: id

Definition:

unik identifikation af objektet

Datatype:

Characterstring

Krav:

Obligatorisk

Multiplicitet:

1

Modeleksempler:

unik identifikation

Dataeksempler:

id = 811cd589-7d11-43e9-86a8-6c1e9c03e2ec

6.2. Alle grunddataobjekttyper skal understøtte registreringstid

Regel: Alle grunddataobjekttyper af stereotypen DKObjekttype skal modelleres med grunddataegenskaber for registreringstid.

Rationale: 

Det er vigtigt, at bevare datagrundlaget for (rets)reglers forvaltning, så man til enhver tid kan fremfinde de data, der var aktuelle engang, og man kan dokumentere trufne beslutninger over for borgere og virksomheder. Ved at håndtere registrering og afregistrering af dataobjektversioner ved hjælp af tidsstempling, gennemgår grunddataobjekterne en registreringshistorik, og man kan hermed leve op til forventningen om sporbarhed.

Derfor skal grunddataobjekter modelleres med et registreringstidsinterval - det vil sige tidsintervallet, hvor en version anses for at være ajour i informationssystemet.

En dataobjektversionregistrering foretages af en aktør (som kan være et it-system) og resulterer i en registreret dataobjektversion. Aktøren betegnes registreringsaktør.

Implikationer:

Hver UML-klasse med stereotypen DKObjekttype skal modelleres med følgende egenskaber:

Grunddataegenskab: registreringFra

Definition:

starttidspunkt af den registrerede dataobjektversions registreringstidsinterval

Datatype:

DateTime

Krav:

Obligatorisk

Multiplicitet:

1

Kilde:

http://link.til.begrebsmodel Begrebsmodel: Temporale begreber

Grunddataegenskab: registreringTil

Definition:

sluttidspunkt af den registrerede dataobjektversions registreringstidsinterval

Datatype:

DateTime

Krav:

Obligatorisk

Multiplicitet:

0..1

Kilde:

http://link.til.begrebsmodel Begrebsmodel: Temporale begreber

Grunddataegenskab: registreringsaktør

Definition:

aktør som foretager en registrering

Datatype:

Characterstring

Krav:

Obligatorisk

Multiplicitet:

1

Kilde:

http://link.til.begrebsmodel Begrebsmodel: Temporale begreber

Modeleksempler:

Registreringstid

Dataeksempler:

registreringFra = 2021-06-21T10:45

registreringTil = Null

registreringTil = 2021-08-21T11:57

registreringaktør = Geodatastyrelsen

registreringaktør = Matriklens informationssystem

6.3. Grunddataobjekttyper bør understøtte virkningstid

Regel: Alle grunddataobjekttyper af stereotypen DKObjekttype bør modelleres med grunddataegenskaber for virkningstid.

Fritagelse fra krav om angivelse af virkningstid skal godtgøres.

Hvis bitemporalitet er angivet som historikmodel til objekttype skal grunddataegenskaber for virkningstid angives.

Man må ikke angive grunddataegenskaber for virkningstid, hvis registreringstid er angivet som historikmodel til objekttype.

Rationale: 

Bestemte forretninger kan have behov for at kunne holde styr på både hvordan deres forretningsobjekter var i fortiden, hvordan de er lige nu, og evt. også hvordan de vil være i fremtiden. Man skal m.a.o. kunne holde styr på alle tilstande som et forretningsobjekt har befundet sig i, befinder sig i lige nu, og (evt.) vil befinde sig i ude i fremtiden; og ikke kun på forretningsobjektets nuværende tilstand. Et informationssystem der understøtter sådan en forretning giver mulighed for at registrere, hvornår i virkeligheden et forretningsobjekt har ændret sig.

Sådan en forretning er eksempelvis Danmarks Administrative Geografiske Inddeling (DAGI), hvis informationssystem giver mulighed for i dag at registrere, at to kommuner vil sammenlægges om f.eks. et år. Man kan både se, hvordan kommunernes grænser ser ud i dag, hvordan de så ud for et år siden, og hvordan de vil se ud om et år.

Et virkningstidsinterval er afgrænset af tidspunktet hvor tilstanden i virkeligheden begynder at eksistere, og tidspunktet hvor tilstanden stopper med at eksistere. virkningstidsintervallet angives med egenskaberne virkningFra og virkningTil.

Hvis et informationssystem understøtter virkningshistorik, skal der for grunddata, også registreres hvem der er virkningsaktøren, dvs. hvilken aktør som afstedkommer fødslen eller ændringen af forretningsobjektet.

En aktør kan være navnet på den organisation eller det informationssystem, som har afstedkommet ændringen. Registerejeren bør tage højde for eksterne kendskab til relevante aktører, når virkningsaktører angives. Eksempelvis kan registreringsaktøren for en kommuneændring i DAGI være Styrelsen for Dataforsyning og Effektivisering, mens virkningsaktøren, som har forårsaget ændringen, kan være Indenrigs- & Boligministeriet.

Implikationer:

Som hovedregel bør alle grunddataobjekttyper indeholde virkningstid, men jf. ovenstående er det ikke meningsfuldt for alle grunddataregistre at operere med denne information. Krav om virkningstid kan dispenseres for, hvis registerejer kan godtgøre, at bitemporalitet hverken er relevant fra et forvaltningsmæssigt perspektiv eller et anvenderperspektiv. I forbindelse med afklaringen kan det være relevant, at gennemføre en særskilt høring om emnet blandt anvendere og andre registre. En dispensation kan gøres betinget og f.eks. kan det være et krav, at spørgsmålet genbesøges ved større ændringer af det bagvedliggende forvaltningssystem. Dispensation kan gives af Grunddata Arkitekturforum.

Er bitemporalitet angivet som historikmodel skal følgende egenskaber angives:

Grunddataegenskab: virkningFra

Definition:

starttidspunkt af den registrerede dataobjektversions virkningstidsinterval

Datatype:

Date, DateTime

Krav:

Betinget

Multiplicitet:

1

Kilde:

http://link.til.begrebsmodel Begrebsmodel: Temporale begreber

Grunddataegenskab: virkningTil

Definition:

sluttidspunkt af den registrerede dataobjektversions virkningstidsinterval

Datatype:

Date, DateTime

Krav:

Betinget

Multiplicitet:

0..1

Kilde:

http://link.til.begrebsmodel Begrebsmodel: Temporale begreber

Grunddataegenskab: virkningsaktør

Definition:

aktør som afstedkommer fødslen eller en ændring af en forretningsobjektinstans

Datatype:

Characterstring

Krav:

Betinget

Multiplicitet:

1

Kilde:

http://link.til.begrebsmodel#virkningsaktør Begrebsmodel: Temporale begreber

Modeleksempler:

Virkningstid

Dataeksempler:

virkningFra = 2021-06-21T10:45

virkningFra = 1938-12-24

virkningFra = 1844-01-01 (til angivelse af kun årstal)

virkningTil = Null

virkningTil = 1945-05-05

virkningsaktør = Tinglysningsretten

virkningsaktør = Matriklens informationssystem

6.4. Alle grunddataobjekttyper bør modelleres med status

Regel: Alle modelentiteter af stereotypen DKObjekttype bør modelleres med status, der klart angiver, hvor et forretningsobjekt er i sin livscyklus.

Rationale: 

forretningsobjekter gennemløber typisk en livscyklus. Forretningsdomænet kan opstille regler for hvilke statusser, der er gyldige for et givet objekt, og for, hvordan forretningsobjektet kan gennemløbe disse.

Disse tilstande skal placeres og udstilles i et vedtaget udfaldsrum, som modelentiteten skal referere til. Dataobjektets status udtrykker dataobjektets relevans for databrugeren.

Et grunddataobjekts livscyklus må ikke være i strid med angivelsen af virkningstid.

Implikationer:

Hver UML-klasse med stereotypen DKObjekttype bør modelleres med status. Angivelse af status er vel at mærke kun relevant såfrem forretningsobjektet gennemløber en livscyklus. Den klassifikation som bruges til at angive status skal have mere end én værdi i sit udfaldsrum.:

Grunddataegenskab: status

Definition:

Situation på et bestemt tidspunkt i livscyklen af en forretningsobjektinstans.

Datatype:

Klassifikation

Krav:

Frivillig

Multiplicitet:

1

Kilde:

http://link.til.begrebsmodel Begrebsmodel: Temporale begreber

Modeleksempler:

Status

Dataeksempler:

Status = i høring

Status = godkendt

Status = afvist

6.5. Alle modelentiteter bør understøtte beskedfordeling

Regel: Modelentiteterne af stereotypen DKObjekttype bør modelleres således, at dataobjektet kommer til at indeholde informationer, som kan forbedre kvaliteten af hændelsesbeskeder, der udsendes i forbindelse med opdatering af dataobjektet. Disse informationer omfatter den forretningsmæssige kontekst, hvori dataobjektet opdateredes, samt den bagvedliggende forretningsmæssige årsag til opdateringen.

Rationale: 

For at give brugeren af grunddata viden om, hvorfor og hvordan data er blevet ændret, bør grunddataobjekter indeholde information om

  1. den forretningshændelse, der har udløst ændringen

  2. den forretningsproces, hvori ændringen er sket

Implikationer:

Hver UML-klasse med stereotypen DKObjekttype bør modelleres med følgende attributter:

Grunddataegenskab: forretningshændelse

Definition:

Den forretningshændelse, som afstedkom opdateringen

Datatype:

Klassifikation

Krav:

Frivillig

Multiplicitet:

1

Grunddataegenskab: forretningsproces

Definition:

Den forretningsproces, som har opdateret dataobjektet

Datatype:

Klassifikation

Krav:

Frivillig

Multiplicitet:

1

Modeleksempler: