Vejledning til dataopmærkning i MeMo. Næste generation Digital Post Maj 2018, version 0.9

Transkript

1 Vejledning til dataopmærkning i MeMo Næste generation Digital Post Maj 2018, version 0.9

2 Indhold 1 Introduktion Terminologi 4 2 Opbygning af MeMo Fast definerede ressourcer Fleksible ressourcer Digital Post ressourcer Afsender ressourcer 6 3 MessageHeader dataopmærkning AttentionData Undermyndighed Overmyndighed Produktionsenhed (P-nummer) Attention person GLN (Global Location Number) Momsnummer (SE-nummer) AttentionData for kontaktpunkt ContentData CPR-nummer CVR-nummer CVR/RID-nummer KLE FORM Synsindkaldelse Ejendomsnummer MeMo til Print ReplyData 11 4 MessageBody dataopmærkning Action klassen Send meddelelse på flere sprog og formater Send meddelelse på et sprog og i et format Send meddelelse på et sprog og i flere formater Send meddelelse på flere sprog og i et format Send meddelelse på flere sprog og i flere formater Send meddelelse fra myndighed til myndighed 20 Appendix A. Intro til RDF 23

3 1 Introduktion [Denne version af vejledningen er udarbejdet som en del af høringsmaterialet til udsendelse maj 2018.] Dette dokument er en teknisk vejledning til anvendelse af dataopmærkning i datastandarden MeMo til anvendelse i næste generation Digital Post (NgDP). Vejledningen er tiltænkt leverandører af Digital Post løsninger samt myndigheder, som ønsker at anvende dataopmærkning af Digital Post meddelelser. Vejledningen er forholdsvis teknisk og forudsætter kendskab til domænet Digital Post. Dataopmærkning giver mulighed for, at afsenderen præcist kan angive modtager, samt hvilke ReplyData, som ønskes returneret. Dataopmærkning giver også mulighed for, at modtagere bedre kan fordele meddelelser i Digital Post, således at afsender får færre supporthenvendelser og flere rettidige svar. Endelig giver dataopmærkningen også mulighed for at hjælpe modtagere til at huske og reagere korrekt på den fremsendte meddelelse. Den logiske datamodel for MeMo er beskrevet i detaljer i dokumentet MeMo Model beskrivelse. MeMo beskriver syntaks og semantik for netop en Digital Post meddelelse Denne vejledning indeholder en uddybning af følgende elementer og emner i MeMo: Opbygning af MeMo ved brug af RDF. Dette er beskrevet i afsnit 2. Brug af dataopmærkning i MessageHeader, herunder: o AttentionData som indeholder supplerende oplysninger om modtageren. F.eks. en ansvarlig person i modtagende organisation. Dette er beskrevet i afsnit 3.1 o ContentData som anvendes til at præcisere indhold og emne. Dette er beskrevet i 3.2 o ReplyData som returneres ved besvarelse af meddelelse. Dette er beskrevet i afsnit 3.1 o Brug af dataopmærkning i MessageBody, herunder: o Brug af Actions, som gør det lettere for modtager at reagere på posten. Dette er beskrevet i afsnit 4.1 o Sende meddelelse på flere sprog og formater. Dette er beskrevet i afsnit 4.2 Vejledningen indeholder retningslinjer for opmærkning af data i MeMo formatet. Det er afsenderens ansvar at dataopmærke korrekt for at modtageren af posten kan få det fulde udbytte.

4 1.1 Terminologi I dette afsnit beskrives den terminologi, som anvendes i vejledningen. Term Digital Post Meddelelse Afsendersystem Fagsystem Modtagersystem Visningsklient Forklaring Løsningen som modtager Digital Post meddelelser, videresender til myndigheder og virksomheder, samt opbevarer meddelelser for de borgere og virksomheder som ønsker det. En Digital Post meddelelse der indeholder digitalt indhold til modtageren i form af metadata og filer. Det IT-system som afsender Digital Post meddelelser til Løsningen. Det fagsystem som skaber og udsender meddelelser via et afsendersystem. Et IT-system kan godt være både afsendersystem og fagsystem. Det IT-system som myndigheder og virksomheder kan opsætte til at modtage Digital Post meddelelser i MeMo format. Brugergrænsefladen som borgere og virksomheder anvender til at se og besvare Digital Postmeddelelser. Visningsklienter vil som minimum blive stillet til rådighed af Borger.dk og Virk.

5 2 Opbygning af MeMo Dette afsnit beskriver hvorledes man kan repræsentere datastandarden MeMo i overensstemmelse med RDF standardmodellen for dataudveksling (se nærmere omkring RDF i Appendix A) og i en genkendelig, hierarkisk XML-struktur. Følgende retningslinjer gælder for anvendelse af RDF i den fysiske model Modellen har en fast struktur, som sikrer entydige syntaks og semantik og tillader ensartet håndtering af meddelelser, samtidig med at modellen er fleksibel, så den kan rumme variationer af forskellige typer af meddelelser. Alle klasserne i den logiske model er beskrevet som ressourcer i den fysiske model. Som udgangspunkt benyttes eksisterende felter fra Dublin Core vokabular, ellers benyttes lokale udvidelser memo: til beskrivelsen af MeMo ressourcer. En meddelelse skal overholde den beskrevne struktur, og skal være et validt RDF format. Navne angives på engelsk For XML eksempler på MeMo-formatet henvises til: MeMo_XML_eksempel_Full.rdf - indeholdende alle beskrevne elementer og MeMo_XML_eksempel_Minimum.rdf - et eksempel med minimalt indhold. 2.1 Fast definerede ressourcer Ressourcer er fast definerede i MeMo formatet og angives på samme måde. Ressourcerne udtrykker den logiske model og kan derfor være obligatoriske og have obligatoriske elementer. Eksempelvis skal header oplysningerne forefindes i MeMo meddelelsen, hvor dc:identifier og dc:title er obligatoriske elementer (se udsnit nedenfor). <rdf:description rdf:about=" <memo:header> <rdf:description rdf:about=" <dc:identifier>abc-1234</dc:identifier> <dc:title>lønseddel</dc:title> <memo:notification xml:lang="da">lønseddel fra DIGST</memo:Notification> <memo:caseid>sag </memo:caseid> <dc:type>obligatorisk</dc:type> </memo:header>

6 Fleksible ressourcer Det er muligt at udvide modellen til at medsende data på specifikke domæneområder. Domænespecifikke felter skal udtrykkes som ressourcer, og vil være betinget af meddelelsens type og indhold. Domænespecifikke udvidelser kan enten være defineret af Digital Post eller af den enkelte afsender Digital Post ressourcer Ressourcer som benyttes på tværs af myndigheder og meddelelser skal altid angives på samme måde som en del af MeMo namespace. I de tilfælde er der ofte tale om et nummer, id eller kode med en tilhørende tekst, der kan angives som henholdsvis memo:id og memo:label. Det vil f.eks. gælde: CPR-nummer FORM-koder KLE-koder Eksempelvis: <rdf:description rdf:about=" <memo:id> </memo:id> <memo:label>vedligeholdelse/renovering af køretøjer</memo:label> Afsender ressourcer En afsender (myndighed eller organisation) kan udvide dataformatet ved at beskrive egne ressourcer, som er specifikke for netop det domæneområde. Det giver mulighed for, at afsenderen kan opmærke og medsende netop de informationer om indholdet af meddelelsen som er relevante, og som med størst sandsynlighed kan hjælpe modtageren med at sortere og fordele indkomne meddelelser. Modellen er den samme som beskrevet ovenfor, blot navngiver afsenderen selv sin ressource og afsenderen bestemmer selv syntaks og semantik på de elementer, som skal beskrive ressourcen. En ressource skal angives på samme måde fra gang til gang. I eksemplet nedenfor er ressourcen Synsindkaldelse og der er angivet to elementer til beskrivelse heraf henholdsvis Registreringsnummer og Stelnummer.

7 [xmlns:fstyr=" <rdf:description rdf:about=" <fstyr:registreringsnummer>ab12345</fstyr:registreringsnummer> <fstyr:stelnummer>wfr18zz67w094959</fstyr:stelnummer> Afsender definerede ressourcer kan kun angives i ContentData klassen (se afsnit 3.2) 3 MessageHeader dataopmærkning I tidligere versioner af Digital Post, har det være muligt at vedhæfte en separat fil (attentionformat.xml) indeholdende dataopmærkninger fra afsenderen. Formålet med at medsende de yderligere data er, at modtageren kan få supplerende informationer på en struktureret måde, der kan hjælpe med automatisk at sortere og fordele modtagne meddelelser. Eksempler på eksisterende dataopmærkninger fra afsendere, er data i forbindelse med straffe- og børneattester fra Rigspolitiet og synsindkaldelser fra Færdselsstyrelsen, som er defineret i Initiativ 1.5 i den fællesoffentlige Digitaliseringsstrategi. I MeMo datastandarden er dataopmærkningerne indlejret sammen med de øvrige data, så der ikke længere er tale om separate filer, der skal medsendes. Data er struktureret med en fast syntaks og semantik, men har også indbygget en vis fleksibilitet, som tilgodeser, at der over tid kan være andre domæner som ønsker at opmærke. MeMo datastandarden skelner mellem dataopmærkninger der har til formål at supplere information omkring afsenderen eller modtageren af meddelelsen (AttentionData) og dataopmærkninger, som har til formål at supplere information omkring indholdet af meddelelsen (ContentData). Dette er beskrevet i henholdsvis afsnit 3.1 og afsnit 3.2. Eksempelvis kan en meddelelse vedrørende et barn sendes fra en myndighed til en forælder. Meddelelsen sendes i dette tilfælde til forældrenes CPR-nummer (primærpart), mens barnets CPR-nummer angives under ContentData (sekundærpart), fordi det er barnet meddelelsen vedrører. 3.1 AttentionData Der skal angives én afsender og én modtager i en meddelelse, og de skal helt entydigt kunne identificeres med enten CPR-nummer, CVR-nummer eller MyndighedsID.

8 Der kan være behov for at angive supplerende oplysninger om afsender- eller modtagerorganisation fx. for at identificere organisatorisk tilhørsforhold, for at identificere en fysisk lokation, en ansvarlig person eller lignende. Følgende AttentionData beskrevet som ressourcer kan som udgangspunkt angives som supplerende data i relation til afsender eller modtager. Listen er ikke udtømmende, men kan udvides, hvis der bliver behov herfor. Høringsparter opfordres til at give input til yderligere data som kan medsendes. Bemærk, at hver ressource kun kan angives én gang for henholdsvis, afsender og modtager. Et bud på hvordan ressourcerne skal udtrykkes er angivet nedenfor Undermyndighed <rdf:description rdf:about=" <memo:id>[afdelingsid]</memo:id> <memo:label>[afdeling]</memo:label> Overmyndighed <rdf:description rdf:about=" <memo:id>[juridiskmyndighedid]</memo:id> <memo:label>[juridisk myndighed]</memo:label> Produktionsenhed (P-nummer) <rdf:description rdf:about=" <memo:id>[p-nummer]</memo:id> <memo:label>[navn på produktionsenhed]</memo:label> Attention person <rdf:description rdf:about=" <memo:id>[id/medarbejderid]</memo:id> <memo:label>[navn for attention]</memo:label> <rdf:description rdf:about=" <memo:id>[ adresse]</memo:id> <memo:label>[navn på ejer]</memo:label> GLN (Global Location Number) <rdf:description rdf:about="

9 <memo:id>[gln]</memo:id> <memo:label>[gln titel]</memo:label> Momsnummer (SE-nummer) <rdf:description rdf:about=" <memo:id>[se-nummer]</memo:id> <memo:label>[ejer af SE-nummer]</memo:Label> AttentionData for kontaktpunkt Ved initial oprettelse og afsendelse af en meddelelse fra en borger eller virksomhed til en myndighed via Digital Post, kan afsenderen identificere den korrekte modtager ved opslag i Myndighedsregisteret. Data for det valgte kontaktpunkt (kontaktpunkt ID, kontaktpunkt gruppe og eventuelle søgeord) struktureres i en AttentionData klasse for kontaktpunkt data, og skal medvirke til, at den korrekte modtager hos myndigheden kan identificeres. Klassen giver også mulighed for at medsende strukturerede data, som kan være hentet i forbindelse med genereringen af en meddelelse eksempelvis fra opslag i myndighedens kontaktpunkter, når f.eks. en borger skriver til en myndighed via en visningsklient. <rdf:description rdf:about=" <memo:contactgroup>[kontakgruppe]</memo:contactgroup> <memo:contactpointid>[kontaktpunktid]</memo:contactpointid> <memo:contactpointlabel>[kontaktpunkt betegnelse]</memo:contactpointlabel> <memo:searchword>[søgeord 1]</memo:SearchWord> <memo:searchword>[søgeord 2]</memo:SearchWord> 3.2 ContentData Afsenderen af en meddelelse kan medsende supplerede information om indholdet af meddelelsen, for at hjælpe modtageren med at sortere og fordele indkomne meddelelser. Som eksempel kan nævnes at der i forbindelse med nogle henvendelser til en myndighed, kan være krav om, at afsenderen skal medsende nogle bestemte oplysninger, relevante for typen af henvendelse. Det kan f.eks. være, at man i en meddelelse vedrørende sit barn, skal angive barnets CPR-nummer eller at man skal angive et matrikelnummer i en byggesagsansøgning. Data om meddelelsen skal i MeMo formatet angives under ContentData i overensstemmelse med beskrivelsen heraf. Eksempelvis CPR-nummer som beskrevet nedenfor.

10 De medsendte dataopmærkninger skal angives som ressourcer i overensstemmelse med RDF standardmodellen. Som tidligere beskrevet vil nogle ressourcer være relevante på tværs af afsendende organisationer og meddelelser. For at sikre konsistens vil de blive defineret af Digital Post og skal angives i overensstemmelse hermed. Det drejer sig (foreløbigt) om følgende: CPR-nummer <rdf:description rdf:about=" <memo:id>[cvr-nummer]</memo:id> <memo:label >[Navn]</memo:Label > CVR-nummer <rdf:description rdf:about=" <memo:id>[cvr-nummer]</memo:id> <memo:label>[virksomhedsnavn]</memo:label> CVR/RID-nummer <rdf:description rdf:about=" <memo:id>[cvr-rid-nummer]</memo:id> <memo:label>[navn]</memo:label> KLE <rdf:description rdf:about=" <memo:id> </memo:id> <memo:label>byggesagsgebyrer</memo:label> FORM <rdf:description rdf:about=" <memo:id> </memo:id> <memo:label>syn af køretøjer</memo:label> I andre tilfælde definerer afsendende organisationer selv deres ContentData, og skal således selv beskrive ressourcerne i overensstemmelse med MeMo formatet og RDF. I det følgende er vist, hvordan allerede kendte opmærkninger fra offentlige myndigheder (udarbejdet i regi af Initiativ 1.5) skal angives i MeMo meddelelsen.

11 3.2.6 Synsindkaldelse Nedenfor findes eksempel på, hvordan synsindkaldelser kan angives fra Rigspolitiet. <rdf:description rdf:about=" <fstyr:registreringsnummer>ab12345</fstyr:registreringsnummer> <fstyr:stelnummer>wfr18zz67w094959</fstyr:stelnummer> Ejendomsnummer Nedenfor findes eksempel på, hvordan ejendomsnummer kan angives fra SKAT. <rdf:description rdf:about=" "> <skat:ejendomsnummer>[xxx-yyyyyy]</skat:ejendomsnummer> MeMo til Print Et andet eksempel på ContentData, er data som er relevante for at kunne printe en meddelelse og sende den som et fysisk brev. I de tilfælde, hvor en modtager er undtaget fra at skulle modtage Digital Post kan der medsendes adresseinformation, som giver mulighed for, at en MeMo meddelelse kan sendes til en printleverandør eller printafdeling, hvor meddelelsen printes og sendes som fysisk brev til den angivne adresse. ContentData herfor skal struktureres som i eksemplet nedenfor. <rdf:description rdf:about=" <memo:address1>[1. adresselinje]</memo:address1> <memo:address2>[2. adresselinje]</memo:address2> <memo:address3>[3. adresselinje]</memo:address3> <memo:zipcode>[postnummer]</memo:zipcode> <memo:cityname>[by]</memo:cityname> <memo:countrycode>[landekode f.eks. DK]</memo:CountryCode> Information om print- og brevformat samt forsendelsesmetode skal aftales separat, og er ikke en del af MeMo-formatet. 3.3 ReplyData I Digital Post er det muligt at besvare meddelelser, hvis afsenderen har angivet, at det er muligt dvs. anført at meddelelsen kan besvares. Når meddelelsen bliver besvaret vil svaret blive en del af en konversation/tråd af meddelelser. Det angives i MeMo ved i klassen ReplyData at angive ID på forrige meddelelse.

12 Svar Svar på henvendelse Henvendelse Figur 1 Sammenkædning af meddelelser Meddelelser i en konversation skal derfor opfattes som en kæde af meddelelser, hvor hver meddelelse alene peger på den forrige besked, hvilket en visningsklient eller et mailsystem kan bruge til at præsentere sammenhængen mellem beskederne for brugeren Klassen ReplyData giver også afsender mulighed for at angive andre data, som skal med retur, når der svares på meddelelsen. Det er typisk informationer som ikke er relevante at præsentere for modtager, men som den afsendende myndighed kan anvende til at fordele og præjournalisere svaret effektivt, når det kommer retur. Det er illustreret i følgende use case Use case nr. 1 Medsend ReplyData ved besvarelse Formål Aktører Formålet med denne use case er at vise, hvorledes en myndighed kan medsende ReplyData, som sendes med retur i svaret fra en borger Myndighed, sagsbehandler, fagsystem og anvendersystem Hændelse Startbetingelse En myndighed ønsker at sende en meddelelse om, at en borger skal indsende en aktuel formueopgørelse Myndighedens fagsystem integrerer til Digital Post via et afsendersystem

13 Normalforløb: En sagsbehandler udarbejder meddelelse om, at en borger skal indsende en aktuel formueopgørelse, som kan indgå i sagens oplysning. Felt ReplyData#1 MessageID ReplyID (samme som ID) Afsendersystemet opretter en MeMo-instans, som indeholder følgende ReplyData: 4ceef18e-a60a-49ec-8c7beb065f (id på første besked) Tomt i første besked CaseID Borgeren ser meddelelsen på borger.dk og besvarer meddelelsen. Borger.dk kopierer ReplyData og danner sit eget sæt af ReplyData, som her kun består af ReplyID. Felt ReplyData#1 ReplyData#2 MessageID 4ceef18e-a60a-49ec- 8c7b-eb065f d888b b5f a1be2d0 ReplyID (tom) 4ceef18e-a60a-49ec- 8c7b-eb065f CaseID (Tom) Slutresultat 1 Myndigheden modtager beskeden fra borgeren i et input managementsystem som via CaseID kan journalisere den indgående besvarelse direkte i fagsystemet. Borgeren kan i sin visningsklient på Borger.dk få præsenteret henvendelsen og svaret herpå i en sammenhæng. 4 MessageBody dataopmærkning I dette afsnit beskrives dataopmærkning for de klasser der findes bodydelen af MeMo.

14 4.1 Action klassen Formålet med Action klassen er, at afsenderen kan medsende data, der giver modtageren mulighed for at interagere med andre løsninger. Der kan være en eller flere actions tilknyttet et dokument. I en Action klasse kan angives en label, som er en slags overskrift til den givne action, og som eventuelt kan benyttes som tekst til et link eller en knap i en visningsklient. Endvidere kan anføres en mulig deadline for, hvornår handlingen skal være udført. Afhængig af modtagerklienten kan informationerne benyttes som en ekstra service til modtageren, hvor denne f.eks. gøres opmærksom på mulige handlinger og nært forestående tidsfrister. Der skelnes overordnet mellem kalenderinformation og andre interaktioner. Kalenderinformation er aftaledata, som visningsklienten kan vælge at understøtte, og som kan give modtageren mulighed for integration til egen kalenderløsning. Eksempel på kalenderdata: <rdfs:description rdf:about=" <memo:uid> t230445z @xxx</memo:uid> <memo:dtstart> </memo:dtstart> <memo:dtend> </memo:dtend> <memo:summary>indkaldelse til syn</memo:summary> <memo:location>bilsyn A/S, Borgergade 9, 9000 Aalborg</memo:Location> <memo:organizercn>jens Hansen</memo:OrganizerCN> <memo:organizermailto>jh@bilsyn.dk</memo:organizermailto> <memo:description>de indkaldes hermed til bilsyn...</memo:description> </rdfs:description> Andre interaktioner skal angives som en URI, og vil typisk være et dybt link til eksterne løsninger. Afsenderen kan f.eks. medsende et dybt link til sin egen betalingsløsning, til en webservice, eller til anden form for interaktion, der kan være relevant for modtageren. Eksempel på angivelse af dybt link <rdf:description rdf:about=" <memo:label>betaling</memo:label> <memo:actiondeadlinedatetime> T12:00:00 </memo:actiondeadlinedatetime> <memo:interaction rdf:parsetype="collection"> <rdf:description rdf:about=" <memo:uri>[url til betalingsløsning]</memo:uri> </memo:interaction>

15 Da understøttelsen af Actions vil være betinget af modtagerens visningsklient skal informationerne her betragtes som en service eller supplerende information, og skal således også fremgå andetsteds af meddelelsen. Digital Post vil anvende URL skanning i forhold til actions angivet i meddelelser. Yderligere sikkerhedstiltag vil blive diskuteret i samarbejde med den kommende leverandør af Digital Post. 4.2 Send meddelelse på flere sprog og formater MeMo muliggør at meddelelser sendes helt eller delvist på flere sprog og formater, for at anvendere kan målrette deres digitale kommunikation til modtageren. En meddelelse er struktureret således, at den kan indeholde et eller flere dokumenter, der kan indeholde en eller flere filer. Fx kan en meddelelse indeholde en lønseddel eller en afgørelse med en række bilag. Meddelelse Dokument Dokument Fil Fil Fil Figur 2 Eksempel på overordnet datastruktur Nedenfor følger en række use-cases som illustrerer datamodellen Send meddelelse på et sprog og i et format I denne use-case udnyttes muligheden for flere sprog og formater ikke, og den er således meget lig den eksisterende Digital Post løsning.. Use case nr. 2 Aktører Navn: Send meddelelse på et sprog og i et format Myndighed, sagsbehandler, fagsystem og anvendersystem

16 Hændelse Startbetingelse En myndighed ønsker at afsende en afgørelse, som indeholder et følgebrev, et afgørelsesdokument og en klagevejledning Myndighedens fagsystem integrerer til Digital Post Normalforløb: En sagsbehandler træffer en afgørelse i en borgersag og udarbejder et følgebrev samt afgørelse og vedlægger en klagevejledning i pdf. Fagsystemet genererer en meddelelse, hvor følgebrev og afgørelse konverteres til pdf og sendes til afsendersystemet. Afsendersystemet opretter en instans af Me- Mo, som indeholder følgende indekserede dokumenter med tilhørende filer: Følgebrev PDF Meddelelse Afgørelse PDF Klagevejledning PDF Slutresultat Borgeren modtager meddelelsen og ser den i sin visningsklient på borger.dk Send meddelelse på et sprog og i flere formater Myndigheden arbejder med at målrette sin digitale kommunikation. En myndighed udsender i dag et kortfattet følgebrev, en orientering samt klagevejledning. Følgebrevet giver ofte anledning til mange spørgsmål, fordi virksomheder ikke læser den vedhæftede orientering. Myndigheden vil derfor gerne fjerne følgebrevet og vise orienteringen direkte for virksomheden. For at sikre at virksomheden hjælpes bedst muligt, har myndigheden udarbejdet en html-version af orienteringen, som fremhæver de væsentligste punkter, samt en traditionel pdf-version såfremt virksomheden ikke har mulighed for at se html. Use case nr. 3 Aktører Navn: Send meddelelse på flere sprog og i et format Myndighed, sagsbehandler, fagsystem og anvendersystem Hændelse En myndighed ønsker at afsende en afgørelse, som indeholder et orienteringsdokument i pdf og html samt en klagevejledning

17 Startbetingelse Myndighedens fagsystem integrerer til Digital Post via et afsendersystem Normalforløb: En sagsbehandler sender en orientering, udarbejder et orienteringsdokument og vedlægger en klagevejledning i pdf. Fagsystemet genererer en meddelelse, hvor orienteringen konverteres til html og pdf og sendes til afsendersystemet. Afsendersystemet opretter et MeMoformat, som indeholder følgende indekserede dokumenter med tilhørende filer: Orientering HTML Meddelelse PDF Klagevejledning PDF Slutresultat 1 Virksomheden modtager meddelelsen og åbner den i visningsklienten på Virk. Her vises HTML versionen, hvor klagevejledningen er vedhæftet Slutresultat 2 Virksomheden afhenter meddelelsen via et modtagersystem. Meddelelsen vises i mail-klienten, hvor visning i html er slået fra. Her vises PDF-version som indlejret, hvor klagevejledningen er vedhæftet Send meddelelse på flere sprog og i et format En myndighed arbejder med at målrette sin digitale kommunikation til borgere, som kan have forskellige primære sprog. En myndighed udsender i dag en indkaldelse til en række borgere, hvor myndigheden ikke kender borgernes primære sprog. Myndigheden vil gerne sende samme meddelelse på flere sprog for at øge antallet af rettidige fremmøder. Use case nr. 4 Aktører Navn: Send meddelelse på flere sprog og i et format Myndighed, sagsbehandler, fagsystem og anvendersystem Hændelse En myndighed ønsker at afsende en indkaldelse, som indeholder et brev på dansk og engelsk

18 Startbetingelse Myndighedens fagsystem integrerer til Digital Post via et afsendersystem Normalforløb: En sagsbehandler sender en orientering og udarbejder et brev på dansk og engelsk. Fagsystemet genererer en meddelelse, som indeholder begge filer og sendes til afsendersystemet. Afsendersystemet opretter et Memo-format, som indeholder et dokument med brevets afsender og modtager samt vedhæfter filen på dansk og engelsk. Meddelelse Brev Dansk, PDF Engelsk PDF Slutresultat 1 Borgeren åbner posten i en visningsklient f.eks. Borger.dk. Borger.dk kender borgerens sprogpræferencer, som i dette eksempel er engelsk, og viser dokumentet i den engelske version. Den danske version kan åbnes som vedhæftet fil Slutresultat 2 Borger.dk viser brevet til borgeren. Borger.dk kender ikke borgerens sprogpræferencer, som i dette eksempel er engelsk, og viser dokumentet i den danske version. Den engelske version kan åbnes som vedhæftet fil Send meddelelse på flere sprog og i flere formater. Myndigheden arbejder med at målrette sin digitale kommunikation til borgere, som kan have forskellige primære sprog. En myndighed udsender i dag en høringsmeddelelse til en række borgere. Høringsmeddelelsen består af et høringsbrev, et bilag modtaget fra en anden myndighed samt en klagevejledning. Myndigheden vil gerne tydeliggøre høringsbrevet ved at sende samme meddelelse i en læsevenlig html-version. Endvidere ønsker myndigheden at sende høringsbrevet og klagevejledningen på dansk og engelsk. Det er ikke muligt at oversætte det tekniske bilag, da det kommer fra en anden myndighed. Use case nr. 5 Navn: Send meddelelse på flere sprog og i flere formater

19 Aktører Myndighed, sagsbehandler, fagsystem og anvendersystem Hændelse Startbetingelse En myndighed ønsker at afsende et høringsbrev, som indeholder et brev på dansk og engelsk, et bilag på dansk samt et bilag på dansk og engelsk Myndighedens fagsystem integrerer til Digital Post via et afsendersystem Normalforløb: En sagsbehandler sender en orientering og udarbejder et høringsbrev på dansk og engelsk, og en klagevejledning vedlægges på dansk og engelsk. Fagsystemet genererer en meddelelse bestående af indekserede dokumenter med tilhørende filer, som indeholder begge filer i både pdf og html fra høringsbrevet og på begge sprog: Afsendersystemet opretter et MeMo-format, som indeholder følgende: Høringsbrev på dansk og engelsk i to formater (4 filer) Teknisk bilag i pdf(1 fil) Klagevejledning på dansk og engelsk i pdf (2 filer) Det kan illustreres således: Dansk PDF Engelsk PDF Høringsbrev Dansk HTML Engelsk HTML Meddelelse Teknisk bilag Dansk PDF Dansk PDF Klagevejledning Engelsk PDF Slutresultat 1 Visningsklienten Borger.dk viser brevet til borgeren. Borger.dk kender borgerens sprogpræferencer, som i dette eksempel er engelsk. Borger.dk kan vise html og viser derfor dokumentet i den engelske html-version. De øvrige pdf-

20 dokumenter kan ses som vedhæftede filer. Filen MeMo_XML_eksempel_MultiFiles_MultiLanguage.rdf er et XML eksempel på en MeMo meddelelse med flere filer i forskellige formater og sprog. Filen MeMo_XML_eksempel_MultiFiles_MultiLanguage_Reply.rdf er et XML eksempel på et retursvar på en MeMo meddelelse med flere filer i forskellige formater og sprog Send afgørelse i flere formater Digital Post meddelelser kan både være dokumenter vedrørende afgørelser fra myndigheder eller meddelelser omkring faktisk forvaltningsvirksomhed, fx invitation til forældremøde i børnehave eller indkaldelse til operation. Digital Post og visningsklienter viderebehandler således ikke afgørelser, og MeMo-formatet muliggør ikke angivelse af, hvilke formater eller sprog af afgørelsen, som har bevismæssig prioritet. Det vil således være den afsendende myndigheds ansvar at sikre, at modtageren får de korrekte data vist uanset hvilken sprog og format, afgørelsen vises på. Fx er det afsenderens ansvar, at den sprogversion af brevet, som vises for borgeren, har det korrekte indhold. Ønsker myndigheden ikke tvivl omkring hvilket format eller sprogversion, som er den gældende, bør man undlade at sende i flere versioner, så der ikke kan opstå tvivl. 4.3 Send meddelelse fra myndighed til myndighed MeMo kan også anvendes til at sende meddelelser mellem Myndigheder. I nedenstående eksempel anvender begge myndigheder et sagsbærende fagsystem. Det er klassen ReplyData som anvendes til at understøtte forløbet. Der er tale om en kommune, der sender en anmodning om et kystbeskyttelsesprojekt til Kystdirektoratet. Use case nr. 6 Aktører Hændelse Navn: Send Afgørelse på flere sprog. Myndighed, sagsbehandler, fagsystem og anvendersystem En myndighed Startbetingelse Myndighedens fagsystem integrerer til Digital Post via et afsendersystem Normalforløb:

21 En sagsbehandler hos kommunen udarbejder en ansøgning om kystbeskyttelse og vedlægger et skitseprojekt som pdf. Afsendersystemet hos kommunen opretter et MeMo-format, som indeholder følgende: Ansøgning i PDF Skitseprojekt i PDF CaseID angives i ReplyData Felt ReplyData#1 MessageID ReplyID d609791a-1eb a1a3bfb Tomt i første besked CaseID Kystdirektoratets afhentningssystem opretter ansøgningen i fagsystemet og kystdirektoratets medarbejder påbegynder sagsoplysning. I den forbindelse udarbejdes en besvarelse med uddybende spørgsmål. Felt ReplyData#1 ReplyData#2 MessageID d609791a-1eb a1a3bfb a248f674-aff8-4d59- a e10957b80 ReplyID d609791a-1eb a1a3bfb CaseID Medarbejderen I kommunen besvarer spørgsmålet og medsender ovenstående ReplyData samt følgende: Felt ReplyData#1 ReplyData#2 ReplyData#3 MessageID d609791a-1eb a1a3bfb a248f674-aff8-4d59-a e10957b80 0a2c5638- fca bb1a-

22 d9b90b75ebab ReplyID d609791a-1eb a1a3bfb a248f674- aff8-4d59- a e10957b80 CaseID Slutresultat 1 Eksemplet viser anvendelse af ReplyData med to sagsbærende fagsystemer. Historikken i ReplyData medfører at begge myndigheder har mulighed for at præjournalisere meddelelsen som et indgående dokument i fagsystemet. Filen MeMo_XML_eksempel_AuthorityToAuthority.rdf er et XML eksempel på en MeMo meddelelse sendt mellem myndigheder. Filen MeMo_XML_eksempel_AuthorityToAuthority_MultibleReply.rdf er et XML eksempel på hvordan flere Reply klasser benyttes ved en længere korrespondance.

23 Appendix A. Intro til RDF MeMo meddelelsen er struktureret i overensstemmelse med RDF (Resource Description Framework) standardmodellen. RDF er et rammeværk til at beskrive ressourcer på nettet defineret som en URI. En ressource kan være en fysisk genstand, dokumenter, abstrakte koncepter, tal, tekster etc. RDF bygger på en graf-baseret data model, hvor en ressource beskrives ved hjælp af subject, predicate og object (triple), eksempelvis Udtrykkes data som en URI, giver det mulighed for at skrive sætninger i maskinsprog, såkaldt linked data, eksempelvis: <rdf:rdf xmlns:rdf=" xmlns:feature=" <rdf:description rdf:about=" <feature:color rdf:resource=" </rdf:rdf> Subject Predicate Object ols.com/clothes#t-shirt s.com/clothingfeatures#color colors#white Se for mere information om RDF RDF strukturen kan valideres på W3.org online validatoren:

24 digst.dk