Le projet Eurêka vise à normaliser les ressources pédagogiques au Québec, facilitant leur accessibilité et qualité, avec près de 20 000 ressources actuellement référencées. Il met l'accent sur la validation et l'exploitation des métadonnées tout en respectant les normes multilingues et différents standards. Face aux limitations des bases de données traditionnelles, une évolution vers une architecture orientée graphe est envisagée pour son successeur.

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