Semantha Museum Standaardisatie

Semantha museum onderscheidt zich onder meer van andere software doordat wij de veldindeling tegen beperkte kosten kunnen aanpassen aan de wensen van afzonderlijke musea. Een nadeel van het vaststellen van een eigen veldindeling door individuele musea zou kunnen zijn dat gegevensuitwisseling en dataconversie moeilijker kunnen worden.

Wie zich verdiept in de beschikbare informatie over standaards, kwaliteitsinstrumenten en beoordelingscriteria raakt gemakkelijk de weg kwijt: de beschikbare informatie is een ware jungle van veelal abstracte specificaties. Uitleg over toepassing in de praktijk is lang niet altijd aanwezig en geeft ook vaak weinig houvast bij het kiezen van een eigen veldindeling. Dit maakt het voor individuele musea moeilijk om verantwoorde keuzes te maken.

MetaClass wil haar klanten hier graag behulpzaam bij zijn. Om een en ander snel concreet te maken zijn wij een plan gaan maken om de basis veldindeling van Semantha Museum zoveel mogelijk in overeenstemming te brengen met standaards. Dit plan is beschreven in "Velddefinities Semantha Museum 1.2". Daarin staat een kruistabel ("crosswalk") waarin de velden van Semantha Museum 1.2 worden 'gemapt' naar de volgende standaards:

De basisregistratiekaart van de Stichting IMC,
De Historisch-Voorwerpkaart van SIMIN,
De Registratie van Archelologische Collecties in Musea (opgesteld in opdracht van de Vlaamse Gemeenschap),
De Dublin Core.

Daarnaast bevat het een literatuurverwijzing en een uitgebreide verantwoording waarin ook de belangrijkste andere standaards aan bod komen.

Neem contact met ons op voor meer informatie.

Semantha Museum

Verantwoording

Inleiding

In 2004 is voor het Natuurmuseum in Groningen op maat een applicatie voor registratie van de collecties van voorwerpen en literatuur. De velden in deze applicatie zijn in overleg bepaald. De veldlengtes van alfanumerieke velden is destijds gebaseerd op de bestaande data uit de oude applicatie.

Toen MetaClass op basis van deze applicatie in 2005 de eerste versie van het softwarepakket "Semantha Museum" ontwikkelde ontstond er behoefte aan een standaard veldindeling die in de demo gebruikt zou kunnen worden en die ook als startpunt zou kunnen dienen in gesprekken met musea over de gewenste veldindeling. Bovendien zou deze veldindeling gebruikt kunnen worden door musea die een specifieke veldindeling niet nodig of te kostbaar zouden vinden. Voor deze veldindeling zijn wij direct op zoek gegaan naar een standaard die een redelijk overzichtelijk aantal velden beschrijft. Wij hadden gehoord van het bestaan van de basisregistratiekaart en wisten de hand te leggen op de Basisregistratiekaart van het Centrum voor Religieuze Kunst en Cultuur (CRKC). De toelichting op deze basisregistratiekaart was echter erg summier, zodat veel van de veldlengtes en veldindeling destijds nog zijn gebaseerd op onze informatie over de data van het Natuurmuseum.

Toen wij recentelijk op zoek gingen naar meer informatie over standaards bleek echter dat de "basisregistratiekaart" die in Nederland als minimale standaard voor collectieregistratie geldt niet die van het CRKC is maar die van de Stichting IMC en dat hierbij veel meer toelichting beschikbaar is, waaronder ook veldlengtes. Daarnaast bleken er nog verscheidene andere standaards te zijn. Zo veel zelfs dat men al snel van de bomen het bos niet meer ziet.

Voor onze basis veldindeling is het belangrijk dat de veldindeling een redelijk compleet minimum omvat zodat de basisversie van de applicatie en de demo niet te ingewikkeld worden, maar dat veel musea zich er wel in kunnen herkennen en dat een museum dat niet te hoge eisen stelt er mee uit de voeten kan. Bovendien willen wij de veldindeling daadwerkelijk implementeren in Semantha Museum, wat nog een aantal praktische eisen oplevert die vooral samenhangen met de de facto standaard van relationele databases.

Om in dit kader tot een doorsnede te komen van zoveel mogelijk relevante standaards streven wij na om de "kleinst gemene veelvoud" te hanteren van de minimale of beperkte standaards of als minimaal of beperkt aangeduide subsets. De kleinst gemene veelvoud houdt in dat alle velden van elke minimale of beperkte subset of standaard te 'mappen' (herleiden) zijn naar overeenkomstige velden in de basis veldindeling van Semantha Museum. In de crosswalk is vervolgens ook de mapping opgenomen van deze velden naar andere velden van de vermelde standaarden, zodat een zo compleet mogelijke crosswalk ontstaat.

Relationele databases

Onder software ontwikkelaars gelden relationele databases tegenwoordig als de de facto standaard. Hierbij betreft het niet een formele specificatie, maar een convergentie in de markt die toelaat om conclusies te trekken over wat een relationele database is en hoe die moet werken. De impact daarvan voor de software ontwikkeling is uitermate concreet: functionaliteit die door de databases goed wordt ondersteund is snel en gemakkelijk aan te spreken. Wil men echter dingen die non-standaard zijn, dan moet men die zelf bouwen. Dat is niet alleen kostbaar maar leidt ook vaak tot sub-optimale oplossingen die ook voor de gebruiker niet geweldig functioneren.

MetaClass wil der halve zoveel mogelijk de standaard van relationele databases volgen en heeft waar nodig interpretaties gemaakt van de standaards ten behoeve van inpassing in het relationele model. Een van de eisen van relationele databases is dat veldindeling, veldtypes en veldlengtes van tevoren worden vastgelegd. De enige standaard die ons ter beschikking stond die deze informatie bood was de basisregistratiekaart van de stichting IMC. Deze is bovendien de eenvoudigste standaard (kent de minste velden), zodat deze het meest geschikt was voor onze doelen. De afwegingen bij de vertaling naar relationele databases hebben dan ook vooral betrekking op deze basisregistratiekaart.

Basisregistratiekaart (BRK)

De basisregistratiekaart is van oorsprong waarschijnlijk gemaakt voor handmatige registratie (op papier), de instructies ten aanzien van de computer zijn later toegevoegd. Dit heeft ertoe geleid dat er een aantal constructies worden gebruikt die niet passen binnen relationele databases. Vroeger was dat wellicht niet zo'n probleem, maar moderne software is in hoge mate gebaseerd op het gebruik van standaardcompontenten. Voor gegevensopslag zijn relationele databases tegenwoordig zonder meer de standaard. De afwijkende constructies zijn met wat creativiteit wel naar relationele tabellen te vertalen, maar voor gekunstelde oplossingen kunnen geen standaard softwarecomponenten worden gebruikt. Dat zou leiden tot een flinke verhoging van de ontwikkelkosten. Bovendien zou het resulterende datamodel slecht uitwisselbaar worden met andere sectoren en zal de applicatie ook wat betreft de werking voor de gebruikers blijven afwijken van wat gebruikelijk is.

Omdat gebruikers van collectieregistratie software in toenemende mate, net als bijna iedereen tegenwoordig, ook allerlei andere software gebruiken en informatieuitwisseling steeds belangrijker wordt kiest MetaClass ervoor om dicht bij het relationele model te blijven. Dit leidt tot iets minder flexibiliteit in de basisversie van Semantha Museum. Omdat MetaClass aanbiedt om de veldindeling voor specifieke musea aan te passen is dat geen probleem en komt het de standaardisatie in de uiteindelijke gegevensverzamelingen die met behulp van Semantha Museum worden beheerd eerder ten goede.

De afwijkende constructies betreffen:

1.Herhaalde relatie-velden. Relationele databases werken met tabellen. Daarbij komen de regels in de voorwerpen-tabel overeen met de registratiekaarten en de kolommen met de velden. Herhaling is alleen mogelijk door de voorwerp-regels te relateren aan regels in een andere tabel. Herhaling van trefwoorden laat zich hier goed naar vertalen, want volgens het relationele model dient men niet de trefwoorden zelf in de voorwerpen-tabel op te slaan, maar in een afzonderlijke gerelateerde tabel.

2.Woordcontrole. In termen van een relationele database (normalisatie) moet dit worden opgelost door een gerelateerde tabel met de woorden. Vervolgens kan men in de user interface vrije tekst invoer met woordcontrole implementeren, of kan men selectie aanbieden, eventueel met behulp van een zoekfunctie. Eigenlijk hoort de keus voor een van deze drie oplossingen niet thuis n de velddefinities. MetaClass beschouwt 'woordcontrole' daarom als specificatie van een relatie met een woorden-tabel waarin de 'woorden' (eigenlijk termen) uniek zijn.

3.Herhaalde tekst-velden. Hiervoor is in het relationele model geen passend equivalent. Het nut van het herhaalbaar zijn van die velden is bovendien niet duidelijk. Bij het zoeken en presenteren is de betekenis van de hoeveelste herhaling immers onduidelijk. Men kan de tekst dus net zo goed in één veld plaatsen. Daarvoor moet men wellicht wel een grotere veldlengte kiezen. Zo nodig kan voor het veld een meerregelig invoerveld worden gebruikt, zodat de gebruiker met behulp van regel-einden eenzelfde onderscheid kan maken als met het gebruik van een extra veldherhaling.

4.Variabele veld-qualfiers. Deze worden toegepast in 12 afmetingen. Dit maakt het zoeken erg lastig. MetaClass opteert dan ook voor vaste afmetingvelden. Vooralsnog beperkt tot lengte, breedte en hoogte. Gewicht en schaal zouden kunnen worden toegevoegd als daar regelmatig behoefte aan blijkt te zijn.

5.Herhaalde veldgroepen. Deze horen in termen van het relationele model (normalistie) duidelijk in een eigen tabel thuis. Besluit men om af te zien van variabele veld-qualifiers voor de afmetingen dan is het voor de gebruiker wel veel gemakkelijker om de afmetingvelden gewoon direkt in de registratiekaart te hebben, en kunnen die worden opgeslagen in de voorwerpen-tabel zelf. Herhaling van dateringen (van, tot en met) is technisch geen probleem, maar het is onduidelijk welk doel hiermee wordt beoogd, zodat onduidelijk wordt wat het zoeken op datering eigenlijk op zal leveren. Gaat het om verschillende perioden in de geschiedenis van het voorwerp dan lijkt het logisch om ook nadere informatie over die periodes te vermelden. Gaat het om wijzigingen die in het voorwerp zijn aangebracht dan wil men waarschijnlijk ook vermelden wie dat heeft gedaan en misschien ook welke materialen daarbij gebruikt zijn. Gaat het om toevoeging van onderdelen dan wil men waarschijnlijk ook vastleggen om welke onderdelen het gaat. Om deze onduidelijkheid te voorkomen is het beter om de datering standaard niet te herhalen en voor musea waar de herhaling wel zinvol is een specifieke en betekenisvolle extra tabel te relateren die dan ondermeer een niet-herhaalde datering zal bevatten.

6.Variabele eenheid. Dit komt voor bij 12 afmetingen. Dit maakt het zoeken met behulp een relationele database zo goed als onmogelijk. De database zoekt namelijk gewoon naar getallen en zal dus geen verschil zien tussen millimeters en meters. In de database moeten dus alle afmetingen in dezelfde eenheid worden vastgelegd. Normalisatie leidt er toe dat deze eenheid niet voor elk individueel voorwerp vastgelegd wordt, maar eenmalig voor het betreffende museum, dus in de tabel Instelling. Als gewicht wordt toegevoegd is daarvoor een afzonderlijke eenheid in de tabel 'Instelling' nodig.

Zo nodig zou men wel in de user interface naar een geschikte eenheid kunnen vertalen, bijvoorbeeld 1000 mm als 1 m kunnen afbeelden, of de gebruiker de keuze kunnen geven om 1 m. in te voeren en dat naar 1000 mm vertalen. Dit is echter irrelevant voor gegevensuitwisseling en dataconversie en hoort dus niet thuis in dit document. Wat wel relevant zou kunnen zijn is dat uit de bij de invoer gebruikte eenheid informatie zou kunnen worden afgeleid over de nauwkeurigheid van de maten. Dit is echter niet betrouwbaar als de gebruiker hierin geen richtlijnen volgt. Dergelijke richtlijnen en een relatie met de nauwkeurigheid is helaas niet te vinden in de documentatie van de basisregistratiekaart. Wij kunnen daarom vooralsnog niet beter doen dan dit aan de orde stellen bij het overleg over de veldindeling van het individuele museum.

7.Variabel datatype. Dit komt voor bij datering. Men kan hier invullen: een jaar, een datum, een periode (van - tot en met) waarbij men weer kan kiezen voor jaar of datum, en ook open periodes mogelijk zijn (alleen van, of alleen tot). In relationele databases moet men voor elke kolom van tevoren kiezen voor een datatype. De meeste databases ondersteunen bovendien geen periodes. Daarom is één kolom voor 'van' en één kolom voor 'tot en met' noodzakelijk.

Voor het overige is het gebruik van jaartallen en datums door elkaar een kwestie van variabele eenheid. Ook hier zou men in de user interface een zekere flexibiliteit kunnen inbouwen door vertaling van datum naar jaartal en omgekeerd. Zo kan 1850=1899 worden vertaald naar "van: 1-1-1850 tot en met: 31-12-1899", zodat de database bij het zoeken naar een willekeurige datum tussen 1850 en 1899 het voorwerp ook zal vinden. Dit heeft wel als nadeel dat men de (impliciete) informatie over de nauwkeurigheid van de vastlegging verliest. Nu is datering in de praktijk ook niet altijd even precies. Zo zijn er soms discussie tussen experts over de datering van een voorwerp waarbij de meningen meerder jaren uiteen lopen. Bij archeologische voorwerpen zijn onzekerheidsmarges van eeuwen niet ongewoon. Daarom is het wenselijk om expliciete informatie over de precisie te kunnen vastleggen. Dit biedt ook gelijk de mogelijkheid om vage aanduidingen als 'ca.' te vervangen door een exactere precisie waaruit is af te leiden vanaf/tot welke datum men redelijk zeker is van de datering, zodat daar bij het zoeken gebruik van kan worden gemaakt.

In de velddefinities voor Semantha Museum zijn vanwege het bovenstaande een aantal velden van de basisregistratiekaart gesplitst. Deze kunnen als daar behoefte aan is gemakkelijk weer worden samengevoegd. Ten behoeve van rapportages worden hiervoor soms al afgeleide velden opgenomen in de applicatie, die ook zijn beschreven in de velddefinities.

In Semantha Museum hebben alle tabellen een veld 'id' voor interne identificatie en worden alle relaties gelegd middels foreign keys. In het schema velddefinities worden de key en foreign key velden niet vermeld. In plaats daarvan wordt de gerelateerde tabel als type vermeld en worden tabellen die alleen 2 foreign keys bevatten overgeslagen. Dit maakt het schema gemakkelijker te begrijpen voor mensen die geen kennis hebben van relationele databases.

De Historisch-Voorwerpkaart (HVK)

De Historisch Voorwerpkaart is een oude standaard, die gericht is op handmatige registratie. Een handleiding die toelicht hoe een geautomatiseerde historische voorwerpkaart zou moeten worden gebruikt hebben wij niet kunnen vinden. Toch is de Historische Voorwerpkaart nog steeds relevant. Zo is bijvoorbeeld de informatie die op internet staat over de uitgebreide standaard voor registratie van historische collecties in Musea veel beter te interpreteren als men kennis heeft van de historische voorwerpkaart. Ook lijken er lijnen te zijn tussen de Historische voorwerpkaart en CIMI, en daarmee ook SPECTUM.

Bij de interpretatie van de Historische voorwerpkaart in termen van relationele databases treden vergelijkbare problemen op als bij de interpretatie van de basisregistratiekaart. Deze worden hier alleen besproken als ze niet eerder aan de orde zijn geweest bij de basisregistratiekaart.

De veldindeling van de historische voorwerpkaart is vrij uitgebreid: er zijn 90 velden. In de Handleiding (5) onder "1.5 Minimale gegevens" genoemde veldnummers zijn in de crosswalk tabel vet gedrukt. Daarnaast worden er nog veldnummers genoemd die men nodig heeft als men een inventarisboek wil produceren en als men standcatalogus wil creëren. Deze zijn in de tabel cursief weergegeven.

Helaas zijn een aantal aanduidingen voor meerdere interpretaties vatbaar. Onduidelijkheden en punten waarop de basis veldindeling van Semantha Museum afwijkt worden hier onder besproken

1.Materiaal per onderdeel "25/27". Het is de vraag wat de schuine streep betekent. Het lijkt niet logisch dat er van/tot en met wordt bedoeld, want veld 26 heeft dezelfde naam als veld 24, dus dan zou hier 24/27 hebben gestaan. Waarschijnlijk bedoelt men en/of.

2.Merk/inscriptie "34/38". Uitgaande van en/of zijn deze velden aanwezig in de tabel

3.Afmetingen "28/31". Het invullen van alleen deze velden is niet zinvol: deze velden geven alleen de betekenis aan van waarde die in het volgende veld (29/32) wordt ingevuld. Waarschijnlijk bedoelt men hier 28 t/m 30 en/of 31 t/m 33. Dit is vergelijkbaar met de basisregistratiekaart, zie aldaar.

4.Pedigree "50/57" Dit is niet te interpreteren: Van 55, 56 en 57 is al aangegeven dat ze tot de minimale gegevensset behoren. Deze velden betreffen bovendien eveneens de objectgeschiedenis. Alleen veld 50 is ook niet zinvol, in de voorbeelden wordt het gebruikt om de betekenis van navolgende velden aan te geven. Het is dus aannemelijk dat een meer complete beschrijving van de voorwerphistorie wordt nagestreefd.

Een dergelijke beschrijving zou kunnen worden gemaakt door het toevoegen van een tabel "Voorwerphistorie" die 1:0-m aan de voorwerpen wordt gerelateerd. Hierbij moet worden aangetekend dat de werkwijze met het aangeven van de betekenis in het ene veld van waarden in het andere veld (variabele veld-qualifier) erg flexibel is, maar ongebruikelijk bij het ontwerpen van relationele databases. De reden hiervan is dat het alleen zinvol is om te zoeken in dergelijke gegevens als de gebruiker booleanse logica goed beheerst. Onze ervaring is dat dit voor de meeste gebruikers niet het geval is. Dit zal in de praktijk de bruikbaarheid van deze velden beperken. De vraag is dan of het registreren van deze gegevens in een gestructureerde vorm voor kleinere musea zinvol is. De meerwaarde ten opzichte van het vastleggen van voldoende exacte verwijzingen naar documentatie die de historie beschrijft zou wel eens een even goede zo niet betere documentatie op kunnen leveren met minder inspanning. Dit is in lijn met de RACM standaard die hier onder wordt besproken. Daarom laten we een Pedigree tabel vooralsnog buiten de basis veldindeling. Wel vervangen we het veld 'bijonderheden' door 'historie' zodat in vrije tekst de objecthistorie kan worden vastgelegd. Musea die dit wensen kunnen dit in het kader van het laten maken van een eigen veldindeling wel een objecthistorietabel laten toevoegen.

Registratie van Archelologische Collecties in Musea (RACM)

De behoefte van het Natuurmuseum Groningen aan een specifieke veldindeling is waarschijnlijk geen toeval: de veldindeling van zowel de basisregistragtiekaart als de historisch-voorwerpkaart bevat wel een aantal velden die specifiek zijn voor door de mens gemaakte voorwerpen (Artefacten), maar vergelijkbare velden voor natuurhistorische en archeologische objecten ontbreken. In België is in opdracht van de afdeling Beeldende Kunst en Musea van de Vlaamse Gemeenschap inmiddels een onderzoek gedaan dat tot doel had om standaarden te formuleren voor de geautomatiseerde registratie van archeologische collecties in Vlaamse musea. Het resultaat is drie standaards: De minimale standaard, de aanvullende standaard en de uitgebreide standaard. Deze zijn summier beschreven op internet (4). In de crosswalk tabel zijn alle velden van de minimale en aanvullende standaard opgenomen. Bovendien is voor de andere velden die al in de tabel stonden zo mogelijk de benaming in de uitgebreide standaard vermeld. Om een consequente nummering te krijgen zijn de nummers van de uitgebreide standaard vermeld. De nummers van velden die deel uitmaken van de minimale standaard zijn vet gedrukt. De velden die daar geen deel van uitmaken maar wel van de aanvullende standaard zijn in cursief weergegeven.

Uit de crosswalk blijkt gelijk dat er nog een aantal velden aan de basis veldindeling van Semantha Museum moeten worden toegevoegd. Er zijn echter enkele velden die nadere bespreking behoeven:

134 Referentie. De mogelijkheid tot het maken van referenties naar aanvullende gegevens. In de informatie op internet is niet te vinden of het hier om een tekstuele beschrijving gaat of gestructureerde data.

133 Referentie soort. De betekenis is op basis van wat op internet is beschreven niet geheel duidelijk. In de instructie bij de historische voorwerpkaart (5) is wel een vergelijkbaar veld te vinden, 78 Aard referentie. Als mogelijke waarden voor dit veld worden genoemd 'afbeelding', 'beschrijving', 'gebruikt', 'gecatalogiseerd' en 'vermelding'. In de Dublin Core (zie hier onder) wordt een nadere specificatie van 'Relation' opgenomen, maar daar betreft het weer andere waarden: 'IsPartOf', 'IsVersionOf', 'IsFormatOf, 'HasFormat', 'IsReferencedBy, 'References', 'IsBasisFor, 'IsBasedOn', 'Requires'.

In Semantha Museum zijn twee soorten referenties:

Referenties naar afbeeldingen (media). Dit zijn in feite op internet vertoonbare media bestanden, die naar de server geupload zijn, en dus ook daadwerkelijk vanuit de applicatie en/of een website bekeken c.q. afgespeeld kunnen worden. Op dit moment worden allen afbeeldingen ondersteund. Het is de bedoeling om hier in de toekomst ook ook ander media in op te nemen, zoals video, audio, documenten van diverse types (pdf, html) etc.. Zo lang het uitsluitend om afbeeldingen gaat lijkt een vermelding van de soort overbodig. Als ook andere media worden ondersteund zou aan de relatie een 'soort' veld kunnen worden toegevoegd. Nadeel is dat dit de user interface, waarmee nu met een enkele muisklik relaties worden gelegd, veel minder intuïtief zou maken. Hier moet dan een oplossing voor worden gezocht.

Referenties naar literatuur. Dit zijn alle vormen van documentatie en media die niet naar de server geupload zijn. Meestal betreft het boeken of tijdschriften waarin het voorwerp genoemd wordt of wordt afgebeeld, of waar de categorie van voorwerpen wordt beschreven (i.v.m. determinatie). In de basisversie is dit een tekstveld waarin meerdere regels kunnen worden gebruikt voor meerder verwijzingen. De gebruiker is vrij om hier ook de soort referentie in te vermelden, dus toevoeging van een afzonderlijk 'soort' veld is hier niet direct noodzakelijk.

Heeft men echter ook de bibliotheekmodule dan kan men dit veld laten vervangen door referenties naar in die module vastgelegde gegevens. Het gaat hier uiteraard om een n:m relatie. Het toevoegen van een 'soort' veld aan die relatie zal de user interface wel minder intuïtief kunnen maken, afhankelijk wat voor oplossing hiervoor gekozen wordt.

Verder blijkt uit de beschrijving van de uitgebreide standaard dat men veelal voor specifieke contexten een veld 'opmerkingen' heeft waar de historisch-voorwerpkaart spreekt van 'bijzonderheden'. Semantha museum had hiervoor een meerregelig tekstveld waarin men alle bijzonderheden kwijt kon. Daar beide termen uitwisselbaar blijken, of het onderscheid onduidelijk is, kan men de context-gebonden opmerkingen evengoed toevoegen aan het meerregelige veld 'opmerkingen'. Het veld 'bijzonderheden' kan dan vervallen.

Dublin Core

Dublin Core is eigenlijk een vreemde eend in de bijt: ten eerste is het onderwerp van de standaard publicaties c.q. documentatie. Meer iets voor een bibliotheek dan voor een museum, zou je denken. Toch wordt het ook in relatie tot voorwerpen toegepast. Dit heeft wellicht te maken met het tweede verschil: het is geen standaard voor registratie maar een standaard voor ontsluiting. Bij registratie wil men graag aangeven wat geregistreerd zou moeten worden en hoe. Daarbij moet rekening worden gehouden met meerdere doelen waarvoor de gegevens in de toekomst gebruikt zullen worden. Bij ontsluiting wordt vanuit een specifiek doel gedacht: het zoeken en bladeren in de gegevens. Daarbij kan men omwille van de overzichtelijkheid en om een hele hoop discussie over veldindelingen te voorkomen best wat velden op één hoop gooien. Dit beperkt weliswaar de nauwkeurigheid waarmee men kan zoeken, maar de oorspronkelijke gegevens blijven bestaan, en kunnen voor specifieke doelen altijd weer op een andere manier ontsloten worden. Bij registratie geldt die vrijblijvendheid niet: eenmaal gemaakte keuzes zijn niet meer terug te draaien of slechts tegen hoge kosten.

Door deze doelstelling van ontsluiting kon men met Dublin Core dus met een eenvoudige standaard beginnen, en kan men die later altijd nog uitbreiden. Daardoor is de huidige versie van Dublin Core relatief eenvoudig. Dat is voor ons doel van het bepalen van een basis veldindeling natuurlijk een voordeel. Voor de toepassing in de praktijk is het dat ook: de consensus is veel groter dan ten aanzien van andere standaarden en het animo om iets met deze standaard te doen lijkt dat ook.

Reden genoeg dus om de Dublin Core in de crosswalk tabel op te nemen. Er blijven echter wel een paar eigenaardigheden:

Sommige Dublin Core elementen komen bij een hele reeks velden in de tabel voor. Dat is nu precies eerder genoemde het "op één hoop gooien" en is geen probleem,

Daar Cublin Core in wezen over publicaties gaat is het de vraag wat er bedoeld wordt in relatie tot objecten: wordt de registratiekaart zelf beschreven of het voorwerp waar de registratiekaart betrekking op heeft. De interpretatie van CIMI gaat uit van het laatste.

Het is niet reel om de Dublin Core in zijn geheel te betrekken in de "kleinst gemene veelvoud" bepaling: er zijn allerlei velden die voor fisieke voorwerpen minder belangrijk of niet van toepassing zijn:

Source "A Reference to a resource from which the present resource is derived". Als het om een kopie gaat (bijvoorbeeld van een (ander) schilderij) kan hier het origineel worden vermeld.

Publisher Uitgever. CIMI raadt gebruik van dit veld ook aan voor degene die een voorwerp beschikbaar maakt voor presentatie. Dit is af te leiden uit de velden 'verwering' ('leen') en 'verworven van'

Contributor "An entity responsible for making contributions to the content of the resource. " Dit komt wel voor op de historisch-voorwerpkaart, maar wordt daar niet tot de meest noodzakelijke velden gerekend.

Rights "Information about rights held in and over the resource. Typically a Rights element will contain a rights management statement for the resource, or reference a service providing such information. " Bij fysieke voorwerpen betreft het in de eerste plaats eigendomsrecht

Format The physical or digital manifestation of the resource. Typically, Format may include the media-type or dimensions of the resource.

Audience "A class of entity for whom the resource is intended or useful.". Vermoedelijk betreft het hier de oorspronkelijke doelgroep, niet de doelgroep waarvoor het museum het voorwerp tentoonstelt.

Language De taal waarin de publikatie is gesteld. Voor voorwerpen alleen relevant mbt opschriften.

Provenance "A statement of any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity and interpretation. The statement may include a description of any changes successive custodians made to the resource." Dit is vergelijkbaar met het gebruik van Associatie van de historisch-voorwerpkaart. Zie in dit hoofdstuk onder 'Historisch-Voorwerpkaart', bij 'Pedigree'.

InstructionalMethod "A process, used to engender knowledge, attitudes and skills, that the resource is designed to support. "

AccrualPeriodicity "The frequency with which items are added to a collection."

AccrualPolicy "The policy governing the addition of items to a collection".

Tenslotte hebben we hier en daar hebben we ook gebruik gemaakt van additionele subqalifiers (achter de punt) van DONOR, het project van de koninklijke bibliotheek, om een iets nauwkeuriger match te krijgen. Het donor project lijkt echter inmiddels enigszins achterhaald, daarom is zoveel mogelijk gebruik gemaakt van de officiële Engelstalige handleiding (6), geinterpreteerd volgens de Guide to Best Practice van CIMI (7).

Overige

Er zijn nog meer standaarden, die om verschillende redenen niet in de crosswalk zijn verwerkt:

SPECTRUM

Aan deze standaard van MDA wordt veel gerefereerd. Helaas is SPECTRUM geen open standaard: voordat men informatie van enig detail kan downloaden moet men eerst de voorwaarden accepteren die de uitgever stelt. Deze voorwaarden stellen onder meer dat men de standaard niet mag gebruiken in software. Wil men de standaard in software gebruiken dan moet men lid worden van de uitgevende organisatie. Vervolgens moet de software gekeurd worden door deze organisatie. Een dergelijk traject is bij de huidige prijsstelling van Semantha Museum te kostbaar. De prijzen verhogen zou de software onbereikbaar maken voor kleinere musea. Dat zou het kind met het badwater weggooien zijn. Om een voor niet-juristen onoverzichtelijke situatie te vermijden hebben wij de standaard vooralsnog niet gedownload.

Gelukkig is de rechtsgrond voor de SPECTRUM licentieovereenkomst niet het patentrecht maar het auteursrecht. Voor zover de auteusrechthebbende überhaupt eisen kan stellen ten aanzien van het gebruik vloeit dat altijd voort uit het kopiëren van (delen van) een zelfstandig werk. Zo lang wij dat niet doen mag er dus best overeenstemming zijn tussen de veldindeling van Semantha Museum en de SPECTRUM standaard. Dat kan natuurlijk ook gemakkelijk, want de elementen van de historisch voorwerpkaart ziet men regelmatig terugkomen in andere standaards. Wij zullen dan ook niet aan individuele musea vragen of hun veldspecificaties velden bevatten die ook in SPECTRUM voorkomen en achten ons vrij om hun specificaties te implementeren.

CIMI

De praktische betekenis van de verschillende concept-standaarden die in dit kader tot stand zijn gekomen is niet duidelijk. Duidelijk is wel dat de SPECTRUM XML Schema standaard nu door MDA wordt onderhouden, zie aldaar. Wel is hier wat meer informatie over te vinden, dan over SPECTRUM, bijvoorbeeld door vermelding in crosswalks. (De website www.cimi.org was helaas langdurig uit de lucht, maar veel informatie stond nog wel in de cache van google).

CIDOC Core Data Standard for Archaeological Objects

Met ca. 44 velden en zonder 'minimale' subset is deze standaard ietwat te uitgebreid om mee te nemen in de "kleinst gemene veelvoud" voor de basis veldindeling van Semantha Museum. De beschikbare documentatie is bovendien te beperkt om een verantwoorde mapping te kunnen maken.

CIDOC International Guidelines for Museum Object Information

Met ca 74 velden en zonder (informatie over een) 'minimale' subset is deze standaard veel te uitgebreid om mee te nemen in de "kleinst gemene veelvoud" voor de basis veldindeling van Semantha Museum. De beschikbare documentatie is bovendien te beperkt om een verantwoorde mapping te kunnen maken, tenzij men aanneemt dat de betekenis van de velden vergelijkbaar is met die van de historische voorwerpkaart. Dan is de meerwaarde van zo'n mapping voor het doel van dit document echter weer gering.

UKOLN RSLP Collection Description

Als uitbreiding op Dublin Core is dit wellicht de meest interessante standaard. Het onderwerp is echter collecties, niet individuele voorwerpen. Er zijn twee kerndocumenten: het schema en het analytisch model. Het schema lijkt redelijk eenvoudig. Het analytisch model is bedoeld als een model daarentegen komt verbijsterend complex over. We hebben dit voorlopig maar even laten rusten.

Literatuurverwijzing

1.Hogenboom, Jeanne, "Basisregistratie voor collecies voorwerpen en beeldmateriaal", Stichting IMC, Rotterdam, 1988/1993, ISBN 90-71929-01-9

2.Ezerman, Jolandan (red), "Syllabus bij de basiscursus Registratie en Documentatie", Landelijk Contact Museumconsulenten, Amsterdan, 2002, ISBN 90-805735-3-1

3.Vier, E.A. de, "handleiding registratie van literatuurcollecties in musea, Nederlandse Museumverening (SIMIN-publicatie nr 3), Den Haag, 1990, ISBN 90-70225-03-4.

4."Standaarden voor de registratie van archeologische objecten in een museale context", ARON, 2003, http://www.culturelebiografie.be/culturele_biografie_vlaanderen/index.cfm?id=1445

5.Boot, Caroline e.a., Handleding voor de beschrijving van historische voorwerpen, SIMIN-publicatie 2, Rotterdam, 1982

6.Diane Hillmann, "Using Dublin Core", http://www.dublincore.org/documents/usageguide/

7."Guide to Best Practice: Dublin Core", CIMI (RFC 2413 Version 1.1 ), 21 April 2000, http://www.cimi.org/public_docs/meta_bestprac_v1_1_210400.pdf (niet meer toegankelijk?)

8.Verhoeven, Henk, "Basisregistratiekaart Relationeel 0.1", MetaClass, Groningen, 2006, op verzoek verkrijgbaar via info@metaclass.nl

Publicaties 1 en 2 zijn te bestellen bij de Stichting Gelders Erfgoed via http://www.gelderserfgoed.nl/?item=producten.

Verwijzingen naar informatie over de onder "Overige" genoemde standaards zijn hier doelbewust weggelaten om de lezer niet uit te nodigen om zich in deze informatiejungle te begeven. Via de hyperlinks achter de aandachtspunten onder "overige" kan men dat vanuit de elektronische versie desgewenst toch doen.