Last modified 5 years ago Last modified on 06/27/12 11:24:27

Introduction: Vue d'ensemble du projet Comète

Le projet Comète vise à développer une application logicielle permettant de trouver, agréger, organiser en collection et diffuser le patrimoine numérique des institutions d'enseignement et autres intervenants des systèmes d'éducation.

Pourquoi un nouveau projet logiciel

La question est légitime, vu qu'il existe bon nombre de projets existants ayant des objectifs qui recoupent au moins partiellement ceux du projet Comète.

Néanmoins, aucun projet existant ne répondait à l'ensemble des besoins des partenaires du projet. Par ailleurs, il n'est pas question de réinventer la roue : le projet Comète conservera plusieurs acquis des projets qui en sont à l'origine (ORI-OAI, Eurêka et Paloma) et réutilisera plusieurs logiciels libres, avec ou sans modification.

Ce que le projet COMETE n'est PAS

Nous souhaitons à tout prix éviter de reproduire:

  1. Un dépôt où le modèle commun se limite à l'exploitation du plus petit dénominateur commun, soit Dublin Core non-qualifié.
    • Bon nombre de projets se limitent, par conception ou en pratique, à un tel ensemble au niveau fonctionnel (recherche, gestion, affichage).
      • La raison est que les métadonnées des corpus réels sont très variables, tant au niveau des formats et profils utilisés, qu'au niveau du respect de ces formats et profils. Entre autre, l'utilisation exacte des vocabulaires imposés est souvent très variable, même au sein d'un même profil d'application.
  2. Un dépôt où tous les dépôts moissonnés doivent s'entendre sur un profil d'application commun, et générer des métadonnées correctes
    • La coopération entre ORI-OAI et Eurêka pour l'échange de métadonnées a montré qu'il est extrêmement difficile d'obtenir des formats et vocabulaires réellement communs. Pourtant le contexte était presque idéal; en effet les partenaires:
      • sont en communication directe
      • partagent le même format de métadonnées de base (LOM)
      • utilisent seulement deux profils d'application (NORMETIC et LOMFR)
      • ont une langue commune (le français)
    • Le monde plus large est considérablement plus complexe, et l'arrivée de nouveaux standards au niveau des formats (entre autre MLR) ne va pas améliorer les choses.

Il est utopique de penser que les corpus existants vont du jour au lendemain:

  • Se mettre à produire des métadonnées 100% syntaxiquement valides
  • Utiliser correctement et systématiquement des vocabulaires contrôlés, et les rendre disponibles
  • Suivre l'évolution des standards

Ils vont changer lentement. Et ils ne vont changer que SI nous leur fournissons des outils qui:

  • leur permettent de produire facilement des métadonnées correctes et validées
  • leur démontrent les bénéfices de le faire

Nous essayons d'inciter les organisations à utiliser les bons vocabulaires, développés par les comités après des mois de discussions. Or, même si elles le font, à peu près personne ne les exploite dans leur interface. Peu de systèmes les utilisent pour filtrer les recherches, encore moins pour suggérer des mots clés ou pour faire des équivalences.

Pour dire les choses crûment, dans les systèmes actuels, une ressource dont les métadonnées respectent scrupuleusement les standards a exactement la même chance d'être trouvée, qu'une autre dont les métadonnées les respectent très mal.

De surcroît, il est déraisonnable de demander à l'ensemble des organisations d'un système éducatif de fournir des métadonnées valides et respectant les profils d'applications et les bonnes pratiques, si on ne leur fournit pas des outils qui leur permettent de vérifier facilement la qualité de leurs ressources. 'Facilement' signifiant :

  • Pouvant être vérifié de façon informatisée par un ordinateur
  • Ne nécessite pas de support des TI locales (doit être un service web publiquement accessible)
  • Couvre tous les aspects
    • Syntaxe
    • Respect du profil d'application
    • Utilisation des termes du vocabulaire annoncé, ou de celui imposé par le profil d'application selon le cas.
    • Rapport d'erreurs, dans un format compréhensible et suffisamment contextualisé pour que
      • Selon la nature de l'erreur, une personne chargée de l'édition des métadonnées ou un programmeur soit en mesure de corriger l'erreur.
      • Le contexte soit lisible informatiquement pour qu'un éditeur de métadonnées puisse afficher l'erreur dans ou près du champ d'édition approprié.

Qu'est-ce que COMETE (architecturalement parlant)

Une architecture modulaire

La majorité des projets sont initialement conçus pour être modulaires. Pourtant peu de projets atteignent une séparation modulaire réelle. Dans le cas de COMETE, la modularisation ne constitue pas un simple voeu pieux de pureté architecturale, elle est impérative à la réussite du projet:

  • Sans la possibilité de remplacer, ou de largement modifier un composant en cours de développement, il apparaît peu probable qu'il sera possible de mener le projet à terme vu les incertitudes technologiques et humaines liées au projet.
  • Sans architecture modulaire, il devient très difficile de suivre le développement de modules externes, ce qui occasionnerait d'énormes problèmes de maintenance, et l'impossibilité de reverser nos contributions.
  • Sans APIs bien définis, il est difficile de faire des tests automatisés et de bien collaborer entre les équipes.
  • Sans architecture modulaire stricte, il est impossible d'envisager une convergence à terme du projet ORI-OAI et de COMETE.

Certes, modulariser a un coût en terme de performance brute, mais la seule opération vraiment critique au niveau performance (latence, scaling) est la recherche. La majorité des modules ne sont donc pas sur le chemin critique.

Pourquoi Fedora Repository comme base pour Comète

Voir Architecture/Modules/FedoraRepository

Une architecture Search on harvest

Le projet COMETE utilise une architecture « Search on harvest » (recherche sur moissonnage), pour les raisons suivantes:

  • Il est extrêmement difficile d'offrir un tri par pertinence dans une recherche fédérée
  • Cette architecture permet de définir son propre métamodèle et permet d'y convertir l'ensemble des ressources, même si la conversion est informatiquement coûteuse (elle peut se faire en différé), ce qui d'une part simplifie l'implantation et, d'autre part, permet de ne pas se limiter au plus petit dénominateur commun comme tant d'autres projets.
  • L'accès aux métadonnées n'est pas dépendant de la disponibilité des dépôts distants.
  • La latence est énormément moindre.

Pour plus d'information, voir l'article: Ariadne Infrastructure for Managing and Storing Metadata

Aspects novateurs

Recherche

La véritable recherche et développement est au niveau de l'intégration recherche plein-texte vs recherche sur les champs. Il y a un certain nombre d'options pour l'implanter:

  • Sérialisation des recherches (exemple: filtrage sur les données RDF, puis recherche plein-texte)
  • Un seul système fait la recherche (ex: Virtuoso)
  • Pré-traitement (ex: closure transitive de certains vocabulaires pour aplatir le modèle de recherche en quelque chose que Lucene peut comprendre)

Indépendamment de l'architecture choisie, foncièrement il n'y a pas d'autre façon de chercher efficacement dans une base de donnée que de chercher dans des indexes. Ceux-ci peuvent être rendus plus pertinents (pré-calculs, données structurées selon les requêtes, localité, segmentation). La question est de savoir comment ces indexes sont construits et quels systèmes en sont responsables.

Avec l'arrivée de MLR, la recherche plein-texte d'une version aplatie des métadonnées utilisées historiquement par presque tous les référentiels ne sera plus applicable (les étiquettes de vocabulaires n'étant plus en langue naturelle).

Assurer l'unicité des termes de vocabulaires et des identités

Peu de dépôts ont essayé de le faire pour des données moissonnées, et à notre connaissance aucun ne l'a fait dans un contexte de moissonnage général (sauf dans le cadre de projets de recherche universitaire).

Peu de systèmes peuvent le faire (point) pour des données qui ne sont pas RDF à la base. Or, c'est largement ce qui permet de gérer des collections, de faire des ensembles, d'avoir les fiches du même auteur, etc. C'est également ce qui permet d'établir des correspondances entre les vocabulaires de classification, ce qui permet ensuite d'obtenir les ressources qui correspondent aux termes des ces vocabulaires, sans devoir inclure chaque terme applicable de chaque vocabulaire dans les métadonnées de chaque ressource.

Plus d'information sur la gestion des correspondances entre vocabulaires est disponible dans la Documentation du module Vocabulary

Profils d'application définis dynamiquement

Il ne s'agit pas ici de se limiter aux profils normalisés (NORMETIC, LOMfr, etc.). Les responsables de la rédaction des métadonnées, même professionnels, n'ont à toutes fins pratiques jamais besoin de voir l'ensemble des éléments et valeurs possible d'un profil d'application dans leur contexte local. Par contre, ils peuvent être très intéressés à valider des fiches contre ce profil local dans le cadre d'un workflow.

La gestion et la définition simple de profils d'application complets, et leur intégration à l'éditeur et la validation seront une première. À notre connaissance aucun système ne l'a fait, sauf dans le cas de profils statiques.

Le projet COMETE a déjà développé un standard pour la représentation informatique des profils d'application.

Gestion des collections

Peu de systèmes permettent de définir dynamiquement des collections, sans changer les données stockées. Il s'agit pourtant d'une étape essentielle à la constitution et la maintenance à faible coût de collections incluant des ressources moissonnées de l'extérieur.

En savoir plus sur la gestion des collections dans COMETE.

0.9.8 © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.62668 sec.)