BREED - over de grenzen van informatie

NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER

There is no such thing as metadata.

De stelling

De term "metadata" en het concept hiervan is ouderwets.

De onderbouwing

Onze organisaties digitaliseren. Dat betekent dat informatie zich steeds meer van het hoofd en het document verplaatst naar databases. In tabellen beschrijven wij hoe de wereld om ons heen eruit ziet. Wij beschrijven daar bijvoorbeeld welke gebouwen er om ons heen staan (BAG)of welke mensen er leven (GBA). Zo hebben wij (vaak) ook het volgende in tabellen beschreven: personeel, financiën, bedrijven, scholen, kunstwerken, etc. Daarnaast hebben wij ook een database met een beschrijving van onze dossiers en documenten.

De term "metadata" betekent letterlijk zo veel als "informatie over informatie". De idee erachter is dat documenten informatie zijn en dat dus de beschrijvingen van documenten informatie over informatie zijn.

Maar wat is het verschil tussen de beschrijving van bijvoorbeeld een gebouw en de beschrijving van een document? In beide gevallen gaat het om een verzameling kenmerk-waarde-paren. Bijvoorbeeld "Datum bouw = 23-07-1999" en "Datum ontvangst = 23-07-1999". Bij beide beschrijvingen geven we aan waar het beschreven object zich bevindt; hetzij met XY-coördinaten, hetzij met een URL o.i.d. In beide gevallen streven we naar betrouwbare gegevens en in beide gevallen voorzien ze in een informatie-behoefte die de organisatie kent n.a.v. haar taken en verplichtingen m.b.t. de beschreven objecten.

Een gebouw (of persoon, of kunstwerk, of...) is geen informatie. Bij de beschrijving ervan in tabellen kunnen we dus ook niet spreken over "metadata". Eigenlijk zouden we daarom bij de beschrijving van documenten ook niet meer moeten spreken over "metadata". Want waarom zouden we een andere naam gebruiken voor iets dat in principe hetzelfde is? Ik stel daarom voor dat wij spreken over "kenmerken" i.p.v. "metadata".

Bovendien, documenten zijn geen informatie. Documenten zijn dragers van informatie. De meeste kenmerken gaan over de drager/vorm en niet over de inhoud.

De gevolgen

Nu gaat het mij niet om de discussie over de naam van het beestje. Het gaat mij erom dat registraties uit de BAG, GBA, personeelsadministratie, Zakenmagazijn, DMS/RMA, etc. allemaal gelijk zijn. Gelijk in vorm en uiterlijk om precies te zijn, maar verschillend in objecttype (= welk soort object wordt er beschreven?). Deze visie heeft een aantal consequenties. Ik noem er twee.

- Consequentie 1: Documenten en "metadata" moet je gescheiden houden.

Onder het mom van digitale duurzaamheid wordt er regelmatig voorgesteld om metadata onlosmakelijk te verbinden aan het document, bijvoorbeeld door deze als XML in het document te plaatsen. Dat lijkt mij het equivalent van een BAG-beheerder die gegevens over gebouwen in de gevels gaat kerven. Ben je op zoek naar bijvoorbeeld alle gebouwen uit 1986? Dan zul je langs ieder gebouw moeten lopen om de gevel te lezen. Ben je op zoek naar alle documenten uit 1986? Dan zul je ieder document moeten inzien om de XML te lezen. In beide gevallen, zeker de laatste, kun je een robot het werk laten doen, maar erg efficiënt is het niet. Mijn mening is dat je de beschrijvingen in de databases moet houden en er in je beheersprocessen voor moet zorgen dat de verwijzing naar het object altijd klopt.

Bovendien bestaat de wereld om ons heen - schrik niet - niet alleen maar uit documenten. De inkapseling van kenmerken in het document is lastig als er geen document is. De inkapsel-methode kan slechts bij één objecttype: het document.

Je zou eventueel ook nog kunnen overwegen om kenmerken van personen, gebouwen, zaken, etc. ook bij het document in te kapselen, voor zover die objecten een relatie hebben met het document. Een object kan echter relaties hebben met meerdere documenten. Dat betekent dus dat je keer op keer dezelfde gegevens opslaat. Dat is hoogst inefficiënt.

- Consequentie 2: Het DSP is niet de ordeningsstructuur.

Een andere consequentie is dat het DSP niet de ordeningsstructuur is. Het DSP omvat de beschrijvingen van een aantal niet-stoffelijke objecttypen die in onze omgeving voorkomen: processen, documentsoorten, etc. De ordening van onze informatie is het informatie-model, waarin ook de objecttypen van het DSP zijn opgenomen. In het informatie-model staat van welke informatie de organisatie beheert en hoe deze informatie samenhangt. De organisatie beheert bijvoorbeeld informatie over gebouwen, personen, processen, zaken, documenten, etc. En al die informatie is aan elkaar gelinkt. Zo'n informatie-model kun je bijvoorbeeld vast leggen in de beeldtaal die ook in het RSGB en de RGBZ zijn gebruikt. Ik ken overigens niet één organisatie die een dergelijk informatie-model heeft.

Wij richten onze informatie-huishouding dus niet zaak- of procesgericht in, maar object-gericht. Onze ordening krijgt daardoor niet langer een hiërarchische mappen-structuur zoals we die kennen van de BAC (steeds specifiekere codes) of de zaakgerichte benadering (zaaktype -> zaken -> documenten), maar een netwerk-structuur à la RGBZ en RSGB. Overigens zijn de (meeste) DMS'en, Zaaksystemen en dergelijke al zo ingericht. Een organisatie-breed overzicht van álle objecttypen ontbreekt echter meestal.

Vind ik leuk

0 leden vinden dit leuk

▶ Hierop reageren

Berichten in deze discussie

Permalink Antwoord van Ingmar Koch op 25 Maart 2011 op 9.20

Interessant Marco, maar je ziet volgens mij een paar dingen over het hoofd...

1.Metadata zijn Data over Data
Je schrijft dat de wereld om ons heen niet alleen uit documenten bestaat. Ik weet even niet of je hierbij doelt op het feit dat er ook archiefstukken zijn die 'anders' zijn dan een traditioneel 'document' (bijvoorbeeld een webpagina) of dat je er op doelt dat de wereld om ons heen uit echte, wezenlijke, concrete dingen bestaat. Voor het gemak ga ik nu even uit van het laatste.
Documenten zijn niet 'het echte' leven, documenten / archiefstukken 'documenteren' het echte leven. Zelfs de akten van de burgerlijke stand, die altijd 'waar' zijn (als er staat dat je getrouwd bent, ben je getrouwd), zijn een schriftelijke neerslag van een actie in het echte leven: het uitspreken van het Ja-woord. Dus, documenten zijn niet 'de echte wereld' maar gaan over de echte wereld, net zoals een personeelsadministratie gaat over personeel en niet het personeel is.
En daarom zijn de kenmerken van een document metadata, maar zijn de kenmerken van een gebouw of personeelslid data. Kenmerken van de kenmerken van een gebouw of personeelslid, zijn dan weer metadata. Het probleem dat dan wel ontstaat is dat dit een oneindig proces is, want ik moet / kan natuurlijk ook weer metametadata vastleggen en metametametadata en ...

2. Scheiding van documenten en metadata of niet?
In jouw analogie met het gebouw ga je er van uit dat de metadata enkel in de muur van het gebouw gekerfd zijn en niet ook nog in een aparte database, die het zoeken en vinden van de informatie vergemakkelijkt. Het idee van het opnemen van de metadata in de gebouwen is bedoeld als een extra verzekering voor het geval die database/toegang het begeeft. Je kunt in zo'n geval 'gewoon' door de stad lopen en de database opnieuw opbouwen, zonder dat je al het uitzoekwerk opnieuw moet doen.

(Dat is precies hoe het e-depot van Antwerpen werkt. Alle metadata zijn bij de archiefstukken opgenomen, maar ook in een 'archiefapplicatie'. Als die applicatie niet meer werkt, bijvoorbeeld omdat de database corrupt is, dan kan deze redelijk eenvoudig weer hersteld worden, door alle metadata weer uit de archiefstukken te extraheren.)

Een ander argument om de metadata bij het 'document' op te nemen is dat 'documenten' ook 'in het wild' voorkomen. Ze zijn ook (wel eens) te benaderen zonder toegang tot de database waarin de metadata zijn opgenomen. Als je zo'n document wil openen, lezen en correct interpreteren kun je niet zonder metadata en dan is het handig als ze er gewoon in zijn opgenomen.

3. DSP, ordening en objecttypen

Het DSP is nooit de ordeningsstructuur, in het DSP wordt de gehanteerde ordening beschreven:

Een plan waarin is vastgelegd de wijze waarop de toegankelijkheid van archiefbescheiden is georganiseerd en de wijze waarop archiefbescheiden zijn ingedeeld en gerangschikt (Archiefwiki).

Verder lijkt het er op dat jij ordening vooral van belang vindt voor de terugvindbaarheid van objecten. Dat lijkt me echter eerder een zaak van beschrijving en ontsluiting. Weer uit de Archiefwiki:

Het vervaardigen van toegangen wordt niet als ordening beschouwd: ordening, beschrijving en ontsluiting zijn verschillende begrippen.

Verder moet toegeven dat ik niet precies snap wat je bedoelt met een informatie-huishouding die object-gericht is en wat een "informatie-model" is... Dus of je dat nog wat verder kunt toelichten?

▶ Beantwoorden

Permalink Antwoord van Marco Klerks op 28 Maart 2011 op 0.46

Deels in reactie op Ingmar, maar ook aanvullend:

1. De wereld om ons heen
Ik bedoel inderdaad dat de wereld om ons heen bestaat uit concrete dingen. Daarmee bedoel ik overigens niet alleen de tastbare dingen zoals gebouwen en personen, maar ook concepten als zaken, processen, rollen etc. (kun je niet aanraken, maar bestaan wel).

2. Documenten zijn geen data; het zijn dragers
Documenten zijn niet de schriftelijke neerslag van activiteiten. Zij bevatten de schriftelijke neerslag van activiteiten. Het zijn dragers. Het document zelf (papieren vellen, digitaal bestand, etc.) is geen informatie, maar bevat informatie. In het DMS beschrijven wij niet alleen de inhoud van het document, maar het geheel van het document: inhoud én vorm. Zo leggen wij onder meer ook vast wat bijvoorbeeld het bestandsformaat is en welke beheershandelingen er zijn uitgevoerd. Als de vorm an sich geen data is, dan zijn de kenmerken in het DMS ook niet (allemaal) metadata.

Goed, ik realiseer mij dat mijn titel wat misleidend is; er zijn wel degelijk data over data, dus metadata. Waar het mij om gaat is dat documenten net zo echt zijn als gebouwen, personen, zaken, processen, etc. In wezen is data data, ongeacht waar het over gaat. Het wekt dan verwarring om in het ene geval van metadata te spreken en in het andere geval niet.

3. DIV heeft niet het monopolie over data-beheer.
Wij DIV'ers denken vaak in metadata. Bij een document leggen wij bijvoorbeeld auteursgegevens vast. We hebben dan metadata-velden als “naam” en “postcode”. Maar eigenlijk zegt “naam” niks over het document. Het zegt iets over de persoon. En “postcode” zegt iets over het adres (BAG). Eigenlijk is het best kortzichtig van ons DIV'ers, om “naam” en “postcode” metadata te noemen.

Als wij erkennen dat wij kenmerken vastleggen over objecten, te weten documenten, wat zegt dat dan over onze verhouding met vastleggers van kenmerken over andere objecten zoals gebouwen, personen, medewerkers, financiën, etc.? Wij proberen de (nieuwe) DIV te positioneren als dé experts, dé adviseurs, soms zelfs dé controleurs in de organisatie op het vlak van informatiebeheer. Wij zien onszelf vaak als de middelste kolom van het 9-vlaksmodel. Is dat eigenlijk niet arrogant tegenover die collega's die ook al jarenlang (niet-documentaire) informatie beheren? Wij doen eigenlijk allemaal hetzelfde: data vastleggen over objecten. Is DIV daar beter in dan de rest?

DIV, met die "D" prominent aanwezig, haalt haar bestaansrecht niet uit het bestaan van (alle) informatie. Zij haalt haar bestaansrecht uit het bestaan van documenten. Die objecten heeft de overheid en daar wilt zij data over vastleggen. De overheid kent echter ook andere objecten, waar zij data over wilt vastleggen. Wil DIV zich daarmee bemoeien? Ik vind het best, maar dan moet zij zich wel beseffen dat zij niet meer bezig is met documenten en data over documenten. Zij kent dan ook andere objecten en data over die objecten. Dat is zeker geen metadata. Ow, en zet dan gelijk een streep door die "D", want die dekt de lading niet meer.

4. Inkapselen van metadata
Nog even over de Antwerpse aanpak. Als de database herbouwd moet worden uit de (meta-)data die opgenomen is in de documenten, dan wordt dat een nachtmerrie. Bij data die over het document gaan en echt alleen over het document, kan het nog goed gaan. Data over zaken, personen, ruimtelijke objecten komen echter in 10-, 1.000- of zelfs 1.000.000-voud voor. Je zult zien dat er verschillen in de data zitten. Succes.

Bovendien, als je database onherstelbaar beschadigd is, dan heb je behoorlijk lopen prutsen.

Ik kan mij enigszins vinden in het verhaal rondom het document dat voorkomt “in het wild”.

5. DSP, ordening en objecttypen
Op dit punt kom ik een andere keer terug. Het is al laat terwijl ik dit schrijf. ;-)