De aangekondigde overname van Yahoo! heeft me aan het denken gezet. Waarom zou Microsoft een zoekmachine willen overnemen? Maar Yahoo! is inmiddels veel meer dan alleen maar een zoekmachine. Neem Flickr en del.icio.us. Wordt dat dan misschien de nieuwe strategie? "Op zoek naar leven na de zoekmachine…". Wordt al die metadata, die we met pijn en moeite hebben toegevoegd dan ook overbodig? Gelukkig niet, Ik denk zelfs dat we die inspanningen nu pas echt goed gaan terugverdienen!

In een TEDtalks demonstratie  over photosynth is te zien hoe heel veel foto’s, van bijvoorbeeld de Notre Dame, onder andere afkomstig van Flickr, tot één geheel kunnen worden gesmeed in een soort virtuele wereld waar je met je computer doorheen kan lopen. 
Dit is mogelijk door onder andere gebruik te maken van Geotagging, een microformat waarin metadata over de locatie kan worden vastgelegd. Aan veel van die foto’s is natuurlijk ook andere metadata gekoppeld, bijvoorbeeld over de architectuurstijl van het gebouw of detail informatie over de beelden die erin verwerkt zijn. Niet alle gebruikte foto’s bevatten even rijke metadata, maar doordat ze via Geotagging met elkaar in verband gebracht kunnen worden kan die achtergrond informatie ook automatisch gekoppeld en verreikt worden. (Nu snap ik die overname pas echt goed…)
Je kunt zelfs nog een stapje verder gaan en niet alleen foto’s op deze manier aan elkaar koppelen maar ook video’s.
Overigens zit Google ook niet stil. En andere bedrijven spelen er ook steeds beter op in, door bijvoorbeeld camera’s uit te voeren met automatische Geotagging. Da’s mooi, want dan kunnen we nog wat verwachten.

In ieder geval zal dit de weg naar nog meer en eenvoudiger te bereiken resources breder, sneller, mooier en geanimeerder maken. Het onderwijs zou gek zijn als ze daar niet de vruchten van zouden plukken.

LinkedIn vraag: "Is Massive Online Multiplayer based virtual education the future?" (zie: http://www.linkedin.com/answers/career-education/education-schools/CAR_BUE/116643-8438858)

Tegenstrijdig
Liever drie metadata standaarden dan één lijkt tegenstrijdig, want standaardisatie is er toch om zoveel mogelijk op dezelfde manier te doen?

Diversiteit
Het antwoord is diversiteit. Diversiteit stimuleert innovatie en maakt ruimte voor kwalitatieve verbeteringen. Het streven naar één standaard is nog wat anders dan één standaard opleggen en alle andere standaarden in de ban te doen. Het bestaan van varianten van metadata dwingt tolerantie af, onder andere bij de systemen die er mee om moeten gaan.

Tolerantie
Zitten er dan geen grenzen aan die tolerantie? Natuurlijk wel. Het is juist het zoeken naar die grenzen waarmee je criteria kan formuleren die aanleiding geven voor kwalitatieve verbeteringen. Twee voorbeelden:

• Tolerant omgaan met een andere standaard kan alleen als die andere standaard dat ook doet
• Tolerantie moet wel een hoger doel dienen en geen doel op zich worden. (Het is haast net als in de grote mensen wereld…)

Harmonisatieprincipes
In het HarmonyManifest worden vijf harmonisatieprincipes genoemd: Extensibility, Modularity, Refinements, Multilingualism en Machine-processability.

Tolerant omgaan met diversiteit en tegelijkertijd streven naar één standaard vormen op zichzelf  criteria voor de harmonisatieprincipes van standaarden. Een nieuwe standaard moet altijd ruimte bieden voor het ontstaan weer nieuwe standaarden. Dit principe wordt vooral goed gewaarborgd als je je houdt aan het principe Modularity, maar stelt ook eisen aan de vier andere principes.

Een ander harmonisatieprincipe daarnaast richt zich meer op het proces van harmonisatie. Tijdens het harmonisatieproces mogen compromissen nooit worden gemaakt op het niveau waar de standaarden voor bedoeld zijn, omdat je daarmee de voordelen van diversiteit teniet doet.

Om een harmonisatieproces goed uit te voeren is het dus razend belangrijk om goed op een rij te hebben waar metadata nu eigenlijk voor bedoeld is en waar metadata inmiddels voor gebruikt wordt en misschien ook wel in de toekomst voor gebruikt kan worden…

http://kennisnet.wikia.com/e-portfolio/wiki/Categorie:ISSUES

http://kennisnet.wikia.com/e-portfolio/wiki/Overzicht_van_in_mei_2007_te_behandelen_issues

http://www.maths.ed.ac.uk/mathqti/

De gezamenlijkekenniscentra beroepsonderwijs bedrijfsleven en het CoördinatiepuntKwalificaties Beroepsonderwijs stellen via hun website de gepubliceerde kwalificatiedossiers beschikbaar.

Wanneer je de link ‘Kwalificatiedossiers‘ volgt, kom je op een webpagina met de nodige zoekfunctionaliteit. In de zoekresultaten zie je onder andere een icoontje van een winkelwagen. Als je een dossier of een onderdeel van een dossier hebt gevonden kan je op het winkelwagentje klikken. Wees gerust, je koopt dan niets! Je voegt het eigenlijk toe aan een lijst met favorieten. Via de link "open winkelwagentje" open je die lijst en kan je een aantal dingen met die dossier(onderdelen) doen. Eén van die dingen is om er voorbeeld metadata mee te genereren. Dit doe je met de knop "export LOM".

De verkregen metadata is natuurlijk maar een deel van de totale metadata die je aan een leerobject kan toevoegen. Ik heb dan ook het idee dat de huidige implementatie van de export knop voornamelijk van dienst kan zijn bij het genereren van voorbeeld materiaal. Ontwikkelaars van content arrangeer- of ontwikkeltools of metadata editors kunnen dit gebruiken bij de ontwikkeling van hun tools. Zo kunnen ze op basis van de voorbeelden ook een lijst met alle mogelijke termen uit het CKS in de interface opnemen. Deze zijn namelijk vastgelegd in VDEX-bestanden, waar ook in de metadata naar wordt gerefereerd.

Twee voorbeelden zijn: algemene competenties; overige CKS termen. Voor iedere wijziging in de dossiers zal een nieuwe versie van de VDEX beschikbaar worden gesteld. Op dit moment is er nog geen mechanisme om automatisch de laatste versie te kunnen vinden. Voornoemde versies zijn volledig platte lijsten, vooralsnog zonder structuur informatie. Meer info over de structuur van de dossiers is te vinden op http://coordinatiepunt.nl/competent/index.html.

Twee stellingen:
Stelling één, een open deur waar iedereen het mee eens zal zijn:

Om geen extra drempels op te werpen om computergebruik in het onderwijs geaccepteerd te krijgen moet je voorkomen dat gebruikers tegen kinderziektes aanlopen die heel eenvoudig zijn op te lossen en in vele domeinen ook al daadwerkelijk zijn opgelost.

Stelling twee, vreselijk generaliserend, en in feite een uitdaging naar de betrokkenen om het tegendeel te bewijzen (als ze dat al willen):

"Programmeurs zijn lui."

Helaas moet stelling één vaak het onderspit delven ten opzichte van stelling twee. En het helpt niet als er software gemaakt wordt die luie programmeurs probeert tegemoet te komen, zoals te lezen is in het artikel "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)", waarin Joel Spolsky zegt:

"Postel’s Law about being "conservative in what you emit and liberal inwhat you accept" is quite frankly not a good engineering principle"

Conclusie is dat er ook rond encoding een architectuur-principe van kracht is:

Geef altijd aan welke encoding er gebruikt wordt. Maak daarbij bij voorkeur gebruik van een eenduidige encoding, bijvoorbeeld UTF-8 -en niet windows1252, lees ‘Karaktercodering is nog een ondergeschoven kindje’-

Veel aan het internet gerelateerde afspraken maken gebruik van vaak terugkerende onderdelen. Voor onderdelen die vaak terugkeren loont het dan ook de moeite om daar tijdens het ontwerp vanuit een architectuur visie bij stil te staan. Neem bijvoorbeeld de URI’s.
URI’s worden gebruikt in het content-zoekprofiel om te verwijzen naar de gebruikte vocabulaires, soms om leerobjecten te identificeren en uiteraard in het veld met de verwijzing naar het leerobject zelf.
URI’s worden gebruikt in de afspraak OAI-PMH. De belangrijkste URI daarin is de base-URL, die aangeeft waar een repository is te vinden. Je wilt natuurlijk voorkomen dat jouw repository opeens onvindbaar wordt, omdat je de base-URL hebt moeten (…) aanpassen. Je wilt per slot van rekening zo weinig mogelijk redirects op je repository-server hebben.
URI’s worden gebruikt in SRU/SRW.  Daarbij zie je bijvoorbeeld het belang van de lengte van een URI in relatie tot de keuze voor SRU of SRW.
URI’s worden in VDEX gebruikt als termIdentifiers, maar belangrijker nog is dat je goed nadenkt over de URI voor de VDEX zelf, want zodra je een VDEX publiceerd, zullen diverse systemen ernaar verwijzen. En die verwijzingen wil je toch minstens tien jaar lang onveranderd kunnen ondersteunen, ook wanneer je als organisatie besluit een andere serverapplicatie of onderliggende CMS of organisatiestructuur of wat dan ook te wijzigen.

Mijn conclusie is daarom ook om in de architectuur rekening te houden met een goed URI ontwerp. Hieronder een eerste poging om daar een principe voor op te stellen:

Een architectuur die gebruik maakt van URI’s moet speciaal voor die URI’s een deel-architectuur bevatten waarin wordt voldaan aan de tips ten aanzien van URI-ontwerp zoals gegeven op de web-pagina http://www.w3.org/Provider/Style/URI.

Op de website van het programma E-portfolio NL staat informatie over de Regeling Implementatie en uitwisseling e-portfolio 2007-2008. Dit is een stimuleringsregeling waarin zes projecten kunnen deelnemen. Op 8 mei is er een voorlichtingsbijeenkomst over de regeling. Projectideeën moeten uiterlijk 7 juni digitaal ingeleverd zijn.

Dat is ruim een maand de tijd. Dat lijkt misschien erg kort dag om een goed projectidee te schrijven dat ook nog aan alle voorwaarden en criteria die in de regeling staan te voldoen. Ik ga dat hier niet ontkennen, maar uit ervaringen met eerdere regelingen blijkt dat het zeer zeker niet onmogelijk is! Wat ik wel kan doen is geïnteresseerden een stukje op weg te helpen…

Op bladzijde 7 van de regeling staat bijvoorbeeld:

"Indien reeds voldaan wordt aan (delen van) de afspraak E-portfolio NL dan dient dit te worden aangegeven."

Menig "penvoerder" zal hierin blind moeten vertrouwen op wat de technische partners (e-portfolio systeem leveranciers) daarover zeggen. Daarom is het ook mogelijk om bij wijze van proef de systeemleverancier een voorbeeld e-portfolio op te laten sturen.
Ik wil hier overigens de vertrouwensbasis tussen de potentiële partners niet bij voorbaat mee ondermijnen! Ik kan me trouwens heel goed voorstellen dat het voor systeemleveranciers ook prettig is om, gedurende de ontwikkeling van hun e-portfolio systeem, feedback te krijgen over de correctheid van de e-portfolio packages.
Ook voor andere technische en niet technische vragen over de afspraak E-portfolio NL kunt u contact opnemen.

Regelmatig worden mij content-packages opgestuurd met de vraag of ik ze wil toetsen tegen de geldende standaarden. Zolang dergelijke vragen me niet met een te hoge frequentie bereiken, geef ik er graag gehoor aan. In het antwoord hou ik dan echter niet alleen rekening met wat er in de afspraken staat, maar probeer ik ook te letten op zaken als "maintenance releases" en openstaande issues.

Relevante antwoorden neem ik ook op in een van de wiki’s (EduRepWiki of ePortfolioWiki).
Zo ook een recent antwoord op een content-package dat gebruik maakte van de IMS Content Packaging Specification version 1.1.2. Dit was overigens niet de eerste keer dat ik een dergelijk pakketje krijg opgestuurd, maar wel de eerste keer dat ik de tijd heb genomen een uitgebreid antwoord te formuleren en ook in de wiki op te nemen. Het viel me namelijk op dat haast alle pakketjes die ik ontvang van deze verouderde versie gebruik maken. Terwijl er toch al sinds oktober 2004 een versie 1.1.4 bestaat. Dit is weliswaar een maintenance release, maar die is er niet voor niets. Bij de validatie van een imsmanifest.xml bestand die gebruik maakt van de oude versie kan het namelijk (afhankelijk van de xml-validator) heel goed voorkomen dat er een foutmelding komt die zijn oorsprong vindt in het schema (de xsd).

Waarom gebruikt men dan nog steeds die oude versie? Antwoord is waarschijnlijk omdat ADL SCORM-CP v1.2 ook gebruikt maakt van die oude versie. Het content-package schema van SCORM 2004 "adlcp_v1p3.xsd" bevat geen verwijzingen naar IMS-CP v1.1.2, maar gezien de beperkte verspreiding van SCORM 2004 in Nederland ligt het wellicht meer voor de hand om te kijken naar andere mogelijkheden. In de EduRepWiki doe ik een voorstel, waarbij het SCORM-CP schema dat in het content-package wordt meegeleverd moet worden aangepast. Ik doe daarbij tevens een oproep om voorbeelden van applicaties waarin deze aanpassing te maken is in de wiki op te nemen.

Tenslotte een belangrijke overweging. Wanneer levert het gebruik van de oude versie van content-packaging eigenlijk problemen op. Dan moet ik toegeven dat een eindgebruiker daar misschien wel helemaal niets van hoeft te merken. De problemen ontstaan namelijk pas wanneer je de xml-bestanden gaat valideren op basis van de schema’s waar vanuit die xml-bestanden naar verwezen wordt. Dus moet ik me hier wel druk over maken?!?