PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT PILOT INSTROOM TWEEDE KAMER Eindrapport Document Distributie Naam Gert Jan Lodder Functie Hoofd Dienst Informatievoorziening Tweede Kamer Jacqueline Slats Tom de Smet Hoofd Sector Informatie, Infrastructuur & Innovatie Nationaal Archief Hoofd Collecties Beeld en Geluid Angelique Schalk Projectleider Tweede Kamer Mette van Essen Projectleider Nationaal Archief Daniel Mogendorff Projectleider Beeld en Geluid Versie 1.0 Pagina 1 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Versiebeheer Versie Auteur V0-1 D. Mogendorff V0.2 v.0-9 v. 0.91 D. Mogendorff A. Schalk M. van Essen D. Mogendorff A. Schalk M. van Essen D. Mogendorff Wijzigingen Datum 17-nov-2013 Eerste review projectleiders 19-nov-2013 Conceptversie verzonden aan stuurgroep ter bespreking in overleg op 5 december 27-nov-2013 Twee “Gaps op hoofdlijnen” toegevoegd in 2.5 – Nationaal Archief 5-dec-2013 Correcties doorgevoerd, met positief advies aangeboden aan stuurgroep 29-jan-2014 Geaccordeerd door stuurgroep 5-mar-2014 A.Schalk v 0.99 M. van Essen D. Mogendorff A. Schalk V1.0 M. van Essen D. Mogendorff Versie 1.0 Pagina 2 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT INHOUDSOPGAVE 1 Inleiding 5 2 Samenvatting & Conclusie 6 2.1 Inhoud Pilot 6 2.2 Proces van instroom 6 2.3 Metadata analyse 7 2.4 Beschikbaarsteling en uitlevering 8 2.5 Gaps op hoofdlijnen 8 2.6 Organisatie omvang 8 2.7 Conclusie 9 3 Proces van instroom 10 3.1 Creëren video bestanden door de Tweede Kamer 11 3.1.1 13 Gaps - Creëren video bestanden door de Tweede Kamer 3.2 Creëren metadata bestanden door de Tweede Kamer 13 3.2.1 17 Gaps - Creëren metadata-bestanden Tweede Kamer 3.3 Transfer naar Beeld en Geluid 17 3.3.1 18 Gaps - Transfer naar Beeld en Geluid 3.4 Instroom van Beeld en Metadata bij Beeld en GELUID 18 3.4.1 Beschrijving flow instroom 19 3.4.2 Gaps - Instroom bij Beeld en Geluid 21 3.5 Instroom van Metadata in het e-Depot van het Nationaal Archief 21 4 23 Eisen aan Essence (Beeldmateriaal) 4.1.1 5 Gaps – Eisen aan essence (Beeldmateriaal) Metadata Analyse 23 24 5.1 Inleiding 24 5.2 Algemeen 24 5.3 Metadata en de verschillende entiteiten die ze beschrijven 25 5.4 Generiek metadatamodel voor het beheren van (digitale) informatie 26 5.4.1 Metadata met betrekking tot identiteit 27 5.4.2 Metadata met betrekking tot beschrijving 30 5.4.3 Metadata met betrekking tot gebruik 33 5.4.4 Metadata met betrekking tot het activiteitenplan 36 5.4.5 Metadata met betrekking tot de geschiedenis van activiteiten. 37 Versie 1.0 Pagina 3 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 5.4.6 6 Metadata met betrekking tot relatie Beschikbaarstelling en uitlevering 6.1.1 39 41 Gaps – Beschikbaarstelling en uitlevering 42 Bijlage A - Specificaties van Essence (Beeldmateriaal) 43 Bijlage B - Specificaties van naamgeving aangeleverde bestanden 45 Bijlage C - Mogelijkheden en standaarden duurzame opslag bij Beeld en Geluid 46 Bijlage D - Jargonmatrix 49 Bijlage E - VLOS metadata template gesegmenteerde debatdag 52 Bijlage F - VLOS Metadata template ongesegmenteerde debatdag 60 Versie 1.0 Pagina 4 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 1 INLEIDING Dit eindrapport is het eindproduct van de pilot “Instroom audiovisueel materiaal Tweede Kamer”, een opdracht van de Tweede Kamer aan Beeld en Geluid en het Nationaal Archief om de mogelijkheden en eventuele knelpunten te onderzoeken bij het instromen in een duurzame omgeving van audiovisuele files van plenaire Tweede Kamerdebatten, samen met de bijbehorende metadata. Hierbij is gekeken in welke mate de ingestroomde gegevens voldoen aan de normen van de archiefwettelijke regelgeving. In deze pilot treedt het Nederlands Instituut voor Beeld en Geluid (BenG) op als audiovisuele partner van het Nationaal Archief (NA). Het doel is om de beelden zodanig op te slaan dat uiteindelijk een formele overbrenging van materiaal naar het Nationaal Archief in de toekomst gerealiseerd kan worden. Dit document beschrijft de uitgevoerde stappen tijdens de pilot en is – zoals aangekondigd bij project initiatie – een GAP-analyse waarin wordt aangegeven welke stappen nog genomen moeten worden om tot een operationele stroom en tot volledige overdracht van materiaal te komen. Buiten de scope van dit project valt de voorgenomen samenwerkingsovereenkomst tussen Nationaal Archief en Beeld en Geluid en de juridische aspecten van overbrenging. Deze pilot heeft gebruikgemaakt van de bestaande infrastructuur van de drie partijen. De GAP-analyse beschrijft en analyseert het proces van instroom en splitst deze op in drie onderdelen: Proces van instroom (hoofdstuk 3) Eisen aan beeldmateriaal (hoofdstuk 4) Metadata-analyse (hoofdstuk 5) Daarnaast wordt in hoofdstuk 6 kort ingegaan op de mogelijkheden rond beschikbaarstelling en uitlevering. Versie 1.0 Pagina 5 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 2 SAMENVATTING & CONCLUSIE 2.1 INHOUD PILOT De volgende vergaderdagen zijn onderdeel van de pilot, een totaal van ongeveer 50 uur beeldmateriaal. Hiervan zijn metadata en essence (beeldmateriaal) ingestroomd in de archieven van Beeld en Geluid. Daarnaast is de metadata van deze vergaderingen ingestroomd in het eDepot van het Nationaal Archief. Debatjaar 2012-2013 Gesegmenteerd gearchiveerd (met afzonderlijke catalogusbeschrijving per debat): e 99 vergadering - plenaire zitting - 25 juni 2013 e 100 vergadering – plenaire zitting - 26 juni 2013 Ongesegmenteerd gearchiveerd (met catalogusbeschrijving per gehele vergaderdag): e 102 vergadering – plenaire zitting - 2 juli 2013 e 103 vergadering – plenaire zitting - 3 juli 2013 e 104 vergadering – plenaire zitting - 4 juli 2013 Ter indicatie: per jaar wordt in totaal ongeveer 1200 uur plenair vergaderd in de Tweede Kamer en 7000 uur in commissieverband. Tijdens de pilot was de omvang van één vergader-uur ongeveer 30 gigabyte. 2.2 PROCES VAN INSTROOM Tijdens de pilot zijn in totaal vijf vergaderdagen (plenaire zittingen Tweede Kamer) duurzaam gearchiveerd. Het gaat hier om het beeldmateriaal dat vanuit de regiekamer Tweede Kamer wordt geregistreerd en uitgezonden, dit is hetzelfde beeldmateriaal dat aan de omroepen wordt aangeboden. Het beeldmateriaal van deze vergaderdagen –in totaal ongeveer 50uur– is via de K2server van de Tweede Kamer aangeboden aan Beeld en Geluid, samen met de bijbehorende metadata uit VLOS 2.0 (“Verslaglegging Ondersteunend Systeem”), wat onder andere gevoed wordt door de Dienst Verslag en Redactie (DVR). Deze metadata stromen ook naar het eDepot van het Nationaal Archief. Na archivering zijn beeld en metadata direct opvraagbaar via de Beeld en Geluidcatalogus, vanwaar een directe link beschikbaar is naar de Handelingen op overheid.nl. Om ook de samenhang tussen archivering en ontsluiting van materiaal in kaart te brengen, is er in de pilot gekozen voor twee varianten: het archiveren en metadateren van een vergaderdag als geheel en het archiveren en metadateren van een vergaderdag in segmenten. In het eerste geval wordt een vergaderdag slechts op hoog niveau ontsloten (hele vergadering). In het geval van segmentatie wordt elk debat afzonderlijk beschreven en ontsloten tot op sprekerniveau. Om bovenstaande mogelijk te maken zijn de VLOS-metadata “gemapt” naar de standaarden van de Beeld en Geluidcatalogus en wordt het beeldmateriaal voor oplevering in logische segmenten geknipt. Versie 1.0 Pagina 6 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Afbeelding 1: Basis informatiestroom 2.3 METADATA ANALYSE Doel van de pilot is een proof of concept van duurzame audiovisuele archivering conform standaarden van het Nationaal Archief. Om die reden moeten de te archiveren gegevens voldoen aan de in Nederland als norm gestelde eisen voor een volledige recordsmanagement-metadataset zoals beschreven in de NEN-ISO 23081-standaard voor Metadata. Deze is onder te verdelen in de volgende categorieën: 1. Beschrijvende metadata. Op dit vlak is er in de pilot een grote slag geslagen en stromen de gegevens grotendeels volgens de genoemde ISO-standaard van de Tweede Kamer naar het Nationaal Archief en naar Beeld en Geluid. 2. Preserveringsmetadata. Deze hebben betrekking op het gebruik, activiteitenplan rond beheersactiviteiten en de geschiedenis daarvan. Deze gegevens laten zich het best vangen in afspraken tussen de drie partijen bij het definitief opzetten van een operationele stroom. Dit eindrapport biedt een stevig handvat voor het maken van deze afspraken middels de uitgebreide metadata-analyse door het Nationaal Archief (hoofdstuk 5). Hier wordt een vergelijking gemaakt tussen de metadatarichtlijnen die reeds worden toegepast binnen de pilot en metadata die nog geïmplementeerd moeten worden. Ook in hoofdstuk 5 staan aanbevelingen hoe dit het best gedaan kan worden. Versie 1.0 Pagina 7 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 2.4 BESCHIKBAARSTELING EN UITLEVERING Middels de bestaande Beeld en Geluid-catalogus iMMix is materiaal direct na instroom beschikbaar voor uitlevering. Een vergadering kan als geheel worden opgevraagd, er kan echter ook een deel worden geselecteerd, bijvoorbeeld een enkele vraag of een enkele spreker, middels de "partial restore"-functionaliteit die de catalogus biedt. Dit kan zowel in het bronformaat als in formaten van andere resolutie. Er komen ook mogelijkheden beschikbaar om het beeldmateriaal via een streamingservice weer te geven. 2.5 GAPS OP HOOFDLIJNEN Om dit proces van duurzame archivering in de toekomst volledig te automatiseren en in te richten op een groter volume van dagelijkse instroom zijn in de kern de hieronder genoemde aanpassingen nodig. In de komende hoofdstukken wordt hier dieper op ingegaan. Waar doorlooptijd wordt genoemd wordt uiteraard uitgegaan van beschikbaarheid van de benodigde personen voor het uitvoeren van deze activiteiten. Beeld en Geluid: x Indien gewenst, in samenwerking met de Tweede Kamer, het verfijnen van de metadatastructuur met het oog op ontsluiting en beschikbaarstelling (doorlooptijd 3 maanden) x Kleine technische aanpassingen aan het instroomproces (doorlooptijd 3 maanden) Tweede Kamer: x Automatiseren van de metadata-aanleveringen via bestaande CC-Connectkoppelingen (doorlooptijd 3 maanden) x Automatiseren van aanleveren van audiovisuele bestanden (doorlooptijd afhankelijk van uitvoering vervolg Tweede Kamer-AV-programma) Nationaal Archief x x x Volledige overdracht van audiovisueel materiaal kan niet los worden gezien van de afspraken rond overdracht van de Handelingen aan het Nationaal Archief. Ook op dit punt dienen afspraken meer in detail te worden vastgelegd Het automatiseren van de instroom van metadata in eDepot Ten behoeve van beschikbaarstelling is het gewenst dat er een directe link mogelijk is naar het (lage resolutie) beeldmateriaal, in elk geval vanuit het Nationaal Archief Algemeen x Afstemming en afspraken over preserveringsmetadata tussen Nationaal Archief, Beeld en Geluid en de Tweede Kamer, conform OAIS richtlijnen en de NEN-ISO 23081-standaard. 2.6 ORGANISATIE OMVANG Binnen de pilot zijn inhoudelijke specialisten betrokken uit de volgende organisatie onderdelen: Tweede Kamer x AV Programma (valt onder Facilitaire Dienst) x Bureau informatisering en Projecten (valt onder directie Informatiseringbeleid) x VLOS team (Dienst Verslag en Redactie) x Dienst Informatievoorziening / Centraal Archief Versie 1.0 Pagina 8 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT De volgende systemen zijn geraakt: VLOS, CC-Connect, AV Systemen. Nationaal Archief x Product Specialist e-Depot, Adviseur Recordsmanagement, de x afdeling Advies & Acquisitie en de x Preservation researcher. De volgende systemen zijn betrokken: SDB4 en eDepot Beeld en Geluid x Metadatabeheer (Unit Collecties en Beschrijvingen) x Conservering & Digitalisering (Unit Infrastructuur, Beheer en ICT) x Applicatiebeheer (Unit Infrastructuur, Beheer en ICT) De volgende systemen zijn betrokken: iMMix, DFI, GMI Naast de eerder genoemde projectleiders leverden de volgende personen een inhoudelijke bijdrage aan dit eindrapport: Naam Functie Roger Krom Tweede Kamer – Specialist Informatiesystemen Martijn de Boer Tweede Kamer – Engineering Architect AV-Programma Daniel Steinmeier Beeld en Geluid – Specialist Instroom & Applicatiebeheer Vincent Huis in ‘t Veld Beeld en Geluid – Manager afdeling Metadatabeheer 2.7 CONCLUSIE De systemen van de drie partijen sluiten goed op elkaar aan. Tijdens de pilot zijn enkele handmatige ingrepen uitgevoerd die in een vervolgtraject geautomatiseerd moeten worden, vooral aan de kant van de Tweede Kamer. Daarnaast dienen er op het gebied van preserveringsmetadatering verdere afspraken gemaakt te worden tussen het Nationaal Archief, Beeld en Geluid en de Tweede Kamer, zoals in de metadata-analyse wordt aangegeven. Versie 1.0 Pagina 9 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 3 PROCES VAN INSTROOM In dit hoofdstuk wordt in detail het proces van instroom van materiaal beschreven, vanaf het moment van filmen van een vergadering in de plenaire zaal van de Tweede Kamer, tot en met het moment dat het in de Beeld en Geluid-catalogus beschikbaar is voor uitlevering en daarnaast de metadata beschikbaar zijn in het eDepot van het Nationaal Archief. De beschrijving van dit proces is in dit hoofdstuk onderverdeeld in de volgende stappen x x x x x Creëren videobestanden door de Tweede Kamer (3.1) Creëren metadatabestanden door de Tweede Kamer (3.2) Transfer naar Beeld en Geluid (3.3) Instroom van Beeld en Metadata bij Beeld en Geluid (3.4) Instroom van Metadata in het eDepot van het Nationaal Archief (3.5) Afbeelding 2: Proces van instroom Versie 1.0 Pagina 10 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 3.1 CREËREN VIDEO BESTANDEN DOOR DE TWEEDE KAMER Keuze van een videoplatform voor de Pilot: Om kosten en doorlooptijd te reduceren is er gekozen om een van de bestaande video ingestsystemen in te zetten voor de pilot. Ten tijde van de pilot bestaan er bij de Tweede Kamer twee videosystemen die de plenaire vergaderingen in opgenomen vorm beschikbaar kunnen stellen. Bestaande Ingestsystemen: - Loggers van Arbor ten behoeve van de debatgemist-website (www.debatgemist.nl). K2 / Status systeem welke is ingericht als onderdeel van aanbesteding A06 Plenaire Vergelijking Ingest systemen K2 + Stratus Arbor Logger + Fetcher Resolutie 1920x1080 (native) 720x406 Video Codec XDCAM HD422 Long GoP H.264 Bitrate 50 [Mbit/sec] 100 [kbit/sec] Bestandstype (wrapper) MXF - SMPTE-377M [*.ts] MPEG Transport Stream Automatische export Mogelijk via integratie MAM Reeds uitgevoerd Alleen de specificaties van de K2-Server voldoet aan de archiefstandaarden van Beeld en Geluid. Oorspronkelijke functie van het systeem: Het systeem K2 + Stratus + FTP client wordt ingezet om fragmenten van plenaire vergaderingen op te vragen en te ontsluiten richting geaccrediteerde partijen van “het samenwerkingsverband”. Deze partijen zijn NOS, RTL, ROOS (Regionale omroepen) en de Tweede Kamer. Versie 1.0 Pagina 11 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Afbeelding 3: Workflow creatie videobestanden Tweede Kamer Ingest. Alle vergaderingen in de plenaire zaal worden opgenomen. Hiertoe logt een gebruiker in op de K2 en wordt het opnamekanaal handmatig gestart. Ook de naamgeving van de opgenomen essence gebeurt handmatig. Vergadering wordt in zijn geheel opgenomen. - Naamgeving: <vergaderzaal> <datum dd-mm-yyyy> - Vergadering wordt als één volledige clip opgenomen. Segmentatie: Elke vergadering wordt gesegmenteerd per activiteit. Vanuit VLOS wordt een XML aangeleverd met ten minste de volgende informatie: - - Per vergadering: o Vergaderzaal (bijvoorbeeld: Tweede Kamer Plenaire zaal) o Datum van aanvang van de vergadering o Vergaderjaar o Nummer vergaderdag (sequentieel per vergaderjaar) o Aanvangstijd o Sluiting (tijd van sluiting) Per activiteit: Versie 1.0 o Activiteitsoort o Bestandsnaam van het te exporteren fragment behorende bij de activiteit (bijv: TKP1213100061-TKP) o Aanvangstijd van het fragment o Eindtijd van het fragment Pagina 12 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Aan de hand van deze data wordt de juiste clip opgezocht en worden de activiteiten als subclip geëxporteerd en aangeleverd aan de FTP Client, vanwaar transport naar Beeld en Geluid plaatsvindt. 3.1.1 Gaps - Creëren video bestanden door de Tweede Kamer Met de huidige inrichting en technieken is het niet mogelijk om bestanden automatisch te segmenteren, hiervoor is een Media Asset Management-systeem noodzakelijk. Het aan te schaffen Media Asset Management-systeem zal worden aanbesteed. Hieronder enkele algemene punten in dit kader: 1. Lokale (tijdelijke) opslag van beeldmateriaal (vóór verzending aan Beeld en Geluid) x Bepalen van de capaciteit uitgedrukt in uren materiaal x Redundantie opslag 2. Bepalen beleid voor het verwijderen van de essence uit de lokale, tijdelijke, opslag x Verificatie archivering x Duur lokaal bewaren (denk ook aan ontsluiting t.b.v. derden) 3. Automatische Ingest: x x Definiëren welke kanalen er opgenomen dienen te worden. Wijze van opname: continue, geagendeerd, of afhankelijk van status vergadering 4. Koppeling en integratie met het VLOS system, aanlevering van segmentatie data. x Moment van aanlevering 5. Automatisering / segmentatie van bestaande opgenomen content aan de hand van de XML. 6. Bijzondere aandacht voor de situatie waarbij de vergadering doorgaat tot na middernacht. Daar waar de vergadering tot na middernacht doorgaat ontstaat de situatie dat de tijdcode van het IN-punt groter is dat de tijdcode van het UIT-punt. 3.2 CREËREN METADATA BESTANDEN DOOR DE TWEEDE KAMER Tijdens de pilot is het geregisseerde beeld gebruikt uit de regiekamer van de plenaire vergadering. Voor de bijbehorende metadata is de XML van het ongecorrigeerde verslag van VLOS gebruikt. Er is gekozen om het AV-materiaal (MXF) niet als een groot bestand aan te leveren aan de iMMix catalogus van BenG. Deze keuze is gemaakt vanwege: gebruiksvriendelijkheid, grootte van bestand en beperking aan iMMix-catalogus (beeld van een standaard-instroom is bij voorkeur niet langer dan 4 uur). Het AV-materiaal van een geheel debat dag moet “geknipt” (gesegmenteerd) worden. Van elk MXF-bestand moet er op basis van de bestandsbenaming een relatie zijn met een XMLmetadatabestand. Een XML-metadatabestand kan een relatie hebben met meerdere MXF-bestanden in geval een debat vanwege een schorsing (langdurig) is onderbroken. Segmentatie Om segmentatie op een logische plek te laten plaatsvinden, is gekozen om dit op VLOS-activiteiten te doen (in overeenstemming met de agenda van de vergadering). De eis die het NA stelt is dat een vergadering in zijn geheel te reconstrueren moet zijn, met behoud van de chronologie en context. Om het AV-materiaal te kunnen segmenteren wordt alleen niveau 1 (activiteiten), gebruikt. Aan de hand van de VLOS-XML kunnen deze activiteiten met een begin- en een eindtijd gebruikt worden voor Versie 1.0 Pagina 13 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT de daadwerkelijke segmentatie. Een verbijzondering hiervan is een (langdurige) schorsing binnen of gedurende een bepaalde activiteit. Vooralsnog is het niet gelukt hiervoor een risicoloze aanduiding te vinden waarmee een debat kan worden opgedeeld of tussenliggende schorsingsdelen kunnen worden uitgesloten in (?). Dit heeft te maken met het op willekeurig welk niveau, als draadelement in de XML, kunnen toevoegen van schorsingen. Een aanpassing van de markeringsmethodiek in VLOS lijkt hiervoor nodig om een passende en zekere oplossing te bieden. Relatie in XML met andere bronnen AV-metadata kunnen we niet los zien van de metadata uit andere bronnen. Een relatie tussen deze informatie en de specifieke AV-ontsluiting moet worden gewaarborgd. Voor nu is er een Debat-ID toegevoegd om daarmee de link te leggen tussen de verschillende informatiebronnen van de Tweede Kamer. Ook is de relatie tussen het ‘officieel’ gepubliceerde geschreven verslag op overheid.nl onderzocht. Omdat daar ook een vertaalslag voor wordt gemaakt van de VLOS-XML lijkt het mogelijk deze verbintenis op te nemen.. Uitwerking XML Ten behoeve van het beschikbaar stellen en het terugvindbaar maken van de vergadering of het vergaderonderdeel op basis van o.a. datum, onderwerp en sprekers, wordt de XML verder uitgewerkt. Deze uitwerking dient tevens als navigatie binnen een bepaald AV-bestand en bevat aanvullende kenmerken en verwijzingen naar externe informatiebronnen. Dat gebeurt tot en met maximaal de hieronder genoemde niveaus en is afhankelijk van de activiteit-soort. 1: activiteit (BenG term: expressie) 2: activiteithoofd (BenG term: selectie) 3: activiteitdeel (BenG term: selectie, feitelijk een sub-selectie) Deze drie hebben een hiërarchische verhouding. Een plenair debat en een interpellatiedebat (expressie) bestaat uit een of meerdere termijnen (selecties) met daarbinnen spreekbeurten (subselecties). Tevens wordt er van elke activiteit een lijst met sprekers geleverd (ongeacht hun rol). Het komt voor dat de expressie geen selecties en/of sub-selecties heeft. Dit doet zich voor bij de nummers 1 t/m 11 (zie afbeelding 4). Zo bevat een activiteit-soort van het type “mededeling” alleen een begin en eindtijd, aangevuld met een lijst van sprekers. Vragenuur en debatten Bij een vragenuur is de expressie Vragenuur. Deze bestaat uit selecties op basis van activiteithoofd=’vraag’, de afzonderlijke vragen van een Kamerlid m.b.t. een bepaald onderwerp, maar binnen die vragen bestaan verschillende spreekbeurten (dit zijn sub-selecties). Daarnaast zijn ook hier de sprekers (ook de mensen die alleen interrupties hebben gedaan). Deze verdeling geldt ook voor plenaire debatten, inclusief de interpellatiedebatten, maar hier spreken we over termijnen in plaats van vragen als selectie. Expressie (vragenuur): - selectie (eerste vraag) - sub-selecties (spreekbeurten) - selectie (tweede vraag) - sub-selecties (spreekbeurten) - selectie (derde vraag) - sub-selecties (spreekbeurten) Versie 1.0 Pagina 14 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT - selectie (vierde vraag) - sub-selecties (spreekbeurten) enz. Stemmingen Voor stemmingen geldt een andere gelaagdheid van ontsluiting. Een activiteit van het soort Stemmingen heeft selecties op basis van activiteithoofd soort=’stemming’. Spreekbeurten hierbinnen, te herkennen als activiteitdeel soort=’spreekbeurt’ worden genegeerd. Wel wordt er voor de gehele activiteit een lijst van sprekers bijgeleverd in de XML. Voorbeeld: de MXF van de activiteit stemmingen wordt aan de hand van een begin en eindtijd geknipt. De stemmingen starten om 13.00 uur en eindigen om 13.30 uur. Hiervan hebben we dan 1 MXF bestand en 1 XML bestand. In dit half uur zijn over 10 onderwerpen stemmingen geweest (activiteithoofden). De XML is dan verder uitgewerkt zodat de afzonderlijke stemmingsonderwerpen beter toegankelijk zijn in die 30 minuten. Handmatige mapping De XML van VLOS kan echter niet zomaar in de catalogus van BenG ingevoerd worden. Hiervoor moet eenmalig, handmatig een bewerking op de VLOS-XML plaatsvinden, zodat de VLOS-XML gemapt kan worden die van de iMMix-catalogus, en er aan de GMI.xsd gevalideerde XML ontstaat. Er moet beschreven worden tot en met niveau 3 hoe de VLOS-XML past in de iMMix-XML. Nu gaat dat handmatig, de bedoeling is dat al deze activiteiten door CC-Connect uitgevoerd kunnen worden. Om die reden worden de handmatige activiteiten nu al volgens de richtlijnen van CC-Connect uitgevoerd en zijn daarmee een logische voorbereiding op deze mogelijke, toekomstige automatiseringsslag. Met dit laatste als uitgangspunt is de VLOS-XML omgezet naar passende bestanden. Omwille van de voortgang van het project is er voor gekozen de gelaagdheid te beperken e tot maximaal het 2 niveau (selectie), indien van toepassing. Dat betekent dat de data van het geheel aan sub-selecties, zich in de pilot bevindt binnen één selectie. Er moet t.b.v. de iMMix-catalogus een aantal default-waardes meegegeven worden, zoals: een iMMixID, een waarde dat de XML van de TK afkomstig is, de tijdsduur, aanvangstijden en eindtijden. De tijdsmarkeringen moeten naar milliseconden omgerekend worden. In elke XML moeten de volgende onderdelen terugkomen: het betreft een plenaire vergadering van de TK, het vergaderjaar, vergadernummer en activiteitvolgnummer (dit laatste ten behoeve van de reconstructie, waarmee de chronologische volgorde van de daadwerkelijke vergaderdag in stand blijft). Versie 1.0 Pagina 15 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Afbeelding 4 XMLsegmentatie niveaus In bovenstaand schema een weergave van de niveaus, waarvan afhankelijk van de activiteitsoort, de onderdelen in grijs niet worden gespecificeerd in de XML. In deze proef zijn de selecties beperkt tot 1 verzamelselectie voor de gehele activiteit. Templates ten behoeve van automatisering Tijdens de handmatige verwerking van de VLOS-XML zijn er ‘templates’ opgesteld met de omschrijving voor het functionele, en deels technische, ontwerp van de CC-Connect-applicatie. In bijlage E een kopie van de betreffende templates voor een gesegmenteerde vergaderdag, bestaande uit een algemeen deel (expressie) en een specifiek deel voor de uitwerking van een selectie. Ongesegmenteerd Voor de pilot is tevens gekozen voor het aanleveren van ongesegmenteerde debatsdagen, waarbij de debatdag niet is opgedeeld in segmenten per activiteitsoort. In dit geval worden naast de gebruikelijk default-waardes, onderstaande uitgangspunten gehanteerd en alleen de volgende gegevens opgenomen: x 1 xml en 1 mxf, met als begintijd de begintijd van de eerste activiteitsoort en als eindtijd de eindtijd van de laatste activiteitsoort; x geen afzonderlijke segmenten (items) voor elke activiteitsoort; dus alleen een Expressie en geen Selecties; x deze Expressie koppelen aan ID 4897914 (het idee van de 'Reeks' met als werktitel 'hele debatdag'); x in Annotatie op het niveau Expressie (conform aan opgeknipte debatdagen) de gegevens: o Kamer: Tweede Kamer o Vergadersoort: Plenair o Vergaderjaar: 2012-2013 o Vergadernummer: bijvoorbeeld 099 Versie 1.0 Pagina 16 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT x x x x in het attribuut Context een ID van het gehele debat, bijv. TKP1213100000 (dus met drie maal 0 i.p.v. het vervolgnummer van een activiteit van elke afzonderlijke activiteitsoort); Publicatie idem aan de Publicatie van een Expressie van een opgeknipt debat; Positie idem aan de Positie van een Expressie van een opgeknipt debat, met uitzondering uiteraard voor de begin- en eindtijd, die idem zijn aan de begin- en eindtijd van de gehele MXF. Een aan het gmi.xsd te valideren XML-bestand In bijlage F volgt de template voor een ongesegmenteerde debatsdag (Template-volledige vergadering.xml). Advies Beeld en Geluid Met het oog op ontsluiting en beschikbaarstelling adviseert Beeld en Geluid in een vervolgtraject de volgende aanpassingen op het gebied van aangeleverde metadata: 1. Aanmaken van de volgende Subselecties op basis van ‘Activiteithoofdsoort’: a. Vragenuur, Selectie per Vraag, Subselectie per Spreekbeurt b. Plenair debat: Selectie per Termijn en Subselectie per Spreekbeurt c. Interpellatiedebat: idem 2. Vermelding partijen in het veld Namen 3. Uitbreiding inhoudelijke metadata (bijv. vermelding departementen toevoegen, waarden uit de activiteiten-index zoals nu toegepast aan de VLOS-xml, gecorrigeerd verslag) 4. Optioneel kunnen de spreekteksten in de Beeld en Geluid-catalogus worden opgenomen. Bij het in de pilot ingestroomde materiaal is per subselectie een link opgenomen naar de bijbehorende Handelingen op overheid.nl. Daar zijn deze spreekteksten ook terug te vinden. 3.2.1 Gaps - Creëren metadata-bestanden Tweede Kamer 1. Uiteindelijk zal het gecorrigeerde verslag gebruikt worden. Dit kan mogelijk gevolgen hebben voor het creëren van de metadata. 2. Het omrekenen van de seconden naar milliseconden ten behoeve van de iMMix-catalogus is in de pilot handmatig aangepast. Vaststellen op welke plek deze translatie gemaakt moet worden. 3.3 TRANSFER NAAR BEELD EN GELUID Nadat zowel de te archiveren videobestanden (zie 3.1) als de bijbehorende metadata (zie 3.2) gecreëerd zijn, worden de bestanden overgedragen aan Beeld en Geluid. Tijdens de pilot zijn de MXF-bestanden aangeleverd op een harde schijf, bij één vergadering is de overdracht met een FTP-verbinding gerealiseerd. Echter, de bestaande FTP-faciliteiten van de Tweede Kamer bieden niet voldoende bandbreedte om het beeld te transporteren. De FTP Client heeft zogenaamde watchfolders aangemaakt. Wanneer er essence in een geconfigureerde folder verschijnt, zal deze worden getransferd via FTP naar de externe FTP-server van Beeld en Geluid. Momenteel heeft deze FTP-koppeling echter onvoldoende bandbreedte voor overdracht van de grote hoeveelheden data. Versie 1.0 Pagina 17 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 3.3.1 Gaps - Transfer naar Beeld en Geluid Vanuit de LDR van de Tweede Kamer zijn er een aantal mogelijkheden voor de aanlevering van MXF aan Beeld en Geluid, de mogelijke keuzes zijn: 1. Gebruik maken van de huidige FTP; deze optie valt af, omdat hij niet voorziet in voldoende bandbreedte. Het niet-gesegmenteerde bestand van een vergadering is 330 G.Byte groot, dit duurt met een gemiddelde verbindingssnelheid van 0.9 M.Byte/s meer dan 100 uur. 2. Een dedicated FTP-lijn, met voldoende bandbreedte. 3. Aanlevering via de Mediagateway van Ericsson. Of gebruik maken van een FTP aangeboden via Ericsson. 4. Aanleveren via een nieuw kanaal (aan te besteden). 3.4 INSTROOM VAN BEELD EN METADATA BIJ BEELD EN GELUID In onderstaande afbeelding is het gehele proces van instroom van een nieuwe collectie te zien van begin tot eind. Dit is hoe de Tweede Kamer-pilot tot nu toe is verlopen. De stappen worden toegelicht in hoofdstuk 3.4.1 “Beschrijving flow instroom”. Achtergrondinformatie over de mogelijkheden en standaarden van Beeld en Geluid rond duurzame opslag zijn te vinden in Bijlage C. In de eerste fase van de pilot zijn er afspraken gemaakt over bestandsformaten , aanlevering, rechten, voorwaarden en beschikbaarstelling. Vervolgens is het formaat van de metadata en de mapping naar database-velden binnen de catalogus van iMMix afgestemd met de afdelingen Catalogusbeheer en Applicatiebeheer. Hierna volgen een aantal proefimports van metadata en essence waarbij belangrijke bevindingen worden teruggestuurd naar de aanleverende partij zodat deze verbeterd kunnen worden. Wanneer het format van de metadata en de essence helemaal voldoet aan de eisen kunnen de metadata via de GMI (Generieke metadata importer) in de catalogus geïmporteerd worden. De essence wordt via de DFI (Digitale File Importer) opgeslagen in het Storage Management Systeem DivArchive waarbij het bestand op twee verschillende locaties wordt opgeslagen op tape. De essence wordt in deze fase ook gekoppeld aan de metadata in de catalogus zodat deze te bekijken en te bestellen is. Versie 1.0 Pagina 18 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT DFI / GMI Functioneel overzicht [1] Verzoek aanlevering [2] OK [4] Metadata Aanleverende partij Beeld en geluid [5] Metadata [4] Metadata NOK [5] Metadata [3] MXF plaatsen Catalogusbeheer Applicatiebeheer DFI [12] \\as-immix-#\ ImportFolderGMI FTP Storage [12] MXF + Trigger XML [6] Conversie 7, 8 iMMix client DIVA / mam-iMMix [13] XML/AXF (Trigger = dark metadata) [11] Trigger XML Beheerha ndeling maken [9] iMMix HighRes Importservice iMMix … service Status verhogen (2X) [14] [10] Trigger XML iMMix: Tijdelijke drager wordt verwijderd, nieuwe drager wordt aangemaakt \\as-immix-#\ DFI Applicatiebeheer Afbeelding 5: Instroom van een collectie bij Beeld en Geluid. (Auteur: P. Hoffman) 3.4.1 Beschrijving flow instroom [1] Een nieuwe instoom moet plaats gaan vinden. Er vindt afstemming plaats over voorwaarden, levering van materiaal, rechten en bestandsformaten en naamgeving. Zie bijlage B voor specificaties van bestandsformaten en naamgeving. [2] Indien OK Versie 1.0 Pagina 19 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT [3] De aanleverende partij plaatst het materiaal, de MXF-bestanden, op een FTP-server. [4] Er vindt afstemming plaats met catalogusbeheer m.b.t. de mapping van de metadata. In het geval van de Tweede kamer worden de metadata volgens het schema van de GMI.xsd gevalideerd en als xml aangeleverd. [5] In de afstemming onder punt 4 wordt applicatiebeheer ook betrokken om technische zaken rondom instroom te regelen, zoals het checken van de MXF en het doen van proefimports. De taak van catalogusbeheer is om inhoudelijk zorg te dragen dat velden goed landen in de database. De taak van applicatiebeheer is om te zorgen dat de instroom zonder technische fouten verloopt.. [6] Als de metadata helemaal goed zijn bevonden kunnen deze geïmporteerd worden in de catalogus door deze aan te bieden aan de GMI (Generieke Metadata Importer). In de xml worden tijdelijke dragers vermeld om een latere koppeling met de mxf-en in de catalogus mogelijk te maken. De xml-en worden in de importmap van de GMI geplaatst. [7] De GMI-service leest de xml-en in, valideert deze en maakt de metadata en dragers aan. Wanneer er een fout optreedt, wordt de betreffende xml in de submap “fout” geplaatst. In de map \Logs\iMMixGMIService kan de reden gevonden worden. [8] Na een succesvolle import van de metadata moeten er in de client van iMMix beheerhandelingen voor de tijdelijke dragers gemaakt worden. De status van deze beheerhandelingen moet achtereenvolgens verhoogd worden naar “Gepland” en “Onder handen”. Tijdens de pilot was dit een handmatige activiteit, dit is te automatiseren zoals ook het geval is voor andere geautomatiseerde instromen bij Beeld en Geluid. [9] Een service op de applicatieserver ziet de betreffende beheerhandelingen [10] De service genereert trigger-xml-en en zet de status van de beheerhandeling op “Gereed”. Ook wordt een mail gestuurd naar de postbus van de betreffende iMMix-omgeving. De triggers hebben dezelfde naam als de MXF. Het is dus belangrijk dat de naamgeving van de MXF-en altijd overeenkomt met de naamgeving zoals deze in de metadata vermeld staat, anders kan er geen koppeling van de essence plaatsvinden. [11] De applicatiebeheerder ziet de trigger-XML in de DFI-map op de applicatieserver verschijnen en kopieert deze middels FTP naar de FTP-Server. Ook dit is bij een operationele instroom een geautomatiseerde stap. [12] Het DFI-systeem ziet een MXF en XML met dezelfde naam (de XML moet altijd als laatste worden geplaatst). De DFI zorgt dat de MXF m.b.v. DIVA en mam-iMMix in de storage geplaatst wordt. In deze fase vindt ook altijd nog een MXF-check plaats om zeker te stellen dat de essence voldoet aan de gestelde eisen. Dit is een automatische check die hetzelfde functioneert als de handmatige MXFcheck die in de test-/certificeringsfase wordt gebruikt. [13] Vanuit mam-iMMix worden een XML en AXF-bestand met o.a. de nieuwe GUCI naar iMMix gestuurd. De trigger-XML is hierin opgeslagen als dark metadata. [14] De HighRes importservice op de applicatieserver verwerkt de XML en AXF-bestanden. Hierbij wordt een set van drie bestanden aangemaakt: x x Media Archive drager: Ook wel administratieve drager genoemd. Dit is feitelijk een verwijzing naar de GUCI. MXF drager: Een verwijzing naar het HighRes bestand. Versie 1.0 Pagina 20 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT x MPEG drager: een verwijzing naar het LowRes bestand. 1 Hierna is de tijdelijke drager zoals deze bij import van de metadata was aangemaakt in de catalogus verwijderd en in de plaats daarvan zijn de definitieve dragers gekoppeld aan de metadata. De bestanden zijn nu ook te bekijken en te bestellen. 3.4.2 Gaps - Instroom bij Beeld en Geluid Momenteel zijn er nog een aantal openstaande punten die verhinderen dat de flow precies plaatsvindt zoals deze zou moeten volgens bovenstaand model. 1. Om automatisch in te kunnen stromen, dient de essence (Beeldmateriaal) te voldoen aan de archiefstandaarden. Tweede Kamer-beeldmateriaal voldeed aan deze standaarden, maar werd tijdens de pilot in eerste instantie niet als zodanig herkend. Een kleine change in de door Ericsson beheerde Beeld en Geluid-systemen kan dit probleem oplossen. (actie Beeld en Geluid, doorlooptijd 1 maand) 2. De metadata van de ongesegmenteerde vergaderingen bevat nog enkele kleine punten die import verhinderen, zoals meerdere voorkomens van zelfde sprekernamen binnen een record. Tijdens de pilot zijn deze handmatig aangepast. Bij de gesegmenteerde vergadering doet dit probleem zich niet voor. Volgens de XSD wordt er correct aangeleverd, de daadwerkelijke import lukt echter niet. (actie Beeld en Geluid i.s.m. Tweede Kamer) 3. Als de instroom van Tweede Kamer-materiaal vastere vorm krijgt, dient er een een creator code aangevraagd te worden, zodat handmatig verplaatsen van de files niet meer noodzakelijk is. Op dat moment kan de Tweede Kamer de files rechtstreeks FTP-en naar de DFI-instroomserver van Beeld en Geluid (actie Beeld en Geluid, doorlooptijd 1 maand) 4. Webservice inrichten die de handmatige handelingen voor het verplaatsen van bestanden overneemt van de afdeling applicatiebeheer (actie Beeld en Geluid, doorlooptijd 2 maanden) 3.5 INSTROOM VAN METADATA IN HET E-DEPOT VAN HET NATIONAAL ARCHIEF Binnen de pilot is ook gekeken naar de instroom van metadata in het e-Depot van het Nationaal Archief. De metadata uit VLOS2.0 zijn ingelezen in het e-Depot. Er zijn drie verschillende tests gedaan: 1. De volledige VLOS2.0-documenten van de vergaderingen 99 t/m 103 zijn als record (bestand + metadata over dit bestand) in het e-depot ingelezen. Daarbij is gebruik gemaakt van de minimale set van metadata die nodig is bij het inlezen. 2 Het VLOS2.0-document van de 99ste vergadering (deze is gesegmenteerd en ongesegmenteerd aanwezig in de catalogus van Beeld en Geluid) is als record ingelezen in het e-depot. Hierbij is gebruik gemaakt van een uitgebreide set van metadata. Deze metadata zijn deels aangevuld (eventgeschiedenis, actoren etc.) en deels gemapt uit het VLOS2.0-document. Daarnaast is het gehele VLOS2.0-document aan de metadata toegevoegd door gebruik te maken van het element AgencySpecific metadata in het metadataschema van het Nationaal Archief. Hierdoor worden de metadata van het VLOS2.0-document volledig geïndexeerd tijdens de ingest. Versie 1.0 Pagina 21 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT ste 3. Een gedeelte van de 99 vergadering. Dit gedeelte bestond uit de gesegmenteerde vergadering. Bij deze ingest is de essence ingelezen als record aangevuld met metadata op dezelfde manier als bij onderdeel 2. Deze drie testen zijn succesvol afgerond en gedemonstreerd aan de Tweede Kamer en Beeld en Geluid. Door deze drie testen te doen is inzicht ontstaan in het volgende punten: a. mogelijkheden die er zijn om gegevens met elkaar te koppelen (het leggen van relaties) b. mogelijkheden om de context te borgen c. welke metadata waar opgeslagen kunnen worden Versie 1.0 Pagina 22 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 4 EISEN AAN ESSENCE (BEELDMATERIAAL) Om duurzame opslag van beeldmateriaal en geluid te garanderen hanteert Beeld en Geluid de open MXF-standaard. Deze standaard is naast open ook gangbaar en wordt onderhouden en ondersteund door grote fabrikanten. Een ander voordeel van deze standaard: hij wordt “mediapark-breed” gebruikt en materiaal dat volgens deze standaarden is gearchiveerd is direct voor broadcast geschikt. De Tweede Kamer is er in geslaagd MXF (beeld) bestanden aan te bieden die aan de requirements van MXF- certificatie voldoen. De volledige specificaties zijn terug te vinden in bijlage A 4.1.1 Gaps – Eisen aan essence (Beeldmateriaal) Geen gaps. Bij het eventueel operationeel inregelen van de instroom van Tweede Kamer beeldmateriaal bij Beeld en Geluid volgt officiële certificering van de instroom door Ericsson. Versie 1.0 Pagina 23 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 5 METADATA- ANALYSE 5.1 INLEIDING Metadata beschrijven de context, inhoud en structuur van de digitale informatie die gecreëerd wordt, evenals het beheer van deze records door de tijd heen. Ze zijn onmisbaar om de terugvindbaarheid, bruikbaarheid, authenticiteit, integriteit en betrouwbaarheid van de records te kunnen garanderen. Door metadata wordt het beheer van informatie op de lange termijn mogelijk gemaakt en zij zijn daarnaast van essentieel belang voor de uitwisseling van informatie. Het uitgangspunt voor de metadata-analyse binnen deze pilot is niet een volledig uitgewerkt en/of gemapt metadataschema. Het is de bedoeling dat met deze analyse inzichtelijk wordt wat er op dit moment vastgelegd wordt (bij de TK, BenG en het NA) en hoe we de relatie met deze metadata kunnen behouden. Daarnaast kunnen de “GAPs” die naar voren komen, dienen om verder te praten en afspraken te maken hoe we deze in een eventueel vervolgstadium kunnen oplossen. 5.2 ALGEMEEN Digitale informatie bestaat (vaak) buiten een “formeel” archiefsysteem/beheersysteem en wordt aangemaakt in een bedrijfssysteem dat een specifiek doel dient (bijvoorbeeld het VLOS-systeem). Deze informatie wordt gebruikt en begrepen door de mensen die beschikken over voldoende kennis van de processen die uitgevoerd worden, over de mensen die de erbij betrokken zijn, over de informatie die wordt aangemaakt en over de directe context van deze informatie. Deze bedrijfssystemen zijn niet altijd even robuust. Het volgende wordt niet in alle gevallen vastgelegd: x x x Contextuele verbanden Expliciete informatie die nodig is om de onderdelen van de informatie buiten de specifieke bedrijfscontext te identificeren, waardoor de uitwisseling met gerelateerde systemen moeilijk kan worden Beheerprocessen die nodig zijn om de duurzaamheid van de informatie te waarborgen (voor zolang dat nodig is). Binnen de pilot zien we dit ook. Het VLOS-systeem, waar we nu de metadata uit gebruiken, heeft niet als doel het vastleggen van metadata, maar is een hulpmiddel voor de Dienst Verslag en Redactie (DVR) voor de vastlegging van de vergadering. De vastlegging van beheerprocessen die nodig zijn voor digitale duurzaamheid is daarom eigenlijk niet aanwezig. In de rest van dit hoofdstuk wordt aangegeven hoe dit beter vormgegeven kan worden. Samenvattend: We leggen metadata vast voor de volgende doeleinden: x x x x x x Vergroten van de duurzame toegankelijkheid en betrouwbaarheid van (digitale) informatie Bevorderen van een juiste interpretatie van de (digitale) informatie Het mogelijk maken om gegevens uit te wisselen tussen organisaties en/of systemen (interoperabiliteit). Het transparant en openbaar maken van (digitale)informatie Het adequaat beveiligen van informatie wanneer en waar het moet Het beheren en weer representeren van (digitale) informatie Versie 1.0 Pagina 24 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 5.3 METADATA EN DE VERSCHILLENDE ENTITEITEN DIE ZE BESCHRIJVEN De rijksoverheid moet voldoen aan bepaalde normen en standaarden m.b.t. metadata. In de pilot is onderzocht of de metadata die worden vastgelegd voldoen aan de eisen zoals deze gesteld zijn in de NEN-ISO 23081. Deze norm definieert generieke metadatatypen die moeten worden vastgelegd en beheerd om de context van de digitale informatie (of archiefbescheiden) te kunnen documenteren en begrijpen. De norm identificeert voor de belangrijkste entiteiten ook een minimum aantal vaste aggregatieniveaus die vereist zijn om interoperabiliteit te bewerkstelligen. Metadata kunnen bij verschillende entiteiten horen. Een entiteit is een zelfstandige “wezenlijke eenheid” die kan worden beschreven en waar informatie aan kan worden verbonden. De beschreven entiteiten kunnen heel concreet zijn (bijvoorbeeld een persoon of een document) maar ook abstract (zoals een proces of een idee). De volgende entiteiten zijn van belang voor archiefbescheiden: x x x x De archiefbescheiden zelf. Dit kan een afzonderlijk document zijn, maar ook een aggregatie van verschillende archiefbestanden (record-entiteit) De mensen of organiserende structuren in een bedrijfsomgeving (actor-entiteit) De verrichte bedrijfsactiviteit (activiteit-entiteit) De regels die de transactie en het documenteren van de bedrijfsactiviteit bepalen (mandaatentiteit) Afbeelding 6: relatie entiteiten Bovenstaande afbeelding laat duidelijk zien dat de entiteit Record een centrale en onmisbare rol vervult. Het record is de neerslag van de processen en activiteiten. De metadata opgeslagen bij het record moeten het record dan ook zo volledig mogelijk beschrijven. Versie 1.0 Pagina 25 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Informatie over de actor, het mandaat en de activiteit kan op verschillende manieren worden vastgelegd. Deze kan als contextinformatie worden opgenomen in de metadata bij het record. In dit geval is er sprake van een 1-entiteitmodel. Het is echter ook mogelijk om deze gegevens als losse entiteiten te beschrijven. De gegevens over de verschillende activiteiten worden dan via een relatie aan elkaar gekoppeld. Voor deze analyse is uitgegaan van een 1-entiteitenmodel. Dat betekent dat de metadata die in onderstaande paragrafen worden besproken het record beschrijven. Indien ze iets anders beschrijven wordt dit specifiek aangegeven. Het kan dus zijn dat op sommige punten extra contextinformatie over de actoren, activiteit en het mandaat moet worden vastgelegd. De NEN-ISO 23081 beschrijft alle entiteiten in termen van generieke groepen elementen. In de volgende paragrafen worden deze groepen kort toegelicht en waarnaar er gekeken wordt welke elementen al vastgelegd worden binnen de pilot en welke elementen nog niet. Middels conclusies, aandachtspunten en aanbevelingen per groep is geprobeerd inzichtelijk te maken wat de eisen m.b.t. metadata inhouden. 5.4 GENERIEK METADATAMODEL VOOR HET BEHEREN VAN (DIGITALE) INFORMATIE De metadata die hieronder gedefinieerd staan kunnen worden toegepast op de entiteit record en zijn van essentieel belang voor de het behoudt van informatie die gevormd wordt. Belangrijk om te weten is dat de beginwaarden van deze metadata-elementen worden toegekend op het moment van creatie van de digitale informatie (in het geval van de pilot dus op het moment van creatie bij de Tweede Kamer). In de loop der tijd worden er gegevens toegevoegd aan het record, bijvoorbeeld als de digitale informatie van context verandert, maar ook gegevens over beheersactiviteiten worden aan de metadata toegevoegd. De zes metadata-groepen waar we naar kijken zijn: a. Identiteit – metadata die het mogelijk maken om de records waar de metadata naar verwijzen uniek te identificeren. Hierdoor kunnen er relaties gelegd worden naar de records wat ook nodig is voor het uitwisselen van gegevens. b. Beschrijving – metadata die het mogelijk maken records te vinden bij een zoekactie. Daarnaast verduidelijken deze metadata de context van het record. c. Gebruik – metadata die het gebruik van de records op de langere termijn vergemakkelijken en mogelijk maken. d. Activiteitenplan - metadata die informatie bevatten voor het beheren van records met de daaraan gekoppelde metadata. Deze metadata bestaan uit beheersactiviteiten die in de toekomst zullen plaatsvinden. e. Geschiedenis van Activiteiten – metadata die eerder uitgevoerde acties op de records en bijbehorende metadata documenteren. Deze metadata tonen aan dat de records en de metadata door de tijd heen hun authenticiteit hebben behouden. f. Relatie – metadata die twee of meer entiteiten (kunnen ook meerdere records zijn) met elkaar verbinden. De metadata die vastgelegd moeten worden voor het beheer van digitale informatie zijn niet statisch. Ze zullen blijven toenemen bij het uitvoeren van de verschillende processen voor het beheer van digitale informatie (of records). Versie 1.0 Pagina 26 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Samenvattend: Metadata over de identiteit, de beschrijving, het gebruik en de relatie laten de huidige staat van het record zien. Het activiteitenplan bevat de toekomstige planning voor het beheer. De geschiedenis van de activiteiten bevat de informatie over hetgeen met het record door de tijd heen is gebeurd. Het activiteitenplan kan door de tijd heen wijzigen en wordt (automatisch) gedocumenteerd in de geschiedenis van de activiteiten. Identiteit Beschrijving Gebruik Relatie Geschiedenis Van Activiteiten Activiteitenplan Huidige Status VERLEDEN TOEKOMST Afbeelding 7: Ontwikkeling Metadata 5.4.1 Metadata met betrekking tot identiteit We willen digitale informatie kunnen opvragen, uitwisselen, beheren en exporteren. Om dit mogelijk te maken moeten we de informatie kunnen herkennen. De metadata binnen deze groep onderscheiden het beschreven record van de andere digitale informatie die in het systeem is opgeslagen. De volgende elementen moeten vastgelegd worden: - Type entiteit (n.v.t.) – specificeert de entiteit die beschreven wordt. Dit is enkel verplicht bij een meer-entiteitenmodel, dus binnen deze pilot is dit element niet van toepassing. Aggregatie (V) – is nodig om bij uitwisseling van gegevens deze op het juiste niveau te koppelen. Registratiekenmerk (V) – identificeert op unieke wijze de beschreven entiteit Aggregatie: Verschillende aggregatieniveaus worden gebruikt om informatieobjecten (hiërarchisch) te groeperen waardoor de samenhang kan worden aangegeven. Daarnaast wordt het toekennen van metadata efficiënter, omdat bepaalde gegevens overerven, dit voorkomt redundantie. Bij de export van een record uit een systeem, moet wel nagegaan worden of alle relevante metadata goed worden meegeleverd. Versie 1.0 Pagina 27 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Voor het uitwisselen van informatie tussen verschillende systemen, is het noodzakelijk dat we weten op welk niveau de informatie beschreven wordt. Zowel de Tweede Kamer, Beeld en Geluid als het 2 Nationaal Archief onderkennen verschillende aggregatieniveaus. Het is belangrijk dat we weten hoe de verschillende aggregatieniveaus zich tot elkaar verhouden, zodat we zeker weten dat we over dezelfde informatie praten. In onderstaande afbeelding is te zien hoe de verschillende aggregatieniveaus zich tot elkaar verhouden zoals er nu vanuit gegaan is binnen de pilot. Werk Vlos document Realisatie Vergadering Reeks Activiteit Expressie Vraag/document Selectie (item?) Subselectie Archief Serie Dossier Record Afbeelding 8: Aggregatieniveaus Registratie Kenmerk: Door het vastleggen van een registratiekenmerk (of identificatiekenmerk) in de metadata wordt het beschreven record onderscheiden van de andere digitale informatie die in het systeem is opgeslagen. Deze gegevens moeten aan het record worden toegekend bij de registratie in het systeem. Binnen de pilot kunnen we een onderscheid maken tussen de zogenaamde “technische” identificatiekenmerken en een meer inhoudelijk identificatiekenmerk. De eerste is de unieke sleutel van het 2 Daarnaast identificeert de NEN-ISO 23081 voor de belangrijkste entiteiten ook een minimum aantal vaste aggregatieniveaus die vereist zijn om de interoperabiliteit te bewerkstelligen. Deze zijn niet meegenomen in deze analyse. Versie 1.0 Pagina 28 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT systeem waarmee de data binnen het systeem terug te vinden zijn. Wanneer de data zich buiten het systeem bevinden is deze (database)sleutel vaak niet meer relevant. Het andere identificatiekenmerk is een collectiereferentie of een catalogusnummer waarmee een record met zijn metadata terug te vinden is. Bij het exporteren van het record blijft dit identificatiekenmerk van waarde zolang de link met de metadata blijft bestaan. Buiten het systeem wordt dit vaak vastgelegd als een extern identificatiekenmerk. In onderstaande afbeelding worden de verschillende identificatiekenmerken (per instituut) die in de pilot voorkomen op de verschillende aggregatieniveaus weergegeven Afbeelding 9: Identificatiekenmerken per instituut Conclusie: De metadata m.b.t de identiteit zijn volledig aanwezig en het record en zijn metadata zijn uniek identificeerbaar binnen de verschillende systemen. Aandachtspunten: - - Goed definiëren wanneer het gaat om het unieke identificatiekenmerk binnen het systeem en waar het gaat om een identificatiekenmerk waarmee het record en zijn metadata worden teruggevonden. Goede afspraken maken over de aggregatieniveaus die we gebruiken en op welk aggregatieniveau we welke metadata koppelen. Versie 1.0 Pagina 29 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT - Het toekennen van het TPK-kenmerk, dat binnen de pilot is gebruikt, gebeurt buiten het systeem. Het is de vraag of dit zo handig is voor de toekomst en of hierdoor de link/context met de informatie in de systemen van de TK wel behouden blijft. Aanbeveling: Technisch zit hier geen probleem. Afspraken tussen de verschillende partijen moeten gemaakt worden over bovenstaande aandachtspunten, waardoor in een vervolgtraject de relatie m.b.t. metadata en de essence tussen de drie partijen verder geïmplementeerd kan worden. Hieronder valt ook het verder uitzoeken van welke identificatiekenmerken het beste gebruikt kunnen worden bij het leggen van de relatie tussen de verschillende systemen. 5.4.2 Metadata met betrekking tot beschrijving Deze groep van metadata beschrijven het record. Hiermee wordt nagegaan of het ook het record is wat men zoekt. Het gebruik van deze elementen dient twee functies: 1. Ze maken het mogelijk dat het record terug te vinden is bij het zoeken 2. Ze maken het mogelijk de context van het record te begrijpen. De volgende elementen moeten vastgelegd worden: - Titel (V) – Beknopte formeel-inhoudelijk beschrijving van het record Classificatie (V) – Het groeperen of in samenhang aanbieden van verwante records. Omschrijving (O) – Het verschaffen van nadere inhoudelijke informatie Plaats (V) – Het beheer en de terugvindbaarheid van de entiteit. Voor een digitaal record kan dit zijn: applicatie met unieke sleutel, een URL of een storagelocatie Jurisdictie (n.v.t.) - geldt niet voor het record, maar wordt vastgelegd in de contextgegevens (zie Toepassingsprofiel Metagegevens Rijksoverheid) Externe Identificatiekenmerken (V ivt) – Kenmerken toegekend aan het record, buiten de huidige beheersomgeving De elementen titel, omschrijving en plaats kunnen en worden door alle systemen vastgelegd. Hoe om te gaan met het element externe identificatiekenmerken is reeds in de vorige paragraaf beschreven. Jurisdictie Jurisdictie is niet van toepassing op de entiteit record. Er zullen echter wel metadata die betrekking hebben op de entiteiten actor, activiteit en mandaat extra moeten worden toegevoegd aan de metadata van het record. Het Toepassingsprofiel Metagegevens Rijksoverheid geeft in het element 15 – context duidelijk aan wat in ieder geval vastgelegd moet worden. Versie 1.0 Pagina 30 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Nr Element Definitie Toepassing Verplichting 15C-1 Actor Een organisatie of persoon De organisatie of de persoon die formeel Verplicht verantwoordelijk voor of verantwoordelijk of gemandateerd is betrokken bij opmaken, opnemen voor het stuk. van archiefbescheiden en/of processen van informatie- en archiefbeheer 15C- -Identificatiekenmerk Uniek kenmerk van een actor 1-2 Verwijzing naar de actor onder wiens Verplicht. formele verantwoordelijkheid het stuk is gecreëerd. Er dient een verwijzing te zijn naar de plaats waar nadere informatie over het heden en verleden van de actor gevonden kan worden 15C- -Aggregatieniveau Niveau in de hiërarchie van de actor. Van Aanbevolen belang voor de uitwisselbaarheid. 1-3 Waarden (zie de Richtlijn): Institutie, Organisatie-eenheid, Groep, Functionaris. 15C- -Geautoriseerde naam Elke overheidsorganisatie heeft een Optioneel officiële naam die bekend moet zijn en 1-4.2 waaronder zij gevonden dan wel geciteerd kan worden. 15C- - Jurisdictie Bevoegdheden van (formele) actor. Optioneel 1-8 Afbeelding 10: Gegevens over de actor Nr Element Definitie Toepassing Verplichting 15C-2 Activiteit Het geheel van taken, functies, Omschrijving van het proces waar het Verplicht activiteiten en transacties die op record uit voorkomt (opgemaakt en/of basis van een mandaat worden gebruikt is). uitgevoerd door een actor. Advies: Hier kan gebruik worden gemaakt van de MARIJ waar processen tot op functieniveau zijn uitgewerkt en gekoppeld aan generieke waardelijsten. Deze informatie zou ook kunnen worden afgeleid van het classificatieschema, mits dit aansluit op de taken/processen. Dit schema dient echter stabiel in de tijd te zijn en daarom is meer gedetailleerde en Versie 1.0 Pagina 31 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT actuele informatie noodzakelijk t.a.v. de feitelijke bevoegdheden en verantwoordelijkheden waarmee een proces is ingeregeld op het moment dat het record wordt opgemaakt, ontvangen en/of gebruikt in een proces. 15C- -Identificatiekenmerk Uniek kenmerk van een activiteit. Verwijzing naar het proces of de activiteit Aanbevolen waarin het stuk is gecreëerd. Er dient een 2-2 verwijzing te zijn naar de plaats waar nadere informatie over het heden en verleden van de activiteit kan worden gevonden. 15C- -Aggregatieniveau Niveau in de hiërarchie van de activiteit. 2-3 Aanbevolen Van belang voor de uitwisselbaarheid. Waarden (zie de Richtlijn):Sector, Taak/Functie, Handeling/Proces, Activiteit/Transactie. 15C- -Naam 2-4 Kernachtige omschrijving van de Actuele (formele)benaming van activiteit activiteit. (of bedrijfsproces) Verplicht Afbeelding 11: Gegevens over de activiteit: Classifcatie: Het toepassen van classificatie geeft inzicht in de onderlinge samenhang (de context). Alle records opgemaakt binnen een bepaald bedrijfsproces kunnen worden geklasseerd onder één classificatiecode. Dit wordt vastgelegd in een classificatieschema. Aan een classificatieschema worden bewaar- en vernietigingstermijnen verbonden. Ook zouden op vergelijkbare wijze andere informatie-eigenschappen aan documenten kunnen worden gekoppeld (denk aan gebruiksrechten, vertrouwelijkheid en openbaarheid). Hiermee kun je bereiken dat dergelijke eigenschappen automatisch worden toegekend aan digitale informatie. Conclusie: Hoe de context van de actor, de activiteit en het mandaat bij de metadata van het record worden opgeslagen, is nog niet duidelijk. Ook de classificatie, die door de Tweede Kamer moet worden vastgelegd, is voor AV-materiaal nog niet aanwezig. De overige elementen zijn wel aanwezig in de metadata gebruikt voor deze pilot. Aandachtspunten: - Het vastleggen van de contextinformatie binnen de metadata die het record beschrijven Classificatie vastleggen op het moment van creatie, waardoor het toevoegen van eigenschappen aan je digitale informatie automatisch kan verlopen. Versie 1.0 Pagina 32 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Aanbevelingen: De gehele context waarbinnen het AV-materiaal tot stand komt, moet uiteindelijk geborgd worden. Dit betekent dat AV-materiaal niet los gezien kan worden van de overige materialen. In de pilot is alleen naar AV-materiaal gekeken. De registraties die gecreëerd worden door de AV-afdeling staan los van de creatie en het beheer van de overige (digitale) informatie binnen de Tweede Kamer. Dit gebeurt voornamelijk bij de DIV-afdeling van de Tweede Kamer. Bij deze informatiestroom wordt rekening gehouden met een ordeningsplan/classificatieschema en selectie en waardering van de informatie. Een aanbeveling voor een vervolg zou zijn om met het proces waarin het AV-materiaal wordt gecreëerd beter aan te laten sluiten op de overige informatieprocessen binnen de Tweede Kamer, waardoor de context van het gehele proces beter en gemakkelijker geborgd kan worden. 5.4.3 Metadata met betrekking tot gebruik Deze groep van metadata beschrijft het gebruik van het record. Deze groep bevat elementen die de toegang op de langere termijn bevorderen tot aan de rechten die aan het rceord zijn toegekend. Metadata die hier worden vastgelegd, bevatten de grootste verscheidenheid aan informatie, namelijk van informatie over gebruiksrechten tot informatie over de technische bijzonderheden die vereist zijn om het record nu en in de toekomst te kunnen weergeven. De volgende elementen moeten vastgelegd worden: - Technische omgeving (V) – informatie die nodig is om het record te reproduceren en weer te geven, zoals informatie over bestandsformaat, eisen aan decodering en ondersteunende technologie Rechten (Vivt) – gebruiksrechten, intellectueel eigendom, beperkingen, toestemmingen etc. Toegang (Vivt) – openbaarheid, vertrouwelijkheid Doelgroep (O) Taal (O) Integriteit (V) – Informatie waaruit blijkt dat de integriteit van het record en zijn metadata behouden is gebleven sinds het aanmaken ervan. Documentvorm (V) – informatie over de erkende vorm van het archiefstuk, die de interne structuur bepaalt en betrekking heeft op het doel van het record in de transactie of op de functie, activiteit of transactie die het record documenteert. Technische omgeving; Er zullen verschillen zitten in de metadata die nodig zijn afhankelijk van de aard van het object. Op het laagste aggregatieniveau voor archiefbescheiden bestaan de eisen uit het identificeren van technische onderlinge afhankelijkheden voor hardware, software en bestandsformaat. Wat je over bovenstaande kan toevoegen is nog vrij breed. De eisen die voor de technische omgeving en het formaat hier worden gebruik zijn de eisen zoals ze gesteld worden in het Toepassingsprofiel Metagegevens Rijksoverheid. In een eventueel vervolgtraject op deze pilot moet bekeken worden hoe de volgende gegevens kunnen worden vastgelegd 1. Identificatiekenmerk (V) – Uniek kenmerk van het digitale bestand 2. Naam digitaal bestand (V) – Korte omschrijving of benaming van een digitaal bestand 3. Type (V ivt) – Wijze van groepering omwille van samenhang. Het type dient vastgelegd te worden wanneer een digitaal bestand onderdeel uitmaakt van een “digitaal pakket”. Waarden kunnen zijn Samengesteld bestand (bijv. Website, XML-bestand +stylesheet), Container (bijv. Versie 1.0 Pagina 33 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT zip, mxf), Enveloppe (bijv. e-mail, METS-bestand), Data/enkelvoudig gegevensbestand (de eigenlijke bitreeks) 4. Omvang (V) – Ruimtebeslag op medium meestal uitgedrukt in bytes of een veelvoud ervan 5. Bestandsformaat (V) – Code volgens welke gegevens op een gegevensdrager zijn opgeslagen. Dit geeft de benodigde informatie over de applicatie waarmee het record kan worden geraadpleegd. Voor de karakterisering van bestanden zijn verschillende tools 3 ontwikkeld 6. Creatieapplicatie (V ivt) – Omschrijving van de applicatie waarmee het bestand oorspronkelijk gemaakt is. Dit levert extra informatie over de mogelijkheid het record te raadplegen wanneer dit op basis van de informatie over het bestandsformaat niet mogelijk blijkt. Dit kan veroorzaakt worden door incompatibiliteit van bestandsformaten. 7. Fysieke Integriteit (V) – Uitdrukking van mate van volledigheid en onbeschadigd zijn van een digitaal bestand 8. Datum aanmaak (V) – Datum, waarop het huidige digitale bestand is aangemaakt 9. Event plan (V ivt) – Activiteit of gebeurtenis die aangeeft wat in de toekomst moet/zal gebeuren met het digitale bestand. Dit kan gebruikt worden voor bijvoorbeeld het jaarlijks overzetten op een andere drager, of het periodiek controleren van de integriteit. 10. Relatie (V) – definieert de samenhang met andere digitale bestanden, of (intellectuele) entiteiten zoals Record. Rechten: Voorwaarden die verbonden zijn aan het gebruik van het Record anders dan raadpleging dienen vastgelegd te worden. Het gaat hier om gebruiksrechten (licentieregelingen, copyright, intellectueel eigendom), beperkingen (zoals voor kopiëren of uitgeven), toestemmingen en eventuele voorwaarden. Deze gebruiksrechten kunnen in de loop der tijd ook wijzigen. Indien hier niets over vastgelegd wordt in de metadata dan is het record standaard rechtenvrij. Toegang/toegankelijkheid: Toegang/toegankelijkheid bestaat uit twee onderdelen, namelijk de openbaarheid (mogelijke beperkingen aan raadpleging) en de vertrouwelijkheid (het afschermen van informatie tegen inzage door onbevoegden) Voor de registraties in de plenaire zaal is bovenstaande niet van toepassing. Gaan we in een vervolgtraject ook de commissievergaderingen meenemen, dan moet dit goed vastgelegd worden. Beeld en Geluid kan op verschillende manieren informatie afschermen, die naar alle waarschijnlijkheid voldoen aan de gestelde eisen. 3 Een voorbeeld van zo’n tool is DROID (http://sourceforge.net/projects/droid/) met daarachter de PRONOM registry (http://www.nationalarchives.gov.uk/PRONOM/Default.aspx) met informatie over de bestandsformaten. Versie 1.0 Pagina 34 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Integriteit: Fysieke en inhoudelijk integriteit moeten worden vastgelegd. Hiervoor wordt aangeven of een record (op alle aggregatieniveau’s) nog volledig is, dan wel of er delen verloren zijn gegaan of illegaal zijn gewijzigd. Het gaat hier over de logische integriteit; de technische integriteit van de daadwerkelijke data valt onder format en hetgeen wat daarover vastgelegd moet worden. 1. Fysieke Intergriteit 2. Inhoudelijke Integriteit Checksum Essence (=record) 2. Periodieke controle op integriteit Voor export wordt een checksum van het record gegenereerd. 1. Tijdens ingest wordt Checksum gecontroleerd 1. 1. 2. Inhoudelijke Integriteit: NU: is het record volledig (alle vergaderingen met metagegevens) Toekomst: Zijn er gegevens/vergaderingen verloren gegaan Checksum Vlosdocument (= record) Identificeren van en afspraken maken over: - gebruiksrechten - vertrouwelijkheid - openbaarheid En hoe deze vast te leggen Periodieke controle op integriteit 1. Inhoudelijke Integriteit: NU: is het record volledig (alle xml-records met metagegevens) Toekomst: Zijn er gegevens/xml-records verloren gegaan 1. 2. Tijdens ingest wordt Checksum gecontroleerd Afbeelding 12: Afspraken met betrekking tot toekomstig gebruik Conclusies: Over de metadata met betrekking tot gebruik is veel bekend. Binnen de pilot wordt op dit moment nog weinig vastgelegd. Dit is deels omdat hier inhoudelijke afspraken over gemaakt moeten worden tussen de verschillende partijen. Aandachtspunten: Gebruiksrechten: op het materiaal opgenomen in de plenaire zaal zitten gebruiksrechten Vertrouwelijkheid en openbaarheid: NA hanteert na overbrenging “openbaar tenzij” . Mocht het materiaal (metadata en essence) beperkingen hebben dan moet dit vastgelegd worden. Aanbevelingen: Versie 1.0 Pagina 35 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT M.b.t Format: Er zijn verschillende tools beschikbaar om bestandsformaten te herkennen, identificeren en eigenschappen te extraheren. Het inbouwen van deze tools in een export- en/of import-workflow kan ervoor zorgen dat dit proces automatisch verloopt. Aandachtspunt hierbij: bepaal welke gegevens moeten worden vastgelegd en hoe. Voor de interoperabiliteit is het aan te raden om bestandsformaten, software, hardware, compressies en encoderingen op een eenduidige en unieke manier te identificeren (bijvoorbeeld middels PUIDs). Gebruiksrechten: uitzoeken wat de invloed van eventuele gebruiksrechten op de registraties van de plenaire zaal is en hoe dit in de metadata vastgelegd kan worden. 5.4.4 Metadata met betrekking tot het activiteitenplan Dit is de metadatagroep waarin de elementen zitten die het beheer van de records en de bijbehorende metadata mogelijk maken. Bepaalde activiteiten liggen van te voren al vast, zoals vernietiging, verandering van openbaarheidsregime e.d. Het is aan te bevelen om voor deze activiteiten een activiteitenplan op te nemen, waardoor de toekomstige verandering van status kan worden geautomatiseerd. De volgende elementen moeten vastgelegd worden: - Datum/tijd activiteit Datum (en eventueel tijd) waarop de activiteit dient plaats te vinden Activiteittype – Soort activiteit ter ondersteuning van beheer, registreren, evalueren, bewaren, verwijderen en actualiseren Beschrijving activiteit - Informatie die de actor nodig heeft om de geplande actie uit te voeren Activiteit relatie – informatie over de actor (en het mandaat) die de activiteit zal uitvoeren Activiteitentrigger - Indicatie van mechanisme waarop gebeurtenis of actie in gang wordt gezet Wanneer een geplande activiteit plaatsvindt, dient er een activiteit aangemaakt te worden in de metadata met betrekking tot de geschiedenis van activiteiten (zie volgende paragraaf). De registratie wordt dan vervolgens verwijderd uit de metadata met betrekking tot het activiteitenplan. De geschiedenis van activiteiten legt hierdoor vast wat er is gebeurd, wanneer het heeft plaatsgevonden, waarom het heeft plaatsgevonden en wie het heeft uitgevoerd Versie 1.0 Pagina 36 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 2. Aangeven overgedragen naar Nationaal Archief in systeem 1. Datum van overdracht vastleggen in metagegevens Toegang 2. Verandering openbaarheidsregime vastleggen. Toegang 3. Verandering vertrouwelijkheid vastleggen. 1. Datum van overdracht vastleggen in metagegevens 4. Verandering gebruiksrechten vastleggen. Afspraken overdracht worden vastgelegd in een “Transfer Agreement” Toegang Afbeelding 13: Metadata m.b.t. activiteitenplan Conclusie en Aanbeveling: Het vastleggen van deze metadata wordt niet verplicht gesteld in de Richtlijn Metagegevens Rijksoverheid of het Toepassingsprofiel Metagegevens Rijksoverheid. Het is echter wel aan te bevelen om dit in de toekomst in te richten, omdat er een enorme groei is aan digitale informatie en het in de toekomst onmogelijk wordt om dit soort activiteiten per record handmatig vast te gaan leggen Het vastleggen van deze activiteiten begint idealiter bij de creatie van het record bij de Tweede Kamer. Gelijk aan de aanbeveling m.b.t.classificatie werkt dit het beste als er aangesloten wordt op de rest van de digitale informatie die binnen de Tweede Kamer wordt gecreëerd. Denk hierbij aan het vastleggen van activiteiten m.b.t. selectie en waardering en bewaartermijnen . Specifieke activiteiten binnen deze pilot die geregistreerd kunnen/moeten worden in een activiteitenplan zijn: 1. Datum van overdracht, c.q. overbrenging 2. Datum veranderingen in openbaarheidsregime 3. Datum veranderingen vertrouwelijkheid 4. Datum veranderingen gebruiksrechten Hoe dit het beste gerealiseerd kan worden zal in een vervolgtraject onderzocht moeten worden, ook omdat dit niet alleen het AV-materiaal raakt, maar ook de ander digitale informatie van de Tweede Kamer. 5.4.5 Metadata met betrekking tot de geschiedenis van activiteiten. Deze metadatagroep heeft betrekking tot de geschiedenis van de activiteiten. De metadata documenteren het spoor van eerdere archiefbescheiden, activiteiten of andere acties die ten aanzien Versie 1.0 Pagina 37 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT van zowel het record als de bijbehorende metadata zijn uitgevoerd. De elementen specificeren voor elke activiteit het activiteittype, wat er is gebeurd, wanneer dit heeft plaatsgevonden, waarom dit heeft plaatsgevonden en wie het heeft uitgevoerd. De basisfunctie van deze metadata is dan ook de volgende: het aantonen dat het record door de tijd heen zijn authenticiteit heeft behouden. Dit wordt gedaan door het documenteren van het aanmaken van het record en de metadata, evenals alle belangrijke activiteiten die daarna hebben plaatsgevonden ten aanzien van het record en de metadata. De volgende elementen moeten vastgelegd worden: - Activiteit identificatiekenmerk (O) – uniek identificatiekenmerk van de activiteit Datum/tijd activiteit (V) – Datum (en optioneel de tijd) waarop de activiteit heeft plaatsgevonden Activiteittype (V) – Soort activiteit (creatie record, registratie record etc.) Beschrijving activiteit (O) – beschrijving van de activiteit Activiteit relatie (V) – informatie over de actor (en het mandaat) die de activiteit heeft uitgevoerd Conclusies en Aanbevelingen Binnen de pilot worden deze gegevens nog niet vastgelegd. Het vastleggen van deze gegevens begint bij de Tweede Kamer, maar ook Beeld en Geluid en het Nationaal Archief zullen activiteiten moeten vastleggen. Daarnaast moet het systeem de mogelijkheid bieden om reeds bestaande metadata m.b.t. de activiteiten geschiedenis (of eventgeschiedenis) vast te leggen of te behouden. Het e-Depot van het Nationaal Archief heeft de mogelijkheid tot vastleggen van activiteitengeschiedenis voor zowel de metadata als het record. Bij de Tweede Kamer en Beeld en Geluid zal onderzocht moeten worden hoe dit kan. Naast het technische gedeelte (het daadwerkelijke vastleggen van de metadata) geven de events die vastgelegd moeten worden een goede indicatie/aanknopingspunt m.b.t. inhoudelijk punten die verder uitgewerkt moeten worden. De volgende activiteiten moeten in ieder geval vastgelegd worden: 1. Registratie van de vergadering in een registratiesysteem (Parlis?) 2. Creatie van het Record (VLOS-document en essence) 3. Normalisatie/migratie van de essence – in de pilot werd de essence uiteindelijk in een MXF-format volgens de archiefstandaarden van Beeld en Geluid getranscodeerd. Deze slag zal bij een operationeel proces niet nodig zijn, dan is de Tweede Kamer in staat zelf het goede format aan te leveren. 4. Instroom essence en metadata (zowel bij Beeld en Geluid als bij de Tweede Kamer) 5. Controle en Akkoord na instroom 6. Vastleggen toekomstige beheeractiviteiten: migraties, controles etc. In onderstaande afbeelding is geprobeerd dit schematisch weer te geven. Veel punten zijn nog open en er is verder onderzoek voor nodig. Daarnaast hangt aan het registreren van deze activiteiten ook het inregelen van werkprocessen en het aanwijzen van verantwoordelijkheden. Bij elke activiteit moet ook de verantwoordelijke actor en het mandaat wat deze actor heeft, worden geregistreerd. Versie 1.0 Pagina 38 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 1. Registratie in ParlisID 3. Normalisatie migratie van Essence 2. Creatie Record (Vlosdocument + essence) Verwijderen essence (blijft vlosdocument bewaard na opmaken officiele verslag?) 4. Instroom Essence in DFI 5. Controle en Akkoord 4. Instroom Metagegevens iMMix 5. Controle en Akkoord Afspraken Instroom worden vastgelegd in een “Transfer Agreement” Afspraken verantwoordelijkheden Afspraken triggers Etc. Instroom Vlosdocument + extra metagegevens TK zorgdrager Tweede Kamer zorgdrager, Beeld en Geluid beheerorganisatie. Controle en Akkoord Vastleggen toekomstige beheeractiviteiten: - migratie - controle op integriteit - etc. Toestemming aan zorgdrager voor uitvoeren beheeractie die de digitale informatie veranderen (bijv migratie) Controle Relatie Akkoord O.K Afbeelding 14: Vast te leggen activiteiten 5.4.6 Metadata met betrekking tot relatie Relatie bevat metadata die twee of meer entiteiten (kunnen ook meerdere records zijn) met elkaar verbinden. Een relatie kan ook als aparte entiteit beschouwd/geïmplementeerd worden (meerdere entiteitenmodel) Binnen de pilot is de relatie niet als aparte entiteit beschreven. Daarom behoren de metadata van de relatie als gekoppelde metadata beschouwd te worden en als groep beheerd te worden. Relaties behoren wederkerig te zijn, dat wil zeggen dat de omgekeerde relatie in het gerelateerde record aanwezig behoort te zijn. Ten minste de volgende metadata zijn nodig om een relatie te definiëren: - Identificatiekenmerk van het gerelateerde record – een koppeling naar de identiteit van de gerelateerde entiteit, met als doel de gerelateerde objecten nauwkeurig te kunnen identificeren Type relatie – Geeft op een eenduidige manier de aard van de relatie en de rol van de specifieke gekoppelde entiteit in de relatie weer. Datum relatie – begindatum, en indien relevant, de einddatum van de betreffende relatie. In het geval van de pilot beschrijven/leggen we relaties met ander Records (en aggregatieniveaus). Versie 1.0 Pagina 39 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT VergaderID Activiteithoofdsoort Er moet nagedacht worden over hoe de relatie/ context met de documenten en registratie in deze systemen behouden kan worden. ParlisID Dossiernr Stuknummer Ergens moet nog de relatie met de tijdcode (opgeslagen in het volldige Vlosdocument) ID essence TaakID Relatie met: - Officieel gepubliceerde handelingen die overgebracht worden naar het Nationaal Archief. - Zaken/documenten (met ID) die behandeld worden in de vergadering. Afbeelding 15: Relaties Conclusies en aanbevelingen: Binnen de pilot kunnen relaties gelegd tussen de verschillende records en metadata. Daarbij zijn wel de volgende aandachtspunten: - Relaties dienen wederkerig te zijn. Relaties moeten ook in de toekomst geborgd worden. Het identificatiekenmerk wat toegekend wordt aan de essence en de metagegevens wordt gegenereerd buiten het systeem. Dit is niet ideaal (zie hfst. 5.4.1 metadata m.b.t. identiteit) Versie 1.0 Pagina 40 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 6 BESCHIKBAARSTELLING EN UITLEVERING Bestanden van de Tweede Kamer die zijn ingestroomd in de catalogus van Beeld en Geluid zijn op verschillende manieren te zien en te bestellen voor hergebruik. Na instroom wordt er van alle originelen, de Hoge Resolutie MXF-bestanden een browsing-kopie gemaakt in MPG1-formaat (Lage Resolutie) en een set keyframes. Via de zoek- en bestelomgeving van iMMix Extranet kan gezocht worden op velden als titel, beschrijving, trefwoord en datum en kunnen browsing-kopieën bekeken worden. Alleen partijen die aangesloten zijn op dit extranet hebben toegang tot dit materiaal. Om op het extranet te komen, is tevens een persoonlijk account nodig dat gekoppeld is aan de functie en de rol van de persoon. Met de juiste rechten kan ook materiaal besteld worden. Het is mogelijk om het materiaal te bekijken en aan de hand van de keyframes te springen naar een bepaald moment in de video. Wanneer geschikt materiaal is gevonden kan dat toegevoegd worden aan een winkelwagentje. Aan de hand van de tijdcode kan ook een fragment van het materiaal besteld worden door de speciale partial-restore-functie binnen de gebruikte storagemanagementoplossing DIVArchive. Afhankelijk van de prioriteit wordt het materiaal geleverd zodra lopende bestellingen zijn afgeleverd (prioriteit midden) of 's nachts (prioriteit laag). Materiaal kan, behalve in het bronformaat, ook in verschillende andere formaten uitgeleverd worden. Ook is het mogelijk om het materiaal afgeleverd te krijgen op verschillende manieren. De basisfunctionaliteit voorziet in het downloaden van de file via ftp of het laten versturen van de file naar een ftp-server. Om van deze laatste optie gebruik te maken moet wel Beeld en Geluid de FTP-server toevoegen aan de beheerde lijst van FTP-servers. Deze faciliteit is opgezet voor de Tweede Kamer. Tenslotte is het ook mogelijk om materiaal op DVD of analoge dragers te bestellen. In deze fase is door de Tweede Kamer aangegeven nog geen behoefte aan uitlevering aan derden door Beeld en Geluid te hebben. Het doel is om de beelden zodanig op te slaan bij Beeld en Geluid dat uiteindelijk een formele overdracht aan het Nationaal Archief in de toekomst gerealiseerd kan worden. Pas later in 2014 zal meer duidelijk worden over de wensen en eisen ten aanzien van beschikbaarstelling aan derden. Waarschijnlijk zal het op het volgende neerkomen. De Tweede Kamer zal beelden voor de korte termijn vanuit het te ontwikkelen beeldmagazijn/debat gemist raadplegen. Op de lange termijn vanuit de iMMix catalogus, daar is in de toekomst immers het enige geldende archiefexemplaar. De Tweede Kamer zal wat raadpleegwensen betreft niet erg afwijken van derden die de iMMix catalogus gebruiken. Wat mogelijk moet zijn is dat beelden die alleen nog in de iMMix catalogus staan in zijn geheel terug te halen moeten zijn naar de Tweede Kamer wanneer beeld weer actueel wordt. Aandachtspunten bij de beschikbaarstelling en uitlevering zijn: - Rechthebbenden van de beelden uit de plenaire zaal zijn de partners in het samenwerkingsverband NOS, RTL, ROOS en TK. Zij zijn producenten van het plenaire beeld. Wanneer een vergadering ongesegmenteerd aangeboden is aan de iMMix-catalogus is dit nadelig voor de gebruiksvriendelijkheid, vergaderingen kunnen een lengte van 10 uur hebben. - Versie 1.0 Pagina 41 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT 6.1.1 Gaps – Beschikbaarstelling en uitlevering 1. Afspraken over de door Beeld en Geluid te leveren “Quality of Service”. Bijvoorbeeld, binnen welk tijdspad kunnen moeten de bestanden na opname beschikbaar zijn? 2. Is er behoefte aan webstreaming van de ingestroomde vergaderingen? Binnen het programma Collectie Online wordt bij Beeld en Geluid gewerkt aan een streamingservice. Deze service maakt het mogelijk dat (MXF)-bestanden automatisch worden gedownload en getranscodeerd, met als eindresultaat een vrij te embedden player. Deze player kan de Tweede Kamer of het Nationaal Archief embedden op eigen websites en eventueel customizen met logo’s en dergelijke. Afbeelding 16: Beeld en Geluid catalogus iMMix Versie 1.0 Pagina 42 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT BIJLAGE A - SPECIFICATIES VAN ESSENCE (BEELDMATERIAAL) De volgende video formats kunnen direct in de Beeld en Geluid catalogus instromen: x x x MXF D10-30 MXF D10-50 XDCAM HD422 MXF D10-30 en MXF D10-50 worden voornamelijk gebruikt voor SD-video en zijn in geval van Tweede Kamer beeldmateriaal dus niet van toepassing, omdat in de Tweede Kamer al het beeld in HD wordt vastgelegd. De aanbieder moet er voor zorgen dat de aangeleverde MXF aan de requirements voldoet en door Ericsson gecertificeerd is. Hiertoe voert Ericsson een MXF Check uit op een door aanbieder aan te leveren testfile. De Tweede Kamervideobestanden zijn deze MXF Check inmiddels gepasseerd, waardoor deze instroom gecertificeerd kan worden, en klaar kan worden gemaakt voor automatische instroom. De MXF-files moeten voldoen aan dezelfde naamsconventie als de XML-files, de eerste 13 tekens van de bestandsnaam moeten uniek zijn binnen de aangeleverde batch. De aan te leveren MXF-bestanden moeten technisch voldoen aan onderstaande standaarden. De afspraken die binnen de omroepketen zijn gemaakt rondom implementatie van de MXF-standaard zijn leidend in het handhaven van de standaard. Onderstaande informatie is specifiek voor de leverancier van de MXF-bestanden. MXF (Material eXchange Format) Operational Pattern OP1a Materiaal moet geëncodeerd zijn als MXF, D10-30 of D10-50, de standaard van de DDV, op basis van de SMPTE- richtlijnen: x x x x SMPTE 377M / MXF File Format Specification. SMPTE 378M / Operational pattern OP1a, single item single package; geen open MXF-files, partitions mogen zowel “complete” als “incomplete” zijn. SMPTE 386M / MXF Mapping D-10 Essence Data to the MXF Generic Container. SMPTE 356M / Type D10 Stream Specifications – MPEG-2 4:2:2P@ML for 525/60 and 625/50; Aanvullende specificaties: x x x x Op die plaatsen waar er in deze SMPTE documenten onderscheid gemaakt wordt tussen de PAL(625/50) en de NTSC(525/60) norm, moet worden gekozen voor de PAL-variant. Alleen bitrates van 30 en 50 Mbit/s worden ondersteund, 40 wordt geweigerd. “open” mxf files zijn niet toegestaan; Partitions mogen zowel “Complete” als “Incomplete” zijn. De tijdcode van het AV-materiaal wordt gedefinieerd door de Timecode Track in de Material Package van de MXF file, zoals beschreven in EBU Rec-122 Algemene specificaties voor SD en HD: x MXF OP1a: SMPTE 377, 378 en 379 Versie 1.0 Pagina 43 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT x Tijdcode volgens EBU Rec 122, met als belangrijkste randvoorwaarde dat de tijdcode aan het AVmateriaal wordt gedefinieerd door de Timecode Track in de Material Package van de MXF-file. Subspecificaties voor HD 1080i/50 (50 fields per seconde) XDCAM HD422 (SMPTE 381, SMPTE 382, XDCAM_MXF_HD422_v080) Referentielijst MXF-standaarden: De SMPTE standaarden zijn: x x x x x x SMPTE 377M, for Television: The Material Exchange Format (MXF) File Format Specification SMPTE 378M, for Television: MXF Operational Pattern 1a (Single Item, Single Package) SMPTE 379M, for Television: The MXF Generic Container SMPTE 381M, for Television: Mapping MPEG streams into the MXF Generic Container SMPTE 382M, for Television: Mapping AES3 and Broadcast Wave Audio into the MXF Generic Container SMPTE 386M, for Television: Mapping Type D-10 Essence Data to the MXF Generic Container De EBU Rec 122 is te vinden op onderstaande link x http://www.ebu.ch/CMSimages/en/tec_text_r122-2007_tcm6-50027.pdf De specificatie voor XDCAM HD422 bestaat uit: x x x MPEGHDv120_20080313.pdf – Mapping Type MPEG HD / MPEG HD422 and AES3 Audio Essence to the MXF Generic Container, version 1.20 XDCAM MXF Metadata Correction 20080201_rev1.pdf – Corrections to the metadata description of MXF files generated by XDCAM (rev.1) 4 XDCAM_MXF_HD422_v080.pdf – MXF for XDCAM HD422, 31 Aug. 2007 Versie 1.0 Pagina 44 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT BIJLAGE B - SPECIFICATIES VAN NAAMGEVING AANGELEVERDE BESTANDEN Import van digitale bestanden bij Beeld en Geluid loopt via de DFI (Digitale File Importer). Om te zorgen dat essence en metadata goed gekoppeld kunnen worden, is het ten eerste belangrijk om rekening te houden met de regels rondom naamgeving die gelden binnen de DFI. Tijdens de import van digitale collecties wordt de essence (MXF) gekoppeld met de beschrijving die al eerder is geïmporteerd in de catalogus op basis van aangeleverde xml. Het koppelingmechanisme bestaat uit een zogenaamde trigger-XML waarin door middel van id’s de link wordt gelegd met het juiste metadatarecord en tijdelijke drager. Het is namelijk de bedoeling dat de tijdelijke drager die bij import van de metadata is aangemaakt uiteindelijk wordt vervangen door de daadwerkelijke essence zodat deze te bekijken en te bestellen is vanuit de catalogus. Door middel van het aanmaken van beheerhandelingen bij een tijdelijke drager binnen een metadatarecord in de catalogus worden de triggerxml-en gegenereerd. Zodra de triggerxml is geplaatst op de DFI zoekt het proces van de DFI een MXF-bestand met dezelfde naam als die van de triggerxml maar met een andere extensie. De naam van de triggerxml is gebaseerd op de naamgeving van de tijdelijke drager. Het is dus essentieel dat de naam van de MXF in de aangeleverde xml precies overeenkomt met de naam van de aangeleverde essence, alleen de extensie is verschillend. Ieder aanbieder krijgt een creator code toegewezen, deze maakt een verplicht deel uit van de filenaam. In het geval van de Tweede kamer wordt dit ‘TKP’ Naamsconventie - voorbeeld essence (MXF) De naamgeving bestaat uit [A-Z0-9_-]{13}-TKP.mxf, dat wil zeggen dertien willekeurige tekens die mogen bestaan uit hoofdletters, cijfers, verbindingsstreepjes en underscores plus de toevoeging van de creatorcode ‘-TKP’ plus extensie ‘.mxf’. Het is belangrijk dat de eerste 13 posities uniek identificerend zijn binnen een aangeleverde batch zodat voorkomen wordt dat tijdelijke dragers en bijbehorende triggerxml-en dezelfde naam krijgen. Versie 1.0 Pagina 45 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT BIJLAGE C - MOGELIJKHEDEN EN STANDAARDEN DUURZAME OPSLAG BIJ BEELD EN GELUID Hieronder wordt beschreven welke typen formaten Beeld en Geluid standaard opslaat en welke storage-faciliteiten daarvoor gebruikt worden, met opslag op LTO-tape als eindresultaat. Dit weerspiegeld de stand van zaken bij Beeld en Geluid in November 2013 Standaard bestandsformaten bij Beeld en Geluid Bij Beeld en Geluid zijn meerdere storagecomponenten gelijktijdig in gebruik die gedeeltelijk van elkaar verschillen in functionaliteit en in de manier waarop ze worden ingezet binnen de gehele architectuur. De storageoplossingen bedienen verschillende typen materiaal en verschillende typen functionaliteit richting de eindgebruikers: Type Doel Storagemgmt. Uitleveren via iMMix? MXF D10-30 Video DIVArchive Ja MXF D10-50 Video DIVArchive Ja XDCAM-HD Video DIVArchive Ja MPG-1 Video Uitleverformaat voor productie- en uitzenddoeleinden Uitleverformaat voor productie- en uitzenddoeleinden Uitleverformaat voor productie- en uitzenddoeleinden (HD-materiaal) Browsekopie t.b.v. iMMix-Extranet MediaArchive Nee DPX Video Digitale masterkopie voor filmscans Stornext Nee Formaat Typen storagemanagement en formaten DIVArchive MXF bestanden worden opgeslagen binnen DIVArchive. Dit systeem is het managementsysteem dat opslag naar verschillende storagelocaties regelt. MXF bestanden worden de eerste twee weken opgeslagen op een disk cache om snelle uitlevering van recent materiaal te kunnen waarborgen. Dit gebeurt op een Isilon cluster dat bestaat uit een RAID 60 opstelling van harde schijven. Tegelijkertijd zorgt DIVArchive de opslag van de bestanden naar de StorageTek tape library op locatie in de media gateway op het Mediapark en voor replicatie naar een zelfde Tape library op locatie bij Beeld en Geluid. De Tape library bij Beeld en Geluid dient als een fail-over wanneer de Tape library bij Ericsson mocht uitvallen. DIVArchive zorgt tevens voor uitlevering naar iMMix Extranet zodat alle bestanden die binnen deze constructie worden opgeslagen ook direct besteld kunnen worden. DIVArchive is mediaaware wat in dit geval betekent dat er ook delen uit de MXF besteld kunnen worden (partial file retrieval). Browsingkopieën Versie 1.0 Pagina 46 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT MPG1- en MP3-browsingkopieën worden opgeslagen op een vergelijkbaar Isilon cluster als hierboven benoemd en worden gerepliceerd naar eerdergenoemde Isilon cluster voor fail-over-doeleinden. Een back-up naar tape wordt ook gedaan voor alle browsingkopieën. Ondanks het feit dat deze bestanden lage-resolutie afgeleiden zijn van de masterbestanden wordt er toch voorzien in verschillende backupmaatregelen vanwege de investeringen in tijd en kosten die gedaan zijn om deze afgeleiden te maken. Browsebestanden kunnen niet worden besteld maar wel worden bekeken via Extranet. Deze browsingkopieën worden automatisch aangemaakt als onderdeel van high-res importservice. In het geval van de UB, betekent dit dat reeds eerder gemaakte afgeleiden niet hoeven worden aangeleverd. Deze worden opnieuw gemaakt ten behoeve van het beschikbaar stellen. Stornext Ander typen bestanden dan MXF (bijv. DPX-masterbestanden) worden opgeslagen door de software van de Stornext Hierarchical Storage Manager. Deze oplossing bevat een online disk cache voor tijdelijke opslag en zorgt voor archivering van de bestanden naar de nearline StorageTek-tape library bij Beeld en Geluid. Het is, als extra dienst, mogelijk dat back-ups op offline tapes bewaard worden op locatie in Rijswijk. In tegenstelling tot DIVArchive, kunnen bestanden in Stornext niet direct besteld worden via iMMix Extranet en is er geen partial file retrieval mogelijk. Bestanden kunnen vanaf Stornext benaderd worden via een FTP-server met een directory listing. Het ophalen van het bestand is afhankelijk van de bestandsgrootte en de activiteiten van de tape-robot op dat moment, maar er is geen wachttijd en de server is 24/7 beschikbaar. Duurzame en beveiligde opslag Beveiliging Beeld en Geluid biedt een duurzame en beveiligde storageomgeving. Hiervoor zijn tenminste de volgende beveiligingsmaatregelen genomen: x x x x x x x x In de storageomgeving is een alarmsysteem aangebracht voor diefstal en brand, dat in verbinding staat met een beveiligingsorganisatie/ politie en brandweer. De storageomgeving beschikt over een hoogwaardige electra-, UPS- en noodstroom voorziening die ervoor zorgt dat bij stroomuitval de beschikbaarstelling kan worden gecontinueerd. De apparatuur staat op een fysiek beveiligde locatie om toegang van onbevoegden tegen te gaan. De Beeld en Geluid infrastructuur is een gesloten systeem: cliënt en derden hebben geen toegang tot afgeschermde onderdelen van het systeem, en hebben geen mogelijkheid om beveiligde applicaties, configuraties en of data in te zien, te veranderen of te verwijderen. De servers zijn op afstand bereikbaar door middel van een beveiligd (encrypted) kanaal over internet. Afscherming door accounts te beveiligen met gebruikersnaam en wachtwoord en voorzien van IP restricties. De import van data is beveiligd door middel van HTTPS. Toegang tot systeemsoftware, -configuratie en user data is beveiligd door middel van een zogenaamde RSA key. Versie 1.0 Pagina 47 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT x x x x Transmissie (anders dan importeren en downloaden) van audiovisueel materiaal is beveiligd met hoogwaardige encryptie. Cliënt en derden zijn niet gerechtigd wijzigingen aan te brengen in de centrale netwerkvoorzieningen of de geleverde software. De infrastructuur is beveiligd door middel van een firewall. Anti-virus software is geïnstalleerd op de clients en servers. Duurzaam beheer van AV-collectie Ter beperking van het risico van verlies van digitaal audiovisueel materiaal worden de volgende maatregelen genomen: x x x x x Beeld en Geluid maakt van alle systemen (webapplicaties, databases, zoeksoftware en besturingsystemen) een back-up. Inclusief het audiovisueel materiaal en de Metadata zelf. Ten behoeve van de continuïteit van de dienstverlening wordt een restore geleverd. Dagelijks vindt een back-up plaats van het audiovisueel materiaal en de metadata en wekelijks worden de back-up tapes fysiek op een andere beveiligde locatie dan de storageomgeving van Beeld en Geluid ondergebracht: er worden offsite back-ups bewaard en data van Beeld en Geluid gaan op tape naar externe datakluis. De MXF wordt redundant opgeslagen, in 2 robot systemen die fysiek gescheiden zijn. Van de DPX wordt 1 kopie opgeslagen in de robot en 1 kopie geëxternaliseerd. Beeld en Geluid controleert dagelijks of de geplande back-up procedure volledig en juist is verlopen. In het geval van calamiteiten, die tot gevolg hebben dat de gehele back-up moet worden teruggeplaatst, kan de restore doorlooptijd meerdere dagen duren. Beeld en Geluid zal zich maximaal inspannen om de doorlooptijd zoveel mogelijk te bespoedigen.. Beeld en Geluid gebruik industriestandaarden voor de digitale archivering. Voor de opslag van data (de datarobot) is gekozen voor de het enterprise type van de Oracle Storagetek SL8500. De gebruikte tape technologie (LTO) is een industrie standaard. Langdurige support voor deze technologie is mogelijk door middel van een technische roadmap die hiervoor beschikbaar is. De gebruikte Hierarchical Storage Manager (DIVA) software is een veel gebruikte standaard binnen de archiefwereld en is met name ontwikkeld voor de opslag van AV-materiaal. Opslag en toegang Uiteindelijk komen alle bestanden terecht in de taperobot (StorageTek SL8500) met mogelijke tape back-ups off site op de plank. Het verschil zit in het feit dat DIVArchive media aware is en daarnaast gelinkt is aan de database en iMMix (wat tevens zorgt voor toegang). Stornext is slechts geschikt voor platte opslag van data, ongeacht het type data of de inhoud. Naast opslag is toegang vaak een prioriteit voor gebruikers. Dit wordt gegarandeerd door de vindbaarheid en snelle uitlevering van bestanden. Dit betekent voor Beeld en Geluid dat bestanden en titels in iMMix geregistreerd en gekoppeld moeten worden met de juiste technische informatie over de drager (nummer, dragertype, etc). Om deze koppeling te kunnen maken, is DIVArchive de enige optie voor storagemanagement. Versie 1.0 Pagina 48 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT BIJLAGE D - JARGONMATRIX Term Eventuele Equivalenten Tweede Kamer Nationaal Archief CC Connect DFI CC Connect DVR DVR Essence Beeldmateriaal FRBR Metadata model Gegevensmagazij n Versie 1.0 Beeld en Geluid DFI Beeldmateriaal Uitleg Centraal koppelvlak voor informatie-uitwisseling. Via het koppelvlak worden applicaties met bijbehorende gegevensverzamelingen aan elkaar gekoppeld. Daarbij wisselen de aangesloten systemen gegevens met elkaar uit en bieden ze elkaar onderling services aan. Digitale File Importer Dienst Verslag en Redactie (stenografische dienst, maken de verslagen van de vergadering) Geluids- en beeldmateriaal, digitaal of fysiek, wordt ook wel essence genoemd. Samen met beschrijvende metadata heet het “content”. Wanneer er ook het recht is om het te gebruiken is er sprake van “assets”. Conceptuele basis van het metadatamodel waarop de Beeld en Geluid catalogus iMMix is gebaseerd Een centraal opslagsysteem waar parlementaire data samenkomt vanuit verschillende bronsystemen en volgens een standaard data model wordt opgeslagen. Het streven is de veelheid aan informatie volledig, eenduidig en in samenhang beschikbaar Pagina 49 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT te stellen voor diverse (toekomstige) doeleinden. GMI GMI GUCI HD iMMix MAM MAM MAM MXF PARLIS Parlementair informatiesysteem SDB SDB TDR SDB Versie 1.0 TDR Generieke Metadata Importer Global Unique Clip Identifier. Unieke identifier voor essence binnen Beeld en Geluid archief High Definition video formaat Beeld en Geluid multimediale Catalogus Media Asset Management Systeem. Systeem wat wordt gebruikt voor het opslaan, beheren en distribueren van digitale audiovisuele bestanden Material Exchange Format (container formaat voor uitwisseling en opslag van audiovisueel materiaal) Parlementair informatiesysteem, waarin alle parlementaire stukken ondergebracht zijn,. Griffie gebruikt parlis om vergaderingen voor te bereiden. Safety Deposit Box Software ontwikkeld door Tessella gebaseerd op het OAIS model en die door het NA wordt gebruikt voor het e-Depot Trusted Digital Repository, set van regels en afspraken die een betrouwbare toegang tot digitale bescheiden garandeert, ook op lange Pagina 50 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT termijn Toepassingsprofi el Rijk VLOS Versie 1.0 Het toepassingsprofiel bevat rijksbrede afspraken en beschrijft hoe ministeries deze afspraken kunnen toepassen bij het inrichten van hun digitale informatie systemen. Het toepassingsprofiel is gebaseerd op de Richtlijn Metadata Overheidsinformatie en bevat een minimumset van verplichte metadata. Deze Richtlijn is op haar beurt weer gebaseerd op de in Nederland als norm gestelde eisen voor een volledige recordsmanagementmetadataset die staan in de NEN-ISO 23081 standaard voor Metadata. Verslaglegging Ondersteunend Systeem, Dienst Verslag en Redactie brengt markeringen tijdens het debat aan zodat het verslag sneller gemaakt kan worden. Pagina 51 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT BIJLAGE E - VLOS METADATA TEMPLATE GESEGMENTEERDE DEBATDAG ALGEMEEN DEEL (Template-algemeen deel_incl eindtabs_excl_Selecties_versie_2.1.xml ) (expressie excl. selectie) <?xml version="1.0" encoding="UTF-8" ?> - <!-versie="2.1" datum="dinsdag 6-11-2013" auteur="Roger Krom" Aanvullingen t.b.v. de levering van een volledig vergaderdering van een bepaalde dag toevoeging <Expressie><ReeksMatch><TaakId> "4897914 Hele debatsdag" --> - <!-versie="2.0" datum="dinsdag 8-10-2013" auteur="Roger Krom" <Context><Debat-ID>TKP@</Debat-ID> -> <Context><Contekst>Debat-ID: TKP@</Contekst> <Annotatie> verplaatst naar onderdeel van <Niveau> (stond bij Expressie) <Expressie><Descriptie><Titel HoofdtitelIndicatie="1"> weglaten in get geval van <activiteit soort="Vragenuur" of "Stemmingen"> De "verzameltitel" hiervoor wordt verzorgd door <Expressie><Reeksmatch><TaakID> en per Selectie is er een afzonderlijke hoofd- en alternatieve titel Bij Plenaire en Interpellatiedebatten een hoofdtitel en een alternatieve titel (vooralsnog geen titel bij de selectie(s), later plaats voor termijnaanduiding) <Titel HoofdtitelIndicatie="1"><Tekst>@</Tekst> = [vlosdocument/vergadering/activiteit/titel] <Titel HoofdtitelIndicatie="0"><Tekst>@</Tekst> = [vlosdocument/vergadering/activiteit/onderwerp] <Type>alternatieve titel</Type> --> - <!-versie="1.2" datum="dinsdag 9-9-2013" auteur="Roger Krom" <Context><Contekst>TKP@-TKP</Contekst> -> <Context><Debat-ID>TKP@</Debat-ID> <Publicatie><Annotatie> verplaatst naar <Expressie><Annotatie> Onderdeel van <Selectie> : <Context><Contekst>https://zoek.officielebekendmakingen.nl/h-tk-@@@@.html</Contekst></Context> (1 of meer) komt vooralsnog te vervallen (bij Selectie). Het alternatief moet nog worden besproken. --> - <!-versie="1.1" datum="dinsdag 30-7-2013" auteur="Roger Krom" * Element <Tekst> binnen <Publicatie><Annotatie> is niet nodig. De "tekst" kan in zijn geheel binnen <Annotatie> geplaatst worden --> - <!-versie="1.0" datum="maandag 29-7-2013" auteur="Roger Krom" --> - <GMI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="F:\ICT\Projecten\DFI\GMI\Klant 23 - 2eKamer\Export\gmi.xsd"> Versie 1.0 Pagina 52 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT - <Expressie MatchCondition="Add" MultiplematchCondition="AddToFirstMatch" DFI_leverancier="TK"> - <ReeksMatch MultiplematchCondition="AddToFirstMatch"> <TaakId>@</TaakId> - <!-Id op basis van debatsoort en lijst NIBG, hier het Id van [activiteit/@soort="vragenuur"] Afhankelijk voor het debattype is dit een ander ID: 4739726 4739793 4739800 4739804 4739808 4739813 4739833 4758446 4758447 4758448 4758449 4758450 4758451 4758452 4758453 Vragenuur Opening Mededelingen Hamerstukken Interpellatiedebat Plenair debat Stemmingen Regeling van werkzaamheden Beëdiging Herdenking Verklaring Afscheid Aanbieding Overig Sluiting 4897914 Hele debatsdag --> </ReeksMatch> <Tijdsduur>@</Tijdsduur> - <!-berekend in milliseconden 1000 * ((aantal uur * 3600) + (aantal minuten * 60) + (aantal seconden)) [vlosdocument/vergadering/activiteit/aanvangstijd] [vlosdocument/vergadering/activiteit/eindtijd] eindtijd minus begintijd met vooraf omrekening naar milliseconden voorbeeld: 14:52:45 -> 1000 * ((14 * 3600) + (52 * 60) + (45))= 53565000 14:00:29 -> 1000 * ((14 * 3600) + (00 * 60) + (29))= 50429000 --> - <Descriptie> - <Titel HoofdtitelIndicatie="1"> - <!-default "1" op het niveau van expressie --> <Tekst>@</Tekst> - <!-= [vlosdocument/vergadering/activiteit/titel] --> </Titel> - <!-Bij Vragenuur en Stemmingen <Titel> weglaten, omdat hierin wordt voorzien bij de Selecties --> Versie 1.0 Pagina 53 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT - <Context> <Contekst>Debat-ID: TKP@</Contekst> - <!-DebatID tbv Tweede Kamer gebruik = Debat-ID: + spatie + bestandsnaam exclusief -TKP en de extentie (xml / mxf) TK + P + vergaderjaar (4 posities, biv 1213) + vergaderingnummer (3 posities, incl. evt. voorloopnullen) + activiteitvolgnummer (2 positie, incl. evt. voorloopnul) !!! + deel (=beeldfragment)? Vervalt indien van een gesplitst debat maar 1 xml wordt aangeleverd (identiek aan <Expressie> -> <Selectie> <Positie> -> <Drager> -> <Archiefnummer> minus -TKP en de extensie " .mxf ") Debat-ID: TK + P + vergaderjaar (4 posities, biv 1213) + vergaderingnummer (3 posities, incl. evt. voorloopnullen) + activiteitvolgnummer (2 positie, incl. evt. voorloopnul) + deel (=beeldfragment) --> </Context> - <Niveau MatchCondition="Add" MultiplematchCondition="AddToFirstMatch" intentie="Professioneel" taal="Nederlands"> <Annotatie>Kamer:@ Vergaderingsoort:@ Vergaderjaar:@ Vergaderingnummer:@</Annotatie> - <!-Wordt als Annotatie opgenomen in de NIBG-catalogus Kamer : <vergadering/@kamer Vergaderingsoort : : <vergadering/@soort Vergaderjaar : [vlosdocument/vergadering/vergaderjaar] Vergaderingnummer : [vlosdocument/vergadering/vergaderingnummer] is bedoeld om de verschillende onderdelen op steeds een nieuwe regel te plaatsen (carridge return + linefeed) --> - <Taaklijst indicatie_pushen="1"> <AangemaaktDoor>GMI</AangemaaktDoor> <Status>Nieuw</Status> <NogToewijzen>0</NogToewijzen> <Spoed>0</Spoed> <Teruggezet>0</Teruggezet> <Werkvoorraad>Tweede Kamer</Werkvoorraad> <Beschrijvingsdiepgang>uitgebreid beschreven (niv. 3)</Beschrijvingsdiepgang> </Taaklijst> </Niveau> </Descriptie> - <Publicatie MatchCondition="Add" MultiplematchCondition="AddToFirstMatch"> <Titel>@</Titel> - <!-= [vlosdocument/vergadering/titel] bijvoorbeeld: 100e vergadering, woensdag 26 juni 2013 Versie 1.0 Pagina 54 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT --> <Type>Uitzending</Type> <Begindatum>jjjj-mm-dd</Begindatum> - <!-onderdeel van [vlosdocument/vergadering/datum] notatie is jjjj-mm-dd Dit is anders dan vanuit VLOS aangeleverd --> <DistributieKanaal>televisie</DistributieKanaal> <Zendgemachtigde>Tweede Kamer</Zendgemachtigde> - <Positie MatchCondition="Add" MultiplematchCondition="AddToFirstMatch"> <Begintijd>@</Begintijd> <Eindtijd>@</Eindtijd> - <!-gelijk aan <DragerBegin> en <DragerEind> Vooralsnog is deze oplossing tijdelijk en zal er later naar deze wellicht onnodige verdubbeling gekeken worden --> <DragerSoort>Programma</DragerSoort> <DragerBegin>@</DragerBegin> - <!-berekend in milliseconden 1000 * ((aantal uur * 3600) + (aantal minuten * 60) + (aantal seconden)) [vlosdocument/vergadering/activiteit/aanvangstijd] = aanvangstijd eerst activiteit (opening) --> <DragerEind>@</DragerEind> - <!-berekend in milliseconden 1000 * ((aantal uur * 3600) + (aantal minuten * 60) + (aantal seconden)) [vlosdocument/vergadering/activiteit/eindtijd] = eindtijd laatste activiteit (sluiting) --> - <Drager MatchCondition="AddConnect" MultiplematchCondition="AddToFirstMatch"> <Archiefnummer>[email protected]</Archiefnummer> - <!-Ook aanwezig als <Archiefnummer> binnen de Selectie DebatID tbv Tweede Kamer gebruik (identiek aan <Expressie> -> <Context> -> <Debat-ID> zonder Debat-ID: en met -TKP + de extensie " .mxf ",) TK + P + vergaderjaar (4 posities, biv 1213) + vergaderingnummer (3 posities, incl. evt. voorloopnullen) + activiteitvolgnummer (2 positie, incl. evt. voorloopnul) + deel (=beeldfragment)+ koppelteken + creatotcode (TKP)+ de extensie .mxf --> <Bewaarplaats>Digitaal Archief</Bewaarplaats> Versie 1.0 Pagina 55 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT - <!-defaults --> <Herkomst>TKP</Herkomst> - <!-defaults --> <Dragertype>BESTAND</Dragertype> - <!-defaults --> <ArchiefnummerBron>[email protected]</ArchiefnummerBron> - <!-identiek aan <Drager> <Archiefnummer> --> <DragerMedium>video</DragerMedium> - <!-defaults --> </Drager> </Positie> </Publicatie> <Selectie /> - <!-Selectie mag volgens de gmi.xsd niet "leeg" zijn. Bij bestanden zonder Selecties moet het lege element worden verwijderd !!! --> - <!-Nadere uitwerking, zie: "Template-Selectie_excl_subselecties.xml" --> </Expressie> </GMI> (Template-Selectie_excl_subselecties.xml) (als mogelijk onderdeel van een expressie) - <Selectie MatchCondition="Add" MultiplematchCondition="AddToFirstMatch"> - <!-versie="2.0" datum="dinsdag 8-10-2013" auteur="Roger Krom" <Descriptie> -> titels uitsluitend bij Vragenuur en Stemmingen zoals aangegeven bij <Titel> Bij debatsoorten zonder Selectie(s) geen lege selectie-element i.v.m. validatie!! Versie 1.0 Pagina 56 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT --> - <!-versie="1.2" datum="dinsdag 9-9-2013" auteur="Roger Krom" Uitsluitend selecties aanmaken voor: * Plenaire debatten en Interpellatie-debatten (dit is er maar 1 zolang er nog niet voor de termijnen afzonderlijke selecties worden aangemaakt) * Vragenuur en Stemmingen * Overige debatsoorten dus geen Selectie(s) aanmaken (ook geen lege selectie-element i.v.m. validatie!!) Onderdeel <Context><Contekst>https://zoek.officielebekendmakingen.nl/h-tk@@@@.html</Contekst></Context> (1 of meer) komt vooralsnog te vervallen. Het alternatief moet nog worden besproken. <SelectieType>item</SelectieType> zolang er geen subselecties zijn is de waarde afhankelijk van het type debat: Vragenuur : <SelectieType>Vraag</SelectieType> Stemmingen : <SelectieType>Stemming</SelectieType> Plenair debat : <SelectieType>Plenair debat</SelectieType> Interpellatiedebat : <SelectieType>Interpellatiedebat</SelectieType> Titelaanduiding en samenstel aanpassen na overleg NIBG <Spreker><Functie>@ - @</Functie> -> <Spreker><Functie>@ @</Functie> (koppelteken vervalt) <Niveau><Beschrijving> vervalt aangezien het een herhaling van de titel is. Onderstaand blijft dan over een leeg element met een aantal attributen: <Niveau MatchCondition="Add" MultiplematchCondition="AddToFirstMatch" intentie="Professioneel" taal="Nederlands"> </Niveau> --> - <!-versie="1.2" datum="maandag 5-8-2013" auteur="Roger Krom" n.a.v. aanpassing omzetregels bij sprekers --> - <!-versie="1.1" datum="dinsdag 30-7-2013" auteur="Roger Krom" Voor de duur van de Pilot: Bij Stemmingen : Alleen bij de eerste Selectie wordt een positie ( = tijdcodes + verwijzing naar de file) opgenomen --> - <!-versie="1.0" datum="maandag 29-7-2013" auteur="Roger Krom" --> <SelectieType>item</SelectieType> - <!-<SelectieType>item</SelectieType> zolang er geen subselecties zijn is de waarde afhankelijk van het type debat: Vragenuur : <SelectieType>Vraag</SelectieType> Stemmingen : <SelectieType>Stemming</SelectieType> Plenair debat : <SelectieType>Plenair debat</SelectieType> Interpellatiedebat : <SelectieType>Interpellatiedebat</SelectieType> --> - <Descriptie> - <Titel HoofdtitelIndicatie="1"> - <!-- Versie 1.0 Pagina 57 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT Uitsluitend bij Vragenuur en Stemmingen --> <Tekst>@</Tekst> - <!-Vragenuur en Stemmingen (<activiteit soort="Vragenuur"> en <activiteit soort="Stemmingen">) <activiteithoofd soort="@" -> <titel> --> </Titel> - <Titel HoofdtitelIndicatie="0"> - <!-Uitsluitend bij Vragenuur en Stemmingen --> <Tekst>@</Tekst> - <!-Vragenuur en Stemmingen (<activiteit soort="Vragenuur"> en <activiteit soort="Stemmingen">) <activiteithoofd soort="@" -> <onderwerp> --> <Type>alternatieve titel</Type> </Titel> - <Rollen> - <!-Uitsluitend bij Plenaire debatten, Interpellatiedebatten en Vragenuur !! Opsomming op basis van de aanwezigheid van <activiteitdeel soort="Spreekbeurt"> --> - <Spreker> - <!-In de volgorde van de werkelijk plaatsgevonden "spreekbeurten". Sprekers kunnen daardoor meer dan 1 keer voorkomen (in het geval van een veelheid aan termijnen) --> <Naam>@</Naam> - <!-op basis van [activiteitdeel/@soort="Spreekbeurt"/spreker/aanhef]> + spatie + [activiteitdeel/@soort="Spreekbeurt"/spreker/verslagnaam>] N.B. in bepaalde gevallen is de voornaam onderdeel van de verslagnaam. Dit ter onderschijd tussen leden met dezelfde achternaam --> <Functie>@ @</Functie> Versie 1.0 Pagina 58 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT - <!-op basis van [activiteitdeel/@soort="Spreekbeurt"/spreker/functie] (+ indien aanwezig: + spatie + [activiteitdeel/@soort="Spreekbeurt"/spreker/fractie]) --> - <!-BIJ Kamerleden FIND WHAT: <activiteitdeel soort="Spreekbeurt"><spreker soort="*"><fractie>^(*^)</fractie><aanhef>^(*^)</aanhef><verslagnaam>^(*^)</verslagnaam><weergavenaam>*</ weergavenaam><voornaam>*</voornaam><achternaam>*</achternaam><functie>^(*^)</functie></spreker> REPLACE WITH: ^t^t^t^t^t<Spreker> ^t^t^t^t^t^t<Naam>^2 ^3</Naam> ^t^t^t^t^t^t<Functie>^4 ^1</Functie> ^t^t^t^t^t</Spreker> --> - <!-BIJ bewindspersonen (fractie ontbreekt !) FIND WHAT : <activiteitdeel soort="Spreekbeurt"><spreker soort="*"><aanhef>^(*^)</aanhef><verslagnaam>^(*^)</verslagnaam><weergavenaam>*</weergavenaam><voornaam>* </voornaam><achternaam>*</achternaam><functie>^(*^)</functie></spreker> REPLACE WITH: ^t^t^t^t^t<Spreker> ^t^t^t^t^t^t^<Naam>^1 ^2</Naam> ^t^t^t^t^t^t<Functie>^3</Functie> ^t^t^t^t^t</Spreker> --> </Spreker> </Rollen> <Niveau MatchCondition="Add" MultiplematchCondition="AddToFirstMatch" intentie="Professioneel" taal="Nederlands" /> </Descriptie> - <Positie MatchCondition="Add" MultiplematchCondition="AddToFirstMatch"> - <!-Is identiek aan <Positie> binnen <Publicatie> in het algemene deel Vragenuur en Stemmingen hebben meerdere Selecties. Begin en eindtijden per Vraag/Stemming toepassen op basis van <activiteithoofd> -> </markeertijdeind> Omdat het Stemmingen alle Selecties geheel uit te !! Alleen verwijzing naar de file) opgenomen. Impliciet mogelijk is. <activiteithoofd> -> <markeertijdbegin> en maken van de xml-en nu nog handwerk is, is het niet nodig om bij werken. bij de eerste Selectie wordt een Positie ( = tijdcodes + wordt hiermee aangegeven dat dat bij de overige Selecties ook --> </Positie> </Selectie> Versie 1.0 Pagina 59 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT BIJLAGE F - VLOS METADATA TEMPLATE ONGESEGMENTEERDE DEBATDAG <?xml version="1.0" encoding="UTF-8" ?> - <!-versie="1.0" datum="zaterdag 9-11-2013" auteur="Roger Krom" --> - <GMI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="F:\ICT\Projecten\DFI\GMI\Klant 23 - 2eKamer\Export\gmi.xsd"> - <Expressie MatchCondition="Add" MultiplematchCondition="AddToFirstMatch" DFI_leverancier="TK"> - <ReeksMatch MultiplematchCondition="AddToFirstMatch"> <TaakId>4897914</TaakId> - <!-4897914 = Hele debatsdag --> </ReeksMatch> <Tijdsduur>@</Tijdsduur> - <!-berekend in milliseconden 1000 * ((aantal uur * 3600) + (aantal minuten * 60) + (aantal seconden)) = eindtijd laatste activiteit minus aanvangstijd eerst activiteit [vlosdocument/vergadering/activiteit/aanvangstijd] = aanvangstijd eerst activiteit (opening) [vlosdocument/vergadering/activiteit/eindtijd] = eindtijd laatste activiteit (sluiting) --> - <Descriptie> - <Titel HoofdtitelIndicatie="1"> <Tekst>Plenaire vergadering @, nr. @</Tekst> - <!-defaultwaarde = Plenaire vergadering "vergaderjaar voluit (bijv. 2012-2013)", nr. "vergadernummer" --> </Titel> - <Context> <Contekst>Debat-ID: TKP@@000</Contekst> - <!-Debat-ID: TKP + vergaderjaar (1213) + vergadernummer (3 posities) + 000 --> Versie 1.0 Pagina 60 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT </Context> - <Niveau MatchCondition="Add" MultiplematchCondition="AddToFirstMatch" intentie="Professioneel" taal="Nederlands"> - <Taaklijst indicatie_pushen="1"> <AangemaaktDoor>GMI</AangemaaktDoor> <Status>Nieuw</Status> <NogToewijzen>0</NogToewijzen> <Spoed>0</Spoed> <Teruggezet>0</Teruggezet> <Werkvoorraad>Tweede Kamer</Werkvoorraad> <Beschrijvingsdiepgang>uitgebreid beschreven (niv. 3)</Beschrijvingsdiepgang> </Taaklijst> </Niveau> </Descriptie> - <Publicatie MatchCondition="Add" MultiplematchCondition="AddToFirstMatch"> <Titel>@</Titel> - <!-= [vlosdocument/vergadering/titel] bijvoorbeeld: 100e vergadering, woensdag 26 juni 2013 --> <Type>Uitzending</Type> <Begindatum>jjjj-mm-dd</Begindatum> - <!-onderdeel van [vlosdocument/vergadering/datum] notatie is jjjj-mm-dd Dit is anders dan vanuit VLOS aangeleverd --> <Annotatie>Kamer:Tweede Vergaderingsoort:Plenair Vergaderjaar:1213 Vergaderingnummer:@</Annotatie> - <!-kamer, vergadersoort en vergaderjaar voor de proef de genoemde waarden geven + per vergaderdag betreffend nummer (1, 2 of 3 posities) --> <DistributieKanaal>televisie</DistributieKanaal> <Zendgemachtigde>Tweede Kamer</Zendgemachtigde> - <Positie MatchCondition="Add" MultiplematchCondition="AddToFirstMatch"> <Begintijd>@</Begintijd> <Eindtijd>@</Eindtijd> - <!-- Versie 1.0 Pagina 61 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT gelijk aan <DragerBegin> en <DragerEind> Vooralsnog is deze oplossing tijdelijk en zal er later naar deze wellicht onnodige verdubbeling gekeken worden --> <DragerSoort>Programma</DragerSoort> <DragerBegin>@</DragerBegin> - <!-berekend in milliseconden 1000 * ((aantal uur * 3600) + (aantal minuten * 60) + (aantal seconden)) [vlosdocument/vergadering/activiteit/aanvangstijd] = aanvangstijd eerst activiteit (opening) --> <DragerEind>@</DragerEind> - <!-berekend in milliseconden 1000 * ((aantal uur * 3600) + (aantal minuten * 60) + (aantal seconden)) [vlosdocument/vergadering/activiteit/eindtijd] = eindtijd laatste activiteit (sluiting) --> - <Drager MatchCondition="AddConnect" MultiplematchCondition="AddToFirstMatch"> <Archiefnummer>[email protected]</Archiefnummer> - <!-Afgeleide van <DebatID> (<Expressie> -> <Context> -> <Debat-ID>), maar zonder Debat-ID: en met -TKP + de extensie " .mxf ",) TK + P + vergaderjaar (4 posities, bijv 1213) + vergaderingnummer (3 posities, incl. evt. voorloopnullen) + 000 + koppelteken + creatotcode (TKP)+ de extensie .mxf --> <Bewaarplaats>Digitaal Archief</Bewaarplaats> <Herkomst>TKP</Herkomst> <Dragertype>BESTAND</Dragertype> <ArchiefnummerBron>[email protected]</ArchiefnummerBron> - <!-identiek aan <Drager> -> <Archiefnummer> --> <DragerMedium>video</DragerMedium> </Drager> </Positie> </Publicatie> - <!-Selectie mag volgens de gmi.xsd niet "leeg" zijn. Bij bestanden zonder Selecties moet het lege element worden verwijderd (geldt dus ook voor een volledige vergadering) !!! Versie 1.0 Pagina 62 van 63 PILOT INSTROOM TWEEDE KAMER | EINDRAPPORT --> </Expressie> </GMI> **********************EINDE DOCUMENT********************** Versie 1.0 Pagina 63 van 63
© Copyright 2024 ExpyDoc