Ontwerpdocument. Gegevensarchitectuur. Koninklijke Bibliotheek

Transcriptie

1 Ontwerpdocument Gegevensarchitectuur Koninklijke Bibliotheek - c o n c e p t VGA Paul Doorenbosch Theo van Veen Versie 0.7 ( )

2 Inhoud Managementsamenvatting 1. Inleiding 2. Opdracht doel resultaat 3. Business case 4. Randvoorwaarden 5. Systeem concept 6. Functionaliteit 7. Ontwerp Gegevensarchitectuur Bijlage 1: Functionaliteit Bijlage 2: DCX-elementen Bijlage 3: Lijst van afkortingen en begrippen Onderwerp: Ontwerpdocument KB-gegevensarchitectuur Bestemd voor: Stuurgroep, KB Auteur: Paul Doorenbosch; Theo van Veen Nummer VGA Datum Eerste opzet Herziene opzet Verdere invulling door Theo Tekstuele wijzigingen en structuurwijzigingen PD Tekstuele wijzigingen PD en TvV Tekstuele en structuurwijzigingen PD met name nav bespreking met Paul Mudde (Furore) tekstuele wijzigingen en structuurwijzigingen TvV, PD. PM en MK opmaakwijzigingen conceptversie (VGA (0.7) - ontwerpdocument.doc) 2 / 31

3 Managementsamenvatting Het programma Vernieuwing Gegevens Architectuur is ingesteld om de data-infrastructuur op orde te brengen, zodat de veelvoud aan systemen wordt teruggebracht, de uitwisselbaarheid van data geoptimaliseerd wordt en het eenvoudiger wordt nieuwe diensten en nieuwe vormen van dienstverlening te ontwikkelen, in gebruik te nemen en te onderhouden. In dit document wordt een nieuwe backend-architectuur voorgesteld, die in hoge mate op (internationale) standaardisatie van formaten en protocollen is geënt. Afb. 1: Schematische weergave van systeemelelementen en protocollen Globaal kent de architectuur de volgende beslissingen: - Alle metadata worden in XML vastgelegd. - Het generieke metadataformaat wordt Qualified Dublin Core, met een enkele uitbreiding (DCX) die evenwel de werking van de standaard intact laat. - De DCX-elementen worden vastgelegd in een machineleesbaar registry. - Het generieke formaat voor samengestelde objecten wordt MPEG21 DIDL, dat de structuur van het samengestelde object in een file vastlegt. - Voor het vastleggen van collectiegegevens en services wordt gebruik gemaakt van collectie- en servicebeschrijvingen conform de NISO aanbevelingen. - Het harvesting protocol is OAI; het search and retrieval-protocol is SRU. - Voor indexering wordt gebruik gemaakt van Verity (KB-standaard), voor opslag van XML Oracle (KB-standaard). - Er komt een centrale metadataopslag. Hierin kunnen geen handmatige wijzigingen worden aangebracht. - Voor metadata die in de KB gemaakt en onderhouden wordt gelden twee brondatabases: het GGC en de KB-werkdatabase. De KB-werkdatabase is volgens hetzelfde principe en met dezelfde structuur ingericht als de centrale opslag. Wijziging van records mag alleen in de brondatabases plaatsvinden. - Digitale objecten worden in een filestructuur opgeslagen. - De naamgeving van objecten wordt niet voorgeschreven, maar het opvragen van objecten verloopt altijd via een resolver om de persistentie van de verwijzingen te waarborgen. (VGA (0.7) - ontwerpdocument.doc) 3 / 31

4 (VGA (0.7) - ontwerpdocument.doc) 4 / 31

5 1. Inleiding Dit ontwerpdocument beperkt zicht tot de kern van het programma Vernieuwing Gegevens Architectuur (VGA), t.w.: a. Opslag van KB-metadata en -objecten b. Indexering van interne en externe metadata en tekstobjecten c. De processen en protocollen om de opslag te vullen, te onderhouden en beschikbaar te stellen. De keuzes zijn gedetailleerd besproken in aparte documenten. Hier wordt in voetnoten naar verwezen. Deze documenten zijn te vinden op de projectwebsite van het programma: De hardware en software zijn geen onderdeel van dit document maar wat hier besproken wordt, is van invloed op de te maken keuzes voor de hardware. 1 Begrippen In dit document wordt: - 'metadata' gebruikt voor gestructureerde gegevens over objecten - 'data' gebruikt als overkoepelende term voor 'metadata' en 'objecten' - 'gegevens' gebruikt als synoniem voor 'data' - 'object' gebruikt voor basisentiteiten als een pagina, een boek, een tekst, een film etc. Als het om de digitale verschijningsvorm gaat of indien het onderscheid digitaal-fysiek niet relevant is, wordt 'object' zonder de toevoeging digitaal of fysiek gebruikt. Afkortingen, begrippen en standaarden worden in een bijlage verklaard. 1 De afdeling ICT zal op basis van dit document moeten aangeven wat de consequenties van deze infrastructuur zijn voor hard- en software. In principe zal de huidige hardware- en softwarestructuur niet hoeven wijzigen: Windows als platform, Verity als zoekmachine, Oracle als database voor opslag van metadata en andere data dan de objecten, en een filesysteem als opslag voor objecten. (VGA (0.7) - ontwerpdocument.doc) 5 / 31

6 2. Opdracht doel resultaat 2.1 Opdracht De opdracht van het programma VGA is om een gegevensarchitectuur vast te stellen en in te richten voor metadata en objecten in de KB, om de metadata en objecten te migreren naar de nieuwe infrastructuur en om de implementatie voor te bereiden voor de migratie van de huidige websites naar de nieuwe situatie. Als proof of concept worden in elk geval twee diensten gemigreerd. 2.2 Doel 'In het programma Vernieuwing Gegevens Architectuur (VGA) wordt het gehele proces dat door metadata en objecten in de KB doorlopen wordt, geëvalueerd, gestroomlijnd en aangepast, met als doel betrouwbaar (bestaande) informatiediensten te kunnen leveren en relatief eenvoudig nieuwe functionaliteit in de informatiedienstverlening te kunnen implementeren.' 2 (bron: programmaplan) 2.3 Resultaat Het programma is in twee delen opgesplitst. Het eindresultaat van fase 1 (de huidige fase) is: een gegevensarchitectuur (standaarden, processen, software, interfaces en procedures) die de verwerving, verwerking, opslag, en beschikbaarstelling van metadata en objecten in de KB ten behoeve van het publiek omvat, en een implementatieplan daarvoor. Fase 1 is de uitvoering en implementatie van de voorgestelde architectuur. Vertaald naar op te leveren producten, betekent dit voor deze fase: a. Vaststelling van formaten voor metadata en thesaurusdata. b. Standaarden voor de structurering van de diverse soorten objecten. c. Een standaard voor de identificatie van objecten. d. Een infrastructuur voor inrichting van opslag voor metadata en objecten (full-text, images en overige digitale bestanden). e. Een infrastructuur voor de inrichting van indexen voor metadata en full-text en voor het aanbieden van metadata en full-text aan de search engine. f. Zoekprotocollen en de formaten waarin resultaten aan de webdienst worden geleverd. g. Een structuur voor de toegang tot onderdelen van samengestelde objecten. h. Een structuur voor het converteren van gestandaardiseerde persistente URLs naar locaties. i. Services voor het benaderen en bewerken van data. In dit document wordt uitsluitend de architectuur behandeld. De implementatie van de op te leveren onderdelen komt in een afzonderlijk document aan de orde. 2 Bijkomend voordeel daarbij is dat de beheerlast voor applicatiebeheerders en technisch beheerders (ICT) wordt teruggebracht. (VGA (0.7) - ontwerpdocument.doc) 6 / 31

7 3. Business case 3.1 De KB Onderdeel van het primaire proces van de Koninklijke Bibliotheek is het leveren van elektronische informatiediensten, die zijn samengesteld uit informatie afkomstig uit de eigen databases en uit die van andere partijen. De basisfunctionaliteit van die diensten is het zoeken, vinden en het presenteren van deze informatie. Het gaat daarbij (op dit moment) om ca. 5 miljoen eigen metadatarecords en een in principe oneindig aantal records van anderen. De komende jaren zal het eigen bestand aanzienlijk groeien. Naast metadata gaat het in toenemende mate ook om andere typen data, zoals full-text en images. Ook dit betreft miljoenen objecten. De Koninklijke Bibliotheek is niet gebonden aan een geografisch bepaalde gebruikersgroep. Juist als nationale bibliotheek bevindt die gebruikersgroep zich over heel de wereld. De focus van de KB zal daarom gericht moeten zijn op het internet als medium om te communiceren met de gebruikers. 3.2 Gebruikers en omgeving De gebruiker is gewend aan systemen waar data van diverse partijen naadloos in één zoekactie gezocht kan worden en waar de responssnelheden bijzonder hoog zijn (bibliotheeksystemen van OCLC-PICA, en Google). De huidige prestaties van de KB-diensten steken daar pover bij af, wat zeker ten koste zal gaan van het gebruik. De KB beschouwt haar data niet als exclusief voor zichzelf. Samenwerking, hergebruik en uitwisselbaarheid van data staan hoog op de agenda bij bibliotheken en culturele instellingen. Ook wil de KB van de data van anderen gebruik maken (bijv. in Alfaned). Interoperabiliteit van de data is op dit moment alleen moeizaam te bereiken. De ontwikkelingen op internet gaan hard. De Koninklijke Bibliotheek maakt onderdeel uit van dit informatienetwerk (infogrid), waarin niet alleen data transparant moet worden aangeboden, maar waar ook 'services' moeiteloos met elkaar moeten kunnen worden gedeeld, zowel intern in de KB als daarbuiten (vertaalservices, presentatieservices, e.d.). De ontwikkeling van gepersonaliseerde toepassingen op internet vragen een flexibele infrastructuur. De internetdiensten die de KB biedt moeten betrouwbaar en stabiel (24/7) beschikbaar zijn en een snelle respons bieden. 3.3 Oplossingsrichting De huidige infrastructuur voldoet niet meer. Het aantal systemen bedraagt rond de dertig, de onderlinge uitwisselbaarheid van data is ver te zoeken, het inrichten van nieuwe diensten kost nu maanden. Installatie van off-the-shelf-pakketten is tot nu toe geen oplossing. Vooral de aansluiting daarvan op de gegevensarchitectuur blijkt telkens problematisch te zijn en daardoor veel tijd te kosten. 3 De infrastructuur moet schaalbaar zijn om de groei aan informatie en bezoekers te kunnen opvangen, en open en flexibel zijn om nieuwe ontwikkelingen te kunnen implementeren en nieuwe diensten te kunnen realiseren. Door de gegevensinfrastructuur opnieuw op te zetten ruimt de KB niet alleen een aantal in de loop der tijd gegroeide problemen op, zij maakt haar systemen tevens geschikt voor toekomstige ontwikkelingen en de implementatie van nieuwe vormen van dienstverlening en klantencommunicatie. De KB richt zich hierbij op een 'Service Oriented Architecture' (SOA). 3 Dit is zowel bij de implementatie van Verity als van Metalib gebleken. (VGA (0.7) - ontwerpdocument.doc) 7 / 31

8 4. Randvoorwaarden a. Alle (meta)data in eigen beheer moet in één zoekactie, via één index) doorzocht kunnen worden. b. Alle informatie in eigen beheer moet zonder kennis van de organisatie van die data bereikbaar zijn voor online-diensten van derden 4. c. De performance van de diensten moet de vergelijking kunnen doorstaan met Google en GGC. d. Waar (inter)nationale standaarden in gebruik zijn, worden die geïmplementeerd. 4 Eventuele toestemming daarvoor kan apart geregeld worden. Hiertoe is het RIAA -project in september 2005 herstart door uitbesteding van het opstellen van een pakket van wensen en eisen, de systeemkeuze en het opstellen van een projectplan aan TRAXION bv. (VGA (0.7) - ontwerpdocument.doc) 8 / 31

9 5. Systeemconcept 5.1 Inleiding Data worden in een beperkt aantal bronbestanden gegenereerd. De veranderingen die hierna plaatsvinden aan metadata zijn geautomatiseerd. Wijzigingen in individuele metadatarecords kunnen alleen in de bronbestanden plaatsvinden. De kern van het systeem bestaat uit een XMLdatabase voor metadata. Hierin worden alle metadata van de KB in, minimaal, een generiek en gestandaardiseerd formaat opgeslagen. Dit geldt zowel voor beschrijvende metadata als voor structurele en technische metadata. Verwijzing naar objecten gebeurt door middel van persistente URLs. De opslag van objecten vindt in een filesysteem plaats. Indexering van metadata en tekstobjecten gebeurt in een centrale index. Voor search and retrieval wordt gebruik gemaakt van gestandaardiseerde protocollen. 5.2 Problemen en oplossingen De problemen in de huidige infrastructuur en de oplossingen daarvoor: a. De huidige KB-DTD is slecht onderhoudbaar en niet meer adequaat. De basis voor de nieuwe metadataopslag is de internationale standaard Dublin Core (DC). Uitbreiding hierop worden vastgelegd in een metadata registry. De bewaking van de infrastructuur wordt ondergebracht in de nieuw op te richten afdeling Informatiemanagement. b. KBTITEL is vervuild. De nieuwe metadata opslag wordt opnieuw opgebouwd vanuit de beschikbare bronbestanden. Metadata dienen bij de bron inhoudelijk gevalideerd te worden. Bij de invoer in de XMLopslag van de KB geldt een controle op correcte syntax (well-formed XML) en de aanwezigheid van een titel en een identifier die naar het object verwijst. c. De huidige metadata zijn alleen bruikbaar als specifieke kennis daarover aanwezig is. Door te kiezen voor een intenationale standaard (DC) en een machineleesbaar registry van elementen is kennis over de KB-metadata in menselijk leesbare en machine verwerkbare vorm beschikbaar. d. De huidige gegevensinfrastructuur is niet transparant benaderbaar. Door gebruik te maken van standaarden voor search and retrieval kunnen data benaderd worden zonder dat kennis nodig is van de interne opslag en structurering van data. Naamgeving van objecten wordt niet meer gebruikt om de structuur van objecten vast te leggen. Gegevens die nodig zijn om objecten of onderdelen daarvan op de juiste manier op te vragen worden conform vastgelegde standaarden in URL-parameters ondergebracht en niet in de benaming. e. Niet alle collecties zijn geïntegreerd doorzoekbaar. Alle data van de KB worden minimaal in een generiek formaat opgeslagen, worden centraal geïndexeerd en zijn via standaardprotocollen beschikbaar. f. Het ontbreken van herbruikbare systeemcomponenten voor het verwerken, opslaan en presenteren van samengestelde digitale objecten met o.a. tekst, images en andere digitale formaten. Door te werken met modules en services die via gestandaardiseerde URLs benaderbaar zijn, worden deze onderdelen generiek bruikbaar. De nieuw op te richten afdeling Informatiemanagement wordt verantwoordelijk voor het bewaken van de infrastructuur en voor het doorgeven van de kennis daarover. g. Functionaliteit is vaak beperkt tot een specifieke dienst Door gebruik te maken van een Service Oriented Architecture (SOA) met koppelingen via URLs kunnen services (modules) ook door andere applicaties gebruikt worden. h. De slechte responstijden. De analyse van de huidige responsetijden is nog niet van dien aard dat duidelijk kan worden aangewezen waar de bottleneck zit. Vanaf het begin van het ontwerp en de bouw wordt de (VGA (0.7) - ontwerpdocument.doc) 9 / 31

10 performance van de nieuwe infrastructuur gemonitord. De nieuwe infrastructuur wordt niet eerder operationeel dan als aan de performance-eisen wordt voldaan. i. De hoeveelheid resources die gaat zitten in het creëren en onderhouden van nieuwe websites is omvangrijk. Door in de hele infrastructuur zoveel mogelijk te standaardiseren en modulair op te zetten is de functionaliteit daarvan herbruikbaar. Dit vereist wel aanpassing cq. herbouw van de huidige websites. Dat maakt geen onderdeel uit van deze fase van VGA, maar voor een vervolgtraject zal worden aanbevolen om ook websites meer gestandaardiseerd op te zetten dan nu het geval is. j. URLs en de syntaxis van die URLs zijn niet persistent, o.a. door het migreren van de opslag. Door gebruik te maken van een resolver zal de consistentie van de interne naamgeving van objecten en services niet meer van belang zijn. Het vereist wel dat de verwijzing naar objecten in de resolver consistent wordt gehouden. k. Applicaties moeten veelal kennis hebben over de structuur van namen van objecten om onderdelen op te kunnen vragen of het object zelf op te kunnen vragen. Door gebruik te maken van een standaard voor de structurering van objecten en een service voor de verwerking van die standaard, wordt gezorgd voor een eenduidige verwerking van objecten. l. De infrastructuur van de KB is door de jaren heen versnipperd. Alle metadata wordt in één repository bij elkaar gebracht, opgeslagen volgens één standaard structuur en geïndexeerd in één zoekmachine. Hiermee wordt op termijn het huidige veelvoud aan databases vervangen door één database met één index. Op basis daarvan kunnen alle webdiensten volgens eenzelfde stramien gaan werken. (VGA (0.7) - ontwerpdocument.doc) 10 / 31

11 6. Functionaliteit In dit hoofdstuk wordt ingegaan op de functionaliteit die mogelijk moet zijn op basis van de gegevensarchitectuur. Het houdt niet in dat al deze functionaliteit (zeker niet de nieuwe) in dit deel van het programma gerealiseerd zal worden. De gegevensarchitectuur moet het echter wel mogelijk maken. Elementen uit de datamodellen waarop functionaliteit gebaseerd is, moeten als zodanig in het datamodel aanwezig zijn. 6.1 Huidige 5 en nieuwe functionaliteit a. Zoeken Per applicatie zijn er verschillen in de velden waarop gezocht kan worden, de databases waarin gezocht kan worden en zaken als het combineren en trunceren van termen. De infrastructuur laat toe dat kan gezocht worden op alle velden die in de metadata voorkomen met booleaanse operatoren, truncatie, relevance ranking, proximity, stemming etc. b. Presenteren van metadata uit de index Vanuit de index kan een lijst met korte titels worden opgevraagd. Zowel vanuit de index als vanuit het volledige record moet direct naar het object of een service gelinkt kunnen worden. In de lijst van korte titels kan uiteraard (naar voor en achter) gebladerd worden. c. Bladeren door metadata (browsen) Bladeren in een index is nu nog niet echt mogelijk. Momenteel wordt dit veelal opgelost door lijsten te genereren van termen bijvoorbeeld onderverdeeld naar eerste letter(s). d. Sorteren van metadata In Verity is het mogelijk te sorteren op alle velden die in de index opgeslagen zijn (korte titelpresentatie oftewel captions). Enkele van de huidige webapplicaties maken hier gebruik van. e. Opvragen en presenteren van volledige metadatarecords Volledige records worden vanuit de metadata opgevraagd in soms verschillende formaten. De huidige functionaliteit bestaat veelal uit het presenteren van alle metadata, eventueel met een mogelijkheid de taal te veranderen of door het aanklikken van velden nieuwe zoekacties te starten. Tussen volledige records kan gebladerd worden. f. Opvragen en presenteren van objecten, waaronder full-text De huidige mogelijkheden zijn inzoomen op plaatjes, verschillende formaten opvragen, navigeren binnen een object. Voor al deze onderdelen geldt dat de functionaliteit op detailniveau afhankelijk is van de webapplicatie die voor een specifieke collectie gemaakt is. Webservices Door het gebruik van standaard metadata velden kan analoog aan het gebruik van OpenURL ieder metadata veld gebruikt worden om nieuwe services aan te roepen. Zo kunnen bijvoorbeeld tekstvelden gebruikt worden om een vertaalservice aan te roepen. Hiermee kan nieuwe functionaliteit eenvoudiger worden toegevoegd dan in meer monolithische systemen. 5 Het betreft hier functionaliteit die in een van de huidige websites voorhanden is en die als algemene functionaliteit beschikbaar moet komen, waarna het aan een dienst om hem al dan niet te activeren (VGA (0.7) - ontwerpdocument.doc) 11 / 31

12 7. Gegevensarchitectuur 7.1 Inleiding In het ontwerp speelt het volgende een rol: a. processen die data ophalen en klaar zetten voor een volgend proces b. tijdelijke opslag van data t.b.v. een volgend proces c. permanente opslag t.b.v. de beschikbaarstelling d. protocollen waarmee gegevens worden overgehaald en gezocht kunnen worden e. datamodellen Het ontwerp van de nieuwe infrastructuur is gebaseerd op onderstaand schema. Data en metadata worden op diverse manieren uit interne en externe bronnen vergaard, door conversie gestructureerd en klaar gezet voor volgende stappen zoals opslag en indexering. afb 2 Globaal beeld van de processen die de metadata en objecten binnen de KB gegevensinfrastructuur doorlopen. De rechthoekige blokjes geven de processen aan. OAI en SRU zijn de standaardprotocollen. Het groengearceerde deel geeft de reikwijdte van VGA aan. De grens waar VGA een rol begint te spelen ligt gedurende het proces van aanleveren (voor sommige datastromen hoort het er nog wel bij, voor andere niet). Het einde van de bemoeienis van VGA ligt bij de teruglevering aan de 'website' van metadata en projecten. De presentatie zelf hoort er niet meer bij, maar het leveren van de service om metadata op een adequate manier te kunnen presenteren weer wel. (VGA (0.7) - ontwerpdocument.doc) 12 / 31

13 7.2 Metadata, objecten en services In dit ontwerp wordt onderscheid gemaakt tussen verschillende typen objecten en metadata, en de services waarmee deze door de gebruiker opgevraagd worden. Service (webservice) Onder een service (ook wel webservice genoemd) wordt hier verstaan een webapplicatie die wordt aangeroepen met een URL met daarin mogelijk een aantal parameters, bijvoorbeeld de identificatie van een object Objecten en services Objecten zijn fysiek of digitaal. In beide gevallen is een webservice nodig om deze objecten te kunnen opvragen bijvoorbeeld een bestelfunctie of een service om een document aan de browser aan te leveren. We onderscheiden voor de gebruiker objecten volgens de DCMI vocabulaire in de volgende typen: a) collection b) dataset c) event d) image e) interactive software f) moving image g) physical object h) service i) software j) sound k) still image l) text Ten behoeve van de verwerking van objecten binnen de KB infrastructuur maken we tevens het hieronder beschreven onderscheid Enkelvoudige objecten Enkelvoudige objecten zijn objecten die een enkele entiteit zijn (bijv. een still image in een enkel formaat) met een URL waarmee het object direct gepresenteerd kan worden Samengestelde objecten 6 Samengestelde objecten zijn objecten, die uit meer dan een onderdeel bestaan en meerdere van de in paragraaf genoemde typen kunnen bevatten (bijv. een gedigitaliseerd boek) en waarvan de structuur op een gestandaardiseerde manier wordt vastgelegd. De KB gebruikt MPEG21 DIDL voor het vastleggen van de structuur. 6 Zie VGA (Samengestelde objecten in de KB). (VGA (0.7) - ontwerpdocument.doc) 13 / 31

14 MPEG21 DIDL MPEG21 DIDL (Digital Item Definition Language) legt de structuur van samengestelde objecten vast in een XML-record. Bij de KB is dit een afspiegeling van het object met naam, rol en URL van de onderdelen. Via speciale webservices kan de presentatie van het object of onderdelen daarvan opgevraagd worden Full-text Onder full-text worden alle vormen van tekst verstaan (PDF, ASCII, TEI-gestructureerde tekst, HTML etc.) Full-text kan zowel een enkelvoudig object (pdf, doc etc.) of onderdeel van een samengesteld (MPEG21 DIDL) object zijn en kan zowel intern als extern zijn opgeslagen. Benadering vindt altijd plaats via een URL. Full-text objecten worden evenals de metadata geïndexeerd (zie paragraaf 7.7) Metadata Metadata dienen om gestructureerde informatie over objecten te kunnen leveren en om objecten te kunnen benaderen. Om deze metadata te kunnen vinden is ontsluiting via indexering nodig. Om het object te kunnen benaderen moeten de metadata een verwijzing naar het object en/of de desbetreffende service bevatten Beschrijvende metadata In beschrijvende metadata zijn formele en inhoudelijke kenmerken van objecten vastgelegd. Deze zijn nodig zijn om gebruikers de mogelijkheid te geven objecten te vinden op basis van formele kenmerken als auteur en titel of op basis van inhoudelijke kenmerken als trefwoorden en classificaties. Noodzakelijk onderdeel van de metadata is een eenduidige en persistente verwijzing naar het beschreven object (zie kader). Het metadata model voor beschrijvende metadata wordt Dublin Core extended (DCX, zie kader) Alle beschrijvende metadata komen uiteindelijk samen in een centrale metadataopslag, voortaan KB-MDO genoemd. Dublin Core Extended (DCX) Het generieke formaat waarin alle metadata in de KB beschreven wordt is DCX. Het bestaat uit Qualified Dublin Core termen, waaraan, indien noodzakelijk, elementen kunnen worden toegevoegd (extended terms). Deze dienen alleen worden toegevoegd als er geen adequate DC-termen voor bestaan en er aantoonbaar functionaliteit voor is. Externe applicaties die via SRU/W of OAI records in het DCX-formaat opvragen kunnen deze extra elementen simpelweg negeren. Via inspectie van de Metadata-registry (zie verderop in deze paragraaf) kan eventueel de betekenis en syntax ervan achterhaald worden. De collectiebeschrijvingen komen in structuur overeen met DCX en kunnen als zodanig worden verwerkt. Ze worden daarom niet apart onderscheiden. (VGA (0.7) - ontwerpdocument.doc) 14 / 31

15 Verwijzing naar objecten Verwijzing naar objecten vindt altijd plaats via het Dublin Core veld identifier. Deze identifier is een URL die verwijst naar een service die nodig is om het object op te halen. Identifier velden kunnen ook een ander coderingsschema hebben, zoals ISBN of DOI. Deze zijn extra en worden niet gebruikt voor verwijzing naar KB locaties. De URL is altijd bruikbaar zonder kennis over de structuur van objecten. Als een URL verwijst naar een intern KB-object verwijst deze URL altijd naar de KBresolver die de daadwerkelijke locatie van het object afleidt uit de URL parameters. Bij samengestelde objecten kan via URL-parameters het precieze onderdeel van een object worden aangegeven. Een MPEG21 DIDL-service kan dan in het bijbehorende MPEG21 DIDL-record de exacte URL van het onderdeel opzoeken. Resolver 7 De KB resolver is een webservice die aan de hand van de URL parameters en een interne tabel bepaalt wat de daadwerkelijk fysieke URL van het object is en geeft deze terug aan de browser. Wijzigt een locatie dan wordt de tabel gewijzigd en blijft de extern bekende URL persistent Technische metadata en preserverings-metadata Technische metadata en preserverings metadata zullen meestal aangeleverd en opgeslagen worden als onderdeel van een object Structurele metadata Digitale objecten kunnen uit meerdere onderdelen bestaan, die op de een of andere manier bij elkaar horen. Voor het verwerken en presenteren van deze objecten is kennis nodig over de structuur daarvan en de betekenis van de individuele onderdelen. Voor de metadata die de structuur van het object beschrijven (structurele metadata) ten behoeve van de automatische verwerking is gekozen voor MPEG21 DIDL. MPEG21 DIDL-records bevatten valide XML en worden daarop gecontroleerd. Het is van belang standaardrollen van de samenstellende onderdelen vast te leggen. Hierdoor wordt automatische verwerking van deze onderdelen mogelijk gemaakt. De objecten voor het e-depot worden op aparte wijze behandeld. Structurering daarvoor maakt geen onderdeel uit van VGA Collectie en servicebeschrijvingen Collecties en services worden als specifieke typen van digitale objecten gezien. 7 Zie VGA (De KB-Resolver) 8 Het onderzoek naar digitale duurzaamheid in de KB is nog niet in het stadium dat hiervoor concrete voorstellen kunnen worden gedaan. (VGA (0.7) - ontwerpdocument.doc) 15 / 31

16 Collecties zijn verzamelingen van enkelvoudige of samengestelde objecten, die afzonderlijk worden beschreven en via SRU doorzoekbaar zijn. Alle collecties zijn vindbaar en benaderbaar via collectiebeschrijvingen volgens Dublin Core met uitbreidingen die specifiek zijn voor collecties conform de NISO standaard voor collectie- en servicebeschrijvingen. De collectiebeschrijving biedt de mogelijkheid de collectie te ontsluiten en de bijbehorende servicebeschrijving te vinden. Vanuit de servicebeschrijving kan het adres van de service gevonden worden waarmee de metadata van de collectie doorzocht kunnen worden. Binnen de KB-gegevensinfrastructuur wordt om praktische redenen direct het adres van de service in de collectiebeschrijving opgenomen. NB. Hiërarchisch geordende beschrijvingen die vastgelegd worden in het EAD-formaat worden binnen de KB-infrastructuur behandeld als objecten Thesauri Thesauri zijn databases waarin relaties tussen (metadata-) termen gelegd worden. Ze worden gebruikt om via verwante termen te kunnen zoeken of als hulp om nieuwe zoekacties te kunnen suggereren. Binnen de KB-infrastructuur zal zich dit niet hoeven te beperken tot de klassieke thesauri. Omdat thesauri onderwerp zijn van onderzoek en discussie binnen de KB worden ze in dit ontwerp nog niet meegenomen. Vooralsnog kunnen thesauri wel beschikbaar gesteld worden in het Zthes formaat. 7.3 Bronnen van data en metadata GGC Deze metadata worden door de KB zelf vervaardigd en vastgelegd in het GGC of ze worden in gebruik genomen in het GGC (beschrijvingen door anderen gemaakt waaraan eigendomsgegevens van de KB worden toegevoegd). Deze metadata worden in het GGC gekenmerkt door een van de instellings- en instituutcodes die in gebruik zijn bij de KB. Op basis van deze codes zijn beschrijvingen traceerbaar als KBmetadata. De formaten waarin de metadata vanuit de GGC worden aangeleverd zijn: PICAXML en MARCXML. PICAXML wordt gebruikt, t.b.v. conversie naar het generiek doorzoekbaar standaardformaat in de KB, te weten DCX. MARCXML wordt gebruikt ten behoeve van uitwisseling met instellingen die MARC als standaard voeren. MARCXML MARCXML is het formaat dat in gebruik is in veel bibliotheeksystemen. Het wordt aangeleverd vanuit de GGC. Van alle gegevens die uit de GGC in KB-MDO worden opgeslagen wordt ook het MARCXML-record als toegevoegd blok opgeslagen. PICAXML PICAXML is het formaat waarin OCLCPica metadatarecords kan leveren in XML. Het wordt geconverteerd vanuit het Pica+ formaat, het interne formaat van de GGC. PICAXML is de meest uitgebreide representatie van metadata uit het GGC. (VGA (0.7) - ontwerpdocument.doc) 16 / 31

17 7.3.2 e-depot Deze metadata worden voor wat artikelen uit tijdschriften betreft door uitgevers aangeleverd. In de Batchbuilder, onderdeel van de software, worden de metadata geconverteerd naar DCX. Objecten in het e-depot waarvan de uitgevers geen metadata aanleveren (CD s en monografieën), worden van metadata voorzien door een beschrijving te maken in het GGC. Deze metadata volgen de route van de andere metadata uit het GGC Eigen beheer Objecten, waarvan besloten is dat de metadata niet in het GGC wordt gemaakt, worden in een werkdatabase vervaardigd, waarvan de opzet identiek is aan KB-MDO 9. Conversie is hierdoor niet nodig. Voor collecties worden beschrijvingen conform de NISO standaard gebruikt, met toevoeging van gegevens over de service die nodig is om de collectie te benaderen. Deze records worden eveneens in de werkdatabase vervaardigd Aangeleverd door derden Deze metadata worden handmatig en ad hoc geconverteerd naar de werkdatabase en daar zonodig nabewerkt [bijv. GVN aangeleverde records]. Deze worden voor het verdere proces beschouwd als de bronmetadata Geharveste webpagina s 10 Van geharveste webpagina s worden in elk geval een titel en identificatie (URL) vastgelegd, waaraan eventueel in de index extra metadata kunnen worden toegevoegd (classificatie etc.) De metadata worden niet als apart record opgeslagen in KB-MDO, maar worden uitsluitend vastgelegd in de index (zie paragraaf 7.7.2). 7.4 Opslag We onderscheiden de volgende vormen van opslag Metadata Alle metadata worden gestructureerd in XML volgens één of meerdere schema s en opgeslagen in de KB-MDO. De beschrijvingen in deze database kunnen uitsluitend gewijzigd of verwijderd worden door upload vanuit de in de brondatabases (GGC, werkdatabase e.d.) gemuteerde records. Metadata worden als XML-blob opgeslagen in een Oracle-tabel. 11 De oorspronkelijke metadata kunnen in een alternatief blok worden opgeslagen. 9 Records kunnen niet direct in KB-MDO worden gemaakt omdat daar niet handmatig in mag worden gewijzigd 10 Harvesting van webpagina's is in voorbereiding bij Alfaned maar wordt in de praktijk nog niet uitgevoerd, anders dan voor TEL. 11 De lopende discussie over Native XML oplsag in Oracle 10 heeft geen invloed op het eerste ontwerp. Mocht uit die discussie blijken dat de native XML-opslag de voorkeur heeft, dan moet bekeken worden of dit in de lopende ontwikkeling kan worden ingepast, of dat dit een afzonderlijk herzieningstraject gaat worden. Het mag de voortgang niet beïnvloeden. De keuze voor standaardformaten en procedures zal er ook niet door worden aangetast. (VGA (0.7) - ontwerpdocument.doc) 17 / 31

18 Metadatarecord 12 Een metadatarecord in de KB-MDO kent één of meerdere type blokken. Er is altijd een gestandaardiseerd en gevalideerd blok met een beschrijving volgens DCX. Afhankelijk van de collectie zijn er ook een of meer toegevoegde blokken, bijvoorbeeld een gevalideerd alternatief standaardformaat of een blok met het oorspronkelijke record. Ook signaturen worden in een apart blok opgeslagen. Het aantal toegevoegde blokken is in principe niet beperkt, maar zal ontmoedigd worden. XML-validering wordt in principe niet uitgevoerd binnen een dergelijk blok, maar bij validatie van het geheel moet worden afgevangen dat de aanwezige structurering niet in conflict is met de wel vereiste XML validering. Het is niet toegestaan dit blok te gebruiken voor generieke toepassing of functionaliteit en alleen bedoeld voor specifieke doelgroepen of heel specifieke locale functionaliteit. Metadata registry In de metadata registry worden syntax en semantiek van elementen uit de metadatarecords machine-interpreteerbaar beschreven. De kern wordt gevormd door de Qualified Dublin Core termen (veldnamen), zoals die op de officiële website van DCMI zijn geregistreerd. De extended elementen worden volgens dezelfde systematiek beschreven. De taal waarin termen worden gegevens is Engels. Termen worden afgestemd met de community die belang heeft bij het element. De registry wordt in samenwerking met de European Libraray vrij op internet gepubliceerd bij voorkeur met een eigen domeinnaam. De structuur is gevalideerde XML. Vanuit de registry kunnen schema s en applicatieprofielen gegenereerd worden Metadata gemaakt in eigen beheer Metadata die in eigen beheer gemaakt zijn, worden in een werkdatabase opgeslagen met eenzelfde structuur als de KB-MDO. Vanuit de werkdatabase worden de records geladen in de KB-MDO. Collectiebeschrijvingen worden op dezelfde manier opgeslagen Objecten Objecten worden opgeslagen in een filesysteem. Hiervoor geldt geen ander voorschrift dan dat ze via een unieke URL opvraagbaar moeten zijn. Deze URL ligt vast in de metadata of voor samengestelde objecten in de MPEG21 DIDL-structuur. Structurele metadata wordt volgens MPEG21 DIDL als XML-blob in een Oracle-tabel of eventueel als XML-file opgeslagen. 12 De filosofie achter structuur en opslag van metadata is beschreven in VGA (Metadata in de KB). (VGA (0.7) - ontwerpdocument.doc) 18 / 31

19 Technische en preservation metadata kunnen als onderdeel van de objecten worden opgeslagen (bijv. JPEG). Desgewenst kunnen ze ook als aparte file worden opgeslagen waarmee ze onderdeel worden van een samengesteld object. In dit geval kunnen ze ook geïndexeerd worden Externe metadata en webpagina s Externe metadata en webpagina s worden niet bij de KB lokaal opgeslagen Metadata en objecten uit het e-depot Metadata en objecten worden gezamenlijk in het e-depot opgeslagen. De opslag van objecten speelt geen rol in VGA. De metadata wordt opgeslagen in KB-MDO Geïndexeerde data De geïndexeerde data (tekst en metadata) worden in Verity in de vorm van indexen opgeslagen. In sommige gevallen is dit overigens het enige dat van objecten (bijv. geharveste webpagina s) wordt opgeslagen. 7.5 Aanlevering van data en metadata per bron Het aanleveren van data gebeurt in principe via het OAI-PMH protocol. Omdat dit protocol niet voor alle bronnen beschikbaar is verloopt aanlevering soms per bron verschillend GGC 13 Het basismechanisme om titels vanuit het GGC naar de KB te transporteren is het Online Update Fetch (OUF) mechanisme. De metadata komen vanuit het GGC naar de KB via het Online Update Fetch mechanisme. Dit bestaat uit een deel dat bij het GGC is geplaatst onder beheer van OCLCPica, waarin de PPN's van alle nieuwe, gemuteerde en uit gebruik genomen titels, die in gebruik zijn of waren bij de KB, worden geregistreerd; en een deel bij de KB dat periodiek een request doet aan het GGC-deel om deze geregistreerde titels uit het GGC op te halen. De lijst PPN's die in het OUF wordt geproduceerd wordt gebruikt om records via SRU op te halen uit de NCC. Dit moet in een aantal stappen gebeuren om de informatie waar door pointers in de records naar wordt verwezen (thesaurusgegevens, bovenliggende records bij meerdelige en seriele werken) naar de KB te krijgen. Uit deze informatie worden de volledige records samengesteld en de thesaurusgegevens opgeslagen. De leveringsformaten via SRU uit het GGC zijn MARCXML en PICAXML. Na binnenkomst bij de KB worden de records tijdelijk opgeslagen voor verdere verwerking. De PICAXML uit de tijdelijke opslag wordt geconverteerd naar DCX. De beide oorspronkelijke formaten, PICAXML en MARCXML, blijven bewaard. Het GGC bevat geen objecten e-depot 14 De uitgevers zetten de artikelgegevens via ftp klaar op een server in de KB. In de Batchbuilder worden de metadata uit deze gegevens geëxtraheerd en klaar gezet voor de volgende processen die eveneens in de Batchbuilder plaatsvinden. De technische metadata worden in de Batchbuilder uit de objecten geëxtraheerd en tijdelijk opgeslagen Door de Batchbuilder wordt de tijdschrifttitel van elk artikel gematched met een tabel om de brontitel (tijdschrift) te normaliseren en om de unieke referentie NBN van het tijdschrift toe te 13 Zie VGA (OUF en e-depot). 14 Zie VGA (OUF en e-depot), en VGA (Batchbuilder e-depot en metadataroute artikelen). (VGA (0.7) - ontwerpdocument.doc) 19 / 31

20 voegen. Tevens krijgt elk artikel een unieke identifier in de vorm van een [artikel-]referentie- NBN. Tevens worden telkens als voor het eerst een artikel in een volume, cq. in een issue wordt toegevoegd een metadatarecord voor het volume en het issue gegenereerd. Na deze bewerking worden de records geconverteerd naar DCX en op een specifieke plek klaar gezet om te worden opgehaald door het laadproces om in de KB MDO te worden opgeslagen Eigen beheer Metadata die niet via het GGC tot stand komt wordt gemaakt via een werkdatabase. Deze werkdatabase is in opzet gelijk aan KB-MDO, waardoor verdere conversie onnodig zal zijn. De oudere data blijven, indien gewenst, bewaard in het oorspronkelijke formaat Aangeleverd De aanlevering van door derden geproduceerde data (bijv. voor het Geheugen van Nederland) verloopt via CD-ROMs/DVD's en harde schijven en mogelijk in de toekomst ook via ftp of OAI. De verwerking is nu nog geheel handmatig, maar in de toekomst zal worden aangesloten bij de procedure die voor SGD wordt ontwikkeld De metadata worden adhoc geconverteerd naar DCX en opgeslagen in de werkdatabase, waar nog nabewerking kan plaatsvinden. De oorspronkelijk aangeleverde data kunnen daar bewaard blijven Externe metadata en webpagina s Metadata van derden wordt met het OAI-protocal geharvest. Indien dit niet mogelijk is moet een ander protocol worden gebruikt. Deze metadata worden niet opgeslagen, maar direct aan Verity aangeboden om geïndexeerd te worden Zelf gecreëerde objecten In digitaliseringprojecten worden nu en in de toekomst grote hoeveelheden objecten gecreëerd. Aanlevering zal op verschillende manieren verlopen. De procedure om de workflow te beheersen en het laden te faciliteren is momenteel in onderzoek bij SGD. 7.6 Verwerking en structurering Metadata Verwerking en structurering betreffen het converteren van de oorspronkelijke metadata-formaten naar DCX en het creëren van samengestelde MPEG21 DIDL-objecten. Metadata moeten uiteindelijk altijd een correcte syntax hebben en op bepaalde onderdelen waarvoor schema's zijn ontwikkeld ook valide. Waar de KB zelf de beheersing over de database heeft wordt steeds gevalideerd aan de bron d.m.v, van schema's. In alle gevallen wordt bij opslag als gestructureerde XML in definitieve vorm gevalideerd op geldige XML en de aanwezigheid van verplichte velden zoals title en identifier. Indien records niet gevalideerd kunnen worden, worden ze niet geladen in KB-DMO en krijgt de leverancier een overzicht, met opgave van de fout. Na herstel kunnen ze opnieuw de gehele procedure doorlopen. 15 De initiële vulling van de werkdatabase zal gebeuren door een eenmalige conversie van de huidige metadata naar DCX. De mappings daarvoor zijn grotendeels gemaakt en te vinden op de programmawebsite. (VGA (0.7) - ontwerpdocument.doc) 20 / 31