Nooit meer metadata invoeren – deel 6

Vijf posts met als onderwerp “Nooit meer metadata invoeren” kwamen afgelopen week voorbij:
* deel 1 ging over foto’s;
* deel 2 over video en audio;
* deel 3 ging over Word, Excel, Powerpoint en PDF-documenten;
* deel 4 bekeek een tweetal applicaties voor metadatabeheer in PDF-bestanden;
* deel 5 toonde een PHP-script waarmee metadata uit Office-documenten en PDF-documenten gehaald kon worden.
Vijf dagen is te kort voor een definitieve conclusie, maar in dit deel 6 toch al een voorzichtige blik naar wat dit betekent (of zou moeten betekenen) voor Leertechnologie-afspraaken als LOM en Dublin Core.
Metadata en metadata
Normale mensen vinden discussies over metadata doodsaai, andere mensen vinden het vreselijk interessante discussies. Één ding is zeker: discussies over metadata zijn bijna altijd lang.
Ik vind discussies interessant zolang ze praktisch blijven, dus voor mij geen principevragen als “zijn tags wel metadata?” (zie ook: Folksonomy) of “moet metadata door mensen ingevoerd worden?”.
Het gaat mij hier om: Wat wil ik weten van een object (een bestand/document/filmfragment) om dit object te kunnen vinden en is deze informatie met zo weinig mogelijk inspanning beschikbaar te krijgen?.

Wat wil ik weten?
Hoewel het niet als een expliciete vraag geformuleerd is toen ik deel 1 schreef, werd de vraag wat wil ik eigenlijk weten? steeds relevanter. Immers, de hoeveelheid beschikbare informatie bleek best groot te zijn en zeker niet alle informatie was altijd even relevant (voor mij). Zo is het weten met welk toestel een foto gemaakt is handig als ik een test van digitale camera’s lees, maar niet relevant als ik toevallig op zoek ben naar een afbeelding gemaakt tijdens een CETIS Codebash.
Het beantwoorden van die vraag maakt het daarna ook mogelijk om te kijken of Leertechnologie-afspraaken als LOM en Dublin Core die informatie kunnen vastleggen/beschrijven.

Gemeenschappelijke eigenschappen
Er zijn een aantal dingen die ik eigenlijk altijd wel van een object wil weten. Het lijstje dat ik tot nu toe heb is:
* Titel/naam van het object
* Maker/auteur
* Omschrijving
* Trefwoorden/Keywords/Tags
* Copyright
* Omvang in kB/MB
* Datum
* Aanbevolen player

De eerste drie spreken waarschijnlijk voor zich. Afgelopen week heeft duidelijk gemaakt dat het vastleggen van die informatie vaak in het bestand zelf kan gebeuren (bij Office-documenten, PDF’s, Audiobestanden en Videobestanden bijvoorbeeld). Vaak kan dat overigens ook niet (bij tekstbestanden bijvoorbeeld niet, maar er zijn voldoende bestandsformaten die dat niet ondersteunen).
Trefwoorden (tags) vind ik zelf heel handig omdat het, zelfs als het geen hyperlinks zijn, voor mij vaak de woorden zijn waar ik verder op zoek of die ik juist uitsluit bij het verder zoeken afhankelijk of een gevonden object goed aansluit bij wat ik zoek of juist helemaal niet.
Bij Copyright heb ik het bij voorkeur niet over een nietszeggend stukje tekst als “alle rechten voorbehouden”, maar liever een link naar een pagina die duidelijk beschrijft wat ik er mee mag zoals bij de Creative Commons gebruikelijk is.
En hoewel de omvang van een object veel minder van belang is geworden met de rappe stijging van de beschikbare bandbreedte is het sowieso een eerste indicatie van de omvang van de inhoud. Een foto van 10kB zal niet geschikt zijn om op A4 formaat te printen zonder dat ik daar meer informatie als resolutie etc. over heb. Een MP3-bestand met een track van een CD met een omvang van ongeveer 4MB is waarschijnlijk encoded op 128kps/44kHz en dus techisch de moeite waard om te beluisteren.

De eigenschap Datum had ik hier eerst niet staan, maar heb ik na een opmerking van Michel alsnog toegevoegd. Hij is belangrijk, maar de discussie over ‘welke datum/data leg je vast’, maar het invullen ervan niet geheel eenduidig. In Windows XP zelf wordt hier zowel de datum van aanmaken als de laatste wijzigingsdatum bewaard en niet alle tussenliggende data van wijzigingen.

De laatste eigenschap in het rijtje is waarschijnlijk het meest omstreden. Hij wordt namelijk meestal gegeven vanuit het standpunt van de maker van de content. En natuurlijk als iets een MP3-bestand is, dan weet ik wel waarmee ik het moet afspelen, maar van een Ogg-bestand weet ik dat bijvoorbeeld niet en van MPEG4 heb ik dat ook moeten opzoeken. Een URL naar een Wikipagina met spelers voor de verschillende besturingssystemen is hier waarschijnlijk het verstandigste.

Eigenschappen per objecttype
Toen ik het lijstje van aanvullende einschappen per objecttype maakte viel me op dat dat lijstje eigenlijk best kort is. Wellicht kom ik hier dus nog gigantisch op terug, zoals ik al zei, het is een voorzichtige eerste lijst.

Afbeeldingen
* Afmetingen (hoogte x breedte)
* Resolutie (dpi)
* Aantal kleuren
* Bestandsformaat (gif/jpg/png/…)

Audio
* Duur (in seconden of minuten)
* Audioformaat (WAV/MP3/Ogg/…)
* Aantal kbps (als het een streaming formaat is)

Video
* Alle eigenschappen die bij Audio genoemd worden voor de audio van de video
* Videoformaat (AVI/MPEG1/MPEG2/MPEG4/…)
* Aantal kbps (kunnen ook meerdere formaten in één bestand zijn!)

PDF / Word
* Aantal pagina’s

Powerpoint
* Aantal dia’s

Excel
* Aantal werkbladen

Vastleggen van deze eigenschappen
Ik kan natuurlijk niet voorbij aan het feit dat er afspraken zijn over de soort informatie die je zou willen kunnen vastleggen over (leer-)objecten. Sommige van die sets afspraken zijn specifiek voor/door bibliotheken ontwikkeld, andere sets weer specifiek voor multimedia/video. Ik beperk me even tot een tweetal sets afspraken, voornamelijk omdat ik die andere (METS, MARC, MPEG-21 Part 2) onvoldoende ken om snel een vergelijking te maken. De specifiek voor het onderwijs ontwikkelde IEEE LOM-standaard en de generieke Dublin Core-standaard zijn voor mij wat bekender.

De IEEE Learning Object Metadata (LOM) standaard
De IMS-website heeft een mooi schema van de LOM. Daarin kun je alle elementen zien die onderdeel uitmaken van de LOM.
De gemeenschappelijke eigenschappen zie je hier allemaal in terug: Titel/naam van het object; Maker/auteur; Omschrijving; Trefwoorden/Keywords/Tags; Copyright; Omvang; Aanbevolen player komen allemaal voor in de elementenset. Niet helemaal met de invulling die ik er hierboven aan gaf echter. Met name het opnemen van een URL in plaats van gewoon tekst wijkt af.

Het vastleggen van de overige eigenschappen wordt moeilijker. Size staat uitsluitend voor de omvang in kB, niet voor de afmetingen van een afbeelding.
Afmetingen (hoogte x breedte); Resolutie (dpi); Aantal kleuren; Aantal kbps; Aantal pagina’s; Aantal dia’s; Aantal werkbladen kun je niet kwijt. Bestandsformaat; Audioformaat; Videoformaat ook niet, al kun je het mime-type vastleggen.

Dublin Core metadata-standaard
De situatie voor Dublin Core is niet echt anders. De gemeenschappelijke eigenschappen zie je ook hier allemaal in terug: Titel/naam van het object; Maker/auteur; Omschrijving; Trefwoorden/Keywords/Tags; Copyright; Omvang; Aanbevolen player komen allemaal voor in de elementenset zij het in elementen met andere namen dan bij de LOM.

Het vastleggen van de overige eigenschappen wordt ook hier net als bij de LOM moeilijker.

En nu?
Eigenlijk weet ik nog niet helemaal wat nu de beste oplossing is. De objecttypen die ik hierboven genoemd heb zijn allemaal in staat de gewenste informatie ‘in zichzelf’ op te slaan. Daar is het ontbreken van een match met de bestaande afspraken voor metadata-uitwisseling geen echt probleem voor. Maar voor die andere objecttypen hebben we die elementen wel degelijk nodig. Uitbreiden van een bestaande standaard is echter niet iets wat je ‘zomaar’ even doet. Als gebruiker heb ik er echter wél behoefte aan.
Daar moet ik nog wat langer over nadenk
en. Eerst over vijf minuten maar inbellen voor weer een late telefonische vergadering van een specificatie-ontwikkelprojectteam.