Deelbare metadata
In de vorige blog legden we uit hoe je in drie stappen komt tot deelbare metadata. We maken van onze metadata een timeline waardoor metadata gedeeld en bewaard kan worden zonder consistentie problemen.
De vraag dient zich echter aan hoe we nu met updates omgaan.
Even tussendoor: pragmatiek
We hebben het hier (nog steeds) niet over specificaties, vocabulaires, representaties, records of grafen en dergelijke. Het gaat hier om de pragmatiek: wat er moet gebeuren. Semantiek, hoe je het zegt, en syntax, hoe je het opschrijft, komen later. Wat er moet gebeuren is het uitgangspunt. Het lezen van de voorbeelden op https://nl.wikipedia.org/wiki/Pragmatiek_(taalkunde) is zeer de moeite waard.
Updates in primitieve timelines
In bibliotheken komen soms errata (of corrigenda of addenda) binnen. Daarmee kunnen we niet veel meer doen dan ze bij de oorspronkelijke publicatie voegen. Dat kan je zien als een eenvoudige timeline.
Bij e-mail gaat het eigenlijk net zo. Reacties (replies) worden simpelweg achter de oorspronkelijke e-mail geplaatst. Twitter idem, Facebook idem. Allemaal nogal primitieve timelines.
Veel e-mailsoftware probeert reacties (replies, ook een timeline) integraal te tonen met de oorspronkelijke e-mail. Dat lukt matig omdat het e-mail dataformaat dit niet ondersteunt. Een e-mail thread (conversatie) is ook een timeline.
Zouden we reacties of updates op metadata timeline niet beter kunnen verwerken?
Integratie van updates
Willen we bijvoorbeeld feedback op een stuk tekst dan is iets als Google Docs handiger dan email. Iedereen kent wel het drama van het integreren verschillende reacties; bij meer dan een handvol houdt het echt op.
Google Docs integreert alle edits (reacties) automatisch in een eindtekst. Maar alle updates blijven opvraagbaar. Je kunt ze negeren of expliciet of stilzwijgend accepteren. En je kunt er op reageren.
Zou zoiets ook niet met metadata kunnen? Maar dan decentraal?
Voorwaarden
Wat willen we dan precies met updates op metadata? In elke geval deze twee punten:
- De integratie van updates is uitvoerbaar door een machine. De update beschrijft precies waarop het van toepassing is en hoe die toegepast moet worden, zonder tussenkomst van mensen.
- De integratie is stuurbaar. Je moet kunnen aangeven welke update wel en niet worden meegenomen. Per update, of op basis van regels.
Als dit lukt, dan kunnen we metadata publiceren mét de mogelijkheid om verbeteringen te publiceren met aan het einde van de keten altijd een integraal beeld.
Consistent, geïntegreerd eindresultaat
Het gaat erom dat we uiteindelijk een gewoon metadata record hebben met hierin alle updates verwerkt. 100% automatisch. De achterliggende publicaties (updates) zouden opgevraagd kunnen worden, maar we zien het eindresultaat. Net als in Google Docs: we zien een document. Dat is opgebouwd uit allerlei updates die eventueel op te vragen zijn als ‘history’. Dus geen primitieve timeline van opeenvolgende reactie op reactie, maar een slimme timeline die leidt tot een eenduidig eindresultaat. (Maar dan decentraal uiteraard)
Ingewikkeld?
Het kan misschien erg ingewikkeld lijken om dit te doen, maar gelukkig kan je er heel erg eenvoudig mee beginnen. In Google Docs (overigens bieden Microsoft en Apple inmiddels ook dit soort functionaliteit) kan je tot op de letter updates verwerken. Dat is niet makkelijk om te maken. Maar je kunt eenvoudig beginnen en het dan langzamerhand steeds mooier maken.
Belangrijk is om te beseffen dat ook als je eenvoudig begint, en het primitief lijkt, je toch al de stap hebt gezet naar consistent publiceren en integreren.
Van eenvoudig tot geavanceerd
Er zijn drie niveaus waarop je met een update om kunt gaan. Elk niveau brengt nieuwe mogelijkheden met zich mee, maar ook de uitdaging om dit goed te doen. Dit zijn de niveau’s. Bij een update, vervang
- een geheel record. Dit is in de huidige praktijk ook altijd al zo, alleen is het impliciet en is onduidelijk wat nu de laatste versie is en waarop de update gebaseerd is. Als je begint met verwijzen naar de voorganger zou het al veel problemen voorkomen. Het is eenvoudig om te doen. Dit is echter alleen geschikt om je eigen updates te publiceren (eenrichtingsverkeer).
- enkele eigenschappen. Hiermee publiceer je in feite alleen de wijzigingen, op vrij grofmazig niveau, maar het is daardoor geschikt voor verrijkingen, meerdere partijen en meerrichtingenverkeer. Deze vorm hebben we ook uitgewerkt om te laten zien hoe het werkt. Je kunt hierin ook zo ver gaan dat je meer complexe eigenschappen (sub-objecten, graphs) gedeeltelijk update, zoals steeds meer voorkomt. Dit is minder eenvoudig dan 1, maar goed te doen.
- delen van (teksten) in een property. Tekst-eigenschappen zoals titels en beschrijvingen kunnen, net als in Google Docs ook letter voor letter worden gewijzigd. Dit gaat heel ver, maar is voor wederzijds uitwisselen (delen en verrijken) van metadata niet direct nodig. Het is lastig te implementeren.
En conflicterende updates?
Het mooie is dat we in de timeline af zijn van technische conflicten. Dus dit soort ellende bestaat niet meer:
Dit probleem bestaat niet meer omdat elke versie altijd expliciet gebaseerd is op een vorige en omdat wijzigen expliciet zijn beschreven. Elke versie is read-only en je publiceert veranderingen waarin je precies zegt wat er veranderd is. Zelfs al publiceer je een grofmazige update die alles uit de voorganger vervangt door iets nieuws (punt 1 hierboven), dan heb je toch deze bron van conflicten verholpen.
Conflicten in de echte wereld.
Als de een vindt dat het het publicatiejaar 1780 is en de ander vind dat het 1781 is, en beiden maken ze een update waarin dit staat, dan zijn deze twee updates nog steeds gegarandeerd correct te integreren. Beide editors kunnen echter tot in het eindeloze doorgaan om elkaars update te overschrijven. Tot technische conflicten zal dit echter nooit leiden.
Maar zelfs bij ‘conflicten in de echte wereld’ hebben we met de timeline veel gewonnen. Het wordt nu namelijk transparant en we kunnen kiezen. Wie wat heeft ge-update is precies zichtbaar in de timeline en als curator kunnen we kiezen welke updates we wel of niet willen.
Logica in de client
We hebben dit uitgewerkt in een werkend prototype wat werkt op basis van een werkelijk doodeenvoudige data-opslag en waarbij alle logica in de client zit. Het werkt dus echt decentraal.
Feedback gevraagd
We hebben de afgelopen jaren in een soort achtbaan van ideeen, papers, prototypes en nog meer ideeën gezeten. We vinden het erg lastig om deze ingewikkelde materie goed te beschrijven.
Met jouw feedback zouden we het beter kunnen doen. We hopen dat je ons wilt helpen om de dingen die niet duidelijk zijn te verduidelijken en om het verhaal beter te laten aansluiten bij de leef- en denkwereld van metadataspeclisten.
Wil je ons helpen? Of vind je het gewoon interessant? Laat het ons dan weten.