#erfgoedcabaret en Was will das Weib?
Ik weet natuurlijk niet wat de overwegingen zijn geweest van Archief 2.0-leden om niet deel te nemen ...
In de erfgoedsector wordt soms gebruik gemaakt van embedded metadata, d.w.z. dat metadata al in het bestand worden opgenomen. Zie http://www.den.nl/blog/bericht/4407.
Dat heeft voor- en nadelen: een digital object kan nooit 'dakloos' raken omdat in het bestand vastluigt wat het is en waar het vandaan komt. Maar het is ook omslachtig: als je metadata wilt wijzigen moet dat zowel in het bestand als in het beheersysteem. Het HCO overweegt om ook embedded metadata toe te passen. ZIjn er er archiefdiensten die van embedded metadata gebruik maken?
Reacties
Met veel belangstelling heb ik het blog van Robert Gillesse gelezen over metadata embedden in een digitale afbeelding. Alweer een tijdje geleden ben ik ook met dit onderwerp bezig geweest maar met een iets andere invalshoek. Het ging namelijk niet om het door ons zelf toevoegen van metadata aan de afbeelding maar de metadata die er al in zit er uit te krijgen om daarmee al een beschrijving te krijgen. Beste voorbeeld bij digitale foto's is dat de datum en tijd er altijd bijstaat en tegenwoordig ook vaak de coördinaten. Sommige professionele fotografen gebruiken het ook om aan te geven dat ze de maker en auteursrechthouder zijn en welke licentie van toepassing is. Het merendeel van die EXIF-data is overigens technisch en niet inhoudelijk. Er zijn wel tools te vinden om die data er uit te halen ( om daarna te importeren in je registratiesysteem) maar dat is wat mij betreft gebleven bij enkele tests. Ik hoor graag over ervaringen van anderen.
Deze embedded metadata bracht ons nog wel op het idee dat het voor fotografen en particuliere archiefvormers (of in ons geval de communicatieafdeling met een fotocollectie) via bijvoorbeeld de windows-verkenner heel makkelijk zou zijn om metadata toe te voegen aan de eigenschappen van een foto. Mogelijk alternatief voor het moeten beschrijven van die foto's in een apart systeem of (word/excel-) bestand, voorafgaand aan de verwerving.
Ik denk dat het 'dakloos' raken van digitale objecten vooral een probleem is van afnemers (de klant). Deze krijgt een contextloos bestand met veelal niets zeggende naam.
Voor archieven is het denk ik afdoende om in het bestand een GUID te plaatsen (of GUID als bestandsnaam) die ook bekend/gekoppeld is in het archiefbeheersysteem. Dit is dus eenmalig bij opname in het beheersysteem.
Wanneer een digitaal object wordt afgeleverd kan er een rijk informatie object van worden gemaakt: relevante metadata wordt in het bestand gezet (on-the-fly en na aflevering verwijderd). Wanneer deze stap eenmaal is gemaakt is het een kleine stap om de metadata ook in andere vormen toe te voegen, zodat er een pakketje ontstaat. Ik kan me goed voorstellen dat dit een externe service is, op basis van de handle of GUID van object haalt deze service via een API de metadata op en het bestand en voegt deze samen en levert het af aan de klant.
De gedachte van een externe service bleef nog wat hangen en heeft geleid tot de volgende proof of concept: Image Metadata Embed API
Wat prachtig Bob! Ik ben onder de indruk. Precies hoe je het zou willen - in de header en ook nog in een tekstfile. Twee vraagjes: waar stop je nu precies de info in de header: in de IPTC of EXIF velden? En kan dit ook op basis van OAI-PMH?
Oeps, dan mag ik natuurlijk eigenlijk niet header zeggen (zie mijn blog en commentaar daarop) maar ingesloten in het bestand. :-) Robert Gillesse zei:
Wat prachtig Bob! Ik ben onder de indruk. Precies hoe je het zou willen - in de header en ook nog in een tekstfile. Twee vraagjes: waar stop je nu precies de info in de header: in de IPTC of EXIF velden? En kan dit ook op basis van OAI-PMH?
Robert,
Ik heb me in deze proof-of-concept eigenlijk alleen gericht op een gebruikersvriendelijk eindproduct voor eindgebruikers, dus de meta-data moest eenvoudigweg via bestandseigenschappen (op Windows) in te zien zijn. Technisch is nu EXIF gebruikt, maar IPTC of XMP is geen probleem. Het issue zal meer zijn, welke standaard biedt de meta-data velden die we willen en zijn deze voor de systemen van de doelgroep (instellingen, professionals, eindgebruikers - wie is de doelgroep?) geschikt.
De proof-of-concept maakt nu gebruik van een OpenSearch API, maar een aanroep van een GetRecord methode van een OAI-PMH data provider is ook goed mogelijk (beide in wezen eenvoudige HTTP GET acties). Eigenlijk geldt, als je systeem een open toegang heeft ....
Misschien ons niet heel druk maken waar die data nu precies terecht komen - het is al heel wat dat we ze mee kunnen leveren met het object zelf. Als gezegd word ik erg enthousiast van wat je hebt gemaakt. Benieuwd hoe de archieven daar over denken. Prachtig toch als bij een download de metadata kunt meeleveren?
Een deel van de oplossing van Bob Coret wordt momenteel gebouwd in Atlantis; Metadata (in collectiebeheersysteem) wordt uitgelezen naar bestand bij downloaden.