Overheid.nl Webmetadata

Transcriptie

1 Overheid.nl Webmetadata Het verbeteren van de toegankelijkheid van digitale informatie binnen de Nederlandse overheid HANDBOEK Versie december 2004 Deze uitgave wordt beheerd door: Advies Overheid.nl adres: Nieuwe Duinweg 24-26, 2587 AD Den Haag Postbus 84011, 2508 AA Den Haag telefoon: internet:

2 Colofon Algemeen Opdrachtgever en beleidsmatig verantwoordelijk: Ministerie van Binnenlandse Zaken en Koninkrijksrelaties ( Projectmanagement: ICTU / Advies Overheid.nl ( Auteurs van dit rapport: RAND Europe ( met bijdragen en ondersteuning van Gyata Management Consulting ( en DOXsupport ( Jeff Rothenberg, RAND Corporation Irma Graafland-Essers, RAND Europe Harry Kranenkamp, DOXsupport Abigail Lierens, RAND Europe Constantijn van Oranje, RAND Europe Rob van Schaik, Gyata Management Consulting Opgesteld in opdracht van Advies Overheid.nl Gefinancierd door het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties Rechten Auteursrecht van dit document: Stichting ICTU ( Stichting ICTU geeft iedereen een niet exclusief gebruiksrecht op de inhoud van dit document onder de onderstaande voorwaarden. Bij naleving van de condities betekent dit dat u de inhoud van het document kunt kopiëren en hergebruiken, ook voor commerciële toepassingen. De condities luiden als volgt: Bij geheel of gedeeltelijk gebruik van de inhoud van dit document wordt altijd verwezen naar de authentieke bron. Bij geheel of gedeeltelijk gebruik van de inhoud van dit document wordt altijd de datum van extractie vermeld. Als annotatie wordt daarbij het volgende vermeld: Overheid.nl Webmetadata Het verbeteren van de toegankelijkheid van digitale informatie binnen de Nederlandse overheid HANDBOEK Versie 1.01 Deze uitgave wordt beheerd door Advies Overheid.nl i

3 Inhoudsopgave Colofon...i HOOFDSTUK 1. Inleiding... 1 HOOFDSTUK 2. Definities... 4 HOOFDSTUK 3. Toepassing van metadata Het belang van webmetadata Selectie van relevante metadata-elementen Beheer van webmetadata en COI's Wat is het verband tussen webmetadata en andere metadata? HOOFDSTUK 4. De Overheid.nl Webmetadata standaard Een "optioneel gestructureerde" benadering De elementen Overwegingen voor de selectie van de elementen en verfijningen Codeersystemen en gecontroleerde woordenlijsten HOOFDSTUK 5. Implementatiegids Algemene strategie voor webmetadata De webmetadata management functie Andere bronnen Afsluitende opmerkingen Referenties Appendix A: Beschrijving van de elementen accessibility (toegankelijkheid) audience (doelgroep) contributor (bijdragevan) coverage (dekking) creator (auteur of maker) date (datum) description (omschrijving) format (formaat) identifier (verwijzing) language (taal) mandate (mandaat) preservation (bewaring) publisher (uitgever) relation (relatie) rights (rechten) source (bron) status subject (onderwerp) title (titel) type Appendix B: Gestructureerde metadata Behoefte aan gestructureerde metadata Verschillende opties voor gestructureerde metadata Appendix C: Implementatie-aspecten Ingebedde (embedded) of afzonderlijke metadata Metadata creëren voor oude en nieuwe documenten Levensduur van data en metadata Appendix D: Wijzigingshistorie ii

4 HOOFDSTUK 1. Inleiding Dit handboek beschrijft een nationale standaard voor het vergroten van de transparantie van de overheid in Nederland. Deze standaard dient om burgers en andere gebruikers (bijvoorbeeld bedrijven) te helpen om eenvoudiger online overheidsinformatie te vinden. Deze standaard betreft het creëren en gebruik van metadata. In deze context is metadata de informatie die overheidsinformatie zoals documenten, databases en diensten beschrijft. Een begeleidend rapport (RAND Europe, 2004) aan Advies Overheid.nl vormt de basis voor de metadatastandaard in dit handboek. Naast de eigenlijke standaard bespreekt dit handboek ook de redenen voor het introduceren van de standaard en de achtergrond van het ontwerp van Overheid.nl Webmetadata. Verder bevat dit document advies over de implementatie en gebruik van metadata voor het verbeteren van de ontsluiting en toegang tot overheidsinformatie. Deze standaard is voornamelijk bedoeld voor technische managers en -ontwerpers, en voor ontwikkelaars en managers van websites, databases en andere informatiesystemen binnen overheidsorganen op alle niveaus. Naar verwachting zal de metadatastandaard zelf voortdurend verder ontwikkeld worden. Dit handboek betreft de toepassing van metadata voor de online ontsluiting van en toegang tot informatie. De ontsloten informatie kan online of offline beschikbaar zijn (b.v. gedrukte rapporten en CD-ROM's), hoewel de nadruk ligt op online informatie. Dit handboek heeft geen betrekking op de vele aspecten van het opzetten en onderhouden van online informatie of het ontwerpen van websites en portals van hoge kwaliteit. Records management en archivering worden ook niet besproken, maar wel de relaties tussen records management en het creëren en beheren van webmetadata. Noch in Nederland, noch elders zijn de huidige en toekomstige behoeften van gebruikers met betrekking tot het online vinden van overheidsinformatie diepgaand bestudeerd. Er is ook geen diepgaande informatie beschikbaar over de aanbieders van overheidsinformatie in Nederland. Tijdens het schrijven van dit handboek is er echter een kleinschalige studie ondernomen naar de huidige werkwijze en behoeften van overheidsorganisaties. Bij het ontwikkelen van de Overheid.nl Webmetadata standaard werden ook diverse bestaande standaarden voor metadata bestudeerd. Een van de onderliggende factoren was de aanname van Advies Overheid dat de breed aanvaarde Dublin Core (DC) metadata standaard de basis kon vormen voor de Nederlandse nationale standaard voor webmetadata. Een belangrijke bijdrage daaraan bestond dan ook uit een analyse van de DC standaard en een aantal afgeleide nationale standaarden voor metadata. Deze omvatten onder andere egms uit Groot-Brittannië, AGLS (oorspronkelijk de Australian Government Locator Service, maar nu niet meer beperkt tot de publieke sector) en de hiermee verbonden VAGLS (deelstaat Victoria) en NZGLS (Nieuw Zeeland), de Irish Public Service Metadata Standard (IPSMS), en de Canadian Treasury Board Information Management Standard (TBITS). Verder zijn diverse verwante ontwikkelingen geanalyseerd, waaronder de CEN Workshop egovernment Metadata Application Profile v. 1.0 (CWA 14860, november 2003), GILS (Global Information Locator Service), de EAD (Encoded Archival Description) standaard, het Warwick Framework, ISO-IEC_11179 betreffende Metadata Registraties (MDR), ISO/TS betreffende de principes voor metadata voor 1

5 Inleiding records management, het werk van OASIS over interoperabiliteit bij het zoeken en Topic Maps, en het European Interoperability Framework (EIF) 1. Dit handboek beschrijft de motivering voor het ontwerp van de Overheid.nl Webmetadata standaard. Het handboek legt ook uit hoe degenen die overheidsinformatie beschikbaar maken (de primaire gebruikers van de standaard) de standaard kunnen toepassen. Meer specifiek is het handboek bedoeld voor technisch managers en ontwerpers, implementeerders en managers van websites, databases en andere informatiesystemen die voorzien in online informatie over de overheid. Daarnaast is dit handboek ook bedoeld voor records managers in dergelijke organisaties en iedereen die overheidsdocumenten creëert die online openbaar worden gemaakt. Nota bene: dit handboek is geen praktische handleiding voor de feitelijke implementatie van metadata, maar schetst de context en voorwaarden voor het invoeren van metadata. Het bevat tevens een eerste versie van elementen en verfijningen die voor overheidsdocumenten relevant zijn. Het ontwerp van de Overheid.nl Webmetadata standaard is gebaseerd op de volgende principes: De Dublin Core standaard vormt het uitgangspunt. De nadruk ligt op ontsluiting van en toegang tot webdocumenten met aandacht voor de noodzaak het toegangsdomein te integreren met het records management domein. De standaard dient zo eenvoudig mogelijk te zijn, zonder in de toekomst de mogelijkheden van diverse groepen te beperken bij het beschrijven van het volledige spectrum aan online informatiebronnen en diensten. Er wordt rekening gehouden met implementatie-aspecten zoals: het betrekken van relevante groepen, het bevorderen van de acceptatie, het beheer van metadata in metadatasystemen, en het verzekeren dat de metadata gebruikt kan worden door zoekinstrumenten en -systemen. Deze principes werden aangehouden bij de ontwikkeling van de Overheid.nl Webmetadata standaard, op basis van diverse andere metadatastandaarden die op hun beurt zijn afgeleid van het Dublin Core (DC) model, specifiek egms uit Groot Brittannië en het werk van de CEN Workshop egovernment Metadata Application Profile v.1.0 (CEN Workshop Agreement, 2003). Het resultaat behoudt het grootste deel van de eenvoud van de Dublin Core standaard, maar plaatst deze in een eenvoudig en algemeen "optioneel gestructureerd" model dat veel flexibeler en krachtiger is dan DC of de andere daarvan afgeleide standaarden. Om de behoeften van diverse belanghebbenden af te dekken steunt de standaard op de aanname dat groepen van belanghebbenden (Communities of Interest, COI's) voor hun specifieke belang de standaard zullen doorontwikkelen. Voorbeelden van de mogelijke ontwikkelingen zijn onder andere: het voorzien in verschillende metadata-elementen of verfijningen (velden), verschillende standaardwaarden (defaults) voor bepaalde velden, of verschillende gecontroleerde woordenlijsten (controlled vocabularies) of codeersystemen (coding schemes) voor de veldwaarden. Door deze taak bij de COI s te leggen, is het niet nodig veel van deze aspecten in de standaard vast te leggen, waardoor deze te rigide zou worden. Het is echter noodzakelijk dat de activiteiten van de COI's gecoördineerd worden, 1 Zie het Rapport Designing a National Standard for Discovery Metadata, RAND Europe, 2004 voor meer details over deze standaarden. 2

6 Inleiding en dat inconsistentie tussen hun verfijningen wordt voorkomen. Dit zou kunnen worden ondernomen door een nationaal COI clearinghouse, zoals beschreven in paragraaf 3.2. Het voorzien in webmetadata is een middel om een doel te bereiken. Het heeft weinig zin een standaard voor webmetadata te definiëren als er niet tegelijkertijd systemen en procesmodellen worden ontwikkeld om de standaard inhoud te geven voor wat betreft de ontwikkeling en het beheer van webmetadata binnen een organisatie. Verder heeft het creëren en beheren van webmetadata geen zin als deze niet gevonden kan worden door zoekmachines (finding tools). Dit handboek en de standaard het op gebaseerd is, hebben voornamelijk betrekking op welke webmetadata moeten worden verzameld of aangemaakt, en hoe deze moeten worden weergegeven. Dit dient echter plaats te vinden binnen een bredere context met daarin onder andere de acceptatie of ontwikkeling van systemen en instrumenten voor het verzamelen, creëren, onderhouden en gebruiken van metadata voor de ontsluiting. Door te voorzien in webmetadata en zoekinstrumenten die deze metadata kunnen gebruiken, zal de transparantie van overheidsinformatie in Nederland aanzienlijk worden vergroot. De rest van dit handboek bestaat uit vijf hoofdstukken en drie appendices. Hoofdstuk 2 definieert belangrijke termen die in het handboek worden gebruikt. Hoofdstuk 3 beschrijft de toepassing en het beheer van metadata en Hoofdstuk 4 bevat de standaard. Hoofdstuk 5 is een korte handreiking voor organisaties bij het implementeren van webmetadata. Appendix A bevat gedetailleerde beschrijvingen van de elementen en verfijningen van de standaard, met voorbeelden. Appendix B gaat in op de redenen voor het gebruik van gestructureerde metadata. Tenslotte worden er in Appendix C enkele bijkomende zaken met betrekking tot implementatie besproken. 3

7 HOOFDSTUK 2. Definities Dit hoofdstuk bevat definities van een aantal sleutelbegrippen die in dit handboek verder worden gebruikt en welke een speciale betekenis hebben in de context van ontsluiting en toegang van metadata. Relevante Engelse termen zijn tussen haakjes opgenomen om de toegang tot de internationale literatuur te vergemakkelijken. In navolging van de terminologie van het Dublin Core Metadata Initiative (DCMI), verwijst een codeersysteem (encoding scheme) naar een syntaxcodering of een vocabulaire. (In dit handboek wordt de term "gecontroleerde woordenlijst" gebruikt in plaats van vocabulaire.) Een syntaxcodering is een specifiek formaat of stramien voor het weergeven van een bepaald soort informatie, zoals een datum of objectidentificatie. Voorbeeld: 12 jun 04, 12/6/2004 en (Juliaanse datum) zijn drie manieren om dezelfde dag te coderen, en is bijvoorbeeld de codering van de naam van een webpagina. In tegenstelling hiermee is een gecontroleerde trefwoordenlijst (beheerste vocabulaire; controlled vocabulary, CV) normaal gesproken een gesloten lijst van termen of aanduidingen, zoals afkortingen van de namen van steden of landen, of de namen van de diverse cartografische projecties. Voorbeeld: de VIND catalogus omvat een lijst diensten die door gemeentes worden aangeboden aan burgers en bedrijven, deze lijst zou de basis kunnen vormen van een CV dat dergelijke diensten beschrijft. Een ander belangrijk voorbeeld wordt gevormd door de interdepartementale taxonomie beschreven op Het begrip document of bron (resource) wordt verschillend gebruikt in de context van bibliotheken, archieven, records management en het web (Internet). In dit handboek wordt de meest ruime betekenis gebruikt, en omvat het begrip diensten en voorzieningen, afzonderlijke objecten, alsmede online en offline objecten zoals gedrukte rapporten en CD- ROM's. Houdt er daarbij rekening mee dat informatie afkomstig kan zijn uit vele afzonderlijke bronnen, zoals meerdere documenten of database queries. De Dublin Core metadata standaard omvat een klein aantal metadata-elementen, die elk betrekking hebben op één aspect van een informatiebron (zoals een document of database). De DC-elementen komen overeen met de datavelden op een kaart in een kaartenbak in een bibliotheek. Ze verschaffen informatie zoals de auteur, uitgever, publicatiedatum, formaat, enz. van de beschreven informatiebron. Gecontroleerde trefwoordenlijst (controlled vocabulary): zie de bespreking van codeersysteem. Een Groep van Belanghebbenden (Community of Interest, COI) is elke groep van organisaties, instanties, afdelingen of personen die een bepaald belang delen. Zo zouden verschillende bestuursniveaus (nationaal, provinciaal, gemeentelijk) afzonderlijke COI's kunnen vormen, net zoals niet-overheidsinstellingen. Er bestaan al diverse COI's binnen de Nederlandse overheid. Een goed voorbeeld betreft het werk rond GFO (Gemeentelijk Functioneel Ontwerp), zoals GFO Zaken. Verder kunnen groepen van instellingen of afdelingen die betrokken zijn bij bepaalde overheidsaspecten die bestuursniveaus of organisatiegrenzen doorbreken samen COI s vormen. Bijvoorbeeld als ze betrokken zijn bij de internetpublicatie van bijzondere typen documenten (wet- en regelgeving, vergunningen, Europese regelgeving, officiële publicaties, enz.) of belast zijn met specifieke problemen of onderwerpen (milieuaspecten, etnische onderwerpen, "gender" aangelegenheden, enz.). 4

8 Definities COI's zullen vaak met elkaar overlappen, en dwars door de traditionele hiërarchische grenzen lopen. De term metadata wordt in het algemeen gedefinieerd als "data of informatie betreffende informatie". Metadata heeft vele toepassingen, waaronder de beschrijving van de inhoud van een informatiebron, een uitleg van de interpretatie van een data-element (b.v. of het uitgedrukt is in metrische of Imperial eenheden, of in graden Celsius of Fahrenheit), statistische meting of een subjectieve beoordeling van de kwaliteit van de informatie, of van administratieve functies (b.v. beheer, onderhoud en lokalisering van bronnen). Een eenvoudig voorbeeld van beschrijvende metadata is een kaart in de kaartenbak van een bibliotheekcatalogus. Deze kaart bevat informatie over de auteur, uitgever, publicatiedatum, afmetingen, enz. van een boek of ander object. Bibliothecarissen gebruiken metadata voornamelijk voor dergelijke beschrijvende informatie. Records managers en archivarissen gebruiken metadata ook om, ten behoeve van verantwoordingsprocessen, de context van een activiteit of het bedrijfsproces waarin de records werden aangemaakt te beschrijven. De term metadataverzameling (metadata set) verwijst naar een bepaalde verzameling metadata-elementen. Voorbeeld: de Dublin Core standaard specificeert een bepaalde metadataverzameling bestaande uit de elementen Titel, Auteur/maker, Uitgever, Datum, enz. In de context van online-toepassingen verwijst navigatie/navigeren naar het doorlopen van een logische structuur, zoals een inhoudsopgave, menu of lijst van koppelingen (links) die zodanig is ingericht dat deze de samenhang van een informatiebron beschrijft (bijvoorbeeld boomstructuur of netwerkstructuur). In de meeste gevallen wordt navigeren onderscheiden van zoeken (zie definitie hieronder), maar het onderscheid is soms onduidelijk. Navigeren kan ook overlappen met browsing (bladeren), een minder strikt georganiseerd doorlopen van een verzameling informatie. Voor de definitie van ontologie wordt u verwezen naar de bespreking van taxonomie. In de context van dit handboek is ontsluiting (discovery) het proces van het vinden van relevante informatie. Van belang is te constateren dat met dit begrip het vinden van informatie wordt bedoeld. Dat is dus breder dan het vinden van afzonderlijke documenten of bronnen (resources), aangezien gebruikers vaak zoeken naar informatie die meerdere bronnen beslaat. In de context van metadata betreft ontsluiting echter in het algemeen het vinden van afzonderlijke objecten, zoals documenten. In de context van records management (archiefbeheer) verwijst het begrip record naar een gegeven (archiefbescheiden) dat documentatie of bewijs vormt van een officiële handeling of activiteit uitgevoerd door een organisatie. Voorbeeld: het verlenen van een vergunning door een overheidsinstantie. (Attentie: deze term heeft een andere betekenis term in de context van databases, waar het verwijst naar een bepaalde verzameling datawaarden, zoals een rij in een relationele tabel. In dit handboek wordt deze betekenis echter niet gebruikt.) Een semantisch web (semantic net) is een middel voor het weergeven van informatie als een verzameling knooppunten (nodes) verbonden door een netwerk van relaties. Een semantisch web kan elementen zoals objecten, concepten, gebeurtenissen en processen voorstellen, en bovendien feiten of relaties tussen dergelijke elementen. Voorbeelden zijn het feit dat een stuur een onderdeel vormt van een auto, of de relatie tussen een grootvader en zijn kleinkinderen. Omdat een semantisch web een zeer algemeen en krachtig instrument is kan het in essentie worden gebruikt voor het weergeven van werkelijk alle kennis of informatie. 5

9 Definities Een standaard (standard), zoals gebruikt in dit handboek, is een geaccepteerd voorschrift (norm) dat bijvoorbeeld beschrijft hoe een bepaald proces moet worden uitgevoerd, hoe een document moet worden vormgegeven of ingedeeld, of hoe toegestane waarden worden gekozen voor bepaalde soorten informatie. Voorbeeld: een standaard voor een bepaald soort rapport kan de hoofdstukken opnoemen die in het rapport moeten worden opgenomen, en wat hun inhoud is. Een standaard voor het opgeven van een datum kan de volgorde van de dag, maand en jaar voorschrijven, en of deze met letters of cijfers worden gecodeerd (b.v. "3 juni 2004" of "3-6-04" of " "). Een metadatastandaard omvat een lijst van metadata-elementen (velden) die moeten worden opgegeven, en beschrijft de toegestane waarden van elk van deze elementen. Voor de beschrijving van syntaxcodering (syntax encoding): zie de bespreking van codeersysteem hierboven. Er worden diverse technieken gebruikt voor het beheren en structureren van grote verzamelingen met elkaar samenhangende termen, zoals trefwoorden (keywords). Een enkelvoudige hiërarchie (zoals de naamgeving van planten of dieren) wordt vaak taxonomie genoemd. Elke term heeft precies één plaats in een taxonomie. Dit leidt tot een eenvoudige structuur maar gaat voorbij aan het feit dat veel termen meerdere betekenissen hebben. In een thesaurus of synoniemenlijst kunnen synoniemen en andere gerelateerde termen naar elkaar verwijzen door middel van een beperkt aantal ingebouwde relaties. Zo kan een bepaalde term verschillende betekenissen hebben, in verschillende contexten. Een ontologie is het meest brede terminologische concept: het kan elke mogelijke structuur hebben, afzonderlijke termen kunnen worden gebruikt in meerdere contexten of categorieën, en het kan willekeurige relaties voorstellen tussen de termen en hun contexten. Diverse instrumenten voor het bouwen van een semantisch web kunnen worden gebruikt voor het samenstellen van een ontologie. Voorbeeld: met Topic Maps kunnen termen en concepten worden voorgesteld als "topics" die naar wens verbonden kunnen worden. Webmetadata (discovery metadata) dient gebruikers te helpen bij het vinden van relevante informatie, door te voorzien in nuttige beschrijvende of categoriserende informatie. Bepaalde soorten metadata zijn hierbij mogelijk niet van belang. Administratieve metadata, voor het ondersteunen van het beheer van de bronnen, zal waarschijnlijk weinig bijdragen aan de ontsluiting. Metadata over archiefbescheiden kan echter van belang zijn voor juristen of anderen die de overheid willen aanspreken op haar gedrag. In een online omgeving is zoeken (searching) het gebruiken van een computer om de inhoud van documenten te doorzoeken op combinaties van woorden of zinnen. Als de trefwoorden (keywords) in een document categorieën vormen die overeenkomen met een navigatiestructuur dan kan het zoeken op deze woorden op hetzelfde neerkomen als navigeren. Een zoekinstrument (finding tool) is elk mechanisme of dienst (meestal, maar niet altijd, een computerprogramma) dat gebruikers kan helpen bij het vinden van informatie. Voorbeeld: zoekmachines zoals Google, systemen voor de toegang tot en het opvragen van informatie uit databases, gestructureerde browsing -programma's, en elk ander instrument dat informatie kan vinden en toegankelijk maken. Dit is een bredere definitie dan die van de term "zoekhulpmiddel" (finding aid) die wordt gebruikt door bibliothecarissen en archivarissen. Op hun vakgebied verwijst deze term in het algemeen naar een index, inventaris, uittreksel of een beschrijving, en niet naar een programma dat kan worden uitgevoerd. 6

10 HOOFDSTUK 3. Toepassing van metadata Dit hoofdstuk beschrijft een aantal belangrijke aspecten van het creëren, beheren en gebruiken van metadata Het belang van webmetadata Elke organisatie die online informatie beschikbaar stelt moet mogelijkheden bieden die informatie vindbaar en toegankelijk te maken. Dit is onder andere mogelijk door middel van knoppen, menu's of navigatiestructuren op een website, of door het mogelijk te maken in vrije tekst te zoeken bij online documenten. Het simpel zoeken naar woorden of zinnen is bij online documenten echter minder effectief. Als het betreffende onderwerp samenhangt met een bijzonder woord of zin dan kan deze methode goed werken. In andere gevallen kunnen er echter honderden of duizenden "hits" worden gevonden, zoals iedereen weet die uren gefrustreerd heeft zitten zoeken naar informatie met algemene termen, zoals bijvoorbeeld "water". Een alternatief is het gebruik van metadata om de documenten te beschrijven aan de hand van nauwkeurig gedefinieerde attributen, zoals hun titel, auteurs, publicatiedata of onderwerpen. Webmetadata maakt het gebruikers mogelijk te zoeken op trefwoorden, namen en zinnen in een bepaalde context. Voorbeeld: zoeken naar een organisatie als de uitgever van een document, en niet als één van de vele organisaties die in documenten genoemd worden. Deze manier van ontsluiten kan aanmerkelijk effectiever worden als deze mogelijkheid wordt gecombineerd met gecontroleerde woordenlijsten (gestandaardiseerde lijsten met termen, zoals landenafkortingen of juridische concepten) en gestandaardiseerde beschrijvingswijzen zoals data en telefoonnummers. Voorbeeld: als alle documenten en gegevens over "water" worden beschreven door metadata zoals een subject (onderwerp)-element dat het trefwoord "water" bevat, dan zou een gebruiker met dit trefwoord veel gemakkelijker alle betreffende documenten en gegevens kunnen vinden. Vanuit het perspectief van een overheidsinstelling is het belangrijk gebruikers te helpen bij het vinden van nauwkeurige en geschikte informatie. Als gebruikers schade leiden als gevolg van het vinden van onjuiste of ongeschikte informatie dan zouden zij schadevergoeding kunnen eisen van de instelling. In veel gevallen zal er binnen een organisatie al geschikte webmetadata bestaan. Het is dan alleen nodig deze data te herkennen en te verzamelen. In andere gevallen zal het nodig zijn de webmetadata speciaal te ontwikkelen. Het is voor burgers en bedrijven ondoenlijk om voor elke database met webdocumenten een andere zoekstrategie aan te leren en om weer andere zoektermen te gaan gebruiken. Overheidsorganisaties, die over gemeenschappelijke onderwerpen publiceren zouden daarom afspraken moeten maken over de vorm en betekenis van hun metadata. Een dergelijke interoperabiliteit is vooral van belang voor gebruikers die informatie van meerdere sites of bronnen willen combineren of vergelijken. Het is echter nuttig voor alle gebruikers die overheidsinformatie willen vinden. Daar ligt dan ook de belangrijkste reden voor het advies een nationale standaard voor webmetadata te definiëren. 7

11 Toepassing van metadata 3.2. Selectie van relevante metadata-elementen Het doel van het ontwikkelen van webmetadata is gebruikers te helpen bij het vinden van de informatie die zij nodig hebben. Dit betekent dat de waarde van de metadata-elementen zoals beschreven in paragraaf 4.2 en Appendix A zodanig gekozen moeten worden dat onderstaande vragen voor ieder webdocument beantwoord kunnen worden:: Wat is het onderwerp van het document? Wie is verantwoordelijk voor het opstellen en beschikbaar stellen van de inhoud? Waarom is het gepubliceerd? Wanneer werd het gepubliceerd, en voor het laatst bijgewerkt? Op welke periode of geografisch gebied heeft het betrekking? Uit welke bronnen werd de informatie verkregen? Wat is de doelgroep? In welke taal is het geschreven? Hoe is het via het web toegankelijk? Zijn er beperkingen op het gebruik? De taal gebruikt in metadata beschrijvingen moet zo duidelijk en helder mogelijk zijn. De meeste gebruikers zijn niet bekend met de structuur van overheidsinformatie, met de rollen van die organisaties en de manier waarop zij verwijzen naar processen en documenten. Verder zullen weinig gebruikers vertrouwd zijn met technische en gespecialiseerde termen. De toelichting moet dan ook in duidelijke taal zijn geschreven. Eventuele afkortingen moeten een link hebben naar een woordenlijst of uitleg, of voluit worden geschreven als ze voor de eerste keer in de metadata van een bepaald document voorkomen. Bij het kiezen van trefwoorden en andere beschrijvende begrippen is het verstandig "achteruit" te denken. Zal iemand tevreden zijn met de zoekresultaten van een trefwoord als hij of zij met dat trefwoord informatie opzoekt op een website? En omgekeerd, welke trefwoorden zal iemand naar verwachting gebruiken bij het zoeken naar een bepaald document? Met uitzondering van de elementen die verplicht (mandatory) of verplicht-indien-van toepassing (mandatory if applicable, MiA) zijn, is het niet noodzakelijk een waarde in te voeren voor elk element van elk document. Een description-element (omschrijving) zal mogelijk geen waarde toevoegen indien het title-element (Titel) van een document voldoende beschrijvend is, en een audience-element (doelgroep) is alleen verplicht als een document voor een bepaalde groep bedoeld is. Verder zal een coverage-element (dekking) alleen worden opgegeven voor documenten die betrekking hebben op een bepaalde periode of geografisch gebied. Bij het invoeren van waarden voor elementen zoals title (titel) en subject (omschrijving) moet men er rekening mee houden dat de zoekactie van een gebruiker waarschijnlijk zal leiden tot een lijst met de waarden van deze elementen voor een groot aantal documenten, dus een lijst met titels of omschrijvingen. Titels zonder voldoende context (b.v. "De volgende stap") zijn weinig verhelderend in dergelijke lijsten en zullen niet veel helpen bij het vinden van de gezochte informatie. 8

12 Toepassing van metadata 3.3. Beheer van webmetadata en COI's Het beheer van webmetadata en de bijdragen van COI's (groepen van belanghebbenden) worden hieronder en in Hoofdstuk 5 (Implementatiegids) verder besproken. Deze concepten worden echter hier al geïntroduceerd omdat ze in de rest van deze handleiding worden gebruikt. De verzameling, creatie, beheer en gebruik van webmetadata hoeft in beginsel geen aanmerkelijke nieuwe werklast te vormen voor een organisatie, althans, wanneer in die organisatie een metadatabeheerfunctie voorhanden is. In principe dient in iedere organisatie een metadatabeheerfunctie moeten hebben. Wanneer die niet beschikbaar is nieuw worden opgezet als er geen geschikte bestaande functie is. Hoewel een beheerfunctie voor webmetadata gevonden kan worden onder de bestaande archiefbeheer, records management of websitemanagement functies van een organisatie, gaat webmetadata uit van een ander perspectief en interesses, wat in dit handboek steeds wordt aangegeven. Idealiter wordt de beheerfunctie voor webmetadata geleid door een aparte webmetadatamanager die goed ingevoerd is in het gebruik van metadata en vertrouwd is met de missie van de organisatie en tevens met records management, documentbeheer, online publicaties en e-service functies. De praktijkervaring van verschillende andere nationale metadata-inspanningen leert dat het opzetten van de rol van webmetadatamanager essentieel is voor de succesvolle introductie van metadata in welke organisatie dan ook. Daarom gaat dit handboek er dan ook van uit dat elke organisatie een dergelijke beheerder of manager heeft, hoewel de webmetadata-managementfunctie in principe vervuld kan worden zonder dat daar een specifieke functionaris voor is. Veel beslissingen over metadata kunnen gezamenlijk worden genomen door meerdere organisaties, in een geschikte COI. Zo zal de keuze van een codeersysteem voor geografische informatie van belang zijn voor alle organisaties die kaarten en kadastrale gegevens gebruiken. Verder zullen gecontroleerde woordenlijsten voor specifieke verzamelingen van juridische of technische termen van belang zijn voor alle overheidsorganisaties die dergelijke termen gebruiken. Waar mogelijk zouden COI s zodanig moeten worden opgezet en ingericht dat deze beslissingen gezamenlijk genomen kunnen worden. Dat zou de lasten die samenhangen met metadata verminderen voor de afzonderlijk organisaties. Wel betekent dit dat elke organisatie haar metadata beslissingen moet coördineren met de betreffende COI's. Verder zal elke COI een beperkte administratie en coördinatie met andere COI's vereisen. In de meeste gevallen zal dit werk moeten worden uitgevoerd door de organisaties die lid zijn van de COI's. Om overlappingen en inconsistenties tussen verschillende COI's te voorkomen dient er een nationaal COI clearinghouse te worden opgericht om de COI's te helpen met de coördinatie van hun activiteiten. Een nationaal COI clearinghouse zou het groepen van belanghebbenden mogelijk maken te bepalen of er al een geschikte COI bestaat en, zo niet, om een nieuwe aan te melden zodat anderen van haar bestaan op de hoogte kunnen worden gesteld. Het clearinghouse dient een vergelijkbare rol te spelen met betrekking tot codeersystemen, gecontroleerde woordenlijsten, taxonomieën, thesauri en ontologieën. Voorbeeld: een informatieleverancier die een gecontroleerde woordenlijst voor een bepaalde toepassing (b.v. opgeven van geografisch bereik) moet kiezen of opbouwen, kan onderzoeken of er al een geschikte woordenlijst in gebruik is bij een relevante COI, en zo niet, welke COI de organisatie zou kunnen helpen bij het kiezen of opzetten van een dergelijke woordenlijst. Indien COI's hun eigen, onafhankelijke ontologieën ontwikkelen dient het clearinghouse de afstemming daarvan en de inpassing tot een volledige ontologie te coördineren. Het opzetten van een 9

13 Toepassing van metadata dergelijk clearinghouse vereist uiteraard de nodige middelen, en een goede plaats in een geschikt orgaan van de centrale overheid. Waarschijnlijk kan veel van de vereiste functie worden uitgevoerd door middel van een online werkgroep, maar er moet desondanks een orgaan zijn dat de functie ondersteunt. In ieder geval moet er een database worden bijgehouden met een opgave van alle CIO s met vermelding van het functionele bereik (scope) en de aangesloten organisaties met contactinformatie. Verder dient het clearinghouse beleid te ontwikkelen voor het omgaan met conflicten tussen COI's. Een dergelijk clearinghouse is essentieel om te verzekeren dat het COI-mechanisme haar doel bereikt, en niet tot verwarring leidt Wat is het verband tussen webmetadata en andere metadata? Niet alle metadata is even nuttig bij het ondersteunen van de ontsluiting. De metadataelementen beschreven in Hoofdstuk 4 vormen dan ook een deelverzameling van alle metadata-elementen die een organisatie mogelijk gebruikt. Om gebruikers te helpen bij het vinden van informatie dient een organisatie de relevante metadata uit geschikte bronnen te verzamelen, en eventueel ontbrekende metadata nieuw te ontwikkelen. In een organisatie onderscheiden we in deze context twee domeinen waarbinnen metadata wordt gegenereerd: het records-management -domein voor interne ontsluiting en het toegangs - domein voor externe ontsluiting. In sommige organisaties kan metadata voor online documenten verzameld of gecreëerd en onderhouden worden door een records management groep of functie (hoewel soms ook vanuit de bibliotheek-, documentatie- en publicatiediscipline metadata worden verzameld, gecreëerd en beheerd, en metadata ook gecreëerd kan worden door bedrijfsfuncties in een organisatie worden deze functies hier voor het gemak samengevat als zijnde het werkgebied/domein van records management). De informatiebehoeften vanuit records management functie verschillen aanmerkelijk van die van ontsluiting, en in het algemeen wordt records management metadata niet gecreëerd of verzameld ten behoeve van de ontsluiting. Er zal echter een aanzienlijke overlapping zijn in de metadata die voor deze domeinen of werkgebieden vereist is. In het ideale geval wordt alle metadata die een document beschrijft beheerd door de records management functie aangezien dit in de meeste gevallen ook het domein is waar het document zelf beheerd wordt. Dit type beschrijvende metadata kan ook dienen als webmetadata, hoewel ze dus niet verzameld of gecreëerd zijn ten behoeve van de ontsluiting. Helaas zijn er maar weinig organisaties met een goed functionerende digitale records management functie, hoewel er op dit gebied vooruitgang wordt gemaakt. In tegenstelling hiermee kan een website manager of online service provider worden beschouwd als onderdeel van het toegangs domein ( access domain) van een organisatie. Dit domein betreft alle aspecten van toegang door het publiek tot de overheidsorganisatie. In de online context omvat dit websites met overheidsinformatie en andere e-government diensten. Vaak is er directe toegang tot documenten die worden beheerd door records management. In andere gevallen worden er speciale versies van de documenten gemaakt voor het web. In beide gevallen bestaat de behoefte van het toegangsdomein aan metadata uit de meeste van de beschrijvende metadata vereist door het records management domein, zoals titel, auteur, publicatiedatum, enz. Het toegangsdomein heeft geen behoefte aan metadata die uitsluitend is bestemd voor administratief gebruik (b.v. archiefvernietiging, redactie, of rechtenbeheer), mogelijk heeft dit domein wel behoefte aan aanvullende webmetadata die 10

14 Toepassing van metadata van weinig belang is voor records management, zoals onderwerp- of categorietrefwoorden die niet worden gebruikt voor interne toegang door de organisatie zelf. De ideale relatie tussen metadata in de digitale records management en toegangsdomeinen wordt aangegeven in Figuur 1a (gebaseerd op een concept van Hans Hofman van het Nationaal Archief). Deze benadering zal de hoeveelheid werk in het toegangsdomein aanmerkelijk verkleinen omdat de meeste van de vereiste metadata (zoals titel, uitgever, publicatiedatum, enz.) van elk document worden verkregen uit het records management domein. RM metadata: Titel, uitgever, publicatiedatum, enz. webmetadata: Titel, uitgever, publicatiedatum, enz. Documenten: Rapporten, databases, enz. Records Management domein Toegangsdomein Figuur 1a: Webmetadata onttrekken van records management Zoals reeds eerder gesteld zijn er momenteel helaas weinig organisaties die een werkelijke digitale records management managementfunctie hebben. In de meeste gevallen zal deze situatie dus nog niet bereikbaar zijn. Het is desondanks belangrijk dat de implementatie hiervan in de toekomst te bevorderen, zodra zowel het digitale records management als de digitale toegangsdomeinen voldoende vertegenwoordigd zijn in de organisatie. In alle gevallen moeten de implementeerders in het hun werk bekend maken en coördineren met de records managers in hun organisatie om dubbel werk en inconsistenties te vermijden. Waar mogelijk moet het gebruik van gezamenlijke codeersystemen en gecontroleerde woordenlijsten gecoördineerd worden tussen deze domeinen, om de consistentie te verzekeren en de inspanningen te minimaliseren. Zoals Figuur 1b laat zien zal het toegangsdomein mogelijkerwijs bepaalde zoektermen van de records management functie vertalen zodat deze nuttiger zijn voor gebruikers die zoekacties uitvoeren. Zo kan het nodig zijn technische of juridische termen, die een organisatie gebruikt om haar werk te beschrijven, te vertalen in gebruikelijke termen in de spreektaal. Verder kunnen er in het toegangsdomein nieuwe termen, taxonomieën, thesauri of ontologieën worden toegevoegd om de ontsluiting te bevorderen. 11

15 Toepassing van metadata RM-Metadata: Titel, uitgever, interne sleutelwoorden, enz. Documenten: rapporten, databases, enz. Toegang Afleiden Vertalen Webmetadata: Titel, uitgever, website sleutelwoorden, enz. Webcopieën van documenten Uitbreiden/ Toevoegen Records Management domein Toegangsdomein Figuur 1b: Verkrijgen, wijzigen en opslaan van webmetadata vanuit records management In sommige gevallen kan aanvullende webmetadata ook van belang zijn voor het records management domein, of kan dit domein aanbieden deze metadata te beheren. In de meeste gevallen is deze metadata echter alleen van belang voor het toegangsdomein en zal daar dan ook worden opgeslagen, onderhouden en beheerd. Beide alternatieven zijn geïllustreerd in Figuur 1b. Verder laat het figuur zien dat hoewel het toegangsdomein vaak gebruik maakt van online resources die onder het beheer van records management vallen, het toegangsdomein ook vaak haar eigen kopieën van documenten aanmaakt, bijvoorbeeld om documenten of databases beter geschikt te maken voor het web. Dergelijke kopieën die door het toegangsdomein worden gecreëerd moeten daar ook worden opgeslagen en beheerd (tenzij records management bereid is dit te doen). De verantwoordelijkheid voor de coördinatie van deze inspanningen ligt bij de Webmetadata-manager, zoals beschreven in paragraaf 5.2 later in dit handboek. Als een organisatie webmetadata invoert voordat er een digitale records management functie is, dan zal het toegangsdomein de metadata die het nodig heeft zelf moeten verzamelen en creëren. Verder kan het nodig zijn een zekere hoeveelheid administratieve metadata te verzamelen of te creëren om online documenten te kunnen beheren. Hiermee wordt voorzien in een tijdelijke oplossing voor de records management functie binnen de organisatie. Een bijdrage van records management aan dit proces zal bijdragen aan de effectiviteit en kans op integratie met een toekomstige records management oplossing. Een van de vereisten om toekomstige integratie mogelijk te maken is het gebruik van stabiele, universele verwijzingen (identifiers) bij het beschrijven van eenheden (entities) zodat een records manager kan bepalen of er al metadata bestaat in het toegangsdomein voor een eenheid die later wordt opgenomen in het records management domein. Algemene verwijzingensystemen (global identifier schemes) zoals de Uniform Resource Identifier (URI), Digital Object Identifier (DOI) en het International Standard Book Number (ISBN) komen hiervoor uiteraard in aanmerking. In een toekomstige discussie binnen overheidsorganen en records managers dient te worden besproken of er behoefte is aan een nationaal systeem voor het aanduiden van permanente, unieke verwijzingen voor online publicaties van de Nederlandse overheid. 12

16 HOOFDSTUK 4. De Overheid.nl Webmetadata standaard Dit hoofdstuk beschrijft de Overheid.nl Webmetadata standaard. Paragraaf 4.1 beschrijft de optioneel gestructureerde benadering van de standaard voor het omgaan met gestructureerde metadata. Paragraaf 4.2 geeft een opsomming van de elementen en verfijningen in de ongestructureerde basisvorm van de standaard, de volledige details staan in Appendix A. Paragraaf 4.3 beschrijft de redenen voor het opnemen van specifieke elementen en verfijningen. Tenslotte beschrijft paragraaf 4.4 het gebruik van de codeersystemen en gecontroleerde woordenlijsten in de standaard Een "optioneel gestructureerde" benadering De standaard omvat twee takken. Eén van de takken voorziet in ongestructureerde (platte) metadata, vergelijkbaar met de DC standaard en daarvan afgeleide standaarden. De andere tak voorziet in het toekomstige gebruik van gestructureerde metadata (b.v. zoals besproken in Appendix B) om deelverzamelingen (subsets) te maken van verwante metadataelementen. Hiermee kunnen metadata-elementen die logisch verwant zijn samengevoegd worden, en kunnen complexe online documenten zoals dynamische of samengestelde objecten of e-services of complexe relaties tussen documenten worden beschreven. Metadata conform de gestructureerde tak moet altijd een juiste overkoepelende verzameling (superset) zijn van de metadata in de ongestructureerde tak, om interoperatibiliteit en consistentie tussen de takken te waarborgen. Figuur 2 laat een klassediagram van de metadata in de standaard zien. Onder Overheid.nl Webmetadata wordt het totaal van klassen en subklassen verstaan De namen van klasse NL-meta en de subklassen NL.meta.DC+, NL.DC+ en NL.meta.Extended hebben hun oorsprong in het rapport Designing a National Standard for Discovery Metadata (RAND, december 2004). Er zijn twee mogelijkheden voor de implementatie van de NL-meta klasse op het hoogste niveau, hier voorgesteld door de NL-meta.Extended subklasse links en de NL-meta.DC+ subklasse rechts. De NL-meta.Extended subklasse kan bestaan uit ieder gestructureerd metadatasysteem (zie Appendix B), terwijl de NL-meta.DC+ subklasse beperkt is tot de specifieke verzameling van DC afgeleide elementen en verfijningen die in de volgende paragraaf worden besproken. Dit raamwerk betekent dat een metadataverzameling plat of gestructureerd kan zijn. Om een metadataverzameling te creëren kiest de webmetadatamanager in een organisatie eerst tussen de gestructureerde of de platte subklasse van de NL-meta klasse op het hoogste niveau. Indien de platte NL-meta.DC+ subklasse wordt gekozen dan wordt de lijst van elementen in de volgende paragraaf gekozen, en het resultaat is vergelijkbaar met het Dublin Core model. Deze benadering zal voorlopig waarschijnlijk door de meeste organisaties worden gekozen. Als een organisatie echter behoefte heeft aan een meer flexibele benadering dient deze te kiezen voor de gestructureerde NL-meta.Extended subklasse. Hiermee kan de organisatie een gestructureerde verzameling metadata opbouwen met gebruik van een relationele database (RDB), objecten, een semantische web, of andere geschikte technieken. Voorbeeld: om gebeurtenissen in de levenscyclus van documenten voor te stellen (b.v. 13

17 De Overheid.nl Webmetadata standaard creatie, publicatie, vrijgave, herziening, ongeldigverklaring) kan een objectgeoriënteerde structuur worden gedefinieerd. In een dergelijke structuur bestaat iedere genoemde gebeurtenis uit een aantal verbonden subelementen zoals oorzaak, datum, verantwoordelijke partij, bijdragende partijen, status, resultaat, enz. Ook zou een organisatie die al Topic Maps of een andere gestructureerde benadering gebruikt voor het weergeven van haar informatie de voorkeur kunnen geven aan het definiëren van metadata met een gestructureerde subklasse van NL-meta.Extended subclass. De enige beperking is dat elke gestructureerde verzameling van metadata altijd een representatie moet omvatten van elk van de metadataelementen uit de NL-meta.DC+ tak van de standaard, en een beschrijving van het verband (mapping) tussen de twee representaties. Dit betekent dat elke NL-meta verzameling metadata minimaal de elementen beschreven in de NL-meta.DC+ tak dient te omvatten. Hierdoor wordt de semantische interoperabiliteit en consistentie tussen de takken verzekerd. Iedere NL-meta klasse dient te bestaan uit ofwel een NL-meta.Extended subklasse of een NL-meta.DC+ subklasse, maar waarschijnlijk niet beide, om te verzekeren dat een bepaalde verzameling metadata geen conflicterende metadata bevat die wordt gerepresenteerd door zowel elementen afgeleid van DC als een andere gestructureerde representatie. NL-Meta NL-meta.Extended NL-meta.DC+ Overig Object-georieënteerd Semantisch web (NB: deze zouden een nieuwe implementatie vormen van NL-meta.DC+) Figuur 2: Optioneel gestructureerde benadering van metadata Aangezien de gestructureerde tak van de standaard een representatie van een platte NL-meta.DC+ verzameling metadata kan omvatten, kan een gestructureerde verzameling metadata zowel gestructureerde als ongestructureerde metadata omvatten. Voorbeeld: een RDB metadata representatie zou ofwel één tabel voor elk NL-meta.DC+ element of verfijning kunnen bevatten, ofwel één tabel met alle NL-meta.DC+ elementen en verfijningen als kolommen (data-elementen). Verder zou een objectgeoriënteerde representatie één object kunnen bevatten waarvan de attributen overeenkomen met de NL-meta.DC+ elementen en verfijningen. Een organisatie die nog geen behoefte heeft aan een benadering op basis van gestructureerde metadata kan kiezen voor de rechtertak van het model, met de eenvoudige NL-meta.DC+ benadering. Mocht zich in de toekomst de behoefte aan een structuur voordoen dan kan deze verzameling metadata worden vervangen door een gestructureerde benadering (linkertak van het model) door elk van de bestaande NL-meta.DC+ elementen te representeren in de nieuwe gestructureerde verzameling metadata, en dan de gewenste gestructureerde metadata toe te voegen. Zo kunnen de meeste organisaties de structuurmogelijkheden van de standaard negeren en deze toepassen als afgeleide van Dublin Core. Een organisatie die echter eisen heeft die niet worden afgedekt door de DC benadering kan de linkertak van de standaard kiezen om gestructureerde metadata te creëren, nu of in de toekomst als de behoefte zich voordoet. Deze uitbreidingsmogelijkheid is 14

18 De Overheid.nl Webmetadata standaard veel flexibeler en krachtiger dan het normale mechanisme ter verfijning van DC. (Indien nodig kunnen verfijningen nog steeds worden toegevoegd aan de rechtertak van de standaard, om de elementen van NL-meta.DC+ uit te breiden). Alleen de ongestructureerde NL-meta.DC+ versie van de standaard wordt in dit handboek verder uitgewerkt. De gestructureerde NL-meta.Extended tak dient later uitgewerkt te worden door de afzonderlijke organisaties of COI's die een specifieke behoefte hebben aan gestructureerde metadata De elementen Tabel 1 geeft uitleg van de codes die aangeven of een element in Tabel 2 verplicht is: Tabel 1 Verplichting codes Code Engelse terminologie Betekenis M Mandatory Verplicht MiA Mandatory if Applicable Verplicht indien van toepassing R Recommended Aanbevolen O Optional Optioneel Admin Administrative Administratief De laatste code (Admin) betreft elementen die moeten worden opgenomen voor het basisbeheer van de documenten. Met uitzondering van deze elementen omvat de standaard verder alleen elementen die een rol spelen bij de ontsluiting. Records management elementen vallen hier dus buiten aangezien ze de verantwoordelijkheid zijn van records management. Als er echter, zoals eerder besproken, geen records management functie is in een organisatie ten tijde van de eerste implementatie van een webmetadata systeem, dan moeten de Admin elementen worden verzameld of gecreëerd, naast de ontsluitingselementen van de standaard. Dit is om te verzekeren dat het toegangsdomein haar vervangende digitale records management functie kan vervullen (beschreven in paragraaf 3.4). Als er wel een digitale records management functie is hoeft het toegangsdomein deze Admin elementen niet te creëren of onderhouden aangezien records management dan haar eigen metadata beheert voor administratief gebruik. Elk element en elke verfijning in Tabel 2 wordt voorafgegaan door een indicatie van de bron. In de meeste gevallen is deze indicatie DC voor Dublin Core, maar elementen overgenomen van uitbreidingen van de DC standaard zijn gemerkt als OVERHEID om aan te geven dat het de Nederlandse versie van deze overgenomen elementen is, of dat het gaat om elementen die door Advies.Overheid zijn toegevoegd op basis van ervaring uit eerdere (pilot)projecten. De namen en betekenissen van deze OVERHEID-elementen kunnen verder ontwikkeld worden met de Overheid.nl Webmetadata standaard, zonder noodzakelijk in de pas te blijven met de elementen die de oorspronkelijke bron vormden in andere standaarden. 15

19 De Overheid.nl Webmetadata standaard Ten behoeve van de volledigheid wordt hieronder de oorsprong van deze OVERHEID elementen en verfijningen gespecificeerd. Elementen gemerkt egms komen uit de Britse nationale standaard, elementen gemerkt CEN uit de CEN Workshop, en elementen gemerkt FI uit de Finse nationale standaard. De elementen zijn: egms: date.nextversiondue, date.updatingfrequency, subject.category, subject.keyword, subject.person, subject.processidentifier, subject.programme, subject.project,,status, accessibility, mandate, preservation and right.copyright; FI: contributor.personalname, contributor.corporatename, creator.personlname, creator.corporatename; CEN: type.aggregation. Advies Overheid.nl: type.administrativebody, type.organisation. De kolom Codeersysteem geeft weer of invoeren van een codeersysteem (gecontroleerde trefwoordenlijst) aanbevolen wordt. Appendix A bevat uitgebreide definities en besprekingen van elk element en de verfijningen daarvan, en voorbeelden. 16

20 De Overheid.nl Webmetadata standaard Tabel 2 De elementen Schema Element naam Verfijning Codeersysteem Verplichting DC Date Y M DC Date created DC Date valid DC Date available DC Date issued DC Date modified OVERHEID Date nextversiondue OVERHEID Date updatingfrequency Y DC Language Y M DC Subject Y M OVERHEID Subject category Y OVERHEID Subject keyword Y OVERHEID Subject person OVERHEID Subject processidentifier OVERHEID Subject programme OVERHEID Subject project DC Title M DC Title alternative OVERHEID Title abbreviation DC Audience Y MiA DC Audience educationlevel DC Coverage Y MiA DC Coverage spatial DC Coverage temporal DC Creator Y MiA OVERHEID Creator personalname OVERHEID Creator corporatename DC Identifier Y MiA DC Identifier bibliographiccitation DC Publisher Y MiA DC Type Y MiA OVERHEID Type administrativebody OVERHEID Type aggregation Y OVERHEID Type organisation Y DC Format Y R DC Format extent DC Format medium OVERHEID Status Y R OVERHEID Accessibility O DC Contributor Y O OVERHEID Contributor personalname 17

21 De Overheid.nl Webmetadata standaard Schema Element naam Verfijning Codeersysteem Verplichting OVERHEID Contributor corporatename DC description O DC description tableofcontents DC description abstract OVERHEID mandate O DC relation Y O DC relation isversionof DC relation hasversion DC relation isreplacedby DC relation replaces DC relation isrequiredby DC relation requires DC relation ispartof DC relation haspart DC relation isreferencedby DC relation references DC relation isformatof DC relation hasformat DC relation conformsto DC source Y O OVERHEID preservation Admin DC rights Y Admin OVERHEID rights copyright Tabel 3 Alle elementen, verplichtingen en herkomst Element Verplichting In Dublin Core Element Set 1 Accessibility O Nee afkomstig uit egms 2 Audience MiA Nee afkomstig uit egms 3 Contributor O Ja 4 Coverage MiA Ja 5 Creator MiA Ja 6 Date M Ja 7 Description O Ja 8 Format R Ja 9 Identifier MiA Ja 10 Language M Ja 11 Mandate O Nee afkomstig uit egms 12 Preservation Admin Nee afkomstig uit egms 13 Publisher MiA Ja 14 Relation O Ja 15 Rights Admin Ja 16 Source O Ja 17 Status R Nee afkomstig uit egms 18 Subject M Ja 19 Title M Ja 20 Type MiA Ja 18

22 De Overheid.nl Webmetadata standaard Tabel 4 Verplichte elementen Element Date Language Subject Title Audience Coverage Creator Identifier Publisher Type Verplichting M M M M MiA MiA MiA MiA MiA MiA Tabel 5 Aanbevolen elementen Format Status Voor het gebruik van hoofdletters in de naamgeving van de elementen en elementverfijningen is gebruik gemaakt van de Case Policy for DCMI Term Names (zie Overwegingen voor de selectie van de elementen en verfijningen De algemene motivering voor de selectie van de elementen en verfijningen ter opname in de metadataverzameling is: met uitzondering van de Admin elementen worden alleen elementen opgenomen die bij de ontsluiting voldoende baat opleveren om de inspanningen voor hun creatie en beheer de moeite waard te maken. Men dient hierbij in gedachten te houden dat de eerste versie van deze standaard bedoeld is om verder te worden ontwikkeld op basis van de ervaring en wisselwerking tussen informatieleveranciers op alle overheidsniveaus in Nederland. In veel gevallen zijn elementen en verfijningen ongewijzigd overgenomen uit DC (of van DC afgeleide initiatieven) aangezien deze initiatieven al uitgebreid onderzocht, getest en beoordeeld zijn. Zo zijn bijvoorbeeld veel subject (onderwerp) -verfijningen overgenomen omdat deze algemeen toepasbaar zijn. Vele andere verfijningen werden echter afgewezen omdat ze te specifiek waren gericht op records management of de behoefte van een bepaald land. De namen van de uit andere standaarden overgenomen elementen en verfijningen zijn gehandhaafd, zelfs als ze niet geheel overeenkomen met de Nederlandse situatie. De reden hiervoor is dat het beter leek het internationale gebruik te volgen dan nieuwe namen te introduceren. Indien nodig kunnen deze namen in een latere versie van de Overheid.nl Webmetadata standaard worden gewijzigd. In de tabel is de Engelse schrijfwijze behouden (vertaling zou tot verwarring leiden) maar voor de volledigheid wordt daarachter telkens tussen haakjes de Nederlandse vertaling geplaatst. De date (datum) verfijningen in DC en de afgeleide standaarden kunnen problematisch zijn. Binnen de grenzen van een plat metadatamodel is het moeilijk een gebeurtenis gedurende de levensduur van een document voor te stellen als bestaande uit alle relevante attributen (b.v. datum, oorzaak, betrokkenen, resultaat, enz.). Verder kunnen bepaalde verfijningen van de datum (zoals valid (geldig)) een datumbereik vereisen, wat moeilijk past in het platte DCmodel met enkelvoudige waarden. Desondanks zijn alle datumverfijningen uit DC en egms die verband houden met de ontsluiting overgenomen in de Overheid.nl Webmetadata verzameling. De NL-meta.Extended tak van de standaard (zie paragraaf 4.1) kan worden 19

23 De Overheid.nl Webmetadata standaard gekozen indien een organisatie meer complexe datumreeksen of -bereiken of gebeurtenissen moet weergeven. Records management datumverfijningen zoals dateaccepted (DC), datecopyrighted (DC), datesubmitted (DC), acquired (egms), cutoffdate (egms), declared (egms), en closed (egms) zijn echter niet opgenomen. In navolging van de algemeen geaccepteerde best practices, is date vereist. Zoals gebruikelijk geldt die verplichting alleen voor de publicatiedatum, niet voor de additionele data verfijningen. Het element language (taal) is verplicht in de Nederlandse situatie, er van uitgaande dat de taal van een document niet op voorhand kan worden aangenomen. Instellingen die in het algemeen bepaalde soorten documenten in het Nederlands, of het Engels, uitgeven kunnen geschikte standaardwaarden kiezen voor dit element van de betreffende documentsoorten. Het element subject (onderwerp) en de verfijningen category (categorie), Trefwoordkeyword trefwoord), person (persoon), processidentifier procesverwijzing), programme (programma), en project zijn overgenomen uit egms. In navolging van het algemene gebruik is subject verplicht. Om het aantal afzonderlijke elementen in de Overheid.nl Webmetadata standaard te minimaliseren is er geen afzonderlijk element function (functie) opgenomen. Een dergelijk element maakt echter wel deel uit van andere standaarden op basis van DC, zoals de Australische AGLS. Informatie over de overheidsfunctie waar een document betrekking op heeft kan nuttig zijn bij de ontsluiting, indien er een thesaurus van overheidsfuncties wordt gebruikt als gecontroleerde woordenlijst. Functionele informatie over een document kan worden opgegeven in een category of keyword verfijning van het subject-element. Het element title (titel) en de bijhorende verfijning alternative zijn overgenomen uit DC. Zoals algemeen geaccepteerd is title verplicht. De OVERHEID-verfijning abbreviation is toegevoegd en dient te worden gebruikt indien het document ook onder haar afkorting bekend staat. Dit kan bijvoorbeeld van toepassing zijn op wetten en regelingen waarvan de naam regelmatig wordt afgekort. Een voorbeeld van de toepassing hiervan is te vinden in het consolidatiehandboek van het wetgevingsproject voor de lokale overheid ( Handleiding Consolidatie, versie 13 augustus 2004 ). Het element audience (doelgroep) is opgenomen met als enige DC-verfijning educationlevel (opleidingsniveau), hoewel het noodzakelijk kan zijn andere verfijningen toe te voegen om andere attributen van doelgroepen in Nederland voor te stellen. audience is MiA (verplicht indien van toepassing), omdat het om nuttig te zijn voor de ontsluiting beschikbaar moet zijn voor al de documenten waar het van toepassing op is. Het element coverage (dekking) is MiA omdat dit (waar van toepassing) wordt beschouwd als bijzonder belangrijk voor de ontsluiting. Voorbeeld: bij geconsolideerde wetgeving wordt coverage gebruikt bij beantwoording van de vraag in welke periode is/was deze versie van de tekst geldig? terwijl bij vergunningen coverage het antwoord geeft op de vraag in welk gebied is de vergunning van toepassing? De elementen creator (auteur) en publisher (uitgever) zijn beide opgenomen omdat ze vaak verschillend zijn. Hoewel overheidsinstellingen er vaak van uitgaan dat ze zowel Uitgever als Auteur zijn, worden de meeste documenten in de private sector toegeschreven aan hun auteurs, en hebben daarnaast een uitgever. Er mag één van deze elementen ontbreken, maar dan moet de andere worden opgegeven (in ieder geval voor elk afzonderlijk document), vandaar dat ze beide MiA zijn. (NB: in dit geval is MiA niet geheel nauwkeurig omdat het de bedoeling is dat ten minste één van deze twee elementen altijd moet worden opgegeven). De Finse verfijningen personalname (persoonsnaam) en corporatename (organisatienaam) worden gebruikt voor het onderscheid tussen personen en organisaties. Hoewel de naamgeving van deze verfijningen niet ideaal is lijkt het beter verfijningsnamen te 20

24 De Overheid.nl Webmetadata standaard gebruiken die al algemeen in gebruik zijn, en geen nieuwe te bedenken. Deze verfijningen worden ook gebruikt voor contributor (bijdragevan). Het identifier (verwijzing) element is MiA in plaats van verplicht, om het mogelijk te maken informatie te beschrijven die niet aanwezig is in één enkele, afzonderlijke bron, en dus geen bestandsidentificatie heeft. In alle gevallen waar een identificatie beschikbaar is dient deze te worden opgegeven. De DC-verfijning bibliographiccitation (bibliografischcitaat) is ook overgenomen voor dit element aangezien dergelijke citatie-informatie voor een document aanzienlijk kan bijdragen aan de ontsluiting. Het element type is overgenomen uit DC met de CEN-verfijning aggregation, welke verwijst naar het aggregatieniveau van een document (samenvatting, overzicht, gedetailleerd rapport, ruwe data, enz.). Dit element is Mandatory if Applicable; het is alleen verplicht indien het een document is dat voorkomt in een codeersysteem (gecontroleerde woordenlijst). Echter, de OVERHEID-versie van het type.organisation element is toegevoegd door Advies Overheid.nl, in overeenstemming met het beleid van Advies Overheid.nl en de Voorlichtingsraad (VoRa). De verfijning administrativebody (bestuursorgaan) is eveneens niet overgenomen uit een bestaande standaard, maar toegevoegd door Advies Overheid.nl, in overeenstemming met de Handleiding Consolidatie, versie 13 augustus In deze consolidatiehandleiding voor het project Decentrale regelgeving op Internet is dit element verplicht. Gezien het bredere gebied beslagen door dit handboek zijn deze twee verfijningselementen MiA - indien het beschikbaar is dan is het relevant voor de ontsluiting en dient het element te worden opgegeven. Het element format (formaat) is overgenomen uit de DC-standaard, samen met de betreffende verfijningen. Format is Recommended omdat het in veel gevallen van nut is bij ontsluiting van informatie. Het element status is overgenomen uit egms, omdat het algemeen toepasselijk lijkt te zijn en mogelijk nuttig is bij de ontsluiting. Het is echter aanbevolen omdat het niet altijd relevant is bij de ontsluiting van een document, zelfs als het op dat document van toepassing is. Het element accessibility (toegankelijkheid) is overgenomen uit egms. Daar is het bedoeld om in de toekomst kinderen te beschermen door de toegang tot websites en applicaties te beperken die geen geaccepteerd label hebben. In Nederland wordt niet verwacht dat dit element in de toekomst wettelijk vereist wordt. Er wordt momenteel gewerkt aan een waarmerk voor toegankelijkheid. Dit wordt gefinancierd door het Ministerie van VWS. Dit element zou dan kunnen worden gebruikt in verband met dit waarmerk. Gezien de voorlopige status is het element optioneel in de standaard. Het element contributor (bijdragevan) (zie creator) is optioneel omdat er niet altijd andere medewerkers zijn of niet relevant zijn bij de ontsluiting. Het element description (omschrijving) is overgenomen uit DC met de verfijningen tableofcontents (inhoudsopgave) en abstract (samenvatting). In overeenkomst met de best practices is Omschrijving optioneel aangezien het niet altijd iets nuttigs toevoegt aan title en subject. Aangezien het een tekstbeschrijving is, is het mogelijk minder nuttig bij de ontsluiting dan trefwoorden in het subject-element. Het element mandate (mandaat) is overgenomen uit egms, maar de egms verfijningen van dit element zijn niet overgenomen aangezien deze specifiek waren toegespitst op de Britse wetgeving. Dit element is optioneel omdat het mogelijk niet bijdraagt aan de ontsluiting van bepaalde documenten. 21

25 De Overheid.nl Webmetadata standaard Het element relation (relatiemet) is met alle verfijningen overgenomen uit DC. De aanvullende verfijningen van relation in egms zijn weggelaten aangezien deze minder nuttig zijn voor ontsluiting en meer zijn gericht op records management. Dit element is optioneel omdat het mogelijk niet bijdraagt aan de ontsluiting van een bepaald document. Het element source (bron) is overgenomen uit DC (waarin het geen verfijningen heeft). Het is optioneel omdat het mogelijk niet bijdraagt aan de ontsluiting van bepaalde documenten. Het element preservation (bewaring) is overgenomen uit egms, en de verfijningen dienen te worden gebaseerd op specifieke archiefbeheerstrategieën, zoals besproken in paragraaf 3 van Appendix C. Dit element wordt in het algemeen niet beschouwd als relevant voor de ontsluiting (hoewel het dat in sommige gevallen wel kan zijn). In verband met de problemen van het bewaren van online informatie is dit element opgenomen als een Adminelement dat verschaft wordt door het toegangsdomein indien dit tijdelijk voorziet in de records management functie, zoals besproken in paragraaf 3.4. Het element rights (rechten) is overgenomen uit DC met de egms verfijning copyright(auteursrechten). Informatie over de rechten wordt in het algemeen niet beschouwd als relevant voor de ontsluiting (hoewel het dan in sommige gevallen wel kan zijn). Het is echter opgenomen als een Admin-element voor het geval door de beheerder van de webinformatie voorzien wordt in een tijdelijke records management functie, zoals besproken in paragraaf 3.4. Hoewel metadata met betrekking tot de Wet openbaarheid van bestuur (WOB), zoals weergegeven in diverse verfijningen van het rights element in andere van DC afgeleide standaarden, vereist kan zijn voor bepaalde records management toepassingen, zijn dergelijke verfijningen niet opgenomen in deze eerste versie, om de eenvoud te bevorderen. De egms elementen disposal en location zijn niet opgenomen omdat ze niet van belang lijken voor de ontsluiting. Location zou een relevante zoekterm kunnen zijn voor offline objecten, als een gebruiker wil bepalen welke documenten beschikbaar zijn op locaties in de buurt. Het lijkt echter dat dit in de meeste gevallen niet nuttig zal zijn. Hoewel deze elementen relevant kunnen zijn voor records management zijn ze daar niet noodzakelijk voor en ze zijn dan ook niet opgenomen als admin-elementen in de nederlandse standaard. Appendix A omvat codeersystemen voor elk element of verfijning waarvoor dergelijke systemen (of schema s) beschikbaar voor zijn. Zoals boven reeds genoemd, is het waarschijnlijk het beste de uiteindelijke keuze van een specifiek codeersysteem voor elk metadata-element over te laten aan de betreffende COI. Zo kunnen gebruikers met geavanceerde eisen voor het weergeven van geografische informatie (d.w.z. ruimtelijke dekking) bijvoorbeeld de NEN3610 standaard of een vergelijkbare standaard kiezen Codeersystemen en gecontroleerde woordenlijsten Voor veel algemene metadata-elementen (zoals datum- en landencodes) bestaan breed codeersystemen en gecontroleerde woordenlijsten. De aanbevolen codeersystemen zijn opgenomen in de tabellen in Appendix A. Sommige informatieleveranciers gebruiken echter gespecialiseerde metadata-elementen, wat betekent dat de gecontroleerde woordenlijsten moeten worden overgenomen of ontwikkeld door de betreffende COI's. Zo kunnen gebruikers met geavanceerde eisen voor het weergeven van geografische informatie (d.w.z. ruimtelijke dekking) bijvoorbeeld de NEN 3610 of een vergelijkbare benadering kiezen. De standaard specificeert geen specifieke woordenlijsten voor elke gespecialiseerde toepassing. De bedoeling is dat een 22

26 De Overheid.nl Webmetadata standaard gecontroleerde woordenlijst op het laagst mogelijke niveau wordt gekozen of ontwikkeld, d.w.z. door de kleinst mogelijke COI die de meeste of alle gebruikers van de woordenlijst omvat. Het nationale COI clearinghouse moet de coördinatie hiervan ondersteunen door aan te geven welke woordenlijsten er al bestaan voor een bepaalde toepassing. Het clearinghouse moet ook de centrale coördinatie verzorgen om belanghebbenden te helpen bepalen of er al een geschikte COI voor de ontwikkeling van een gecontroleerde woordenlijst is, en zo niet, helpen bij de oprichting daarvan. Zoals boven besproken, dient de keuze tussen het overnemen of de ontwikkeling van woordenlijst afgestemd te worden tussen de toegangs- en records management domeinen om de consistentie te verzekeren en dubbel werk te minimaliseren. De ontwikkeling en het gebruik van gecontroleerde woordenlijsten is voor de meeste metadata-elementen relatief eenvoudig. Het gebruik van trefwoorden in een subject-element is echter en speciaal, en bijzonder belangrijk, geval. Op het moment is het zoeken op trefwoorden een van de meest gebruikte technieken. Deze wordt toegepast door webzoekmachines zoals Google. Het probleem is echter dat dergelijke vrije-tekst zoekmachines eenvoudigweg zoeken naar woorden in de inhoud van documenten of webpagina s, zonder te weten of ze bedoeld zijn als trefwoord. Goed gekozen trefwoorden in subject-velden kunnen de vindbaarheid aanmerkelijk verbeteren, indien ze bereikbaar zijn voor de zoekinstrumenten. Om te verzekeren dat een zoekmachine een informatiebron vindt op basis van de trefwoorden in een subject-metadata-element van de bron, moeten deze trefwoorden als zodanig door de zoekmachine bereikbaar en herkenbaar zijn. Mogelijk moeten zoekmachines gewijzigd worden om metadata-elementen zoals subject te kunnen vinden en herkennen. Dit zal vooral het geval zijn als metadata-elementen niet zijn opgenomen in de online documenten, maar in een aparte database staan. De zoekmachines moeten dan gewijzigd worden om deze databases te kunnen benaderen. Tenslotte dienen taxonomieën, thesauri en ontologieën ontwikkeld te worden voor het ondersteunen van het beheer van trefwoorden. De ontwikkeling van deze terminologiesystemen moet tussen overheidsinstanties gecoördineerd worden door middel van geschikte COI's en de steun van het nationale COI clearinghouse. 23

27 HOOFDSTUK 5. Implementatiegids Hoewel in het bovenstaande al diverse belangrijke aspecten van de implementatie zijn aangestipt (vooral in paragraaf 3.3), bevat dit hoofdstuk enkele wenken voor de implementatie van de ongestructureerde elementen besproken in dit handboek. Indien een organisatie uitgebreide metadata-mogelijkheden nodig heeft, zoals beschreven in Appendix B, zullen er nadere inspanningen nodig zijn voor het definiëren van een gestructureerde verzameling metadata op basis van de NL-meta.Extended tak van de standaard (zie paragraaf 4.1) Algemene strategie voor webmetadata Hieronder volgt een mogelijk stappenplan voor het implementeren van een strategie voor webmetadata. Sommige organisaties hebben mogelijk al enkele van deze stappen uitgevoerd, terwijl andere organisaties hiermee nog zullen moeten beginnen. a. Definieer een functie voor het beheer van webmetadata voor de organisatie en wijs, indien mogelijk, een webmetadatamanager aan die de middelen heeft deze functie uit te voeren. De rol van deze functie wordt hieronder in meer detail beschreven. b. Identificeer, in samenwerking met records management (archiefbeheer), de vereiste metadata-verfijningen en gecontroleerde woordenlijsten (schemes) om de online documenten en diensten van de organisatie voor gebruikers toegankelijk te maken. c. Als er al relevante metadata bestaat in het records management domein van de organisatie, probeer die dan zo volledig mogelijk over te nemen voor de webpublicaties. Zorg daarbij (voor zover nodig) voor vertaling, aanpassing van de interpunctie en eventueel de structuur. Op die mannier kunnen allerlei dubbele registraties voorkomen worden. d. Als er metadata nodig is in het toegangsdomein welke niet beschikbaar is in het records management domein, bespreek dit dan met records management en spreek af waar de ontbrekende metadata wordt aangevuld. e. Creëer, indien nodig, ontbrekende metadata die specifiek nodig is voor de toegang en mogelijk niet van belang is voor records management. f. Als er geen digitale records management functie is binnen de organisatie, of als de bestaande functie ontoereikend of ongeschikt is voor het beheer van de online documenten van het toegangsdomein, voorzie dan in een tijdelijke recordsmanagement functie om deze rol binnen het toegangsdomein te vervullen. Voorbeeld: veel online documenten zijn kopieën van fysieke records en het is mogelijk niet de taak van records management om deze kopieën te beheren. Het toegangsdomein moet mogelijk voorzien in een vervangende records management functie voor het beheer van dergelijke online publicaties. Dit vereist mogelijk het implementeren van de Admin metadata-elementen zoals weergegeven in paragraaf 4.2 (en Appendix A). 24

28 Implementatiegids g. Gebruik waar mogelijk gecontroleerde woordenlijsten om de toegang te verbeteren: Identificeer bestaande woordenlijsten van toepasselijke COI's via het COI clearinghouse. Coördineer het gebruik van woordenlijsten met records management. Gebruik internationale standaarden, waar van toepassing. h. Als er geen bestaande woordenlijst is die de behoeften afdekt, werk dan samen met records management en/of een geschikte COI om een nieuwe gecontroleerde woordenlijst op te stellen De webmetadata management functie De eerste taak van de webmetadata managementfunctie is het ontwikkelen van een Webmetadata managementplan voor de organisatie. Dit plan dient ten minste de volgende onderwerpen te bevatten: Een algemene strategie voor webmetadata. Een strategie voor de verzameling, creatie en management van webmetadata. Een strategie voor de interne en externe coördinatie van webmetadata. Een strategie voor de kwaliteitsbeheersing van webmetadata. Een strategie om webmetadata toegankelijk te maken voor zoekinstrumenten. Een actieplan om de strategieën te implementeren De webmetadata manager dient samen te werken met de interne beheerders van websites, records management, bedrijfsfuncties en publicaties. Er dient ook samengewerkt te worden met Advies Overheid.nl en relevante COI's voor het ontwikkelen, implementeren en beheren van een algemene strategie voor webmetadata, zoals hierboven besproken. Deze strategie dient de verwachte rollen en interacties te omschrijven tussen de functies voor records management, functioneel beheer, bibliotheek, publicaties, website beheer en webmetadata management. De strategie voor de verzameling, creatie en beheer van webmetadata dient aan te geven waar webmetadata wordt gevonden of ontwikkeld, waar het wordt beheerd, en of het wordt opgenomen in de online resources of apart wordt onderhouden in een database met metadata (metadatabase). De strategie dient beleid te omvatten voor het omgaan met modificaties of updates van de metadata. De juiste methode is geen directe wijzigingen te maken in de metadata, en in plaats daarvan de modificaties of updates op te nemen in nieuwe metadata. (Dit komt overeen met boekhouden waar de boekingen nooit direct worden gewijzigd, maar via correctieboekingen.) Appendix C (paragraaf 1) omvat een bespreking van de afwegingen tussen ingebedde (embedded) en afzonderlijke metadata. Er dient te worden voldaan aan de onderstaande criteria, welke benadering ook wordt gekozen: Metadata moet in logisch verband blijven staan met de beschreven bronnen. Metadata moet toegankelijk zijn voor zoekinstrumenten. Wijzigingen van metadata moeten het risico van vervuiling van documenten minimaliseren. Er moeten voorzieningen zijn voor het eenvoudig actualiseren van relevante metadata. 25

29 Implementatiegids De coördinatiestrategie voor interne en externe webmetadata dient te voorzien in procedures voor het coördineren van de keuzes over webmetadata en te verzekeren dat webmetadata consistent is tussen diverse interne websites van de organisatie en andere relevantie organisaties (b.v. door gebruik/deelname van /aan geschikte COI's). De strategie voor het kwaliteitsbeheer van de webmetadata dient te voorzien in procedures voor het omgaan met wijzigingen in het webmetadatasysteem dat gebruikt wordt binnen de organisatie. Verder dienen er voorzieningen te zijn voor het bewaken en evalueren van het naleven van het beleid neergelegd in de strategieën voor het verzamelen, creëren en beheren van de webmetadata. Kwaliteitsbeheer moet voorzieningen bieden voor de voortdurende verificatie van het gebruik en de vorm van de juiste webmetadata, evenals validatie van de juiste relaties met de beschreven documenten. Het webmetadata managementplan dient te verzekeren dat webmetadata toegankelijk is voor zoekinstrumenten, om de ontsluiting te ondersteunen. Dat kan er toe leiden dat instrumenten geselecteerd dan wel (verder) ontwikkeld moeten worden om webmetadata toegankelijk te maken voor (het bestaande) zoekinstrument. Het kan ook nodig zijn zoekinstrumenten te ontwikkelen die ingebedde (embedded) metadata binnen online documenten kunnen herkennen, of metadata in afzonderlijke metadatabases kunnen bereiken. Tenslotte dient er een stappenplan te worden ontwikkeld voor het toewijzen van rollen en planningen met de taken voor de implementatie van het beheerplan voor webmetadata. De webmetadata manager dient toe te zien op en coördineert de inspanningen voor het consistent verzamelen, creëren en gebruiken van webmetadata en bewaakt de interoperabiliteit tussen diverse interne websites en andere instanties, overheidsportalen en relevante COI's. Dit omvat tevens de coördinatie van het gebruik en de ontwikkeling van verfijningen (refinements) en uitbreidingen van webmetadata, codeersystemen en gecontroleerde woordenlijsten, taxonomieën, thesauri en ontologieën met de betrokken COI's Andere bronnen De volgende gidsen en handboeken zijn elders geschreven ter ondersteuning van nationale metadata activiteiten. Verder zijn verwijzingen opgenomen naar lopende activiteiten voor het ontwikkelen van ontologieën en andere benaderingen voor het organiseren van terminologie. Sommige van deze inspanningen zijn niet beperkt tot ontsluiting, en de adviezen kunnen ook betrekking hebben op records management, archivering en andere aspecten. Hoewel dit handboek een poging is de meest relevante informatie en adviezen uit deze en vele andere bronnen te combineren kunnen organisaties die webmetadata in Nederland invoeren verdere suggesties en voorbeelden in sommige van deze referenties vinden: egms - AGLS - Australian Government Locator Service Implementation Guide: Minnesota richtlijnen voor DC: Nordic Metadata Project richtlijnen voor DC: CEN Workshop Agreement: cwa nov DC - Dublin Core usage guide: W3C - Worldwide Web Consortium semantische web informatie: 26

30 Implementatiegids 5.4. Afsluitende opmerkingen Om de ontsluiting van en toegang tot overheidsinformatie te verbeteren zou webmetadata moeten worden geïmplementeerd en beschikbaar gesteld voor de zoekinstrumenten. Op hun beurt moeten deze zoekinstrumenten de metadata gebruiken om het hun gebruikers gemakkelijker te maken de gewenste informatie te ontsluiten en er toegang tot te krijgen. Dit handboek heeft als doel te voorzien in de motivatie, redenen en adviezen die nodig zijn voor de implementatie van de nationale standaard voor metadata, een essentiële stap in dit proces. De verwachting is echter dat dit handboek en de Overheid.nl Webmetadata standaard zich verder ontwikkelen door hun toepassing en evaluatie, en met de verbetering van online zoeken toegangssystemen. Dit handboek en de standaard moeten dan ook naar behoefte worden herzien om het bereiken van het doel te ondersteunen: het vergroten van de transparantie van de overheid in Nederland. 27

31

32 Referenties AGLS, National Archives of Australia, AGLS Metadata Element Set Part 1: Reference Description, version 1.3, 2002 CEN Workshop Agreement, CWA 14860, Dublin Core egovernment Application Profiles, November 2003 DCMI Usage Board; DCMI Metadata Terms; November 2003 Dempsey Lorcan., Weibel Stuart L., The Warwick Metadata Workshop: A framework for the deployment of resource description, D-Lib Magazine, ISSN , July/August 1996 EAD (Encoded Archival Description), bekeken op 8 juli 2004 European Commission, IDA, European Interoperability framework, for pan-european egovernment services. IDA working document. v4.2, January 2004 GILS (Global Information Locator Service), bekeken in juni 2004 ICTU, Advies Overheid.nl, Handleiding Consolidatie, versie 13 augustus 2004 IPSMS, The Irish Public Service Standard User Guide, version 1.1, June 2002 ISO, ISO 23081/TC, Technical Specification, first edition ISO/IEC Information technology Metadata registries (MDR) Part 3: Registry metamodel and basic attributes, 2003 NZGLS Maintenance Agency, NZGLS Usage Guide Version 2.1, April 2004 OASIS work on search interoperability and Topic Maps, Office of the e-envoy, e-gms for websites, version 2.0, May 2003 RAND Europe, Designing a National Standard for Discovery Metadata, 2004 Treasury Board of Canada, TBITS 39.1: Treasury Board Information Management Standard, Part 1: Government On-Line Metadata Standard, November 8, 2001a Treasury Board of Canada, TBITS 39.2: Treasury Board Information Management Standard Part 2: Controlled Vocabulary Standard, November 8, 2001b 29

33 Appendix A: Beschrijving van de elementen Deze appendix bevat gedetailleerde definities en besprekingen van alle elementen en verfijningen van de NL-meta.DC+ tak (zie paragraaf 4.1). De indeling en inhoud van deze definities zijn grotendeels gebaseerd op de Britse egms standaard. De Overheid.nl Webmetadata standaard omvat een deelverzameling van de elementen en verfijningen van egms, en tevens enkele elementen en verfijningen uit andere bronnen. De elementen worden in het Engels weergegeven om vergelijking en consistentie met internationale standaarden te waarborgen. Bij de naamgeving van elementen in de OVERHEID namespace is de 'DCMI Policy on Naming Terms' gehanteerd als uitgangspunt (zie ook Elk element wordt beschreven door de volgende negen velden: Definitie Een korte tekst ter beschrijving van het element. Verplichting Geeft aan of het element Mandatory (M, verplicht), Mandatory if Applicable (MiA, Verplicht indien van Toepassing), Recommended (R, Aanbevolen), Optional (O, Optioneel), of Administrative (Admin, Administratief), is, zoals beschreven in paragraaf 4.2. Doel Korte bespreking van het doel van het element. Opmerkingen Aanvullende informatie over het element en de verfijningen. Niet te verwarren met Uitleg van het verschil tussen dit element en vergelijkbare elementen. Verfijningen (refinements) Beschrijft optionele subelementen van het element voor het toevoegen van meer specifieke waarden. Voorbeelden Laat zien hoe het element toegepast kan worden om diverse documenten te beschrijven. HTML syntax Laat zien hoe het element moet worden opgenomen in de kop van een HTML bestand als de metadata in online documenten wordt ingebed. NB: het opnemen van deze informatie in de standaard betekent niet dat het gebruik van metadata ingebed in 30

34 Appendix A: Beschrijving van de elementen documenten de voorkeur verdient over het afzonderlijk bijhouden van metadata, zie ook paragraaf 2 van Appendix C. Voor nadere informatie over de HTML en XML syntax van DC elementen en het gebruik van het XML Resource Description Format (RDF) wordt u verwezen naar Voorbeelden van codeersystemen (encoding schemes) Bevat voorbeelden van codeersystemen (gecontroleerde woordenlijsten, formats, enz.) die gebruikt kunnen worden om waarden op te geven van het element of de verfijningen daarvan. [Voorbeelden in vierkante haken zijn niet direct van toepassing op de Nederlandse situatie maar geven verwijzen naar mogelijke codeersystemen.] Deze voorbeelden zijn niet uitputtend of prescriptief. De organisaties welke deze standaard implementeren zijn verantwoordelijk voor het kiezen van geschikte codeersystemen voor elk metadataelement, in overleg met de betreffende COI's. Deze voorbeelden zijn uitsluitend bedoeld om de keuze te ondersteunen. 31

35 Appendix A: Beschrijving van de elementen accessibility (toegankelijkheid) Definitie Verplichting Doel Opmerkingen Beschrijft de beschikbaarheid en bruikbaarheid van de bron voor specifieke groepen. Optional (Optioneel) Stelt diegenen die niet in staat zijn alle informatiebronnen te gebruiken het zoeken te beperken tot bronnen die aan hun eisen voldoen. In de toekomst zullen websites en applicaties voor de bescherming van kinderen in sommige landen geen toegang geven tot documenten die geen geschikt label hebben. Het gebruikt van dit element wordt mogelijk verder ontwikkeld op basis van de aanbevelingen van het DC Metadata Initiative, W3C en andere internationale organisaties die zich met dit aspect bezig houden. Informatie over de W3C Platform for Internet Content Selection (PICS) labels is beschikbaar in de Guidelines for UK Government Websites op en de Internet Content Rating Association website Informatie en instrumenten voor het implementeren van het W3C Web Accessibility Initiative (WAI) is beschikbaar op de W3C WAI site. In Nederland wordt dit element mogelijk gebruik om te voorzien in een waarmerk voor toegankelijkheid. De ontwikkeling hiervan wordt gefinancierd door het Ministerie van VWS. Niet te verwarren met audience (doelgroep) accessibility (toegankelijkheid) geeft aan of sommige gebruikers fysiek in staat zullen zijn toegang te krijgen tot de bron of het te openen; audience (doelgroep) geeft de gebruikers aan voor wie de inhoud is bedoeld. rights (rechten) rights (rechten) geeft aan wie de bron mag inzien; accessibility (toegankelijkheid) geeft aan wie daadwerkelijk in staat is het in te zien. Verfijningen - Voorbeelden Toegang tot een website voor personen die voldoen aan de W3C WAI rating Level AA : accessibility (toegankelijkheid): AA HTML syntax <meta name= OVERHEID.accessibility content= Double-A > Voorbeelden van codeersystemen ICRA Nederlands waarmerk in ontwikkeling bij het Ministerie van VWS. 32

36 Appendix A: Beschrijving van de elementen audience (doelgroep) Definitie Verplichting Doel Opmerkingen Niet te verwarren met Klasse van entiteiten voor wie de bron bedoeld is of nuttig is. Mandatory if Applicable (Verplicht indien van toepassing) Maakt het de gebruiker mogelijk het niveau of hoofdonderwerp van de bron aan te geven, maakt het mogelijk een zoekactie te filteren op informatie geschikt voor de doelgroep. Een klasse van entiteiten kan worden bepaald door de auteur/maker, de uitgever of een derde. accessibility (toegankelijkheid) audience (doelgroep) geeft de gebruikers aan op wie de inhoud is gericht; Toegankelijkheid geeft aan of bepaalde gebruikers de bron kunnen bereiken of gebruiken. Verfijningen Voorbeelden HTML syntax Voorbeelden van codeersystemen rights (rechten) audience (doelgroep) geeft aan de gebruiker aan voor wie de inhoud bestemd is, terwijl rechten de gebruiker informeert over een lijst van personen of groepen die de bron mogen zien. educationlevel Algemene uitspraak over de context van de opleiding of training. (opleidingsniveau) Voor een website om bedrijven met elkaar in contact te brengen audience (doelgroep): bedrijven Voor een document waar ouders naar zoeken om het aan hun kinderen voor te lezen audience.educationlevel (doelgroep.opleidingsniveau): Lagere school <meta name= OVERHEID.audience content= Bedrijven > <meta name= OVERHEID.audience.educationlevel content= Lagere School > [e-gms Audience Encoding Scheme (e-gmsaes) IEEE LOM Audience Encoding Scheme 33

37 Appendix A: Beschrijving van de elementen contributor (bijdragevan) Definitie Verplichting Doel Opmerkingen Entiteit verantwoordelijk voor het bijdragen aan de inhoud van het document. Optional (Optioneel) Maakt het gebruikers mogelijk een document te vinden waar een bepaalde organisatie of persoon aan heeft bijgedragen. Voorbeelden van een contributor: een persoon, organisatie of dienst. In principe moet de naam van een contributor de eenheid aanduiden. Neem alle personen en organisaties op die een belangrijke rol speelden bij het samenstellen van de inhoud van het document, maar die niet als auteur/maker worden beschouwd. Om te zorgen dat deze gegevens hun betekenis behouden indien de eenheid die de bijdrage heeft geleverd niet meer bestaat, of de medewerker sindsdien een andere functie heeft gekregen dient de volledige hiërarchie te worden opgenomen. Voorbeeld: afdeling, divisie, sectie, team. Het kan de voorkeur verdienen de medewerker onpersoonlijk te maken door de functietitel op te geven in plaats van de naam. Neem zo mogelijk de volledige contactgegevens op, vooral als deze elders niet zijn opgenomen. Gebruik indien mogelijk algemene adressen in plaats van persoonlijke, omdat deze minder vaak wijzigen, b.v. Niet te verwarren met Verfijningen Voorbeelden HTML syntax Voorbeelden van codeersystemen Afkortingen zijn mogelijk nietszeggend voor gebruikers. Gebruik de volledige officiële titel van de organisatie, of creëer een link naar een woordenlijst of nadere uitleg. creator creator is de persoon of groep die verantwoordelijk is voor de intellectuele of creatieve inhoud van het document. Een contributor speelt een belangrijke rol maar is niet primair of algemeen verantwoordelijk voor de inhoud. personalname Naam van een persoon (PersoonsNaam) corporatename Naam van een organisatie (BedrijfsNaam) Voor een document geredigeerd door een medewerker van een afdeling contributor (bijdragevan): geredigeerd door Gemeente Rotterdam, Financiële Groep, Middelenbeheerder, Voor notulen geschreven door een secretaris, waarbij de voorzitter van de vergadering verantwoordelijk is voor de inhoud en als auteur wordt opgegeven: contributor (bijdragevan): concept geschreven door Gemeente Utrecht, Regeneratieteam, Secretaris, <meta name= DC.contributor content= geredigeerd door Gemeente Rotterdam, Financiële Groep, Middelenbeheerder, > <meta name= DC.contributor content= concept geschreven door Gemeente Utrecht, Regeneratieteam, Secretaris, > Activiteitenindex: officiële afdelingsnamen en afkortingen [Government Data Standards Catalogue 34

38 Appendix A: Beschrijving van de elementen coverage (dekking) Definitie Verplichting Doel Opmerkingen Bereik van de inhoud van het document/bron. Mandatory if Applicable (Verplicht indien van toepassing) Maakt het de gebruiker mogelijk een zoekactie te beperken tot bronnen met betrekking tot een bepaalde plaats of tijd. Kan worden beschouwd als een subelement van het element subject (onderwerp). Coverage (dekking) omvat meestal een plaats (plaatsnaam of geografische coördinaten), periode (periodenaam, datum, of datumbereik) of jurisdictie (zoals een bij name genoemde administratieve eenheid). De aanbevolen best practice is het kiezen van een waarde uit een gecontroleerd woordenlijst (b.v. de Thesaurus of Geographic Names [Getty Thesaurus of Geographic Names, Waar mogelijk dienen plaatsen met een eigennaam of periodes gebruikt worden in plaats van numerieke aanduidingen zoals coördinaten of periodes. Niet te verwarren met Verfijningen Voorbeelden Elke datum dient in het standaard W3C formaat: jjjj-mm-dd te worden geschreven. In gevallen waarin meer gedetailleerde informatie nodig is over de betrokken periode (b.v. statistische of geografische informatie) kan een verdere structurering nodig zijn, zie ook de voorbeelden. date (datum) coverage.temporal (dekking.intijd) verwijst naar de periode waar de inhoud van de bron betrekking op heeft, niet de datum van creatie of publicatie. subject (onderwerp) coverage (dekking) bevat informatie over het territorium en de periode waarop de inhoud van de bron betrekking heeft. Het kan worden beschouwd als een subelement van het subject (Onderwerp) element. In sommige gevallen zal het nuttig zijn dezelfde informatie op te nemen in beide elementen. spatial (ruimtelijk) temporal (intijd) Voor een lijst drogisten binnen een bepaald postcodegebied coverage.spatial (dekking.ruimtelijk) : 1634 Gestructureerde waarden van coverage.spatial (Dekking.ruimtelijk): Postcode x-y coordinaten Gestructureerde waarden van coverage.temporal: Aanvangsdatum Einddatum Dataverzamelingsperiode Status van de startdatum van de verzameling Startdatum van de verzameling Einddatum van de verzameling Gebruik de puntkomma om waarden te scheiden Voor een lijst drogisten binnen meerdere postcodegebieden coverage.spatial (dekking.ruimtelijk): 1634 AD; 1634 AE; 1634 AF Verfijning van een herhalend element voor meerdere waarden Voor een lijst drogisten binnen meerdere postcodegebieden coverage.spatial (dekking.ruimtelijk): 1634 AD coverage.spatial (dekking.ruimtelijk): 1634 AE coverage.spatial (dekking.ruimtelijk) 1634 AF Voor een document over gebeurtenissen tussen 13 maart 2000 en 13 maart 2001 coverage.temporal (dekking.intijd): / HTML syntax Voorbeelden van codeersystemen Voor een document over gebeurtenissen in Leiden gedurende de jaren 50 coverage.temporal (dekking.intijd) 1951/1960 Coverage.spatial (dekking.ruimtelijk): Leiden, Nederland <meta name= DC.coverage content= NL > <meta name= DC.coverage.temporal content= 1951/1960 > <meta name= DC.coverage.spatial content= 1634 AD > spatial (ruimtelijk): DCMI Point Identificeert een punt in de ruimte m.b.v. geografische coördinaten DCMI Box Identificeert een punt in de ruimte m.b.v. geografische afgrenzing ISO 3166 Landcodes 02iso-3166-code-lists/index.html TGN The Getty Thesaurus of Geographic Names ISO FGDC Content Standard for Digital Geospatial Metadata (CSDGM): 35

39 Appendix A: Beschrijving van de elementen ONS SNAC Database (Standard Names and Codes) FCO (Geographical names and information) list of country names. Binnenkort beschikbaar op en temporal (intijd): W3CDTF (schema op DCMI Period Specificatie van de begrenzing van een periode 36

40 Appendix A: Beschrijving van de elementen creator (auteur of maker) Definitie Verplichting Doel Opmerkingen Eenheid met de hoofdverantwoordelijkheid voor het creëren van de inhoud van het document. Mandatory if Applicable (Verplicht indien van toepassing) Maakt het de gebruiker mogelijk documenten te vinden die geschreven of anderszins gecreëerd zijn door een bepaalde persoon of organisatie. Voorbeelden van een creator: persoon, organisatie of dienst. Normaal dient de naam van een Auteur/maker te verwijzen naar een eenheid. Niet te verwarren met Verfijningen Voorbeelden HTML syntax Voorbeelden van codeersystemen Om het mogelijk te maken een document te vinden indien de afdeling die het heeft geschreven niet meer bestaat of de auteur daar niet meer werkzaam is dient de volledige hiërarchie te worden opgenomen, b.v. afdeling, divisie, sectie, team, enz. Het zal vaak de voorkeur verdienen de auteur onpersoonlijk te maken door de functietitel op te geven in plaats van de naam. publisher (uitgever) De creator (auteur/maker) is degene verantwoordelijk voor de intellectuele of creatieve inhoud van het document. De publisher (uitgever) is de persoon of organisatie die het document beschikbaar stelt. Men zou b.v. contact opnemen met de creator (auteur) om te vragen waarom een bepaald beleid is opgesteld of ingevoerd wordt. Men zou contact opnemen met de publisher (Uitgever) voor nadere informatie over het bestellen van extra exemplaren of het auteursrecht. In veel gevallen zullen de creator (auteur) en de publisher (uitgever) identiek zijn. contributor (bijdragevan) De creator (auteur/maker) is degene verantwoordelijk voor de intellectuele of creatieve inhoud van het document. Een contributor (bijdragevan) speelt wel een belangrijke rol maar heeft geen primaire of algemene verantwoordelijkheid voor de inhoud. personalname Naam van een persoon (persoonsnaam) corporatename Naam van een organisatie (organisatienaam) Voor een document waar de adjunct-directeur primair verantwoordelijk is voor de inhoud creator (auteur): ICTU, egem Unit, Adjunct-directeur, Voor een document geschreven door een externe consultant creator (auteur): RAND-Europe, Consultant, <meta name= DC.creator content= ICTU, egem eenheid, Adjunct-directeur, > <meta name= DC.creator content= RAND-Europe, Consultant, > Activiteitenindex: officiële afdelingsnamen en afkortingen [Government Data Standards Catalogue 37

41 Appendix A: Beschrijving van de elementen date (datum) Definitie Verplicht Doel Opmerkingen Niet te verwarren met Verfijningen Voorbeelden Datum die verband houdt met een gebeurtenis in de levenscyclus van een bron. Mandatory (Verplicht) Maakt het de gebruiker mogelijk een document te vinden door de zoekactie te beperken tot een bepaalde datum, b.v. de datum waarop een bron beschikbaar werd gesteld. In de meeste gevallen verwijst date naar de creatie of beschikbaarstelling van de bron. De aanbevolen best practices voor het coderen van de datum zijn gedefinieerd in een profiel van ISO 8601 [Date and Time Formats, W3C Note, en gebaseerd op de JJJ-MM-DD structuur. coverage.temporal (dekking.intijd) verwijst naar data met betrekking tot het document zelf, en niet de informatie in de bron. Voorbeeld: voor een document over de overheid in de 18e eeuw wordt 18e eeuw opgenomen in coverage, en de publicatiedatum in date. available (beschikbaar) Datum of periode waarin beschikbaar komt of kwam. created (creatie) Creatiedatum van de bron. issued (uitgegeven) Datum waarop de bron formeel werd uitgegeven. modified (gewijzigd) Datum waarop de bron werd gewijzigd nextversiondue Datum waarop de bron zal worden vervangen. (volgendeversieverwacht) updatingfrequency (bijwerkfrequentie) Hoe vaak de bron wordt bijgewerkt valid (geldigheid) Datum/periode waarop/gedurende welke de bron geldig is. Voor een persbericht dat is goedgekeurd en aan de redacties verzonden op 2 december 2002 maar dat pas om 11:00 de volgende dag wordt vrijgegeven date.created (datum.creatie) : date.issued (datum.uitgegeven): T11:00 Voor een consultatiedocument voltooid op 20 maart 2003 dat aan het ministerie werd vrijgegeven voor commentaar op 30 maart, en op 10 april op de website werd gezet voor algemene consultatie met een sluitdatum van 30 mei date.created (datum.creatie) : date.available (datum.beschikbaar) : date.issued (datum.uitgegeven) : date.valid (datum.geldig) : / Voor een home page die op 6 januari 2000 bereikbaar werd date.issued (datum.uitgegeven): HTML syntax Voorbeelden van codeersystemen Dezelfde home page in mei, na wijziging date.issued (datum.uitgegeven: date.modified (datum.gewijzigd: <meta name= DC.date.issued scheme= W3CDTF content= > <meta name= DC.date scheme= W3CDTF content= > W3C (schema op ISO (bijwerkfrequentie) 38

42 Appendix A: Beschrijving van de elementen description (omschrijving) Definitie Omschrijving van de inhoud van de bron. Verplichting Optional (Optioneel) Doel Helpt de gebruiker te bepalen of de bron aan de behoefte voldoet. Opmerkingen Niet-limitatieve voorbeelden van de omschrijving: samenvatting, inhoudsopgave, verwijzing naar een grafische voorstelling van de inhoud, of een vrije tekst omschrijving van de inhoud. Niet te verwarren met Verfijningen abstract (samenvatting) Samenvatting van de inhoud van de bron. tableofcontents Lijst van onderdelen van de inhoud van de bron. (inhoudsopgave) Voorbeelden description (omschrijving): Brochure voor ouders over de invoer van de verplichte afspraken over onderwijs thuis HTML syntax Voorbeelden van codeersystemen description.tableofcontentents (omschrijving.inhoudsopgave) : Documentgeschiedenis/Inleiding/Achtergrond/Lijst van onderdelen/algemene principes/onderdelen <meta name= DC.description content= De elementen en verfijningen ter structurering van de metadata gebruikt door de publieke sector in Nederland, en een inleiding > <meta name= DC.description content= Brochure voor ouders over de invoer van de verplichte afspraken over onderwijs thuis > <meta name= DC.description.tableOfContents content= Beleid en werkgebied/ondersteuning van de implementatie/managementprocessen/wijzigingsbeheer/voldoen aan de OVERHEID standaard > 39

43 Appendix A: Beschrijving van de elementen format (formaat) Definitie Verplichting Doel Opmerkingen Niet te verwarren met Verfijningen Voorbeelden HTML syntax Voorbeelden van codeersystemen Fysieke of digitale vorm van de bron. Optional (Optioneel). Maakt het de gebruiker mogelijk te zoeken naar bronnen in een bepaald format. In de meeste gevallen zal format het medium of de afmetingen van het document of de bron aangeven. De afmetingen kunnen ruimtelijk of in tijd zijn. Het formaat kan worden gebruikt voor het aangeven van de vereiste software, hardware of andere voorzieningen voor het tonen of gebruiken van de bron. De aanbevolen best practice is het kiezen van een waarde uit een gecontroleerde woordenlijst (b.v. de lijst van Internet Media Types [ welke de formaten van computermedia beschrijft). type format verwijst naar het fysieke format van de bron, en Type heeft betrekking op de inhoud. Format omvat documenten op papier of in elektronische vorm, en de software die nodig is om de bron te benaderen. Type beschrijft de categorie van de informatie in de bron, b.v. notulen, jaarverslag, personeelsadvertentie. extent (Omvang) Grootte of tijdsduur van de bron. medium Materiaal of fysieke drager van de bron. Voor een webpagina in HTML: Format (format): Text/html <meta name= DC.format content= Microsoft Word > <meta name= DC.format.medium scheme= IMT content= image/gif > <meta name= DC.format.extent content= 27 KB > Internet Media Type (IMT) Scheme 40

44 Appendix A: Beschrijving van de elementen identifier (verwijzing) Definitie Eenduidige verwijzing naar de bron binnen een bepaalde context. Verplichting Mandatory if Applicable (Verplicht indien van toepassing). Doel Maakt het een gebruiker mogelijk te zoeken naar een specifieke bron of een versie. Opmerkingen De aanbevolen best practice is identificeren van de bron door middel van een cijfer- of karakterreeks op basis van een formeel identificatiesysteem. Voorbeelden van dergelijke systemen zijn de Uniform Resource Identifier (URI), waaronder de Uniform Resource Locator (URL), Digital Object Identifier (DOI) en het International Standard Book Number (ISBN). Niet te verwarren met - Verfijningen (bibliograohiccitation Bibliografische verwijzing naar de bron. (bibliografischcitaat) Voorbeelden identifier (verwijzing): [URI] /contactus/contact.asp HTML syntax <meta name= DC.identifier content= _v1 > Voorbeelden van codeersystemen URI of ISBN ISSN DOI 41

45 Appendix A: Beschrijving van de elementen language (taal) Definitie Verplichting Doel Opmerkingen Taal van de intellectuele inhoud van de bron. Mandatory (Verplicht) Maakt het gebruikers mogelijk hun zoekactie te beperken tot documenten in een bepaalde taal. De aanbevolen best practice voor de waarde van het language-element wordt beschreven in RFC 3066 [RFC 3066, dat samen met ISO 639 [ISO 639, codes (language tags) van twee en drie letters definieert voor de belangrijkste talen. Voorbeelden: en of eng voor Engels, akk voor Accadisch, en en-gb voor Brits Engels. Het gebruik van taalcodes vereenvoudigt het invoeren van het language-element. De meeste gebruikers zullen de betreffende codes snel leren. De meeste systemen kunnen ingesteld worden op de volledige naam van de taal, wat meer gebruikersvriendelijk is. Het gebruik van het language-element is vooral van belang voor documenten die op het Internet worden gezet. Het is van onschatbare waarde voor gebruikers om zoekacties te beperken tot documenten die voor hen nuttig zijn. Niet te verwarren met Verfijningen Voorbeelden Voor een document geschreven in het Engels language (taal): en HTML syntax Voorbeelden van codeersystemen Voor een Poolse vertaling van een oorspronkelijk in het Engels geschreven bron (gebruik relatie om een koppeling te maken met de oorspronkelijke Engelse versie) language (taal): [ISO 639-1] pl <meta name= DC.language scheme= ISO content= en > <meta name= DC.language scheme= ISO content= pl > ISO 639-1; ISO

46 Appendix A: Beschrijving van de elementen mandate (mandaat) Definitie Wettelijk of ander mandaat (competentie) waaronder de bron werd geproduceerd. Verplichting Optional (Optioneel) Doel Verduidelijkt het wettelijke of andere mandaat voor de activiteit waardoor de bron werd geproduceerd. Opmerkingen Er dient een afweging te worden gemaakt tussen het nut van deze informatie en de kosten van het verzamelen er van. Niet te verwarren met rights (rechten) Uitzonderingen op het recht van de betrokkene om informatie in te zien zijn opgenomen in het rights-element. Verfijningen - Voorbeelden HTML syntax Voorbeelden van codeersystemen preservation (bewaring) Definitie Verplichting Doel Opmerkingen Mandate (Mandaat): 1990 volkstelling <meta name= OVERHEID.mandate content= 1990 volkstelling > - Informatie ter ondersteuning van de bewaring en het behoud van een bron op de lange termijn. Administrative (Administratief) Maakt het huidige en toekomstige gebruikers mogelijk het document te lezen, interpreteren en gebruiken. Bewaring zal voornamelijk worden gebruikt door records managers en anderen betrokken bij de langdurige opslag van officiële documenten. Dit element zal worden gebruikt ter ondersteuning van migratie tussen ministeries, behoud en archivering van de bron, en om aspecten van de herkomst van de bron te bewaren bij overdracht van het beheer (zorgplicht) van een ministerie naar het Rijksarchief. Er kunnen diverse benaderingen worden gebruikt voor het bewaren en behouden van elektronische documenten en de onderdelen daarvan bij migratie tussen technische platforms. Informatie over de technische omgeving waarin de originele objecten geproduceerd zijn vergroot de kans van slagen van een dergelijke benadering aanmerkelijk en kan digitale archeologische reconstructie mogelijk maken indien het beheer in het verleden onvoldoende was en de kosten gerechtvaardigd zijn. Een deel van deze informatie zal later mogelijk worden opgenomen in een archiefbeschrijving of documentatie over het beheer van de documenten. Zie Appendix C, paragraaf 3 van dit handboek voor een nadere bespreking. Niet te verwarren met relation.hasformat (relatie.heeft formaat) Dit verwijst naar een ander document dat grotendeels dezelfde intellectuele inhoud heeft, maar gepresenteerd is in een ander formaat. format (formaat) Bevat informatie over het formaat van de bron voor de verwerking op dit moment. Bewaring voorziet in aanvullende informatie voor de bewaring en behoud op lange termijn. Verfijningen - Voorbeelden preservation (bewaring): Microsoft Word XP HTML syntax <meta name= OVERHEID.preservation content= Microsoft Word 2002 ( ) SP-1 > <meta name= OVERHEID.preservation content= Microsoft Word XP > Voorbeelden van - codeersystemen 43

47 Appendix A: Beschrijving van de elementen publisher (uitgever) Definitie Verplichting Doel Opmerkingen Eenheid verantwoordelijk voor het beschikbaar maken van de bron. Mandatory if Applicable (Verplicht indien van toepassing) Maakt het mogelijk een bron te vinden die is uitgegeven door een bepaalde organisatie of persoon. Ook nuttig voor gebruikers die de bron opnieuw willen uitgeven of op andere wijze willen gebruiken, of een exemplaar van de bron willen bestellen. Voorbeelden van publisher (uitgever): persoon, organisatie, dienst. In het algemeen dient de naam van de uitgever te verwijzen naar de eenheid. Publisher (uitgever) wordt hier in de breedste zin gebruikt, zodat een organisatie welke een informatiebron op een website plaatst de uitgever is, zelfs als de bron niet in gedrukte vorm beschikbaar is. De publisher (uitgever) is de persoon of organisatie met welke een gebruiker contact dient op te nemen voor toestemming voor het opnieuw uitgeven van de informatie in de bron, of het verkrijgen van exemplaren in een ander formaat. Niet te verwarren met creator (auteur/maker), contributor (bijdragevan) De publisher (uitgever) is de organisatie of persoon die de bron beschikbaar maakt aan het publiek (op de traditionele wijze door het uitgeven van een boek, of door het plaatsen van de bron op een website). Een gebruiker zou contact op kunnen nemen met de Uitgever om extra exemplaren te bestellen of auteursrechten te bespreken. De creator (auteur/maker) en tot op zekere hoogte ook de contributor (bijdragevan) zijn verantwoordelijk voor de inhoud van de bron. Een gebruiker zou dan ook contact opnemen met de auteur om na te vragen waarom het beleid beschreven in de bron werd ontwikkeld, of hoe er aan de discussie werd bijgedragen. In veel gevallen zullen de publisher (uitgever) en de creator (auteur/maker) identiek zijn. Verfijningen Voorbeelden publisher (uitgever): Advies Overheid.nl, Nieuwe Duinweg 24-26, 2687 AD, Den Haag, HTML syntax <meta name= DC.publisher content= Advies Overheid.nl, Nieuwe Duinweg 24-26, 2687 AD, Den Haag, > Voorbeelden van codeersystemen Activiteitenindex: officiële afdelingsnamen en afkortingen [Government Data Standards Catalogue 44

48 Appendix A: Beschrijving van de elementen relation (relatie) Definitie Verplichting Doel Opmerkingen Niet te verwarren met Verfijningen Voorbeelden Verwijzing naar een gerelateerd document. Optional (Optioneel) Maakt het een gebruiker mogelijk andere documenten te vinden die in verband staan met dit document, of om afzonderlijke documenten te combineren tot een verzameling. De aanbevolen best practice is te verwijzen naar de bron door middel van een cijfer- of karakterreeks op basis van een formeel identificatiesysteem. source (bron) Gebruik source niet indien het juister is deze gegevens op te nemen in het relation element, d.w.z. het is mogelijk nauwkeuriger gebruik te maken van de verfijning relation.isversionof (is versie van). relation.hasformat (relatie.heeft formaat) verwijst naar een ander document dat in principe dezelfde intellectuele inhoud heeft in een ander formaat. conformsto (voldoetaan) Verwijzing naar een bestaande standaard waar de bron aan voldoet. hasformat (heeftformaat) Het beschreven document bestond eerder dan het verwijsdocument, het is in principe dezelfde intellectuele inhoud in een ander formaat. hasversion (heeftversie) Het beschreven document heeft een versie-editie of -aanpassing: het verwijsdocument. haspart (heeftonderdeel) Het beschreven document omvat het verwijsdocument fysiek of logisch. isformatof (isformaatvan) Het beschreven document heeft dezelfde intellectuele inhoud als het verwijsdocument, maar in een ander formaat. ispartof (isonderdeelvan) Het beschreven document is een fysiek of logisch onderdeel van het verwijsdocument. isreferencedby Het beschreven document wordt aangehaald, geciteerd of anderszins (WordtAangehaaldDoor) naar toe verwezen door het verwijsdocument. isreplacedby Het beschreven document is vervangen door het verwijsdocument. (isvervangendoor) isrequiredby Het beschreven document is vereist door het verwijsdocument om (isvereistdoor) daarvan de functie, levering of samenhangendheid van de inhoud te ondersteunen. isversionof (iseenversievan) references (verwijzingen) requires (vereist) Het beschreven document is een versie-editie of -aanpassing van het verwijsdocument. Een wijziging in versie geeft een significante wijziging van de inhoud aan, niet slechts een verschil in formaat. NB: omvat tevens vertalingen van documenten. Het beschreven document haalt het verwijsdocument aan, of citeert het of verwijst er naar. Het beschreven document vereist het verwijsdocument ter ondersteuning van de functie, levering of samenhangendheid van de inhoud. Het beschreven document vervangt het verwijsdocument. replaces (vervangt) Voor een publicatie met daarmee samenhangend persbericht relation (relatie): Persbericht , /news/press/ htm Voor een website welke een eerdere website met vergelijkbare inhoud vervangt relation.replaces (relatie.vervangt): Voor versie 2 van NLDC+, met verwijzing naar versie 1 Relation.isVersionOf (relatie.iseenversievan): /NET/NLDC+ _v1 Voor een document dat nummer 7 vormt in de serie Informatie Management relation.ispartof (relatie.isonderdeelvan): Informatie management reeks, nummer7 Voor een document dat een statistische informatie interpreteert, maar die informatie niet omvat relation.requires (relatie.vereist): X Voor een HTML document dat oorspronkelijk gedrukt was relation.isformatof (relatie.isformaatvan): [ISBN] HTML syntax Voorbeelden van codeersystemen Voor een XML schema document dat de beschikbaarheid van een ander XML schema document vereist als schema processor relation.requires (relatie.vereist): IR/SAelements-2002-v1.0 <meta name= DC.relation content= Persbericht , pers/ htm ><meta name= DC.relation.requires scheme= ISBN content= X > <meta name= DC.relation.isFormatOf scheme= ISBN content= > <meta name= DC.relation.hasFormat scheme= URI content= > URI ISBN ISSN 45

49 Appendix A: Beschrijving van de elementen rights (rechten) Definitie Verplichting Doel Opmerkingen Niet te verwarren met Informatie over rechten in en over de bron. Administrative (Administratief) Geeft aan wie gerechtigd is de bron geheel of gedeeltelijk in te zien, te kopiëren, opnieuw te distribueren, opnieuw uit te geven of anderszins te gebruiken. In het algemeen bevat een rights-element een verklaring betreffende het rechtenbeheer van een document, of een verwijzing naar een dienst welke dergelijke informatie levert. Rights-informatie omvat vaak intellectuele eigendomsrechten, auteursrechten en diverse andere eigendomsrechten. Indien het rights-element ontbreekt mag men geen aannames maken betreffende de status van deze en andere rechten met betrekking op de bron. accessibility toegankelijkheid geeft aan of bepaalde gebruikers in staat zijn de bron te bereiken of te gebruiken; rights geeft aan of dit aan hen toegestaan is. Verfijningen Voorbeelden HTML syntax Voorbeelden van codeersystemen audience audience (doelgroep) geeft aan voor wie de inhoud ontworpen is; rights geeft aan welke personen of groepen de bron mogen inzien. copyright Informatie en identificatie met betrekking tot het juridische eigendom en (auteursrechten) rechten betreffende (her)gebruik van het gehele of gedeeltelijke document. Voor een document waarvan het auteursrecht berust bij RAND-Europe: Copyright RAND-Europe <meta name= DC.rights.copyright content= Copyright RAND-Europe > <meta name= DC.rights content= Classified > Wetgeving - Wetgeving betreffende toegang tot overheidsinformatie omvat vaak een eigen codeersysteem W3C (schema op source (bron) Definitie Verwijzing naar een bron waar de huidige bron van afgeleid is. Verplichting Optional (Optioneel) Doel Maakt het de gebruiker mogelijk bronnen te vinden die ontwikkeld zijn met behulp van de inhoud van een bepaald ander document (b.v. alle documenten gebaseerd op een bepaalde verzameling statistieken). Opmerkingen De huidige bron kan geheel of gedeeltelijk zijn afgeleid van de source (het brondocument). De aanbevolen best practice is identificeren van het document door middel van een cijfer- of karakterreeks op basis van een formeel identificatiesysteem. Niet te verwarren met relation (relatie) Gebruik source (bron) niet indien het beter is deze informatie in het relation (relatie)-element op te nemen, d.w.z. als het nauwkeuriger is gebruik te maken van de verfijning relation.is (relatie.van).of relation.isversionof (relatie.is.versie.van). Verfijningen Voorbeelden Voor een rapport gebaseerd op cijfers verzameld gedurende een onderzoek source (Bron): Cijfers afgeleid van de studie van het Nationaal Archief door Het Convent van Archivarissen HTML syntax <meta name= DC.source content= Cijfers afgeleid van de studie van het Rijksarchief door de Raad van Archivarissen > <meta name= DC.source content= Standaard is afgeleid van het Dublin Core Metadata Initiative > Voorbeelden van URI codeersystemen ISBN ISSN 46

50 Appendix A: Beschrijving van de elementen status Definitie De toestand of status van de bron. Verplichting Recommended (Aanbevolen) Doel Maakt het de gebruiker mogelijk te zoeken naar een document aan de hand van de status daarvan. Kan ook worden gebruikt als referentie door een gebruiker die de status van de bron wil weten. Opmerkingen De status van een document omvat onder andere: De mate waarin het ontwikkeld of afgerond is, b.v. eerste concept, laatste document, afgerond document. Is het in afwachting van goedkeuring? Als het goedgekeurd is, door wie? Versienummer Doel van de bron. Dit is niet het doel van de inhoud (zie description), maar het doel in verband met de status van de bron. Niet te verwarren met Verfijningen Voorbeelden Voor een serie documenten geschreven voor de ontwikkeling van een beleidsstandpunt status: Concept v0.4 Voor openbare consultatie status: Versie 1.0 Voor publicatie HTML syntax <meta name= OVERHEID.status content= Concept v0.2 Voor openbare consultatie > <meta name= OVERHEID.status content= Versie 1.0 Voor publicatie > Voorbeelden van IEEE LOM Status Encoding Scheme codeersystemen 47

51 Appendix A: Beschrijving van de elementen subject (onderwerp) Definitie Verplichting Doel Opmerkingen Onderwerp uit de inhoud van de bron. Mandatory (Verplicht) Maakt het de gebruiker mogelijk te zoeken op het onderwerp van de bron. In het algemeen bevat het subject (onderwerp) trefwoorden of -zinnen of classificatiecodes om het onderwerp van de bron te beschrijven. De aanbevolen best practice is het kiezen van een waarde uit een gecontroleerde woordenlijst of een formeel classificatiesysteem. Er zijn twee veelgebruikte methodes voor het zoeken naar informatie: het doorlopen/navigeren (browsing/drill-down/navigation) door een gids (directory), en direct zoeken door een trefwoord in te voeren. De category (categorie) verfijning is bedoeld om de eerste methode te ondersteunen (doorlopen van een gids met brede klassen), terwijl de keyowrd (trefwoord)-verfijning het direct zoeken ondersteunt. De waarden voor alle subject-refinements (onderwerp-verfijningen) moeten worden gekozen uit codeersystemen: gecontroleerde woordenlijst, thesauri of lijsten van autoriteiten. Er zijn verschillende codeersystemen voor elke verfijning. Het is belangrijk elke waarde te merken met een tag om het codeersysteem aan te geven. Niet te verwarren met Verfijningen Voorbeelden HTML syntax Voorbeelden van codeersystemen Gebruik het niet-verfijnde subject-element (onderwerp-element) voor aanvullende, nietgecontroleerde termen indien deze de gebruikers ondersteunen bij het vinden van de informatie. type subject (onderwerp)-termen verwijzen naar het onderwerp van de bron. d.w.z. waar de bron over gaat, niet wat het is. Voorbeeld: gebruik kaart/map niet als subject (onderwerp) term indien de bron een landkaart is, maar neem kaart/map op in het type element. Gebruikt kaarten als subject (onderwerp) term indien de bron gaat over kaarten, kaarten maken, cartografie, enz. coverage (dekking) coverage (dekking) bevat informatie over de relatie tussen de inhoud van de bron en tijd en plaats. Dit kan worden beschouwd als een onderverdeling van Onderwerp. category (categorie) Indeling in vergelijkbare groepen van onderwerpen. Dienen gekozen te worden uit een gecontroleerde woordenlijst. keyword Woorden of termen gebruikt voor het zo nauw mogelijk beschrijven van het (trefwoord) onderwerp van de bron. Dienen gekozen te worden uit een gecontroleerd vocabulaire of lijst. person (persoon) Dient gebruikt te worden als de bron over een persoon gaat. NB: niet te verwarren met auteur/maker. processidentifier Verwijst naar een specifieke dienst of transactie, met behulp van een (procesiidentificatie) identificatie uit een erkende lijst. programme (programma) project Het bredere beleidsprogramma waar dit document direct betrekking op heeft. NB: denk aan de doelstelling. Niet gebruiken indien deze geen specifieke waarde heeft voor u of de gebruikers. Specifiek project waar dit document direct betrekking op heeft. NB: zie opmerking bij programme. Voor een website voor adviezen aan burgers die naar het buitenland reizen (herhaald element voor meerdere waarden) subject.category (onderwerp.categorie): Tourism subject.keyword (onderwerp.trefwoord): Reizen in het buitenland; Reisadviezen; Nederlandse ambassades; Consulaten <meta name= OVERHEID.subject.category scheme= ACTIND content= Informatiebeheer > <meta name= OVERHEID.subject.keyword scheme= CurriculumOnline content= NL-0383 > category: Activiteitsindex: lijst van taxonomische termen Nederlands Ministerie van Landbouw, Natuur en Voedselkwaliteit: thematische categorisatie (perspectieven) [Government Category List [SIC UK Standard Industrial Classification keyword: ERIC Educational Resources Information Centre thesaurus MeSH Medical Subject Headings LCSH Library of Congress Subject Headings [Seamlessuk subject taxonomy [National Curriculum metadata standard person: [Government Data Standards Catalogue 48

52 Appendix A: Beschrijving van de elementen title (titel) Definitie Verplichting Doel Opmerkingen Naam gegeven aan de bron. Mandatory (Verplicht) Maakt het de gebruiker mogelijk een document met een bepaalde titel te vinden of meer specifiek te zoeken. De titel wordt veel gebruikt als het belangrijkste referentiepunt in de lijst zoekresultaten. In het algemeen is de titel de naam waaronder de bron formeel bekend staat. Voor een alternatieve titel kan elke vorm van de titel die wordt gebruikt als alternatief worden toegevoegd, waaronder een naam waaronder de bron algemeen bekend staat, afkortingen en vertalingen. Als de officiële of formele titel van een document voor de burgers onbegrijpelijk is dan wordt aanbevolen dat er een aanvullende, duidelijke naam aan de bron wordt gegeven. Niet te verwarren met Verfijningen alternative) (alternatief) Elke vorm van de titel die als vervanging of alternatief voor de formele titel van de bron wordt gebruikt. abbreviation Afkorting van de titel van de bron. (afkorting ) Voorbeelden Voor een document dat algemeen bekend staat onder een informele titel title (titel): De Peter Krijgsman aanklacht: rapport van een aanklacht door Mr. Arend van Wolhoven te Delft title.alternative (titel.alternatief) : Het Wolhoven rapport Voor een lijst documenten met dezelfde titel maar verschillende versies. (Dit is veel nuttiger dan een lange lijst documenten die allemaal de titel Toelichting Belastingaangifte hebben). title (titel): Toelichting Belastingaangifte 2002 title (titel): Toelichting Belastingaangifte 2003 title (titel): Toelichting Belastingaangifte 2004 title (titel): Toelichting Belastingaangifte 2005 HTML syntax <meta name= DC.title content= e-government Nederlandse Metadata Standard versie 1 > <meta name= DC.title.alternative content= Overheid.nl Webmetadata-1 > Voorbeelden van codeersystemen 49

53 Appendix A: Beschrijving van de elementen type Definitie Verplichting Doel Opmerkingen Niet te verwarren met Aard of soort van de inhoud van de bron. Mandatory if Applicable (Verplicht indien van Toepassing) Maakt het de gebruiker mogelijk een bepaald soort document te vinden. Type omvat termen voor het beschrijven van algemene categorieën, functies, soorten of aggregatieniveaus van de inhoud. De aanbevolen best practice is het kiezen van een waarde uit een gecontroleerde woordenlijst (b.v. het DCMIType vocabulaire). Gebruik het format element om de fysieke of digitale vorm van de bron te beschrijven. Type.administrativeBody (type.bestuursorgaan): met name in de wetgeving is het belangrijk om te weten welk bestuursorgaan verantwoordelijk is: dit geeft een indicatie van het gewicht van de wetgeving. type: format (formaat): heeft betrekking op de fysieke vorm van de bron, waaronder de software gebruikt voor het creëren, lezen en bewerken. Type heeft betrekking op de inhoud van de bron. subject (onderwerp ) Type beschrijft wat de bron is, niet waar het over gaat. type.organisation / type.administrativebody (type.organisatie / type.bestuursorgaan): creator (auteur/maker) De creator (auteur) is de persoon of groep verantwoordelijk voor de intellectuele of creatieve inhoud van het document. Men zou bijvoorbeeld contact opnemen met de creator (auteur) om na te vragen waarom bepaald beleid is ontwikkeld of hoe het wordt geïmplementeerd. publisher (uitgever) De publisher (uitgever) is de persoon of organisatie die het document beschikbaar stelt. men zou bijvoorbeeld contact opnemen met de publisher (uitgever) met vragen over het bestellen van extra exemplaren of de auteursrechten. In veel gevallen zullen de publisher (uitgever), creator (auteur/maker) en het administrativebody (bestuursorgaan) identiek zijn. Verfijningen Voorbeelden contributor (bijdragevan) Een contributor (bijdragevan) speelt wel een belangrijke rol maar heeft geen primaire of algemene verantwoordelijkheid voor de inhoud. aggregation (aggregatie) Niveau van de bron in een hiërarchie. administrativebody Het bestuursorgaan dat de bron bepaald, bijvoorbeeld bij (bestuursorgaan) wetgeving. Mogelijke waarden voor een gemeente zijn bijvoorbeeld de burgemeester gemeenteraad. organisation (organisatie) Voor de notulen van een vergadering type: tekst/notulen (text/minutes) Verantwoordelijke organisatie, altijd geselecteerd uit een trefwoordenlijst (departement, provincie, gemeente, waterschap, etc.) Waarde blijft normaliter onveranderd voor de gehele website. Voor een kaart type: beeld/kaart (image/map) HTML syntax Voorbeelden van codeersystemen Verantwoordelijke gemeenteambtenaar die een bepaalde regeling in werking laat treden: type.administrativebody: burgemeester (burgomaster) <meta name= DC.type scheme= DCMIType content= minutes > <meta name= DC.type scheme= DCMIType content= maps > <meta name=overheid.administrativebody content= burgemeester. type: DCMI Type Activiteitenindex: lijst van informatietypes Ministerie van Landbouw, Natuur en Voedselkwaliteit: categorieën documenttypes [e-gms Type Encoding Scheme (e-gmstes) metadata_document.asp?docnum=679] type.organisation / type.administrativebody: Codeersysteem gebruikt in de Handleiding Consolidatie, versie 13 augustus

54 Appendix B: Gestructureerde metadata In deze appendix wordt het gebruik van gestructureerde metadata besproken. Deze gestructureerde metadata is in de standaard opgenomen door middel van de NL-meta.Extended optie. 1. Behoefte aan gestructureerde metadata Het breed aanvaarde Dublin Core metadata model (DCMI Usage Board, 2003) voorziet in een beperkte mate van uitbreiding door het toevoegen van verfijningen (refinements) aan de elementen of door het definiëren van codeersystemen (encoding schemes: syntaxcoderingen of gecontroleerde woordenlijsten). Zelfs met deze verfijningen blijft het echter een plat model waarbij weinig structurering mogelijk is. Dat wil zeggen dat alle elementen (title, creator, publisher, date, enz.) zich op hetzelfde niveau bevinden en niet gegroepeerd kunnen worden tot meer complexe verzamelingen van elementen, subelementen, subsubelementen, enz. De verfijningen van de DC-elementen (date.created, date.valid, enz.) voorzien beperkt in een tweede structuurniveau, maar maken echter geen algemeen bruikbare structuur op meerdere niveaus mogelijk. Zelfs zonder een dergelijke structuur heeft DC aanzienlijke voordelen boven het zoeken in vrije tekst, maar de toevoeging van structuur zou leiden tot een krachtiger metadatamodel. Er zijn meerdere redenen om structuur toe te voegen aan een metadata standaard. Deze kunnen worden onderverdeeld in drie categorieën: deelverzamelingen, inkapseling, en het beschrijven van complexe documenten of relaties. Kort gezegd maken deelverzamelingen het mogelijk verschillende groepen of deelverzamelingen te vormen van metadataelementen, b.v. voor administratie, records management, rechtenbeheer, of elementen om de levensduur van de informatiebronnen te verzekeren. Inkapseling voorziet in de behoefte metadata-elementen te combineren die niet alleen vergelijkbare functies hebben, maar nauw met elkaar verbonden zijn. Een voorbeeld hiervan is het concept van een gebeurtenis in de levensloop van een document: elke gebeurtenis heeft een aantal attributen zoals de aanleiding, datum, verantwoordelijke partij, andere medewerkers, status en resultaat, die allemaal gebundeld kunnen worden in een logische capsule zodat de gebeurtenis als één eenheid kan worden benaderd. Hoewel elementen en verfijningen in de geest van DC gebruikt zouden kunnen worden om elk van de attributen van een element (oorzaak, datum, resultaat, enz.) weer te geven, is er geen systeem voor het bundelen of inkapselen hiervan in een enkelvoudige voorstelling van een gebeurtenis. De geografische dekking is een ander voorbeeld dat hiermee in verband staat. Dit kan een meer complexe beschrijving vereisen dan mogelijk met een enkele of een klein aantal vooraf bepaalde elementverfijningen, b.v. arbitraire verzamelingen van coördinaten en plaatsaanduidingen. De laatste reden voor het voorzien in gestructureerde metadata houdt verband met het beschrijven van documenten of bronnen die meer complex zijn dan afzonderlijke statische objecten zoals afzonderlijke documenten of records, of complexe relaties tussen bronnen. Veel online informatiebronnen bestaan uit meerdere componenten, die een andere interpretatie/vertaling (toepassingsprogramma of viewer) vereisen om onderdeel uit te maken van het volledige resultaat dat gebruikers willen zien. In veel gevallen wordt online informatie 51

55 Appendix B: Gestructureerde metadata dynamisch aangemaakt door middel van toegang tot een database of GIS (Geographical Information System) of door het uitvoeren van programma s (Active Server Pages, Java Server Pages, enz.). Bovendien zoeken gebruikers vaak naar informatie, niet naar specifieke documenten of bronnen: ze weten mogelijk niet waar de gewenste informatie aanwezig is en zijn daar ook niet in geïnteresseerd. Een informatiesite die dergelijke vragen wil beantwoorden moet mogelijk informatiebronnen beschrijven die meerdere documenten, databases of zelfs websites omvatten. Bovendien leveren veel sites niet alleen informatie maar ook diensten, zoals interactieve formulieren of transacties om taken uit te voeren. Voorbeelden hiervan zijn het doen van een belastingaangifte, aanvragen van vergunningen, of verrichten van betalingen. Het gebruik van gestructureerde metadata is een effectief instrument voor het beschrijven van dergelijke samengestelde objecten en bronnen. Verder is het soms noodzakelijk complexe relaties te beschrijven tussen documenten, records, agents en activiteiten of gebeurtenissen (mogelijkheden voor het voorstellen van dergelijke relaties in het records management domein worden besproken in ISO ). 2. Verschillende opties voor gestructureerde metadata Er zijn diverse mogelijkheden voor het ontwerpen van gestructureerde metadata, waaronder de toepassing van een relationele database (RDB), objectgeoriënteerde (O-O) technieken (vaak geïmplementeerd bovenop een RDB), of een semantisch web (zoals Topic Maps). Een O-O benadering heeft alle mogelijkheden van een RDB, terwijl een semantisch web alle mogelijkheden heeft van de andere twee benaderingen. Een RDB-benadering van metadata zou kunnen bestaan uit een verzameling relationele tabellen, waarvan elke tabel informatie bevat over één metadata-element of -verfijning voor elk document. Door middel van verbindingen tussen de rijen van deze tabellen (b.v. referenties naar externe sleutels) kan een metadata-ontwerper de indruk wekken van gestructureerde deelverzamelingen of groepen van metadata zoals hierboven beschreven. De gebruikers krijgen toegang tot deze groepen metadata-elementen door middel van queries waarmee tabellen gekoppeld worden (zoals gebruik van join in relationele databases). Een O-O benadering zou een stap verder gaan door het vormen van groepen van metadataelementen die onder een naam benaderd kunnen worden. Het is dan niet nodig queries te schrijven om deze groepen te vormen door het koppelen van meerdere tabellen. In de praktijk worden O-O benaderingen vaak geïmplementeerd als laag boven op een RDB. Hierdoor kan gebruik worden gemaakt van de functies van de gebruikelijke RDB-systemen zoals toegang door meerdere gebruikers, record beveiliging, back-up en herstel- systemen, enz. Maar de O-O benadering betekent dat zowel de beheerders als gebruikers van webmetadata kunnen denken in termen van objecten, zonder te moeten weten welke tabellen gekoppeld moeten worden om de indruk van objecten te geven. Met andere woorden, de O-O benadering voorziet in inkapseling: de mogelijkheid verzamelingen (hier: verzamelingen van metadata-elementen) te behandelen als een eenheid met een specifieke naam. De meeste O-O benaderingen voorzien in klasse-subklasse (IS-A) relaties en vaak ook in deel-gedeelte relaties. Sommige van deze benaderingen maken het mogelijk arbitraire relaties te definiëren. (Hierbij moet rekening worden gehouden met de Dublin Core dumbdown regel, volgens welke de gebruiker van een verfijning geen aandacht hoeft te schenken aan de naam van de verfijning en deze kan beschouwen als het voorkomen van een element op een hoger niveau. Dit is een andere manier om de O-O IS-A relatie uit te drukken welke een subklasse definieert als een verfijning van de hoger liggende klasse. Voorbeeld: date.created is een datum). O-O benaderingen zijn bijzonder geschikt voor het voorstellen 52

56 Appendix B: Gestructureerde metadata van hiërarchieën, maar zijn beperkt in de mogelijkheden voor het voorstellen van complexere structuren zoals een netwerk van webpagina s of ontologieën. Een benadering door middel van een semantisch web is nog krachtiger en maakt het mogelijk arbitraire relaties te definiëren, en attributen toe te kennen aan relaties. Een semantisch web kan alles doen dat met een RDB of O-O benadering mogelijk is. Deze benadering is dan ook bijzonder geschikt voor het voorstellen van complexe structuren zoals webpagina s, ontologieën, werkstromen, processen en diensten. Al deze benaderingen kunnen zonder problemen een platte structuur weergeven, zoals de lijst van elementen en verfijningen volgens Dublin Core of een afgeleide standaard. Voorbeeld: een RDB metadataweergave zou één tabel voor elk element of verfijning kunnen bevatten, of een enkele tabel met alle elementen en verfijningen als kolommen. Op dezelfde wijze zou een O-O weergave een enkel object kunnen bevatten waarvan de attributen overeenkomen met de gewenste elementen en verfijningen. Met andere woorden, elke gestructureerde weergave kan worden gebruikt voor het vormen van een platte verzameling metadata, net zoals een hiërarchisch organigram een bedrijf kan weergeven met een platte managementstructuur (alle werknemers op hetzelfde niveau, niemand rapporteert aan iemand anders). Zoals besproken in paragraaf 4.1, betekent dit dat de twee takken van de standaard interoperabel en consistent blijven, door de platte NL-meta.DC+ elementen weer te geven in elke implementatie van de gestructureerde NL-meta.Extended tak. Elk van deze structuurbenaderingen heeft voordelen en beperkingen. De Overheid.nl Webmetadata standaard maakt dan ook geen keuze. De standaard voorziet in een optioneel gestructureerd raamwerk waarin al deze technieken toegepast kunnen worden om gestructureerde metadata toe te voegen aan de standaard. Een nadere besprekingen van de voor- en nadelen van de diverse technieken om gestructureerde metadata te implementeren valt buiten dit handboek. 53

57 Appendix C: Implementatie-aspecten Deze appendix bespreekt diverse aspecten van de implementatie. De eerste paragraaf beschouwt de vraag of er ingebedde (embedded) of afzonderlijke metadata gebruikt moet worden, de tweede paragraaf opties voor het omgaan met metadata voor bestaande en nieuwe documenten, en de laatste paragraaf een strategie voor het verzekeren van een lange levensduur van de data en metadata. 1. Ingebedde (embedded) of afzonderlijke metadata Een essentiële technische vraag betreft de keuze tussen het inbedden van de metadatawaarden in beschreven documenten, of het afzonderlijk van de documenten opslaan van de metadata, b.v. in een database. Beide mogelijkheden hebben specifieke voor- en nadelen. Onafhankelijk van de gekozen benadering moet echter voldaan worden aan de onderstaande criteria: Metadata moet logisch verbonden blijven met de beschreven documenten Metadata moet toegankelijk zijn voor zoekinstrumenten Bij het wijzigen van metadata moet het risico van beschadiging van de documenten minimaal zijn Als een document herzien wordt moet de betreffende metadata gemakkelijk bij te werken zijn Het inbedden van metadata in online documenten komt neer op het invoegen van de metadata-elementnamen en -waarden (attribuut/waarde-paren) in online documenten, databases, enz. door middel van een mechanisme zoals HTML of XML tags of RDF beschrijvingen. Het voordeel van het opnemen van metadata in documenten is dat zoekmachines zoals Google de metadata in principe kunnen vinden, waardoor gebruikers kunnen zoeken op deze attribuut/waarde-paren. Voorbeeld: een waarde met tag zoals <meta title= Gecodeerde archiefbeschrijving > maakt het mogelijk te zoeken naar deze titel ingebed in het document. Op het moment houden slechts weinig zoekmachines rekening met dergelijke metadata. Helaas heeft het inbedden van metadata in documenten ook een aantal nadelen. Ten eerste vereist het opnemen van metadata in een document het wijzigen van het document zelf wat niet in alle gevallen mogelijk is. Als een website toegang geeft tot een digitaal document dat elders werd opgesteld (b.v. een rapport in PDF-formaat of een beeld in TIFF-formaat) dan kan het onpraktisch of onmogelijk zijn gegevens in te voegen in het bestand. (Dit geldt des te meer voor offline documenten die worden beschreven door online metadata, b.v. publicaties op CD-ROM die niet kunnen worden gewijzigd.) Bovendien betekent dit dat als een document gewijzigd wordt de metadata opnieuw moet worden ingevoegd in de nieuwe versie. En als de metadatawaarden zelf wijzigen (b.v. het invoegen van nieuwe trefwoorden, categoriebeschrijvingen of zoektermen) moet ook het document worden gewijzigd. Tenslotte kan het bij dynamische, vergankelijke bronnen zoals database views, interactieve formulieren of actieve webpagina s niet zinnig zijn metadata op te nemen in de bron zelf. Het scheiden van de metadata van de beschreven documenten (b.v. in een database of ander beheerinstrument voor metadata) voorkomt de noodzaak van het wijzigen van de bronnen om metadata in te voegen of te wijzigen. Het maakt het ook mogelijk de metadata in 54

58 Appendix C: Implementatie-aspecten een meer flexibele vorm op te slaan, zoals in een relationele of objectgeoriënteerde database, of in een semantisch web zoals een Topic Map. Dit maakt het eenvoudiger de optioneel gestructureerde benadering van Overheid.nl Webmetadata toe te passen. Ten slotte kan metadata zo worden gebruikt voor het beschrijven van bronnen die niet gewijzigd kunnen worden of die dynamisch of vergankelijk zijn, zoals database views, transactiefaciliteiten en andere e-services. Het risico van het gebruik van afzonderlijke metadata is dat de metadatawaarden het logisch verband met de beschreven documenten verliezen. Dit risico kan echter aanzienlijk worden verlaagd door toepassing van een algemeen geaccepteerd en universeel systeem voor het identificeren van objecten, zoals het ISBN (International Standard Book Number) of DOI (Digital Object Identifier). Verder dient men te beseffen dat het gebruik van stabiele en betrouwbare identificaties bij het beschrijven van documenten ook om een andere reden essentieel is. Als een organisatie webmetadata verzamelt of creëert voor een document in het toegangsdomein voordat er een records management functie wordt opgezet, dan zal het gebruik van stabiele identificaties de toekomstige records managers informeren dat dergelijke metadata al bestaat in het toegangsdomein. Die gegevens kan hij overnemen als hij later het document wil opnemen in zijn eigen domein. Dit maakt de kans op het aanmaken van inconsistente metadata voor een document kleiner. Ten slotte dient afzonderlijke metadata bereikbaar gemaakt te worden voor de zoekinstrumenten. Dit kan door het exporteren van metadata tags die dan worden opgenomen in de documenten, m.a.w. de hybride benadering. Een andere mogelijkheid is de zoekinstrumenten te voorzien van vraaggestuurde (query language) koppelingen naar databases of application program interfaces (API s) naar andere systemen die de afzonderlijke metadata bevatten. Zoals de hybride oplossing aangeeft hoeven de ingebedde en afzonderlijke metadata benaderingen elkaar niet uit te sluiten. Metadata kan bijvoorbeeld worden beheerd in een database of weergegeven in een semantisch web (b.v. een Topic Map) en dan worden gebruikt voor het aanmaken en exporteren van tags die in de documenten worden opgenomen. Dit is alleen nuttig indien het exportproces geautomatiseerd kan worden. In dat geval combineert deze benadering diverse van de beste (en slechtste) aspecten van de twee basisbenaderingen. Het is dan eenvoudiger voor de zoekinstrumenten om toegang te krijgen tot de metadata, maar de documenten moeten bij iedere wijziging van de metadata worden bijgewerkt. Welke implementatie ook wordt gekozen, het moet voor zoekinstrumenten (zoals zoekmachines) mogelijk zijn toegang te krijgen tot webmetadata, wil deze metadata van enig nut zijn. De ingebedde benadering heeft het voordeel dat de ingebedde metadata tags als tekst kunnen worden gevonden door vrije tekst zoekmachines. Dit vereist wel dat de zoekmachines naar deze metadata tags kunnen zoeken en ze als zodanig interpreteren. Als de metadata afzonderlijk wordt opgeslagen van de beschreven documenten dan moeten de zoekinstrumenten toegang krijgen tot deze afzonderlijke metadata om de gewenste documenten te vinden. Op de lange termijn kan dit een voordeel zijn, indien de zoekinstrumenten ontworpen worden voor het doorlopen van of zoeken in ontologieën of andere terminologische hulpmiddelen. Om toekomstige implementeerders de vrijheid te laten de benadering te kiezen die hen het beste uitkomt, wordt geen uitspraak gedaan over de keuze tussen ingebedde of afzonderlijke metadata. Zo lang er wordt voldaan aan de bovengenoemde criteria is het relatief 55

59 Appendix C: Implementatie-aspecten onbelangrijk of een systeem met ingebedde of afzonderlijke metadata, of een hybride vorm, wordt gekozen. 2. Metadata creëren voor oude en nieuwe documenten Bij het creëren van webmetadata voor het beschrijven van nieuwe online documenten moet gebruik worden gemaakt van de technische mogelijkheden voor het automatiseren van ten minste een deel van het proces van metadata creatie en opslag. Voorbeeld: een documentbeheersysteem of zelfs een tekstverwerker kan functies bieden voor het opslaan van de creatiedatum, auteur en type van een nieuw document op het moment dat dit wordt aangemaakt. Helaas zijn dergelijke automatische mogelijkheden vaak onvoldoende voor het aanmaken van echte metadata. Ze kunnen bijvoorbeeld de login-naam van de auteur gebruiken, in plaats van de onpersoonlijke organisatienaam die de voorkeur verdient, of ze veranderen de revisiedatum iedere keer dat een document wordt gewijzigd, en niet alleen als er een belangrijke verandering in wordt gemaakt. Desondanks moet het mogelijk zijn applicaties aan te schaffen of te wijzigen, of nieuw gereedschap te ontwikkelen, voor het automatisch opslaan van ten minste een deel van de metadata van nieuwe documenten. Meer in het bijzonder kunnen standaardwaarden (specifiek voor de organisatie en functie) toegewezen worden bij de creatie van een document. Dit betreft bijvoorbeeld velden zoals de publisher (uitgever) en (organisationele) creator (auteur), language (taal), coverage (dekking), type, format, enz. De auteur en anderen moeten wel in staat zijn de standaardwaarden te wijzigen, ten tijde van de creatie of later. Zelfs als informatiesystemen de gewenste webmetadata kunnen aanmaken, dan moeten ze tevens deze metadata beschikbaar maken voor extractiemechanismen en/of zoekinstrumenten. Met andere woorden, indien de metadata afzonderlijk wordt opgeslagen moet de webmetadata opgehaald worden uit de documenten die door de informatiesystemen worden gecreëerd, om de afzonderlijke metadatabase te vullen. Als er echter gebruik wordt gemaakt van ingebedde metadata dan moeten de zoekinstrumenten toegang krijgen tot de webmetadata in de documenten die door deze informatiesystemen worden gecreëerd. De informatiesystemen gebruikt voor het creëren van nieuwe documenten moeten deze eisen vervullen om het mogelijk te maken metadata geautomatiseerd te verzamelen. Het verzamelen of aanmaken van metadata voor oudere, reeds bestaande documenten kan mogelijk niet in dezelfde mate worden geautomatiseerd. Als er ingebedde metadata moet worden toegevoegd aan bestaande documenten kan het noodzakelijk zijn de documenten zelf te wijzigen. Dit kan in sommige gevallen moeilijk of onmogelijk zijn, zoals hierboven beschreven. Bovendien is het ongewenst vanuit het records management perspectief. Verder kan het moeilijker zijn later waarden te verkrijgen voor bepaalde metadatavelden (b.v. coverage). Dit kan een nauwkeurige analyse vereisen van de documenten zelf of contact met de oorspronkelijke auteurs/makers of uitgevers, voor zover deze nog te bereiken zijn. Tenslotte zijn bepaalde metadata-elementen mogelijk niet van toepassing op offline documenten die worden beschreven door online metadata. Deze problemen zijn vergelijkbaar met het bekende probleem van oude gegevens (legacy data). Hoewel de problemen niet onoplosbaar zijn, betekenen ze dat het nodig is een gedetailleerde strategie op te stellen, toegespitst op de organisatie, voor het verzamelen of aanmaken van metadata voor oudere bronnen. Aan het begin van dit proces moet elke organisatie beslissen bij welke van de oude documenten dit de moeite waard is. 3. Levensduur van data en metadata Alle digitale informatie, data en metadata, kan onbereikbaar of onbruikbaar worden als de programma s die het weergeven in een door de gebruiker waarneembare vorm of de 56

60 Appendix C: Implementatie-aspecten computers waar deze programma s op draaien verouderd zijn. Hoewel er diverse oplossingen zijn voorgesteld voor het probleem van de digitale levensduur valt de implementatie hiervan buiten de Overheid.nl Webmetadata standaard. Desondanks omvat de standaard metadata voor de bewaring (Admin) ter ondersteuning van de strategie voor de bewaring op lange termijn die wordt gekozen voor de online informatie beschreven met de standaard. De specifieke vorm van metadata voor bewaring hangt af van het systeem dat voor de levensduur wordt gekozen. Als er bijvoorbeeld conversie naar een ander format wordt toegepast dient de bewaringsmetadata het formaat (en de versie daarvan) van een document aan te geven zodat het juist kan worden verwerkt voorafgaande aan de conversie tot een nieuw formaat. Verder dient bij elke conversieslag metadata worden gecreëerd om het conversieproces te documenteren zodat toekomstige gebruikers de kwaliteit van de migratie kunnen evalueren. Als een logische beschrijving van de vorm en inhoud van een document wordt gecreëerd om het mogelijk maken het in de toekomst weer te kunnen geven aan de hand van die beschrijving dan dient de bewaarmetadata de formele beschrijving, of een verwijzing daarnaar, te bevatten. Indien er gebruik wordt gemaakt van emulatie van hardwareplatforms om het mogelijk te maken de oorspronkelijk opgeslagen weergave-software door middel van emulatie te draaien op toekomstige computers dan dient de bewaar-metadata te bestaan uit verwijzingen naar een geschikte emulator en geschikte versies van de oorspronkelijke weergave-software voor het document. De levensduur van metadata (niet de data zelf) vormt een ander probleem. Om de standaard te implementeren kan het noodzakelijk zijn één of meerdere beheersystemen voor metadata te kiezen of te ontwikkelen. Deze systemen moeten voorzien in een geschikte bewaarstrategie ter verzekering van de levensduur van de beheerde metadata. Aangezien de meeste metadatawaarden relatief eenvoudig weer te geven zijn zonder complexe applicatiesoftware is het waarschijnlijk dat een eenvoudig migratiesysteem een effectieve oplossing is voor het bewaren hiervan. Een formele beschrijving zou echter een nog betere oplossing zijn. Wijzigingen in de metadata of metadatavelden (elementen) zelf zal geen groot probleem vormen indien deze apart van de beschreven online documenten wordt opgeslagen. Als de metadata echter is ingebed in de documenten dan zal een wijziging van de metadata leiden tot een wijziging van de documenten, zoals beschreven in paragraaf 1 van deze appendix. Dit kan een probleem vormen, tenzij het modificatieproces geheel en veilig geautomatiseerd kan worden 57

61 Appendix D: Wijzigingshistorie Wijzigingen aangebracht in versie 1.01, 16 december 2004 Grafische vormgeving aangepast aan de huisstijl van Advies Overheid.nl Diverse kleine redactionele aanpassingen omwille van de leesbaarheid. Titel Oorspronkelijke tekst Vervangen door Een nationale standaard voor webmetadata Overheid.nl Webmetadata [In het hele document, uitgezonderd waar verwezen wordt naar (sub)klassen] Oorspronkelijke tekst NL-meta NL-meta.DC+ Overheid.nl Webmetadata Hoofdstuk 1: Inleiding Vervangen door Overheid.nl Webmetadata Overheid.nl Webmetadata - [aantal vermeldingen gereduceerd omwille van de leesbaarheid] Oorspronkelijke tekst Dit handboek beschrijft een nationale standaard voor het vergroten van de transparantie van de overheid in Nederland. Deze standaard dient om burgers en andere gebruikers (b.v. bedrijven) te helpen om eenvoudiger online overheidsinformatie te vinden. Deze standaard (werktitel "NL-meta") betreft het creëren en gebruik van metadata. In deze context is metadata de informatie die overheidsinformatie zoals documenten, databases en diensten beschrijft. Een begeleidend rapport (RAND Europe, 2004) aan Advies Overheid.nl vormt de basis voor de NL-meta standaard in dit handboek. HOOFDSTUK 4. Vervangen door Dit handboek beschrijft een nationale standaard voor het vergroten van de transparantie van de overheid in Nederland. Deze standaard dient om burgers en andere gebruikers (bijvoorbeeld bedrijven) te helpen om eenvoudiger online overheidsinformatie te vinden. Deze standaard betreft het creëren en gebruik van metadata. In deze context is metadata de informatie die overheidsinformatie zoals documenten, databases en diensten beschrijft. Een begeleidend rapport (RAND Europe, 2004) aan Advies Overheid.nl vormt de basis voor de Overheid.nl Webmetadata standaard in dit handboek. De Overheid.nl Webmetadata standaard (tweede alinea) Oorspronkelijke tekst NB: de termen NL-meta, NL.meta.DC+, NL.DC+ en NL.meta.Extended worden voorlopig gebruikt, in afwachting van de formele naamgeving van de metadata standaard voor het web. Vervangen door Onder Overheid.nl Webmetadata wordt het totaal van klassen en subklassen verstaan De namen van klasse NLmeta en de subklassen NL.meta.DC+, NL.DC+ en NL.meta.Extended hebben hun oorsprong in het rapport Designing a National Standard for Discovery Metadata (RAND, december 2004). [de tekst is verplaatst naar Paragraaf 4.2] Par. 4.2: De Overheid.nl Webmetadata elementen (titel; laatste item opsommingslijst) Oorspronkelijke tekst De elementen van NL-meta.DC+ Advies Overheid.nl: type.administrativebody, type.organization Vervangen door De Overheid.nl Webmetadata elementen Advies Overheid.nl: type.administrativebody, type.organisation Appendix A: Beschrijving van de Overheid.nl Webmetadata elementen (eerste alinea) Oorspronkelijke tekst Vervangen door De elementen worden zowel in het Nederlands als in het De elementen worden in het Engels weergegeven om Engels weergegeven om vergelijking en consistentie met vergelijking en consistentie met internationale standaarden internationale standaarden te waarborgen. Voor elementen te waarborgen. Bij de naamgeving van elementen in de die rechtstreeks afkomstig zijn uit DC, blijft de Engelse OVERHEID namespace is de 'DCMI Policy on Naming syntax gehandhaafd. Voor OVERHEID-elementen is Terms' gehanteerd als uitgangspunt (zie ook zoveel mogelijk van de Nederlandse teksten uitgegaan. 58