Mooie metadata?

“De laatste dagen wat aan het experimenteren geweest in de Surfnet Video Portal. Films geupload, uiteraard netjes voorzien van metadata. Wat me daarbij opvalt (en ook bij het lezen van de beschrijving van andere video’s) dat er werkelijk geen enkele vorm van opmaak geaccepteerd wordt, nog geen nieuwe regel. Het resultaat is grijze blokken tekst die bepaald niet uitnodigen tot lezen (en ook niet uitnodigen tot het zelf genereren van metadata).”

(bron)

Een heel terechte klacht van Michel. Ter illustratie, zo ziet dat er uit:
SURF videoportal - Klik voor grotere versie De discussie er omheen is er eentje die al lang gaande is. Je hebt mensen die van mening zijn dat metadata niet voor eingebruikers bedoeld is, dat het informatie is die in het systeem zit en nooit getoond moet worden. Klinkt logisch, maar is het zeker niet als je het hebt over zaken als een omschrijving.

Dan zijn er mensen die heel puur zijn in het scheiden van inhoud en opmaak. Ik heb dat gemerkt toen we bij het opstellen van de nieuwe IMS QTI specificatie ook XHTML “opmaak”-mogelijkheden in het informatiemodel introduceerden. (oei, wat kun je daar stevige discussies over voeren!)
Witregels zijn wel toegestaan, maar een <br/> of lijst (waar Michel het over had), zijn dan uit den boze. Maar het niet bieden van een alternatief is dat dan ook!
Want dan zul je in ieder geval mogelijheden moeten bieden om aan te geven hoe e.e.a. bij elkaar hoort of wat de “structurele samenhang” is. Dus dat iets een opsomming is (waarvan het wellicht handig is om die in een lijst te tonen).

De verschillende uitwisselingsafspraken rond (onderwijskundige-)metadata gaan niet uit van opmaak in de metadata. Terwijl RSS laat zien hoe het eenvoudig geregeld kan worden. Maak het mogelijk om aan te geven of er opmaak in voor komt of niet, biedt de beschrijving in de metadata eventueel in niet-opgemaakte vorm aan als alternatief naast de opgemaakte vorm etc.

En daar komt bij dat het op dit moment nog niet eens om het uitwisselen van metadata gaat/ging. Het was het tonen van een beschrijving in het eigen systeem. Dus dan heb je meteen al veel minder met afspraken met anderen te maken.
Natuurlijk, het kan verstandig zijn een filter te bouwen voor de export, zodat metadata die aan anderen aangeleverd wordt geen opmaak bevat, en je kunt streng zijn bij de invoer zodat de opmaakcodes die gebruikt mogen worden beperkt blijven etc.
Maar het is relatief eenvoudig te regelen. Dus waarom doen we dat dan niet?

0 0 stemmen
Bericht waardering
3 Reacties
Inline Feedback
Bekijk alle reacties
Michel
19 jaren geleden

Mis ik wat? in de tweede alinea bij "witregels zijn wel toegestaan maar een .?. of lijst…".
Ik ben trouwens benieuwd wat er dan wel is toegestaan.

PS: voordat ik deze reactie ging schrijven eerst maar even in FF gekeken of ik daar hetzelfde zag ;-))

Michel
19 jaren geleden

Nog even inhoudelijk: belangrijk punt vind ik dat je opmaak- en structuurinformatie die in metadata aanwezig is wèl betrekkelijk eenvoudig kunt verwijderen, maar niet-aanwezige informatie nooit kunt plaatsen!

Pierre
19 jaren geleden

Oeps, daar stond <br/> en dat is bij mij een toegestane HTML-code (in berichten, niet in reacties, maar daar kun je uiteraard wél gewoon witregels invoeren!), dus die zorgde gewoon voor een nieuwe regel.

Ik denk dat het geheel ook samenhangt met de soort gebruikers van dit soort systemen tot nu toe. Dat waren toch altijd al redelijk ervaren gebruikers, maar waarschijnlijk ook gebruikers die eigenlijk al heel goed wisten wat ze moesten hebben (en dus niet aan het zoeken waren). Als je zo’n databank ook voor een grote groep "andere" gebruikers (dus mensen die het oorspronkelijk materiaal niet gemaakt hebben, of die veel vagere zoekopdrachten hebben) toegankelijk gaat maken, zoals nu ook met de videoportal, heb je simpelweg te maken met andere eisen.
Net zoals dat met de metadataset die gebruikt wordt het geval is. Waar Dublin Core in eerste instantie voldeed, zal dat bij gebruik van de video in het onderwijs, vaak niet meer het geval zijn.