Anvendelse af dobbelthistorik i GD2
|
|
- Cecilie Mikkelsen
- 8 år siden
- Visninger:
Transkript
1 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version: 1.0 Status: Afsluttet Dato: 01. Juni 2015 Fil: Forretningsregler for implementering af dobbelthistorik GD2.docx
2 Dokument historie Version Dato Beskrivelse Initialer Dokument reviewet og frigivet til offentliggørelse SD- RSP Indholdsfortegnelse 1 INDLEDNING DOKUMENTETS FORMÅL FORMÅLET MED DOBBELTHISTORIK GRUNDDATAPROGRAMMETS ANVENDELSE AF DOBBELTHISTORIK BEGREBER UNIK IDENTIFIKATION REGISTRERINGSTID VIRKNINGSTID OBJEKTSTATUS REGISTRERINGS- OG VIRKNINGSAKTØR REGLER GENERELT OPRETTELSE OG ÆNDRING AF FORRETNINGSOBJEKTER Rettelse af indholdsmæssige fejl til samme virkningstid og objektstatus Opdatering af oplysninger til ny virkningstid og/eller ny objektstatus Logisk sletning af et forretningsobjekt Tilføjelse af historik Flere samtidige versioner LÆSNING AF FORRETNINGSOBJEKTER MED DOBBELTHISTORIK GYLDIGE FORRETNINGSOBJEKTER PÅ ET GIVENT TIDSPUNKT GENSKABNING AF FORRETNINGSOBJEKTER PÅ ET GIVENT REAL- TIDSPUNKT EKSEMPLER PÅ ANVENDELSE AF DOBBELTHISTORIK INDLEDNING EKSEMPLER UDEN FLERE SAMTIDIGE VERSIONER Oprettelse af 19 -
3 5.2.2 Rettelse til samme virkningstid Ændring i status Ændring med ny virkningstid Sletning ved statusskifte Genoplivning ved statusskifte Fortryd nedlæggelse Sletning (ikke ved statusskifte) Tilføjelse af historik Samlet eksempel EKSEMPEL MED FLERE SAMTIDIGE VERSIONER Startpunkt Ny samtidig version oprettes Ny version gøres gældende og gammel version udgår af 19 -
4 1 Indledning 1.1 Dokumentets formål Dokumentet har til formål over for leverandører og andre interessenter at beskrive hvorledes registrene i Grunddataprogrammet skal implementere dobbelthistorik. Dobbelthistorik modelleres ved hjælp af bitemporale egenskaber. Det dobbelte består i, at de to tidsaspek- ter virkningstid og registreringstid håndteres i sammenhæng på et givet forretningsobjekt. 1.2 Formålet med dobbelthistorik Registrering af dobbelthistorik omkring et forretningsobjekt er relevant i forhold til at kunne registrere og distribuere data, som giver mulighed for sporbarhed i de foretagne registreringer. Sporbarhed er de egen- skaber, som et offentligt forvaltningsgrundlag skal kunne understøtte, således det til enhver tid er muligt at fremfinde og dokumentere det datamæssige forvaltningsgrundlag (historiske beslutningsgrundlag), som en aktør har brugt som grundlag for en konkret beslutning/sagsbehandling. Der skal være muligt at fremsøge hvad der på et givet tidspunkt har været registreret i det enkelte register omkring et konkret forretningsob- jekt. 1.3 Grunddataprogrammets anvendelse af dobbelthistorik I Grunddataprogrammet er der i forbindelse med udstilling af data på den fællesoffentlige Datafordeler behov for en stringent måde at definere registreringstid og virkningstid på. Dette er vigtigt, fordi data skal kunne sammenstilles på tværs af registre og dermed danne grundlag for en bedre og mere effektiv brug af de offentlige grunddata. Grunddataprogrammets modelregler kan ses på modelregler Bitemporalitet er et anderkendt begreb, som anvendes i databaser mange forskellige steder i Verden og består af: Unik identifikation (UUID) Registreringstid (til og fra timestamp) Virkningstid (til og fra timestamp) I Grunddataprogrammets modelleringsregler er dobbelthistorik beskrevet til at indeholder de bitemporale egenskaber samt: Registreringsaktør Virkningsaktør Derudover er der et yderligere krav til at alle objekter indeholder: Objektstatus Af hensyn til fælles forståelse, implementering og anvendelse, beskrives disse 6 egenskaber under begrebet dobbelthistorik. - 4 af 19 -
5 2 Begreber Dette afsnit beskriver de begreber Grunddataprogrammet anvender i forbindelse med dobbelthistorik. Dokumentet anvender følgende termer: Begreb : Det er fremgår af informationsmodellerne. Forretningsobjekt : En konkret instans af begrebet (har en UUID). Forekomst : De enkelte rækker i tabellen. 2.1 Unik identifikation Alle begreber modelleres med en persistent, unik nøgle af typen UUID ( Universal Unique IDentifier ), dvs. et globalt unikt id, som ikke ændres i et forretningsobjekts levetid. Normalt vil forretningsobjektet, ud over denne unikke nøgle, have en eller flere forretningsnøgler. Men forretningsnøglerne kan ikke stå alene, da disse i nogle tilfælde ændres over tid, ligesom den samme for- retningsnøgle løbende kan indgå i flere forekomster. 2.2 Registreringstid Alle forekomster registreres i databasen med en registreringstid, bestående af to tidsstempler - et fra- timestamp og et til- timestamp. Fra- timestamp er inklusiv og til- timestamp er eksklusiv. Registreringstiden er tidsrummet fra versionen registreres til den enten erstattes af en nyere version eller afregistreres (logisk slettes). Registreringstiden er således fortløbende for et givent forretningsobjekt. Der kan over tid eksistere flere forekomster med samme identifikation, virkningstid og objektstatus. Her vil registreringstid afgøre, hvilken der er/var gældende på et givet tidspunkt. 2.3 Virkningstid Alle forekomster registreres i databasen med en virkningstid bestående af to tidsstempler - et fra- timestamp og et til- timestamp. Fra- timestamp er inklusiv og til- timestamp er eksklusiv. Virkningstid kan oprettes i fortiden, nutiden eller fremtiden. Der skal kun være én gældende virkningstid for en given objektstatus på et givet tidspunkt. Virkningstid må ikke være overlappende for samme registreringstid og objektstatus. 2.4 Objektstatus Alle forekomster registreres i databasen med en status, der angiver, hvor et forretningsobjekt er i sin livscy- klus. 2.5 Registrerings- og virkningsaktør De to attributter udfyldes med navn eller id på den person eller det program, der foretager ændringen. Registreringsaktør, er den aktør der opdaterer databasen, virkningsaktør er den aktør, der er forretnings- mæssig ansvarlig for opdateringen. Attributterne udfyldes altid og er, af hensyn til overskueligheden, ikke medtaget i resten af dokumentet, da indholdet ikke anvendes aktivt i forbindelse med dobbelthistorikken. - 5 af 19 -
6 3 Regler Dette afsnit beskriver forretningsreglerne for anvendelsen af registreringstid, virkningstid og objektstatus - de 3 begreber, der er afgørende for korrekt dobbelthistorik. Reglerne er tænkt til at være let anvendelige for anvendere af data. Dette er på bekostning af større kom- pleksitet ved oprettelse og opdatering af data. Reglerne er efterfulgt af nogle eksempler i afsnit Generelt Dobbelthistorik registreres pr. forretningsobjekt, dvs. hvert UUID har sin egen dobbelthistorik. Et Null timestamp betragtes som uendelig, eksempelvis implementeret som Null timestamps anvendes kun på registreringtil og virkningtil. RegistreringFra og virkningfra skal altid udfyldes med et ikke- fiktivt timestamp. Ligeledes skal objektstatus også altid udfyldes. 3.2 Oprettelse og ændring af forretningsobjekter Der laves altid en ny forekomst i databasen, når en af egenskaberne for et forretningsobjekt ændrer sig. Dvs. at når en forekomst først er oprettet, må den ikke ændres efterfølgende. Eneste undtagelse er opdate- ring af sluttidspunkt for registreringen (registreringtil), der udfyldes når en ny forekomst af samme forret- ningsobjekt oprettes. Ved oprettelse af et nyt forretningsobjekt sættes forekomstens virkningstid, registreringstid og objektsta- tus således: VirkningFra = Timestamp for start på forekomstens gyldighed VirkningTil = Null eller slut på forekomstens gyldighed, hvis denne kendes Objektstatus = Forekomstens livscyklus status, gældende for den angivne virkningstid RegistreringFra = Aktuelt timestamp RegistreringTil = Null Ved ændring af et forretningsobjekt, oprettes en forekomst, hvor virkningstid, registreringstid og objektsta- tus sættes som ved en oprettelse med følgende tilføjelse: RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres) Der må således ikke opstå huller mellem registreringstiden på de to forekomster. Forretningsmæssigt kan ændringer af et forretningsobjekt inddeles i nedenstående variationer: Rettelse af indholdsmæssige fejl til samme virkningstid og objektstatus Opdatering af oplysninger til ny virkningstid og/eller ny objektstatus Logisk sletning af et forretningsobjekt Tilføjelse af historik Flere samtidige versioner Alt efter registrenes livscyklus kan disse give anledning til variationer i dobbelthistorik registreringerne. Dette er nærmere forklaret i de næste underafsnit. - 6 af 19 -
7 3.2.1 Rettelse af indholdsmæssige fejl til samme virkningstid og objektstatus Ved rettelse af indholdsfejl til samme virkningstid, foretages følgende: RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres) Der oprettes en ny forekomst med: RegistreringFra = Aktuelt timestamp RegistreringTil = Null Objektstatus = Kopieres fra den forekomst, der rettes VirkningFra = Kopieres fra den forekomst, der rettes VirkningTil = Kopieres fra den forekomst, der rettes Opdatering af oplysninger til ny virkningstid og/eller ny objektstatus Ved opdatering af oplysninger til ny virkningstid og/eller ny objektstatus, foretages følgende: RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres) Der oprettes en ny forekomst som en kopi af den tidligere forekomst hvor: RegistreringFra = Aktuelt timestamp RegistreringTil = Null Objektstatus = Kopieres fra den forekomst, der rettes VirkningFra = Kopieres fra den forekomst, der rettes VirkningTil = VirkningFra på den nye forekomst (nedenfor) Der oprettes en ny forekomst med: RegistreringFra = Aktuelt timestamp RegistreringTil = Null Objektstatus = Forekomstens livscyklus status, gældende for den angivne virkningstid VirkningFra = Timestamp for start på forekomstens gyldighed VirkningTil = Null eller slut på forekomstens gyldighed, hvis denne kendes Logisk sletning af et forretningsobjekt Ved logisk sletning af et forretningsobjekt, foretages følgende: RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres) Der oprettes en ny forekomst som en kopi af den tidligere forekomst hvor: RegistreringFra = Aktuelt timestamp RegistreringTil = Null Objektstatus = Kopieres fra den forekomst, der rettes VirkningFra = Kopieres fra den forekomst, der rettes VirkningTil = Timestamp for slut på forekomstens gyldighed (tid for sletning) OBS: Registre med objektstatus Nedlagt o.lign er ikke en sletning, men en opdatering, hvor objektstatus anvendes til at beskrive en logisk sletning. Logisk sletning skal anvendes, hvis registreret arbejder med flere samtidige versioner. - 7 af 19 -
8 3.2.4 Tilføjelse af historik Ved tilføjelse af historik, foretages følgende: RegistreringTil = Aktuelt timestamp (på den eksisterende forekomst der opdateres) Der oprettes nye forekomster, som kopier, af de objekter, hvis virkningstid er berørt af historik tilføjelsen: (der kan være tale om en eller flere forekomster) RegistreringFra = Aktuelt timestamp RegistreringTil = Null Objektstatus = Kopieres fra den forekomst, der rettes VirkningFra = VirkningFra, fra den tidligere instans, eller en ny virkningfra, hvis historik tilføjelsen ændrer på virkningfra. VirkningTil = VirkningTil, fra den tidligere instans, eller en ny virkningtil, hvis historik tilføjelsen æn- drer på virkningtil. Der oprettes en ny forekomst med den nye historik: RegistreringFra = Aktuelt timestamp RegistreringTil = Null Objektstatus = Forekomstens livscyklus status, gældende for den angivne virkningstid VirkningFra = Timestamp for start på forekomstens gyldighed (start for den nye historik) VirkningTil = Timestamp for slut på forekomstens gyldighed (slut for den nye historik) Flere samtidige versioner Ved oprettelse af en ny version af et forretningsobjekt, vil resultatet blive flere forekomster med overlap- pende registreringstid og virkningstid, men med forskellige objektstatus. Ved oprettelse af nye versioner, foretages følgende: Der oprettes en ny forekomst med: RegistreringFra = Aktuelt timestamp RegistreringTil = Null Objektstatus = Forekomstens livscyklus status, gældende for den angivne virkningstid VirkningFra = Timestamp for start på forekomstens gyldighed VirkningTil = Null eller slut på forekomstens gyldighed, hvis denne kendes Hvis der eksisterer en anden forekomst med samme objektstatus og virkningstid, skal dette objekt først logisk slettes, jf. nedenstående beskrivelse. Når forekomsten, der beskriver den nye version skifter objektstatus, til samme status som forekomsten der beskriver den aktive version, skal der foretages følgende: Forekomsten for den aktive version skal udgå efter reglerne for Logisk sletning af et forretningsob- jekt, hvorved virkningtil angives med tidspunkt (TID) for skiftet til forekomsten for den nye version Forekomsten for den nye version skal opdateres efter reglerne for Opdatering af oplysninger til ny virkningstid og/eller ny objektstatus, hvor virkningfra sættes til TID - 8 af 19 -
9 4 Læsning af forretningsobjekter med dobbelt- historik Læsning af forretningsobjekter, er altid med udgangspunkt i en identifikation, i form af en nøgle (UUID, evt. Fundet via forretningsnøglen) kombineret med virkningstid og registreringstid. For forretningsobjekter med flere samtidige versioner skal objektstatus dog også anvendes. De to tidsangivelser kan både angives som tidspunkter og som perioder, hvor sidstnævnte vil kunne resultere i en liste af forekomster. Beskrivelserne i dette kapitel samt eksemplerne, tager udgangspunkt i forespørgsler på tidspunkter ikke perioder. 4.1 Gyldige forretningsobjekter på et givent tidspunkt Et gyldigt forretningsobjekt på et givent tidspunkt (TID) identificeres som den forekomst af forretningsob- jektet, med den nyeste registreringstid (registreringtil = Null ), hvor VirkningFra <= TID og VirkningTil > TID. Et gyldigt forretningsobjekt på et givent tidspunkt (TID) med en bestemt objektstatus (STATUS) identificeres som den forekomst af forretningsobjektet, med den nyeste registreringstid, hvor VirkningFra <= TID og VirkningTil > TID og Objektstatus = STATUS. 4.2 Genskabning af forretningsobjekter på et givent real- tidspunkt Et forretningsobjekt kan genskabes på et givent real- tidspunkt (TID), via registreringstid, ved at hente de forekomster hvor RegistreringFra <= TID og RegistreringTil > TID. Forespørgslen kan naturligvis også kombineres med andre elementer, fx en given objektstatus eller en gi- ven virkningstid. - 9 af 19 -
10 5 Eksempler på anvendelse af dobbelthistorik 5.1 Indledning Eksemplerne er opbygget af en illustration, der grafisk viser sammenhængen mellem registreringstid og virkningstid for de enkelte forekomster i eksemplerne. Virkningsperioder og registreringsperioder er i eksemplerne for overskueligheds skyld angivet som datoer. De registrerede informationer i databasens tabeller vil naturligvis være af typen timestamp i overens- stemmelse med Grunddataprogrammets modelregler. Eventuelle registreringer forud for den kontekst, som anvendes i eksemplerne er ikke medtaget. Der er, udover parametrene til dobbelthistorik, medtaget 2 yderligere elementer: Indhold, der med udgangspunkt i NavngivenVej, illustrerer de forretningsmæssige ændringer i ek- semplerne. ID, der er et løbenummer, som er medtaget for at skabe en entydig sammenhæng mellem tabel og illustration. ID vil ikke fremgår af databasen. I tabellerne er der anvendt følgende farver: Sort tekst betyder eksisterende information i databasen Rød tekst betyder ændringer til eksisterende information i databasen Blå tekst betyder nye informationer i databasen I figurer til illustration af de enkelte eksempler er anvendt to farver til illustration af dobbelthistorikken: Rød farve anvendes til at illustrere virkningstiden på en forekomst Blå farve anvendes til at illustrere registreringstider på samme forekomst Teksten, der ses over den røde linje, er forekomstens objektstatus, i henhold objektets livscyklus. 5.2 Eksempler uden flere samtidige versioner Oprettelse I eksemplet registreres det den , at der oprettes en navngiven vej med status foreløbig pr xxxx Københavnvej Foreløbig - 10 af 19 -
11 5.2.2 Rettelse til samme virkningstid I eksemplet registreres der den en rettelse af en stavefejl i vejnavnet, med tilbagevirkende kraft fra xxxx Københavnvej Foreløbig 2 xxxx Københavnsvej Foreløbig Ændring i status I eksemplet registreres det den at den navngivne vej gøres gældende, pr xxxx Københavnsvej Foreløbig 3 xxxx Københavnsvej Foreløbig 4 xxxx Københavnsvej Gældende - 11 af 19 -
12 5.2.4 Ændring med ny virkningstid I eksemplet registreres det den at den navngivne vej skiftede navn pr xxxx Københavnsvej Gældende 5 xxxx Københavnsvej Gældende 6 xxxx Hovedvejen Gældende Sletning ved statusskifte I eksemplet registreres det den at den navngivne vej nedlægges pr xxxx Hovedvejen Gældende 7 xxxx Hovedvejen Gældende 8 xxxx Hovedvejen Nedlagt - 12 af 19 -
13 5.2.6 Genoplivning ved statusskifte I eksemplet, registreres det den at den nedlagte navngivne vej skal genoplives pr xxxx Hovedvejen Nedlagt 9a xxxx Hovedvejen Nedlagt 10a xxxx Hovedvejen Gældende Fortryd nedlæggelse I eksemplet, registreres det den at nedlæggelsen af den navngivne vej skal fortrydes. 8 xxxx Hovedvejen Nedlagt 9b xxxx Hovedvejen Nedlagt 10b xxxx Hovedvejen Gældende Bemærk at 9b kun er relevant for forretningsobjekter, hvor der kan eksistere flere samtidige versioner af 19 -
14 5.2.8 Sletning (ikke ved statusskifte) I eksemplet, registreres det den at den navngivne vej skal slettes pr a xxxx Hovedvejen Gældende 11 xxxx Hovedvejen Gældende Tilføjelse af historik I eksemplet registreres det den , at den navngivne vej havde et andet navn i perioden xxxx Københavnsvej Gældende 7 xxxx Hovedvejen Gældende 12 xxxx Københavnsvej Gældende 13 xxxx Svinget Gældende 14 xxxx Hovedvejen Gældende - 14 af 19 -
15 Samlet eksempel I dette afsnit vises et total billede af forekomsterne i database, for de ovenstående eksempler, hvis de alle foretages på det samme forretningsobjekt, i den rækkefølge ovenstående eksempler er beskrevet, fra op- rettelse via forandringer til sletning. 1 xxxx Københavnvej Foreløbig 2 xxxx Københavnsvej Foreløbig 3 xxxx Københavnsvej Foreløbig 4 xxxx Københavnsvej Gældende 5 xxxx Københavnsvej Gældende 6 xxxx Hovedvejen Gældende 7 xxxx Hovedvejen Gældende 8 xxxx Hovedvejen Nedlagt 9a xxxx Hovedvejen Nedlagt 10a xxxx Hovedvejen Gældende 11 xxxx Hovedvejen Gældende 12 xxxx Københavnsvej Gældende 13 xxxx Svinget Gældende 14 xxxx Hovedvejen Gældende - 15 af 19 -
16 Hvis eksemplet ordnes efter de forekomster, der er gældende ved afslutningstidspunktet for eksemplet, , ser det således ud: 3 xxxx Københavnsvej Foreløbig 9a xxxx Hovedvejen Nedlagt 11 xxxx Hovedvejen Gældende 12 xxxx Københavnsvej Gældende 13 xxxx Svinget Gældende 14 xxxx Hovedvejen Gældende - 16 af 19 -
17 5.3 Eksempel med flere samtidige versioner Startpunkt Dette afsnit beskriver startpunktet for de efterfølgende eksempler med flere samtidige versioner. Der ind- går ikke flere samtidige versioner i startpunktet. Udgangspunktet er en Navngiven vej, der har gennemløbet følgende forløb: Registreringstid 1, : Oprettet som foreløbig, med virkning fra Registreringstid 2, : Rettelse af stavefejl, uændret virkningstid Registreringstid 3, : Navngiven vej gøres gældende, med virkning fra Illustreret giver dette følgende registreringer: Oprettelse som foreløbig 1 xxxx Københavnvej Foreløbig Rettelse af stavefejl 1 xxxx Københavnvej Foreløbig 2 xxxx Københavnsvej Foreløbig Navngiven vej gøres gældende 1 xxxx Københavnvej Foreløbig 2 xxxx Københavnsvej Foreløbig 3 xxxx Københavnsvej Foreløbig 4 xxxx Københavnsvej Gældende - 17 af 19 -
18 5.3.2 Ny samtidig version oprettes I eksemplet, registreres det den at der oprettes en ny version af den Navngivne vej som forelø- big, pr xxxx Københavnvej Foreløbig 2 xxxx Københavnsvej Foreløbig 3 xxxx Københavnsvej Foreløbig 4 xxxx Københavnsvej Gældende 5 xxxx Rustvej Foreløbig - 18 af 19 -
19 5.3.3 Ny version gøres gældende og gammel version udgår I eksemplet, registreres det den at den nye foreløbige version skal gøres gældende pr xxxx Københavnsvej Gældende 5 xxxx Rustvej Foreløbig 6 xxxx Københavnsvej Gældende 7 xxxx Rustvej Gældende - 19 af 19 -
Bitemporalitet på Datafordeleren
Bitemporalitet på Datafordeleren Denne side indeholder en anvenderrettet beskrivelse og dokumentation af grunddataprogrammets historikmodel ved anvendelse og implementering af bitemporalitet. Dokumentet
Læs mereBitemporalitet. Proof of concept. Versionshistorik. Version Dato Hvem Hvad er ændret. Første udkast. Kommentarer fra KL indarbejdet undervejs.
Bitemporalitet Proof of concept Versionshistorik Version Dato Hvem Hvad er ændret 0.9 3. sept 2014 Heidi Vanparys (GST) Flemming Nissen (GST) 0.10 9. sept 2014 Heidi Vanparys (GST) Erik Helweg-Larsen (KL)
Læs mereGD1/GD2 - Model for supplerende forretningsbeskrivelser
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Bilag 11 - Fælles arkitekturramme for GD1-GD2-GD7 GD1/GD2 - Model for supplerende forretningsbeskrivelser Udbudsoption vedrørende supplerende forretningsbeskrivelser.
Læs mereLøsningsarkitektur - Bilag A 1 Sammenstillede services
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Bilag 14 - Fælles arkitekturramme for GD1-GD2-GD7 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Delprogram 1: Effektiv
Læs mereSag og Dokument: Eksempel på brug af generelle egenskaber
Sag og Dokument: Eksempel på brug af generelle egenskaber Der er knyttet en række generelle egenskaber til de enkelte objekter som beskrevet i dokumentet Generelle egenskaber for serviceinterfaces på sags-
Læs mereAdresseprogrammet - Målarkitektur Bilag D - Arkitekturrammer
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Delprogram 2: Effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne Adresseprogrammet - Målarkitektur
Læs mereEjerfortegnelse Løsningsarkitektur Bilag B Informationsmodel Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012 2015
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltningg og genbrug af ejendomsdataa under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet Ejerfortegnelsen Løsningsarkitektur
Læs mereEjerfortegnelse Løsningsarkitektur Bilag C Processer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012 2015
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltningg og genbrug af ejendomsdataa under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet Ejerfortegnelsen Løsningsarkitektur
Læs mereAdresseregister Løsningsarkitektur
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Delprogram 2: Effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne Adresseregister Løsningsarkitektur
Læs mereAdresseregister - løsningsarkitektur Bilag A - Servicebeskrivelser
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Delprogram 2: Effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne Adresseregister - løsningsarkitektur
Læs mereHændelser på dåtåfordeleren
Hændelser på dåtåfordeleren En kort introduktion til begreber og anvendelsesmuligheder SDFE version 1.0 24. oktober 2016 Indhold Indledning... 2 Overordnet arkitektur... 2 Hændelsesbegrebet... 3 Forretningsmæssige
Læs mere1 Klassifikation-version2.0
1 Klassifikation-version2.0 Formål med Klassifikationsmodellen Her specificeres Klassifikationsmodellen, som en informationsmodel for Klassifikationer. Klassifikationer (eller klassifikationssystemer)
Læs mereAnvisning i aflevering af bitemporale data
UDKAST udgivet juni 2019 Anvisning i aflevering af bitemporale data Baggrund Aflevering af data fra it-systemer til et offentligt arkiv er baseret på aflevering af en arkiveringsversion i en relationel
Læs mereKrav til beskedfordeler, dannelse og abonnement
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Bilag 4 - Fælles arkitekturramme for GD1-GD2-GD7 Krav til beskedfordeler, dannelse og abonnement Version: 0.4 Status: udkast Oprettet: 2. juni 2014
Læs mereEjendomsdataprogrammet - Matriklen Løsningsarkitektur - Bilag A Servicebeskrivelser og integrationer
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Matriklen Løsningsarkitektur
Læs mere1 ST Klassifikation Informationsmodel
..27 ST Klassifikation Informationsmodel. Facet En facet angiver en bestemt synsvinkel på klassificering af de objekter, som klassifikationssystemet udgør taxonomien for. Facetten grupper klasser i klassifikationssystemet.
Læs mereEjendomsdataprogrammet - BBR Løsningsarkitektur Bilag C Processer
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - BBR Løsningsarkitektur
Læs mere0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.
Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012
Læs mereDIGST arkitekturnetværk
DIGST arkitekturnetværk Tværgående arkitekturdokumenter i grunddataprogrammet (GD1 og GD2) 20. september 2018 Strand & Donslund A/S Vesterbrogade 149 1620 København V www.s-d.dk Baggrund vigtigste grunddataopgaver
Læs mereNotat om metadata om grunddata
Bilag 16 - Fælles arkitekturramme for GD1-GD2-GD7 Notat om metadata om grunddata 6. december 2013 SAR & PLACE Indledning Metadata data om data betegner ikke en entydig klasse af data. Anvendelsen af betegnelsen
Læs mere1 Klassifikation Informationsmodel
23..27 Klassifikation Informationsmodel. Facet En facet angiver en bestemt synsvinkel på klassificering af de objekter, som klassifikationssystemet udgør taxonomien for. Facetten grupper klasser i klassifikationssystemet.
Læs mereFaktaark for BBR 2.0
1. december 2014 HEGK Faktaark for BBR 2.0 Overordnet beskrivelse og baggrund for BBR 2.0 Indholdsfortegnelse 1. Indledning... 2 2. Baggrund og formål... 3 BBR i dag... 3 Fremtidige BBR 2.0... 4 3. Teknik...
Læs mereSortiment Informationsmodel
2.9.27 Sortiment Informationsmodel 2.9.27. Delsortiment Delsortimentet er en obligatorisk opdeling af sortimentet i værdilister, samlinger af mulige registreringsværdier, hvor hver samling, delsortimentet,
Læs mereSortiment Informationsmodel
8.2.27 Sortiment Informationsmodel 8.2.27. Delsortiment Delsortimentet er en obligatorisk opdeling af sortimentet i værdilister, samlinger af mulige registreringsværdier, hvor hver samling, delsortimentet,
Læs mereFælles datafordeler - Analyse af afhængigheder til GD1-Ejendomsdata og GD2-Adressedata
Grunddataprogrammets delaftale 7 om effektiv og stabil distribution af data fra registrene til både offentlige og private brugere af grunddata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015
Læs mereST Sortiment Informationsmodel
.5.27 ST Sortiment Informationsmodel .5.27. Delsortiment Delsortimentet er en obligatorisk opdeling af sortimentet i værdilister, samlinger af mulige registreringsværdier, hvor hver samling, delsortimentet,
Læs mereFaktaark for DAR 1.0
1. december 2014 HEGK Faktaark for DAR 1.0 Overordnet beskrivelse og baggrund for DAR 1.0 Indholdsfortegnelse 1. Indledning... 2 2. Baggrund og formål... 3 DAR i dag... 3 Fremtidige DAR 1.0... 4 3. Teknik...
Læs mere1 KlassifikationStruktur
..27 KlassifikationStruktur. KlassifikationStruktur Klassifikation er det abstrakte objekt som samler et klassifikationssystem. Klassifikation holder klassifikationssystemets metadata. Klassifikationssystemet
Læs mere3.0 Velkommen til manualen for kanalen Shift 1. 3.1 Introduktion til kanalen 1. 3.2.1 Hvad er et spot? 2. 3.2.2 Opret et nyt spot 2
3.0 Velkommen til manualen for kanalen Shift 1 3.1 Introduktion til kanalen 1 3.2 Shift kanalside 1 3.2.1 Hvad er et spot? 2 3.2.2 Opret et nyt spot 2 3.2.3 Aktivt og inaktivt spot 3 3.2.4 Rediger et spot
Læs mereFinanstilsynets indberetningssystem. Vejledning til Regnearksskabelonerne
Finanstilsynets indberetningssystem Vejledning til Regnearksskabelonerne Finanstilsynet - 2. udgave oktober 2009 Indholdsfortegnelse 1 INDLEDNING... 2 2 FORUDSÆTNINGER... 3 3 TRIN FOR TRIN... 4 3.1 Hent
Læs mereFællesoffentlig beskedmodel version 1.0
Side: 1 Fællesoffentlig beskedmodel version 1.0 Dokumentet indeholder dels en informationsmodel for hændelsesbeskeden og dens miljø, dels en generisk datamodel for hændelsesbeskeden, som kan danne en fælles
Læs mereIdentifikation af planer der ikke findes i PlansystemDK vha. datasættet... 9
Vejledning i brug af Tingbogsudtrækket Version 1.0 af 1. juli 2009 Indhold Indledning... 1 Planer i Tingbogen... 2 Planer i PlansystemDK... 3 Sammenhæng mellem Tingbogen og PlansystemDK... 3 Datastruktur...
Læs mereTestplan - Snitflade-, Integrations- og anvendertest Bilag B: Planens test cycles
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Testplan - Snitflade-, Integrations- og anvendertest Bilag B: Planens test cycles Version: 2.1 Status: Godkendt af styregruppen Oprettet: 19-12-2016
Læs mereAdresseregister - løsningsarkitektur Bilag B - Informationsmodel
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Delprogram 2: Effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne Adresseregister - løsningsarkitektur
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
8.2.27 SortimentStruktur. SortimentStruktur Et sortiment er en samling af klasser, som er udvalgt fra en eller flere klassifikationer, med et specifikt formål om at afgrænse registreringspraksis i en given
Læs mereUnderbilag 2O Beskedkuvert Version 2.0
Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...
Læs mereDatafordeleren - status, muligheder, udvikling
Datafordeleren - status, muligheder, udvikling FOSAKO Forårsmøde 2019 København, 21. marts 2019 Leif Hernø, chefkonsulent og projektchef for test og implementering af adresse- og ejendomsdataprogrammet
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
22.3.27 SortimentStruktur. DataStructure: SortimentStruktur Et sortiment er en samling af klasser, som er udvalgt fra en eller flere klassifikationer, med et specifikt formål om at afgrænse registreringspraksis
Læs mereGrunddataprogrammet. Ibrugtagningsplan for modelregler for grunddata
Grunddataprogrammet Ibrugtagningsplan for modelregler for grunddata 1 Ibrugtagningsplan for modelregler for grunddata Version: 0.5 Status: Godkendt 2 Versionshistorik Version Dato Status Bemærkninger 0.1
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
2.9.27 SortimentStruktur. SortimentStruktur Et sortiment er en samling af klasser, som er udvalgt fra en eller flere klassifikationer, med et specifikt formål om at afgrænse registreringspraksis i en given
Læs mereBilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler
Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7 Etablering af datadistribution på den Fællesoffentlige Datafordeler Version: 0.8 Status: udkast Oprettet: 10.3.2014 Dato: 16. juni 2014 Dokument historie
Læs mereFKG datamodellen Version Implementeringsguidelines. FKG datamodellen Version Implementeringsguidelines
FKG Fælleskommunale Geodatasamarbejde FKG datamodellen Version 2.3.1 Implementeringsguidelines Sidste revisionsdato: 24. oktober 2013 1 Dokumenthistorik Version Dato Initialer Ændring 1.0 5.7.2013 TBS/NIRAS
Læs mereAdresseregister - løsningsarkitektur Bilag B - Informationsmodel
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi 202 205 Delprogram 2: Effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne Adresseregister - løsningsarkitektur
Læs mereGrunddatabeskedmodel version 1.0
Grunddatabesked Side: 1 Grunddatabeskedmodel version 1.0 Grunddata-besked version 1.0 Beskedformatet er det samme for både beskeder, som genereres af datafordeleren på basis af data-opdateringer fra registrene,
Læs mere<navn på proces eller use case>
-- AKT 444548 -- BILAG 1 -- [ Bilag B1_Skabelon Integrationstabel ] -- Bilag B1 Integrationstabel Formålet med integrationstabellerne er at danne et samlet overblik over de tekniske integrationer, der
Læs mere7.0 Velkommen til manualen for kanalen Gæsteliste Introduktion til kanalen Gæsteliste kanalside Hvad er et spot?
7.0 Velkommen til manualen for kanalen Gæsteliste 1 7.1 Introduktion til kanalen 1 7.2 Gæsteliste kanalside 1 7.2.1 Hvad er et spot? 2 7.2.2 Opret et nyt spot 2 7.2.3 Aktivt og inaktivt spot 3 7.2.4 Rediger
Læs mereEjendomsdataprogrammet - BBR Løsningsarkitektur Bilag A Servicebeskrivelser
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - BBR Løsningsarkitektur
Læs mere1 Tilstand informationsmodel - Byggeblok
1 Tilstand informationsmodel - Byggeblok Logisk Informationsmodel for Byggeblokken Tilstand : Overordnet model til at beskrive "tilstande". Modellen er generisk og kan bruges som skabelon på tværs af forretningsområder
Læs mereSortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.
8..27 SortimentOverfør Kort beskrivelse: Denne service distribuerer ØiR Sortimenter til It-systeminstanser, der abonner på sortimentet på vegne af en myndighed. Servicen udstilles som integrationen SF_72
Læs mereGrunddataprogrammet. Side 1 af 11. Aftale om styringsrammer for grunddatamodellen
Grunddataprogrammet Side 1 af 11 Aftale om styringsrammer for grunddatamodellen Side 1 af 11 11. oktober 2013 SAR Aftale om styringsrammer for grunddatamodellen Formål Formålet med aftalen er at sikre
Læs meree-journal Suploader-funktionalitet Suploader-funktionalitet Forfatter: Erik H. Olesen Fejl! Henvisningskilde ikke fundet. Erik H. Olesen Kunde: MedCom
e-journal Suploader-funktionalitet Forfatter: Erik H. Olesen Fejl! Henvisningskilde ikke fundet. Erik H. Olesen Kunde: MedCom Emne: e-journal Suploader-funktionalitet Side 1 af 12 Dokumenthistorik Revision
Læs mereEjendomsdataprogrammet - Matriklen Løsningsarkitektur
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Matriklen Løsningsarkitektur
Læs mereKvalitetssikring af ESR data ift. GD1 og GD2 Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012-2015
Kvalitetssikring af ESR data ift. GD1 og GD2 Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi 2012-2015 22. juni 2015 Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning
Læs mereEjendomsdataprogrammet - Målarkitektur Bilag D: Fælles arkitekturrammer
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Målarkitektur Bilag D:
Læs mereBilag til vejledning i anvendelse af attentionformatet i Digital Post-løsningen. December 2017, version 0.9
Bilag til vejledning i anvendelse af attentionformatet i Digital Post-løsningen December 2017, version 0.9 Hvad kan du læse om? I denne vejledning kan du læse om hvilke retningslinjer, der gælder for den
Læs mereBrugervejledning til databrowseren
Brugervejledning til databrowseren Indholdsfortegnelse Indledning...2 Hvordan tilgås browseren og api et...2 Databrowseren...2 Søgning...2 Visning...4 Features i listevisningen...4 Detaljeret visning...5
Læs mereADK 1.0 KRAVSPECIFIKATION
ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 17-06-2014 MST Oprettelse af krav 0.2 18-05-2014 MST Tilretning af tabeller 0.3 18.06.2014 PKR
Læs mereGrunddataprogrammerne. Georg Bergeton Larsen og Jørgen Grum
Grunddataprogrammerne Georg Bergeton Larsen og Jørgen Grum Styrelsen for Dataforsyning og Effektivisering 29. marts 2018 Side 1 Oversigt - Datafordeler (aktiviteter og planer) - Adresser (GD2) - Ejendomme
Læs mereKursusbeskrivelse. Forarbejde. Oprettelse af en Access-database
Kursusbeskrivelse Oprettelse af en Access-database Som eksempel på en Access-database oprettes en simpelt system til administration af kurser. Access-databasen skal indeholde: et instruktørkartotek et
Læs mereDAR OIO vejledning Version 1.2
DAR OIO vejledning Version 1.2 Indhold 1 Ændringer i forhold til forrige version... 2 2 Introduktion... 3 2.1 Formål... 3 2.2 Læsevejledning... 3 3 Beskrivelse... 3 3.1 Fælles elementer og strukturer...
Læs mereKommentar fra KMS til Specifikation af Serviceinterface for Person
Kommentar fra KMS til Specifikation af Serviceinterface for Person Organisation Side Kapitel Afsnit/figur/tabel /note Type af kommentar (generel (G), redaktionel (R), teknisk (T)) Kommentar KMS-1 G Godt
Læs mere- Kort præsentation af 3 løsningsscenarier
Arbejdspakke under grunddataprogrammets delaftale 2 om adresser, stednavne og administrative inddelinger under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Analyse af danske myndigheders brug
Læs mereEjendomsdataprogrammet - Matriklen Løsningsarkitektur
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Matriklen Løsningsarkitektur
Læs mereEjendomsdataprogrammet - Ejerfortegnelse Løsningsarkitektur
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Ejerfortegnelse Løsningsarkitektur
Læs mereVejledning. Udbygningsaftale. Vejledning til indberetning af en udbygningsaftale i Plandata.dk. Udarbejdet af Erhvervsstyrelsen. Version: 1.0.
Vejledning Udbygningsaftale Vejledning til indberetning af en udbygningsaftale i Plandata.dk Udarbejdet af Erhvervsstyrelsen Version: 1.0.0 Dato: 17-06-2019 Indholdsfortegnelse Revisionshistorik... 3 1.
Læs mereDen fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering
Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering Fundament Vision & Strategi Logik Rammearkitektur Fysik Udvikling/Implementering 2 10.6.2014 De 5 digitaliseringsmål
Læs mere4.0 Velkommen til manualen for kanalen RSS Introduktion til kanalen Hvad er et spot? Opret et nyt spot 2
4.0 Velkommen til manualen for kanalen RSS 1 4.1 Introduktion til kanalen 1 4.2 RSS kanalside 1 4.2.1 Hvad er et spot? 2 4.2.2 Opret et nyt spot 2 4.2.3 Aktivt og inaktivt spot 4 4.2.4 Rediger et spot
Læs mereÆndringer Masseoprettelse og masseredigering af kontaktlærertilknytninger er ny funktionalitet i EASY-A. Forklaring eller beskrivelse
Masseoprettelse og masseredigering af kontaktlærertilknytninger 29-10-2007/version 1/mgl Indhold Ændringer Centrale begreber Generelt Arbejdsgange Fremsøgning af elever Opret (nye) kontaktlærertilknytninger
Læs mere10.2a Samordnet genbrug af ejendoms- og bygningsdata - Kvalificering af business case
Fællesoffentlig Digitaliseringsstrategi 2012 2015 10.2a Samordnet genbrug af ejendoms- og bygningsdata - Kvalificering af business case EBST-REF: 602-18098 SPOR: 1 Arbejdspakke 3 - Processer ift. BBRregistrering
Læs mereVilkår for brug af Støttesystemet Sags- og Dokumentindeks
Version 1.0 Vilkår for brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og
Læs mereSundhedsvæsenets Organisationsregister (SOR) Regler i relation til Sygehus-afdelinger
Sundhedsvæsenets Organisationsregister (SOR) Regler i relation til Sygehus-afdelinger Indhold 1 SghAfd-regler 2 1.1 Grundlæggende funktionalitet i SOR-applikationen 2 1.2 Anvendt terminologi 3 1.3 Regler
Læs mere1 Objekt informationsmodel - Byggeblok
1 Objekt informationsmodel - Byggeblok Logisk Informationsmodel for Byggeblokken Objekt Modellen beskriver og viser hvordan Forretningsobjekt "Objekt" kan forstås. Modellen er generisk, og kan derfor bruges
Læs mereVejledning. Kommuneplanstrategi. Vejledning til indberetning af en kommuneplanstrategi i Plandata.dk. Udarbejdet af Erhvervsstyrelsen. Version: 1.
Vejledning Kommuneplanstrategi Vejledning til indberetning af en kommuneplanstrategi i Plandata.dk Udarbejdet af Erhvervsstyrelsen Version: 1.0 Dato: 09-05-2019 Indholdsfortegnelse Revisionshistorik...
Læs mereMaterialeadministration Sidst opdateret 31-08-2006/version 1.0/Steen Eske Christensen
Materialeadministration Sidst opdateret 31-08-2006/version 1.0/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Arbejdsgange Vejledningen består af 3 dele, som kan læses hver for sig.
Læs mereScope dokument for Advisservice
18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.
Læs mereEjendomsdataprogrammet - BBR Løsningsarkitektur Bilag B Informationsmodel
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - BBR Løsningsarkitektur
Læs mereEksamensbeviser og karakterer til Eksamensdatabasen Sidst opdateret 01-02-2007/version 1.1/Steen Eske Christensen
Eksamensbeviser og karakterer til Eksamensdatabasen Sidst opdateret 01-02-2007/version 1.1/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Arbejdsgange Vejledningen består af 3 dele,
Læs mereModelafleveringsproces
Appendix - Informationsmodel og Datamodel Side: 1 Modelafleveringsproces Modelafleveringsproces Modelafleveringsproces Diagrammet beskriver de processer, der knytter sig til indlevering af en datamodel
Læs merePlaners tilvejebringelse og ophævelse i Plandata.dk
Vejledning Planers tilvejebringelse og ophævelse i Plandata.dk Vejledning til, hvilke status en lokalplan og kommuneplan- og tillæg gennemgår, herunder mulighederne for at foretage fejlrettelser. Udarbejdet
Læs mereVANSEnvelope TESTPROTOKOL FOR DEN GODE VANSENVELOPE. Namespace: urn:oio:medcom:vans-envelope: VANS
VANSEnvelope TESTPROTOKOL FOR DEN GODE VANSENVELOPE VANS 12.05.2011 Namespace: urn:oio:medcom:vans-envelope:1.0.4 DOKUMENT HISTORIK Version Forfatter Dato Beskrivelse 1.0 JAG 12.05.2011 Start på dokument
Læs mereSTØTTESYSTEMET KLASSIFIKATION
STØTTESYSTEMET KLASSIFIKATION v/ Martin Bo Jensen 26. februar 2019 KOMBITs løsninger og fælleskommunal infrastruktur 2 Kommunale fagområder Arbejdsmarked og erhverv Social og sundhed Børn og læring Mit
Læs mereVersion Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.
MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.
Læs mereEjendomsdataprogrammet - Matriklen Løsningsarkitektur - Bilag C Processer
Grunddataprogrammets delaftale 1 om effektiv ejendomsforvaltning og genbrug af ejendomsdata under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Ejendomsdataprogrammet - Matriklen Løsningsarkitektur
Læs mereTips & Tricks nr. 68 Prøvebeviser for gymnasiale fag V02
LUDUS Helpdesk T +45 3614 7070 sc-ludus@dxc.com CSC Scandihealth A/S - en del af DXC Technology P.O. Pedersens Vej 2 8200 Aarhus N T +45 3614 4000 Tips & Tricks nr. 68 Prøvebeviser for gymnasiale fag V02
Læs mereAdresseregister - løsningsarkitektur Bilag C - Processer
Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Delprogram 2: Effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne Adresseregister - løsningsarkitektur
Læs mere5.0 Velkommen til manualen for kanalen HTML-grab Introduktion til kanalen HTML-grab kanalside Hvad er et spot?
5.0 Velkommen til manualen for kanalen HTML-grab 1 5.1 Introduktion til kanalen 1 5.2 HTML-grab kanalside 1 5.2.1 Hvad er et spot? 2 5.2.2 Opret et nyt spot 2 5.2.3 Aktivt og inaktivt spot 3 5.2.4 Rediger
Læs mereBBR. Bygnings- og Boligregisteret. - Version 2.0, marts Morten Lind, SKAT / Ejendomsdatakontoret August 2016
BBR Bygnings- og Boligregisteret - Version 2.0, marts 2017 - Morten Lind, SKAT / Ejendomsdatakontoret August 2016 Parterne bag BBR 2 Baggrunden for BBR 2.0 Grunddataprogrammet og planerne for ny ejendomsvurdering
Læs mereGrunddataprogrammet. Præsentation den 24. februar 2016 Deniz Gøgenur
Grunddataprogrammet Præsentation den 24. februar 2016 Deniz Gøgenur deng@nanoq.gl Overordnede mål og perspektiver Strategiske mål for programmet: Grunddataprogrammet skal sikre korrekte grunddata, der
Læs mereVEJDIREKTORATET. Vejdirektoratet. DANBRO+ Forvaltningsmanual. Modul 0; Bilag Generelle beskrivelser; Årets gang. Dato: 2010-03-29 Revision: 2
VEJDIREKTORATET Generelle beskrivelser Bilag 3: Årets gang dokument: VD_Drift_Modul_0_Bilag_Årets_gang.doc Indholdsfortegnelse 1. INDLEDNING... 3 1.1 Revision og Gyldighed... 3 2. ÅRETS GANG - OVERSIGT...
Læs mereFor at kunne forstå de mange data vi har adgang til, er det nødvendigt at kunne koble dem til den virkelighed, vi vil forstå, analysere, ændre på.
For at kunne forstå de mange data vi har adgang til, er det nødvendigt at kunne koble dem til den virkelighed, vi vil forstå, analysere, ændre på. 1 Vejreferencemodellen er opstået som en reaktion på de
Læs mereUdgivelsen er beskyttet af Creative Commons license, Navngivning 2.5
OIOUBL Guideline OIOUBL UUID UBL 2.0 UUID G32 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL UUID Version 1.1 Side 1 Kolofon Kontakt: IT- & Telestyrelsen E-mail:
Læs merePlan for grunddataforbedringer sommer 2016 forår 2017
GD2 - Adresseprogrammet: Effektivt genbrug af grunddata om adresser, administrative inddelinger Plan for grunddataforbedringer sommer 2016 forår 2017 Styrelsen for Dataforsyning og Effektivisering 1 Plan
Læs mereDAGI Løsningsarkitektur Bilag A - Servicebeskrivelser og integrationer
Bilag 9 Fælles arkitekturramme for GD1GD2GD7 Grunddataprogrammets delaftale 2 om effektiv genbrug af grunddata om adresser, administrative inddelinger og stednavne DAGI Løsningsarkitektur Bilag A Servicebeskrivelser
Læs mereIDAP manual Analog modul
IDAP manual Analog modul Dato: 15-06-2005 11:01:06 Indledning Til at arbejde med opsamlede og lagrede analoge data i IDAP portalen, findes en række funktions områder som brugeren kan anvende. Disse områder
Læs mereBilag A Milepælsplan for GD2
Grunddataprogrammets delaftale 2 om effektivt genbrug af grunddata om adresser, administrative inddelinger og stednavne under den Fællesoffentlige Digitaliseringsstrategi 2012 2015 Bilag A Milepælsplan
Læs mereJAR Øvelse nr. 2. JAR-Manual, Version 1.0. Avanceret søgning. Regionsvejledning
JAR Øvelse nr. 2 Avanceret søgning Regionsvejledning JAR-Manual, Version 1.0 Øvelse ID: 2 Øvelsesemne: Avanceret søgning Øvelsesbeskrivelse: Gør dig i stand til at bygge avancerede søgninger op. Formål:
Læs mereFælles arkitekturramme for GD1-GD2-GD7
Ejendomsdataprogrammet (GD1) Adresseprogrammet (GD2) Cover til Fælles arkitekturramme for GD1-GD2-GD7 Fælles arkitekturramme for GD1-GD2-GD7 - kravbilag til brug for GD1-GD2 s kravspecificering Version:
Læs mereOff-line redigering i Arealdata
Brugervejledning Danmarks Arealinformation Den 6. januar 2009 Off-line redigering i Arealdata Trin-for-trin vejledning 6. januar 2009 INDHOLDSFORTEGNELSE SIDE 1. Redigering i Arealdata 3 2. Proces ved
Læs mere/marius hartmann Integrationskrav 2. Logningskrav 3. Konsekvenser for kommunen
/marius hartmann maha31@frederiksberg.dk 20141002 Ang./ Vilkår for integration til støttesystemet Sags- og Dokumentindeks version 1.3 Denne fælleshenvendelse, som dækker it-arkitekterne fra Ballerup, Odense,
Læs mereSpecifikation af Model for Klassifikation Version 2.0
1 Specifikation af Model for Klassifikation Version 2.0 > Specifikation af Model for Klassifikation Version 2.0 Denne standard kan frit anvendes af alle. Citeres der fra standarden i andre publikationer
Læs mere