Programma Vernieuwing Gegevensarchitectuur (VGA) Onderwerp: Bestemd voor: Auteur: Nummer Datum
Metadata in de KB projectteam Theo van Veen VGA 05.017 2005-09-06
versie:
0.5
v 0.1
2005-05-24
Eerste versie
v 0.2
2005-06-06
Commentaar PD verwerkt
v 0.3
2005-09-06
Voorstel voor implementatie toegevoegd
v 0.4
2005-09-29
Beschrijving overwegingen bij mapping
V 0.5
2005-10-18
Toevoegingen m.b.t. relaties tussen objecten en m.b.t. niet-bibliografische metadata (personen en termen)
Inleiding Een van de uitgangspunten voor de nieuwe KB infrastructuur is dat de metadata van de KB integraal doorzoekbaar moeten zijn zonder voorkennis over die metadata. Dit geldt zowel binnen de KB als voor het zoeken door de buitenwereld. De integrale doorzoekbaarheid vereist een gemeenschappelijk datamodel voor alle metadata. Om doorzoekbaarheid door de buitenwereld te realiseren zonder voorkennis moeten we gebruik maken van een of meer standaard datamodellen zoals Dublin Core, MARCXML, EAD etc. Omdat voor de diverse collecties of bestanden soms verschillende en specifieke functionaliteit vereist is worden soms ook metadata velden gewenst die niet voorkomen in de standaard modellen. In dit document wordt een voorstel beschreven om aan deze soms tegenstrijdige eisen tegemoet te komen. In de huidige infrastructuur maken we gebruik van verschillende datamodellen voor verschillende databases. Deze datamodellen zijn gespecificeerd in de vorm van een DTD, zoals o.a. de KB-DTD en de GVN-DTD. Deze zijn niet standaard en kunnen alleen door KB applicaties gebruikt worden. Integraal aanbieden is daarmee ook niet goed mogelijk. In het kader van TEL is er een on-the-fly conversie gemaakt die metadata uit de meeste KB-bestanden volgens het TEL datamodel beschikbaar kan stellen. Het TEL datamodel wordt een applicatieprofiel genoemd en bestaat uit Qualified Dublin Core met een aantal extensies. Binnen de KB wordt dit DCX genoemd. Dit concept kan als basis dienen voor een datamodel dat ook buiten de KB gebruikt kan worden.
Datamodellen in combinatie met protocollen voor gegevensuitwisseling. Datamodellen worden meestal gespecificeerd in een DTD, een schema of een applicatieprofiel. Services die gebruik maken van standaard protocollen voor Search & Retrieval en harvesting, zoals SRU, Z39.50, OAI, kunnen aan portals en andere webapplicaties een overzicht van de beschikbare datamodellen aanbieden. Een portal of webapplicatie zal daaruit - voorzover deze datamodellen bij de portal bekend zijn - een geschikt datamodel moeten selecteren. Als een service aangeeft dat het datamodel “X” en “Y” kan bieden dan kunnen “X” en “Y” de naam (identificatie) zijn van een DTD, een XML-schema of een applicatieprofiel. Deze naam mag ook een schema identificeren dat gewoon uit tekst bestaat zolang het voor de ontvangende en verzendende partij maar duidelijk is wat er met die naam “X” of “Y” bedoeld wordt. Voorbeeld: als de TEL-portal contact maakt met de SRU-service van de Library of Congres dan geeft deze service aan dat recordschema’s beschikbaar zijn met de namen “DC”, “MARCXML” en “MODS”. De TEL-portal zal dan om “DC” vragen omdat daar de functionaliteit van de TEL-portal op is afgestemd. De problemen De problemen die opgelost moeten worden zijn: -
Veel collecties hebben een eigen datamodel dat meestal is toegespitst op een specifiek type materiaal of specifieke functionaliteit
-
-
-
Indien van Dublin Core gebruik gemaakt wordt, spelen de problemen van specifieke functionaliteit en materiaal ook en worden meestal varianten op Dublin Core gebruikt met een paar metadata velden extra (of minder). Al deze varianten hebben dan ook een ander datamodel met een andere identificatie. De ontvangende en versturende partijen zullen niet alle namen van die varianten kennen en dus niet kunnen bepalen of een door een datamodel van de andere partij op Dublin Core gebaseerd is. Functionele eisen veranderen in de tijd en daarmee soms ook de gebruikte metadata velden. Datamodellen kunnen daarom wijzigen of er worden nieuwe versies gemaakt en krijgen dan een andere identificatie. Indien compleet verschillende standaard datamodellen gebruikt worden, bijvoorbeeld MARCXML en EAD is het moeilijk om één daarvan als gemeenschappelijk datamodel te gebruiken.
Het is dus niet mogelijk om met één standaard datamodel voor de KB aan alle eisen te voldoen. Voor de datamodellen van buiten de KB is te verwachten dat hetzelfde geldt en dat andere partijen dezelfde problemen hebben.
De oplossing Om de KB collecties integraal te kunnen doorzoeken en tegelijkertijd geen concessies te doen aan de mogelijke functionaliteit voor specifieke objecten, laten we de metadata records bestaan uit één of meerdere blokken met verschillende datamodellen. Dit is altijd een DC(X) blok en optioneel een blok conform een ander standaard datamodel en optioneel andere blokken, bijvoorbeeld een lokaal blok. Het DC(X) dient voor de integrale doorzoekbaarheid. Het tweede blok met bijvoorbeeld MARCXML of EAD dient om voor specifiek materiaal met de buitenwereld gegevens te kunnen uitwisselen. Andere blokken bevatten metadata die in eerste instantie lokaal van belang zijn of die gebruikt worden om de originele bron-metadata te bewaren. Zo’n extra blok zorgt er ook voor dat de eigenaar van een collectie niets in de weg gelegd wordt om eigen metadata te blijven gebruiken, maar het wordt afgeraden om onnodig gebruik van te maken omdat deze metadata minder vindbaar zijn voor de buitenwereld.
In bovenstaand figuur zijn verschillende blokken als voorbeeld weergegeven. Bij de standaard protocollen voor gegevensuitwisseling, zoals SRU en OAI, geeft de client applicatie aan welk record formaat gewenst is. Een combinatie van blokken kan overigens ook als record formaat aangeboden worden.
Het DC(X) blok dient om één algemeen beschrijvingsformaat te hebben voor het integraal doorzoekbaar maken van verschillende databases maar zal tegelijk ook dienen om een aantal standaard indexen te definiëren, zoals noodzakelijk is bij gebruik van MARCXML. Bijvoorbeeld: het Dublin Core element “title” komt overeen met MARC tag 245. Voor het indexeren moet dus toch een mapping gemaakt worden naar velden waar een gebruiker op zal zoeken en DC(X) vormt hiervoor een goede basis omdat de zoekvelden daar overeen kunnen komen met de velden uit het metadatarecord. Het probleem van de vele varianten gebaseerd op DC wordt opgelost door één naam te creëren voor alle datamodellen die Dublin Core (DC) als basis hebben. Deze naam is DCX en dit houdt in dat een datamodel dat de identificatie XYZ heeft maar gebaseerd is op DC ook onder de naam DCX beschikbaar is. Het belang hiervan komt sterk naar voren als ook in vooraf onbekende collecties gezocht kan worden. Als een data-aanbieder aangeeft formaat “XYZ” beschikbaar te hebben weet de ontvanger (portal) niet wat “XYZ” voorstelt. Met de naam “DCX” wordt aangegeven dat de Dublin Core veldnamen gebruikt zijn en dat nieuwe veldnamen geïntroduceerd kunnen zijn indien er redelijkerwijs geen DC veldnaam beschikbaar is. Een zoekresultaat kan dus ook onbekende velden bevatten. Omdat de set van DC elementen erg beperkt is wordt ook veel gebruik gemaakt van Qualified Dublin Core, dat meer verfijning biedt d.m.v. extra termen en het gebruik van coderingsschema’s (ISBN is bijvoorbeeld een coderingsschema van het veld identifier). Een verdere verfijning wordt verkregen via het concept van DC applicatieprofielen. Een applicatieprofiel is een lijst met termen uit verschillende sets waaronder Dublin Core en Qualified Dublin Core en eventueel aangevuld met eigen temen of termen uit andere applicatiegebieden. De DCMI organisatie publiceert en aantal applicatieprofielen. We kunnen hiermee de betekenis van DCX iets bijstellen: met DCX wordt bedoeld dat in principe termen zijn gebruikt uit DCMI applicatieprofielen en alleen nieuwe termen gebruikt zijn als er geen veld uit een DC applicatieprofiel bruikbaar was. Het resterende probleem is wat een externe service met die onbekende velden aanmoet. Een eerste stap is het gebruik van een metadata registry waarin de KB maar ook externe partijen hun metadata in kunnen registreren. De DCMI organisatie biedt die mogelijkheid niet. Indien men een nieuwe term aan de metadata wil toevoegen kan eerst de registry geïnspecteerd worden om te bepalen of zo’n term er al is. Zo niet, dan kan men de term in de registry op te laten nemen. Ook een aanbieder van een portal kan in de registry kijken om voor onbekende velden die door de portal ontvangen worden de portal eventueel aan te passen. De European Libary onderhoudt al zo’n registry en hier kan dus bij aangesloten worden. Metadata deskundigen zouden er problemen mee kunnen hebben dat data-elementen hier in een XML-record worden opgenomen zonder dat dit in bijvoorbeeld een XML-schema is vastgelegd. Validatie van een gevonden metadata-record is dan niet mogelijk maar is bij het presenteren van zoekresultaten ook meestal niet zinvol. De meeste applicaties gebruiken voor het presenteren van XML een XSL-stylesheet en daarbij worden onbekende velden gewoon genegeerd. In een XSLstylesheet kan echter wel vastgesteld worden dat er onbekende velden gebruikt worden en het kan aan de gebruiker overlaten worden of deze velden gepresenteerd moeten worden. Eventueel kan een applicatie de gebruiker zelf aanbieden eigen functionaliteit aan zo’n onbekend veld te koppelen. Met deze oplossingen kunnen de metadata van de KB via de standaard protocollen SRU/W en OAI zowel binnen als buiten de KB integraal doorzoekbaar/opvraagbaar gemaakt worden, terwijl voor lokale applicaties de mogelijkheid open gehouden wordt om ook eigen velden te hanteren.
Implementatie. In SRU wordt bij elk SRU-request opgegeven in welk record schema de resultaten aangeleverd moeten worden. In een zogenaamd “explain record” wordt aan de buitenwereld kenbaar gemaakt welke formaten beschikbaar zijn. Hierin is geen rekening gehouden met het feit dat de beschikbare record schema’s kunnen verschillen per collectie of per record en dat die informatie pas beschikbaar kan komen indien de informatie uit de index over een record beschikbaar is. Het SRU protocol biedt hier geen standaard oplossing voor. Ook is er geen standaard manier om aan te geven of een verkort record uit de index of een volledig record uit de XML database gewenst is. M.a.w. bij een zoekactie wordt een bekend record schema gevraagd en alleen als een applicatie a-priori op de hoogte is van de beschikbaarheid van andere formaten zal een van deze formaten mogelijk worden opgevraagd.
De hiervoor gekozen oplossing is om bij het indexeren een veld toe te voegen met beschikbare record schema’s. Dit veld wordt opgenomen in de verkorte records (captions) in de index. Bij het indexeren van fulltext of een website zal er meestal geen volledig XML record zijn en wordt in dit veld aangegeven dat er alleen HTML beschikbaar is. Voor geharveste metadata records uit externe bronnen zal er veelal geen verschil zijn tussen het volledige record en de recordgegevens uit de index. In dat geval kan het veld met beschikbare recordschema’s leeg blijven. Dit veld is overigens geen standaard veld en daarom meestal niet bruikbaar voor externe applicaties. Eén van de mogelijke recordschema’s is die waarbij volledige records in een “envelop” aangeboden kunnen worden met daarin alle beschikbare formaten of een verwijzing daar naartoe. Een standaard voor zo’n envelop is MPEG21 DIDL. De recordschemas in het explain record die via SRU opgevraagd kunnen worden, zijn dan DC, DCX, MARCXML en EAD en MPEG21. Bij het opvragen van MARCXML en EAD kan niet gegarandeerd worden dat een record beschikbaar is in dat formaat. Bij het opvragen van MPEG21 echter krijgt men alle formaten die beschikbaar zijn. Hoewel MPEG21 als standaard meer en meer genoemd wordt, is het hier voorgestelde gebruik nieuw. Omdat het de KB gaat om optimale interoperabiliteit met de buitenwereld is het wenselijk dit idee ook te propageren, maar eventueel oplossingen die de buitenwereld hiervoor kiest over te nemen. Door de gekozen implementatie zullen we andere oplossingen meestal eenvoudig kunnen realiseren. Een bijkomstig voordeel van het gebruik van een envelop zoals MPEG21/DIDL is dat we voor eigen applicaties extra gegevens, bijvoorbeeld exemplaargegevens of catalogiseergegevens, mee kunnen leveren zonder het DC metadata record te “vervuilen”. Een definitieve keuze voor de vorm van de envelope wordt bij implementatie gemaakt. Bij het opvragen via SRU zal het mogelijk zijn een combinatie van recordschema’s op te geven bijvoorbeeld recordSchema=DC+EAD. De metadata records zullen per record schema als een XML blob in de database worden opgeslagen. Dus elk record schema komt overeen met een veld. Dit in tegenstelling met een database tabel met van tevoren vastgelegde velden zoals die binnen een record schema voorkomen. Het moet namelijk mogelijk zijn om nieuwe metadata elementen toe te voegen zonder de tabeldefinities in de database te hoeven veranderen. Validatie van records zal bij de bron plaats moeten vinden. Metadata elementen die niet in de metadata registry geregistreerd zijn maar wel in geharveste metadata records voorkomen zijn in de KB MDO gewoon toegestaan!
Overwegingen en keuzes t.a.v. mapping. Het huidige metadata model van de KB is niet zondermeer over te zetten naar Dublin Core eXtended. Bij de mapping en de conversie moeten daarom een aantal keuzes gemaakt worden en problemen worden opgelost om te zorgen dat geen functionaliteit verloren hoeft te gaan. De hierbij gehanteerde overwegingen en gemaakte keuzes zijn hieronder opgesomd. Voor meer details wordt verwezen naar VGA - 05055. 1) Het voornaamste doel van de metadata is objecten of diensten voor de gebruiker te beschrijven, via indexering vindbaar te maken en om de gebruiker naar het object of de dienst te verwijzen. 2) Uitgangspunt is dat onze metadata zonder extra uitleg voor externe applicaties bruikbaar zijn. Daarom moeten alleen nieuwe velden geïntroduceerd worden indien dat voor de functionaliteit nodig is. 3) De ordening die in de KB-DTD is aangebracht draagt niet bij aan bovenstaand doel en vervalt. De huidige attributen vervallen en waar zinnig worden velden samengevoegd. 4) Een van de belangrijkste velden is het identifierveld. Dit veld moet bij voorkeur een URL zijn die direct naar het object leidt. Voor zover nodig moeten de oorspronkelijke velden daarom tot een URL worden samengevoegd. Identifiers worden herkenbaar gemaakt via het DCMI encoding scheme als XML attribuut of d.m.v. een prefix. Er kunnen meerdere identifier-velden in een record voorkomen en er kan ook naar meerdere objecten verwezen worden. 5) In de KB-DTD komen velden voor die combinaties zijn van andere velden en dat weer in verschillende combinaties. Die velden worden waar zinvol gecombineerd en de varianten vervallen. Bijvoorbeeld de 4 velden “achternaam”, “voornaam”, “achternaam + voornaam” en “voornaam + achternaam” worden gewoon “voornaam + achternaam” (geldt niet voor speciale naamindex).
6) Indien het wenselijk is dat de meer specifieke betekenis van een veld voor de gebruiker zichtbaar is kan dat in het veld worden aangegeven met gewone tekst of een label. Bijvoorbeeld een identifier van het type XYZ wordt niet veld “XYZ” genoemd maar gewoon dc:identifier en de waarde kan dan vooraf gegaan worden door “XYZ:” als label. Voor de gebruiker gaat er dan geen informatie verloren en applicaties hoeven geen nieuwe veldnaam te leren. 7) Indien in één record meerdere objecten beschreven worden, bijv de band van een handschrift en het handschrift zelf, heeft het de voorkeur geen nieuwe velden te introduceren maar de diverse objecten in een container op te nemen. Ze blijven wel onderdeel van het DCX blok. Een alternatief is de objecten door afzonderlijke metadata records te laten beschrijven, maar dat valt buiten de mapping. 8) Indien de metadata fulltext elementen bevatten worden deze uit de metadata gehaald en als apart object in een mpeg21 DIDL structuur opgenomen. Dit speelt bij GVN en Bibliopolis. 9) Administratieve gegevens worden niet naar DCX velden gemapped maar komen in een apart administratief blok of in aparte Oracle velden. 10) Hiërarchische relaties tussen metadata records worden weergegeven met de velden isPartOf en hasPart. Deze velden zijn herhaalbaar. Indien bij het veld isPartOf niet eenduidig is vast te stellen wat het hoger liggende niveau voorstelt wordt dezelfde methodiek gehanteerd als bij 2). De default is dat isPartOf verwijst naar een titel van een hoger gelegen object. Dit object hoeft niet perse een eigen metadata record te hebben. Hiermee maken we dit veld voor eigen applicaties beter “machine-interpreteerbaar” maar voor externe applicaties door de gebruiker interpreteerbaar. Zie ook onderstaand kader voor een meer details. 11) In de KB metadata komen behalve beschrijvingen van opvraagbare objecten ook persoonsbeschrijvingen en thesaurustermen voor. Omdat het gewenst kan zijn deze integraal met bibliografische gegevens doorzoekbaar te maken worden hiervoor naast de typen uit de gecontroleerde DC vocabulaire ook het type “person” en “term” opgenomen met een eigen set metadata elementen.
Relaties tussen objecten en subobjecten (bijv. tijdschrift en artikel) worden in de metadata veelal gelegd via het veld identifier van het object en het veld isPartOf van het subobject. Een object kan echter onderdeel zijn van meerdere objecten en de identifier hoeft niet uniek te zijn. Stel: object A heeft een veld
ABC en object B = subobject van A heeft het veld ABC Willen we alle subobjecten van A vinden dan kunnen we zoeken op isPartOf=ABC. Vanuit het subobject kan object A gevonden worden via zoeken op identifier=ABC. Dit hoeft niet specifiek genoeg te zijn, dus indexeren we ook XYZ=ABC voor object A en kan object A gevonden worden door te zoeken op XYZ=ABC. De applicatie software kan dit afleiden uit het encoding scheme van het veld isPartOf. Hiervoor is dan wel nodig dat de applicatie software van deze regel op de hoogte is. Zo niet, dan kunnen er ook andere objecten gevonden worden die toevallig ABC als identifier hebben. Voorbeeld: Een artikel met isPartOf=12345678 moet een subobject zijn van het tijdschrift met identifier=12345678. Er kunnen echter ook andere objecten zijn met deze identifier. Indien het encoding scheme ISSN is dan kan het tijdschrift gevonden worden met ISSN=12345678. Voor het vinden van subobjecten blijft het probleem bestaan, tenzij we ook hier een apart indexveld het coderingsschema introduceren. Hier is echter geen standaard voor. We kunnen dat deels oplossen door in de zoekopdracht het type van het subobject (in dit geval type=article) mee te geven. Om te zorgen dat een identifier en het isPartOf veld een unieke waarde hebben kan de aanleverende bron de identifier en het overeenkomstige isPartOf veld van een prefix voorzien worden. Bijvoorbeeld: object A heeft veld XYZ:ABC en object B heeft een veld XYZ:ABC Zoeken op isPartOf=XYZ:ABC levert dan alle subobjecten van A. Het voordeel is dat de aanbieder van collectie metadata dit zelf in de hand heeft zonder dat dit invloed heeft op de metadata mapping of de indexering. De applicatiesoftware moet dan wel “weten” dat isPartOf op een identifier slaat en er moet gechecked worden of een dubbele punt in een zoekopdracht geen speciaal teken is voor de indexsoftware.. In VGA willen we trachten beide methodieken te ondersteunen. Wil men alle subobjecten van A kunnen opvragen dan moet de applicatiesoftware weten dat A subobjecten kan hebben. Dit moet uit de andere metadata zoals type en format afgeleid kunnen worden. De vocabulaire voor type moet daartoe eventueel uitgebreid worden.
In een generiek stylesheet template zal dit verder uitgewerkt worden. Zolang de indexering hierop nog niet is aangepast zal dit stylesheet tijdelijk nog refereren aan velden die nu in de index voorkomen. Zodra de metadata conform het nieuwe datamodel in de KB MDO beschikbaar zijn en ook de overeenkomstige indexvelden beschikbaar zijn kan een meer definitief generiek template stylesheet gemaakt worden.
Richtlijnen voor het gebruik van DCX Bij het creëren van velden voor gegevens die niet in DC zitten gelden de volgende richtlijnen: 1) Probeer in eerste instantie de DC velden te gebruiken 2) Probeer in tweede instantie de DCQ velden te gebruiken 3) Check de metadata registry van de European Library en de DCMI website of er een bestaand veld is dat voldoet 4) Bekijk of een veld specifiek is voor een bepaald vakgebied en tracht met vakgenoten tot overeenstemming te komen 5) Laat nieuwe termen alleen aan de registry toevoegen indien deze termen ook voor anderen bruikbaar zijn 6) Nieuwe termen kunnen in een lokaal blok geplaatst worden of worden toegevoegd aan het DCX blok. Het lokale blok wordt alleen op verzoek gepresenteerd. Toevoegen aan het DCX blok heeft de voorkeur. Als het veld niet gebruikt hoeft te worden kan het beter weggelaten worden ! 7) Nieuwe termen in het Engels en met de volgende componenten: 1) waar is de term een eigenschap van, 2) de naam van de eigenschap en 3) het type. Bijvoorbeeld: “abstactLanguageCode”. De eerste en laatste component zijn optioneel.
Toekomstvisie Bovenstaand voorstel is op volgende toekomstvisie gebaseerd. We streven ernaar om in onze gegevens zoveel mogelijk structuur aan te brengen om deze machine-leesbaar en machineinterpreteerbaar te maken. Om dit mogelijk te maken helpt het als we standaardiseren, maar tegelijkertijd moeten we gebruik maken van de intelligentie van applicaties om met veranderende standaarden, fouten in implementaties en niet-gestandaardiseerde gegevens om te kunnen gaan. In de praktijk betekent dit bijvoorbeeld dat een portal voor alle “standaard” velden vooraf gespecificeerde functionaliteit kan bieden, maar als deze portal een niet-standaard veld tegenkomt de gebruiker de mogelijkheid biedt om dit veld toch te presenteren en eventueel te koppelen aan specifieke functionaliteit. Een portal-leverancier kan eventueel een nieuwe versie van zijn portal aanpassen aan nieuw “ontdekte” velden. Het gaat nu nog te ver om van applicaties te verwachten dat ze de betekenis van een metadataveld “begrijpen”. Het is echter wel mogelijk om velden verkregen via de ene service te koppelen aan een ander type service. Bijvoorbeeld kan een veld met een samenvatting als input dienen voor een vertaal-service, een auteursveld kan als input dienen voor een zoekfuncties in een persoonsnamen thesaurus etc. Deze koppelingen kunnen al dan niet dynamisch in applicatie worden vastgelegd en het zijn deze koppelingen die maken dat een applicatie metadatavelden lijkt te “begrijpen”. Over het algemeen zal men geneigd kunnen zijn om voor bovenstaand doel RDF (Resource Description Framework) te gebruiken omdat RDF meer mogelijkheden biedt om met onbekende metadata velden om te gaan. Het is te complex om hier dieper op in te gaan maar vooralsnog gaan we er vanuit dat voor het hier beschreven doel het hier voorgestelde DCX-concept voldoende is en een lagere implementatiedrempel heeft dan wanneer RDF gebruikt wordt. Het gebruik van RDF wordt die beschreven concept echter niet uitgesloten.
