eindrapport pilot Tweede Kamer

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]
&#13;&#10; 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