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/)

1. Le projet Eurêka,
description et perspectives
 Benoit Grégoire <benoitg@coeus.ca>

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

3. Mandat d'Eurêka
 Servir de preuve de concept pour les errorts de
normalisation, avant même leur adoption
 Répondre aux besoins de ses fournisseurs et
consommateurs de métadonnées
 Opérer un référentiel pour le collégial (aujourd'hui
près de 20000 ressources)

4. Priorités d'Eurêka
 Qualité des méta­donné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)

7. Priorité: Moissoner les
dépôts d'aujourd'hui
 Araignée HTML
 Vcard
 XSLT
 Validation

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

10. Développement en quelques
chiffres
 Développé de juillet 2004 à ce jour
 6 développeurs y ont contribué
 46,933 lignes de code

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 plate­forme.
 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, CANAL­U)

14. Démonstration

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éta­modè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

18. Une proposition
d'architecture