Veileder for beskrivelse av informasjonsmodeller

Denne veilederen skal gi en hjelp til virksomhetene i offentlig forvaltning til å beskrive informasjonsmodellene sine i henhold til Spesifikasjonen for beskrivelse av informasjonsmodeller (ModellDCAT-AP-NO) og tilgjengeliggjøre dem i Felles datakatalog. Den gjelder altså først og fremst virksomheter som allerede har informasjonsmodeller som skal høstes, og ikke de som skal starte opp informasjonsmodellering.

Ulike virksomheter bruker ofte ulike modelleringsspråk og -verktøyer. Selv om noen etater forholder seg til de samme modelleringsspråkene og -verktøyene, kan bruken av disse og hvilke versjoner man anvender variere. Hensikten med ModellDCAT-AP-NO er å kunne beskrive virksomhetenes ulike informasjonsmodeller på en ensartet måte. Gjennom en lik tilnærming, er det enklere å finne, forstå, sammenligne og gjenbruke informasjonsmodeller i offentlig sektor.

Det er ikke et mål for denne veilederen å beskrive alle felter i ModellDCAT-AP-NO, heller ikke teknisk og normativt. For normative beskrivelser av alle feltene i spesifikasjonen for informasjonsmodeller, se ModellDCAT-AP-NO og valideringsreglene (shacl).

Målgruppen for denne veilederen er deg som:

For å få best mulig innsikt i ModellDCAT-AP-NO og utbytte av veilederen, er det en fordel om du har litt kjennskap til Resource Description Framework (RDF).

Veilederen består av følgende deler:

I tillegg er det laget et vedlegg, Informasjonsmodellering enkelt forklart som gir en kort innføring i hva informasjonsmodeller er og anbefalt metode for utforming av disse.

Egenskapen dct:identifier brukes til å oppgi identifikatoren til subjektet (første leddet) i en RDF-trippel. Subjektet i en RDF-trippel er per definisjon en identifikator (URI). I en konkret realisering vil instanser av klassene (inkl. deres subklasser) Modellkatalog (dcat:Catalog), Informasjonsmodell (modelldcatno:InformationModel), Modellelement (modelldcatno:ModelElement), Egenskap (modelldcatno:Property), Kodeliste (modelldcatno:CodeListe) og Kodeelement (modelldcatno:CodeElement) derfor få en «innebygd» identifikator. Det er med andre ord strengt tatt ikke nødvendig å ha en identifikator (dct:identifier) i tillegg til den «innebygde» identifikatoren.

Egenskapen dct:identifier er derfor satt som anbefalt og ikke obligatorisk i de nevnte klasser og deres subklasser, med unntak av for Modellkatalog (dcat:Catalog). dct:identifier er satt som obligatorisk for Modellkatalog (dcat:Catalog) for at ModellDCAT-AP-NO skal være kompatibel med DCAT-AP-NO, ettersom dct:identifier er obligatorisk for dcat:Catalog der.

Egenskapen dct:identifier trenger ikke å inneholde den samme identifikatoren som den innebygde URIen i en RDF-trippel, men når det er den samme identifikatoren, anbefales det at hele den innebygde URIen (subjektet i en trippel) kopieres til dct:identifier i en Modellkatalog (dcat:Catalog).

Eksempel i RDF Turtle:

Identifikatoren bør utformes i henhold til Standard for pekere til offentlige ressurser på nett.

Det anbefales å bruke følgende mønster for URI til utgiver (dct:publisher) og produsent (dct:creator), der det siste leddet er organisasjonsnummeret:

Når det er behov for å oppgi at «eieren» for en informasjonsmodell som ikke er den samme som utgiveren (dct:publisher), anbefales det å bruke produsent (dct:creator).

Til dekningsområde (dct:spatial), anbefales det å bruke EU sine kontrollerte vokabularer Continent, Country, og Place. Eksemplet under (i RDF Turtle) viser bruk av Country-vokabularet for å oppgi Norge (NOR):

Det anbefales å bruke Kartverket sine kontrollerte vokabularer for fylke og kommune. Eksemplene under viser Oslo som fylke hhv. kommune.

Du kan finne fram til URIene her.

For lisens (dct:license) anbefales det å bruke EU sitt kontrollerte vokabular for lisens, Licence, hvis lisensen du bruker finnes på listen. I eksemplet under er det CC BY v. 4.0 som er brukt.

Med informasjonsmodell (modelldcatno:InformationModel) mener vi en formell beskrivelse av informasjonen en virksomhet trenger å motta eller selv produsere for å utføre sitt daglige virke. Vi legger til grunn en vid tolkning av begrepet informasjonsmodell. Den omfatter modeller på ulike abstraksjonsnivåer (som konseptuelle, logiske og fysiske modeller) og modeller som beskriver ulike aspekter ved informasjon (som felles- og anvendelsesmodeller).

Kun tittel (dct:title) og utgiver (dct:publisher, se Om …​ «utgiver») er obligatorisk for en informasjonsmodell. Det er med andre ord ikke påkrevd å ta med modellelementer i modellbeskrivelsen din, selv om dette er anbefalt. Hvis modellen din kun er tilgjengelig som f.eks. en bildefil, anbefales det å gjøre den tilgjengelig på en nettside og peke til denne ved bruk av dct:hasFormat. Det er også mulig å referere til en hjemmeside hvor modellen er nærmere beskrevet ved bruk av egenskapen foaf:homepage.

Hva som betraktes som større eller mindre endringer, er en faglig vurdering som denne veilederen ikke dekker. Når du ut fra den faglige vurderingen mener at endringene i informasjonsmodellen din er så store at det kan ha betydning for hvordan informasjonsmodellen skal forstås/brukes, bør du opprette en ny instans av modelldcatno:InformationModel for den nye versjonen av informasjonsmodellen din, slik at den nye versjonen også får en egen identifikator. Dette gjør at både den nye og den gamle versjonen av informasjonsmodellen din kan refereres til. Du bør også bruke egenskapen «Informasjonsmodell: erstatter» (dct:replaces) fra den nye versjonen til den gamle versjonen av informasjonsmodellen (ev. den motsatte egenskapen, «Informasjonsmodell: er erstattet av» (dct:isReplacedBy) fra den gamle til den nye versjonen av informasjonsmodellen). For mindre endringer kan du bruke egenskapene «Informasjonsmodell: versjon» (owl:versionInfo) og «Informasjonsmodell: versjonsnote» (adms:versionNotes) til å dokumentere endringene, uten at det blir opprettet en ny instans og dermed en ny identifikator.

Se eksempel 1 i RDF Turtle, som er en informasjonsmodell uten modellelementer, men med henvisning til hvor modellen finnes. Eksemplet viser også bruk av alle egenskapene (dvs. ikke bare obligatoriske).

Se eksempel 2 i RDF Turtle, som er en informasjonsmodell med et modellelement. Eksemplet viser bruk av kun obligatoriske egenskaper.

To tilfeller:

Figuren nedenfor viser en enkel informasjonsmodell med de mest grunnleggende modellelementene. Modellelementene og egenskap er nummerert etter type.

Mapping til ModellDCAT-AP-NO:

Se eksemplet i RDF Turtle.

I modelleksemplet ovenfor har vi beskrevet basis relasjonstyper som spesialisering og roller. ModellDCAT-AP-NO muliggjør også beskrivelse av mer spesialiserte relasjonstyper, som abstraksjoner, assosiasjoner, komposisjoner, realiseringer og samlinger.

For å kunne beskrive den semantiske betydningen til modellelementer, egenskaper og kodeelementer, kan disse knyttes til begreper.

Siden det ikke er en egen mekanisme i UML for å referere fra modellelementer til begreper, er det i eksemplet opprettet en tag, begrep som plassholder for begrepsreferanser. Begrepsreferansene peker her til Skatteetatenes begreper for folkeregisterperson og fødselsdato.

Mapping til ModellDCAT-AP-NO:

Se eksemplet i RDF Turtle.

ModellDCAT-AP-NO tillater å beskrive begrensninger på bruk av en eller flere modellelementer og egenskaper ved bruk av klassen Begrensningsregel (modelldcatno:ConstraintRule). Begrensningsuttrykk kan være en tekstlig beskrivelse, men også mer maskinelle lesbare uttrykk, som f.eks. Object Constraint Language (OCL). I tillegg er det definert to subklasser til Begrensningsregel, Enten eller (modelldcatno:Xor) og Eller (modelldcatno:Or).

Mapping til ModellDCAT-AP-NO:

Se eksempel i RDF Turtle.

Merk at for klassen Begrensningsregel (modelldcatno:ConstraintRule) må minst én av egenskapene tittel (dct:title) eller begrensningsregel (modelldcatno:constraintExpression) ha en verdi. Dette gjelder imidlertid ikke for subklassene Enten eller (modelldcatno:Xor) og Eller (modelldcatno:Or), hvor kun egenskapen begrensning (modelldcatno:constraint) er påkrevd.

Mapping til ModellDCAT-AP-NO:

Se eksempel i RDF Turtle.

Nedenfor vises to eksempler på bruk av Valg (Choice), hvor det første tar for seg enkelvalg (single choice) og det andre flervalg (multiple choice). Valg (Choice) er et konsept som finnes bl.a. i XML Schema Definition (XSD). I eksemplene har vi benyttet UML-modeller. Siden Valg ikke er et eget element i UML klassediagram, har vi framstilt det som en klasse med stereotype «Valg». Selve valgene har vi også representert som XSD Choice.

Eksempelet viser bruk av rotobjekttype. Rotobjektet er her representert som en klasse med stereotype «Rotobjekttype».

Mapping til ModellDCAT-AP-NO:

Se eksempel i RDF Turtle.

Under Basis modellelementer og egenskaper har vi laget et eksempel på hvordan man kan beskrive en enkel enumerasjon som en kodeliste (modelldcatno:CodeList), og hvordan vi med egenskapen «har verdi fra» (modelldcatno:hasValueFrom) kan angi at et attributt (modelldcatno:Attribute) relaterer seg til en kodeliste.

Andre typiske brukstilfeller er:

Informasjonsmodeller fra en eller flere virksomheter samles i en modellkatalog. En modellkatalog kan ses som et omslag til eller innbinding av modellene. En modellkatalog skal ha én utgiver, og en og samme virksomhet kan være utgiver av flere modellkataloger.

Som minimum skal følgende egenskaper ha verdier:

Se eksemplet i RDF Turtle.

Når du skal publisere katalogen din i Felles datakatalog, må modellene mappes iht. ModellDCAT-AP-NO til et format som kan høstes. Pr. i dag støtter Felles datakatalog følgende RDF-serialiseringer: RDF/XML, Turtle og JSON-LD.

Modellkatalogen må da legges ut som en nettressurs, f.eks. i Github. URIen til nettressursen registreres i Felles datakatalog, og katalogen høstes så automatisk.

Vi lager modeller for å strukturere kunnskap. Vi deler opp informasjonen i tenkte enheter: ting. Disse tingene omtales litt forskjellig avhengig av tradisjon og sammenheng, noen sier klasser eller objekter, noen sier konsepter og i ModellDCAT-AP-NO snakker vi om modellelementer. Uavhengig hva vi omtaler det som er klassen eller modellelementet en måte å samle informasjon om et konsept, noe konkret eller abstrakt.

Denne informasjonen som beskriver «tingen» kan vi kalle egenskaper. Alt vi kan utrykke for å beskrive «tingen» er egenskaper, enten det er enkle fakta som en farge, Enkeltype, eller en struktur av opplysninger slik som en adresse, Datatype, som har flere felter, slik som gatenavn, husnummer, postnummer og poststed.

En modell består som regel av mer enn ett konsept. Relasjonen mellom konsepter er i denne sammenhengen også en egenskap.

Dersom konseptene er konkrete, omtales de ofte som objekter, men sett ut ifra modellen er dette synonymer.

Hvilken type egenskap er litt avhengig av hva vi fokuserer på i modellen.

I en konseptuell modell der man f.eks. setter begreper i en sammenheng vil en kanskje kalle dette forholdet for en Assosiasjon.

Her kan man si at en skyldner kjennetegnes av at man som en av egenskapene har en betalingsforpliktelse til en kreditor.

I modeller som beskriver konkrete forhold, logiske eller fysiske modeller, er det vanlig å beskrive relasjonen mellom to objekter utfra hva det ene objektet betyr for det andre. Rettere sagt, hvilken rolle "Person” spiller for "A-skjema".

Vi kan tenke oss et skjema der man i tillegg til enkle attributter, en slags egenskap, som "beløp" og "betalingsdato" ønsker å beskrive en person med navn og adresse. Person er her et selvstendig konsept eller en klasse som blir brukt av skjemaet, i tillegg er det hektes på adresseinformasjon som en egen klasse.

Skjemaet som skal beskrives, inneholder informasjon om en som skylder penger, derfor kan man tenke seg at dette beskrives som "A-skjema", med to egenskaper og skjemaet relaterer seg til en person, i det ene tilfelle "skyldner", i det andre tilfelle "kreditor". Dette er det samme forholdet som var en assosiasjon i den konseptuelle modellen, men som utrykkes som et rolle-forhold i den logiske eller fysiske modellen.

Ved hjelp av Modellelement, rolle, der ulike Modellelementer knyttes sammen for å beskrive informasjonsstrukturen med attributter som bruker enkeltype og datatype for data om konseptet, kan man utrykke en datastruktur.

ModellDCAT-AP-NO har et større mulighetsrom, noe du kan se tidligere i denne veilederen, men som en enkel start er Modellelement, rolle, attributt med enkeltype eller datatype nok til å beskrive datastrukturer.

Ulike arkitekter vil ha ulike svar på hva de gjør når de modellerer, men her er en metode som virker.