Présentation des motivations et priorités du dépôt et référentiel de ressources d'enseignement et d'apprentissage Eurêka (http://projects.coeus.ca/eureka/, http://eureka.ntic.org/)
2. Petit rappel historique
L'effort de normalisation au Québec visait à
améliorer la productivité des enseignants en:
Permettant de trouver plus facilement des ressources
d'enseignement
Évitant de produire en vase clos plusieurs dizaine de
fois les même ressources
Favorisant la production de ressources de qualité en
en assurant une diffusion plus large
Rendant disponible les ressources produites dans le
reste de la francophonie
4. Priorités d'Eurêka
Qualité des métadonnées
Exploitation réelle des métadonées
Moissoner les dépôts d'aujourd'hui, pas les
hypothétique dépôts de demain
Implantation complète des standards et conformité
5. Priorité: Qualité des méta-
données
Fonctions de validation de de définition des
données très complètes
Validation des formats physique à l'importation
Validation des profils à l'éditions
Définition de nouveaux profils
Validation des profils à la navigation
6. Priorité: Exploitation réelle
des métadonnées
Éviter à tout prix de se limiter au plus petit commun
dénominateur (Dublin core...)
Relations entre les vocabulaires
Équivalence des niveaux scolaires
Vcard (images, resources reliées, éliminations des
doublons)
8. Priorité: Adhérence aux
normes
Un support du multilinguisme sans pareil
Respect complet des métamodèles
Autres standards (Dublin Core, RSS,
OpenDocument, etc.)
9. Architecture technique
Approche web
Base de donnée SQL avec intégrité référentielle
Modèle de donnée interne calqué directement sur
LOM et VDEX
Aucun vocabulaire codé en dur
Moissonage
11. Un contexte un peu
différent...
La majeure partie des systèmes ont été développés
dans un contexte plus simple:
N'ont à traiter que des données produite par leur
propre plateforme.
Et encore, souvent il s'agit d'une simple vue d'une base
de donnée conçu sans tenir compte de l'exportation des
métadonnées.
Ne supportent pas toutes les cardinalités, le
multilinguisme à la saisie, et ont un nombr fini de
profil d'application à traiter.
Se contentent d'une recherche plein texte ou XML,
sans tenir compte des vocabulaires.
12. Un contexte un peu
différent...
Dans le meilleur des cas Eurêka doit vivre avec les
choix des autres
Dans le pire, avec leurs erreurs
13. Différents scénarios de
saisie
Saisie et gestion dans eurêka (Vitrine,
précédemment infiressources)
Système maison utilisant Eurêka comme éditeur
(précédemment CCDMD)
Moissonage, système maison (Infiressources,
CCDMD)
Moissonage, standard (RESPEL, CANALU)
15. Si Eurêka est si avancé,
pourquoi changer?
Modèle de donnée doit être orienté document
L'expertise SQL nécessaire pour évoluer le système
plus loin devient déraisonnable (nous avons
atteint la limite des possibilités des bases de
données relationelles)
Les bases de données XML ne permettraient pas non
plus d'aller plus loin, il faut une base de donnée
orientée graphe
16. Plus précisément...
Présentement il serait particulièrement difficile
d'implanter:
Support de formats qui ne peuvent être représentés
aisément dans le métamodèle de LOM
Une exploitation encore plus grande des relations
entre vocabulaires
Éditeur en lot plus granulaire
Définition dynamique de l'interface
Un découplage total des modules
17. Alors que faire pour son
successeur?
Loose coupling
Rester agnostique face aux choix technologiques
Structurer la communauté de telle façon que
personne ne monopolise le développement
