In dit vervolg op de vorige blog over (de-) centrale aggregatie van metadata leggen we uit wat het probleem precies is. Of liever gezegd: de oorzaak. Want de problemen kennen we wel. Inconsistente data die het moeilijk maakt om een metadatanetwerk in stand te houden.
Schijnoplossingen
Voordat we naar de oorzaak kijken is het goed om eerst eens te kijken naar de schijnoplossingen. Het risico van schijnoplossingen is dat ze de problematiek kunnen verergeren: veel energie (moeten) steken in iets wat niet helpt kan het aggregeren zo beladen maken dat men het niet leuk meer vindt en het niet meer ziet zitten.
Dit zijn die schijnoplossingen:
- Een centrale database voor iedereen maken, dan is verzamelen niet nodig.
- Kopiëren van data uitsluiten en elke keer opnieuw ophalen (zie vorige blog)
- Voortdurend alle data hersynchroniseren (zie vorige blog).
- Data publiceren als LOD (Linked Open Data)
- Alle bronnen een centraal data model laten te gebruiken
- ZIP-files uploaden vervangen door online OAI, door ResourceSync, door Sparql, …
- CSV vervangen door XML, door Triples, door …
Punt 4 is op zich niet verkeerd is, en punt 5 tot op zekere hoogte ook niet maar ze nemen niet de oorzaak weg van het probleem met aggregeren. Het zijn tactische overwegingen: een slimme of handige oplossing gegeven de omstandigheden. Er moet echter iets strategisch veranderen.
Oorsprong van data
Om goed beeld te krijgen van wat nu de kern van het probleem, de oorzaak, echt is moeten we kijken naar waar de data vandaan komt. Dan kunnen we begrijpen waarom die data niet zomaar te publiceren is op de manier waarop we dat nu doen.
De (meta-) data die we aggregeren zijn vrijwel allemaal afkomstig uit processen die plaatsvinden in bijvoorbeeld erfgoedinstellingen. Zo’n instelling heeft een
bepaalde taak en die is meestal gericht op zorgvuldig bewaren. Wat dat ook precies is, er zijn allerlei processen ingericht die het mogelijk maken om de hele levensloop van object te beschrijven; van het ontstaan tot, in sommige gevallen, de teloorgang.
Die processen worden uitgevoerd door mensen en gespecialiseerde systemen. Gezamenlijk zorgen deze mensen en die systemen er voor dat de gegevens steeds de werkelijkheid volgen. Zo getrouw en stipt mogelijk.
Zo’n systeem bevat een database die
- toegang van bepaalde mensen toestaat en die
- data consistent houdt gedurende de gehele levenscyclus.
Stel nu dat we uit die database een record afleiden en die publiceren. De vraag die zich opdringt is dan: wat gebeurt er dan met de toegangscontrole en de procedures rondom de levenscyclus?
We zien hier dat een systeem twee belangrijke zaken toevoegt aan de data, en dat die beide zaken verloren gaan als we de data uit het systeem halen.
De data is buiten het systeem niet volledig!
Zodra je data exporteert, uit een systeem haalt en ‘op straat gooit’, gaat er essentiële informatie verloren: we weten niets meer over de life cycle van de data, en erger: we kunnen daardoor (!) de data ook niet wijzigen.
Het publiceren van data uit een beheerproces van een instelling is dus vooral problematisch omdat een belangrijke aspecten van de informatie niet meekomen. Dit toch publiceren kan wel, maar met een dikke vette disclaimer:
kan zonder opgave van reden en zonder notificatie vooraf door de uitgever gewijzigd worden.
En dat is nu precies de oorzaak van de complexiteit en fragiliteit van metadataaggregatienetwerken.
Of het ook anders kan? Jazeker!
In een volgende blog ga ik daar verder op in. Heb je hier ook ideeën over, of heb je vragen? Neem dan contact op, want we gaan er graag over in gesprek.
Lees het vervolg in: Op naar de Metadata Timeline
Mooi Erik, ik ben benieuwd naar het vervolg!
Idem.