Procedures voor metadatering en opslag van leerobjecten

Structuur en toekennen van rechten in een repository

• Duidelijke afsrpaken maken over naamgeving van subafdelingen. Gebruik bv. sectieafkortingen bij de domeinen zodat overlap wordt voorkomen.
• Alleen op de noodzakelijke niveaus rechten instellen. Dat scheelt werk bij het doorvoeren van veranderingen. ERworden drie relevante niveaus onderscheiden: instelling, faculteit en sectie.
• Het is aan te raden om docenten altijd publisher te maken. Op deze manier hebben ze zicht op de boomstructuur van de eigen instellingen en kunnen ze makkelijk op zoek naar materialen van collega's. Daarnaast kunnen ze hun eigen materialen direct in de vakken van hun collega's plaatsen, zonder dat documenten heen en weer moeten worden gemaild.
• Het is aan te raden de docenten op hun eigen niveau (sectie) alle rechten te geven. Zodoende kunnen de mensen binnen de sectie zelf de verschillende vakgebieden aanmaken en onderhouden.
• Studenten kunnen zich via Blackboard laten registrenen voor vakken. Studenten die vakken aan een andere instelling volgen kunnen zodoende via Blackboard automatisch in HIVE en hebben daardoor de juiste permissies.

Aanbevelingen voor complexe webapplicaties

• Redenen waarom een LCMS alleen een URL naar het object zou moeten bevatten en niet het object zelf:
• Bij complexe applicaties wil men één kernel houden, op één plek, ivm onderhoud.
• Webapplicaties hebben soms server-functionalitiet nodig
• Veel aanbieders zullen niet willen dat hu product vrij, als los object te kopiëren, rondzwert
• Het ligt niet voor de hand dat alle LOs die interessant zouden zijn voor studenten allemaal in de betreffende LCMS opgeslagen worden. Eerder zullen er verschillende repositories zijn waar studenten gebruik van maken. Die verschillende repositories moeten dan wel via de LCMS bereikbaar zijn.
• Metadata moeten bij het object/de content zelf staan en automatisch geharvest worden naar LCMS-en die er gebruik van willen maken. Dit ook weer ivm onderhoud en actualisatie.
• Een learning object moet zo gebouwd zijn dat eze via een weblink te starten is en dan foutloos werkt. Hierbij moet het niet uitmaken of het materiaal binnen zijn eigen omgeving wordt gebruikt of, door gebruik van het LCMS, daarbuiten (bijv. CASK-pagina's draaien binnen de CASK-mgeving - in deze omgeving kunnen dan verschillende pagina's aan elkaar gekoppeld zijn tot één les. In de CAKS-omgeving kunnen automatisch indexen, quizzen, etc. gemaakt worden en zijn er andere extra faciliteiten. CASK-pagina's draaien echter ook als los object in een browser, maar dan zonder die extra functionaliteiten en ook zonder het geven van foutmeldingen).
• In LOM is er nog een aantal velden, met name ID velden, niet geheel uitgekristalliseerd.
• Bij een aantal velden van LOM is er een verschil tussen de LOM standaard zelf en de LOM naar SML binding standaard.

Gebruik van authoring tools

Een serie tools is getest en een keuze is gemaakt voor een auteurstool waarmee studenten zelf leercontent zouden kunnen ontwikkelen, met als eindproduct een SCORM-package. Het ziet er naar uit dat binnen afzienbare tijd een aantal programma's op de markt komt die deze procedure aanzienlijk zal vergemakkelijken. Tot die tijd lijkt het de beste en ook de simpelste oplossing om studenten de gegevens per leerobject met CourseGenie van metadata te laten voorzien en te exporteren als SCORM-package. Deze pakketten kunnen dan door een vaste medewerker in HIVE geüpload worden, zodat de metadata goed terecht komen.