Last modified 6 years ago Last modified on 07/30/11 16:46:30

Go back to the architecture overview page

Le métamodèle des données traitées par COMETE

Le métamodèle ne vise pas à être une synthèse des modèles connus (soit, pour l'instant, LOM, ILOX, MLR, DC et TEF). Il s'agit d'un sous ensemble d'entités dont la sémantique est communes à bon de formats, ou particulièrement importantes. Elles sont choisies parce qu'elle permettent de définir les principales opérations et interprétations que désirent faire les usagers sur les fiches (y compris les gestionnaires du système.) que l'on souhaite supporter dans le cadre du projet COMETE. Il est appelé à grandir avec le temps.

Il ne s'agit pas d'une intersection des modèles connus (certaines entités ne sont pas représentables dans tous les formats), ni d'une union (le modèle se veut le plus petit modèle permettant d'effectuer les opérations désirées).

En tant que tel, c'est aussi un modèle des entités et relations repérables dans le système. Ce n'est pas nécessairement un modèle des structures de données sous-jacentes, qui dépendra de l'implantation.

L'un des objectifs poursuivi est d'assurer l'unicité des identités, termes de vocabulaires, dépôt, etc. lorsque faire se peut.

Implantation dans Fedora

Vous trouverez sur le wiki un page qui traite spécifiquement de l'implantation de l'architecture dans Fedora.

Structure du métamodèle

GraphViz image

OriginalRecord

Une fiche, ou fragment de fiche, exactement telle que moissoné, avant interprétation et traitée comme un blob (une séquence d'octets non interprétés). N'est présent que pour les fiches moissonées, et est non éditable.

NativeRecord

Une fiche, ou fragment de fiche, dans un format natif quelconque: LOM, ILOX, MLR... Transformé dans un format interne ([*MetaDataRecord?]) par un module d'import-export. Diverses sous-classes correspondront probablement aux divers formats natifs.

Deux cas d'utilisation:

  1. La fiche est moissonnée de l'extérieur. Contient alors la fiche originale, après corrections automatisée et dé-référencement des vocabulaires, identités, etc.. Non-éditable: Plutôt appliquer des fiches de correction sur la fiche en format interne produite par le module d'importation.
  2. Une fiche créée et maintenue dans le Repository courant dans un format natif; peut être modifiée par l'outil d'édition approprié.

MetadataView

Une fiche calculée, qui représente la forme visible à l'usager (Façade) d'un graphe de fiches. Elle recouvre un graphe de fiches, incluant fragments, agrégations de fragments, valeurs héritées entre niveaux d'abstraction, et corrections. Bien sûr, dans certains cas, la vue peut faire référence à une seule fiche.

C'est à toute fins utiles la représentation "native" de comète. En pratique, cette vue est matérialisée dans l'implantation et stockée pour des raisons de performance. Elle est régénérée dès qu'il y a modification à l'une des données qui compose la fiche.

Les valeurs définies pour une vue sont essentiellement déterminées par une stratégie de traversée du graphe de fiches, et on prend le premier #Attribute pour un type d'attribut dans la traversée. En général, les fiches de correction viendront avant les fiches corrigées; les fiches concrètes avant les fiches abstraites, etc. Les #ComputedMetadataRecord peuvent désactiver la traversée vers les fiches dont elles agrègent les valeurs.

L'ordre de traversée peut dépendre d'une configuration du site. Par exemple, les fiches de corrections seront acceptées ou non selon la politique du site; s'il y a conflit entre plusieurs corrections, la politique du site doit établir une préférence. En théorie, il est possible de créer une vue composite de plusieurs fiches selon une politique de préférences selon leur origine; et cette politique pourrait même être celle de l'utilisateur plutôt que celle du site. Toutefois, cette dernière option interdit plusieurs optimisations et ne sera probablement pas praticable dans le cadre du projet. (voir plus bas, sur le pré-calcul des clôtures transitives.)

À compléter: Les MetadataView peuvent utiliser la relation de composition pour reproduire les abstractions d'ILOX. Il n'est pas nécessaire que la structure des abstractions dans le MetadataView recoupe celle des dont elles sont la façade.

ILOXFragmentRecord

Dans certains cas, un #NativeRecord peut désigner une partie d'un autre #NativeRecord (utiliser un XPath pour spécifier la partie?)

Ressource

  • URL pour accès et identification
  • Dépôt (optionnel)

Repository

Dépôts de ressources et/ou de fiches. Liés à une organisation.

Profile

Le profil de validation de la fiche

PriorityPolicy

Une politique qui donne priorité à certaines fiches dans le calcul des #MetadataView, selon leur origine et la nature du lien. Définie au niveau du site. (Au niveau de l'usager si la performance le permet.)

Les paires attribut-valeur

GraphViz image

Attribute

Chaque fiche associe à la ressource des métadonnées, sous la forme de paires attribut-valeur. Ceci inclut les métadonnées que le #MetadataView ne traitent pas directement, tiré du #NativeRecord. Par exemple les champs LOM qui n'ont pas d'équivalent dans les #InterpretedAttribute. Ceci permet:

  1. D'inclure ces champs dans la recherche plein texte.
  2. D'afficher ces champs à l'usager, pour qui ils ont peut-être une signification claire.

InterpretedAttribute

Seulement certaines de ces métadonnées sont interprétées, c'est à dire qu'elle ont une sémantique associée qui est comprise par comète ou représentée dans son interface (de recherche notamment). Dans ce cas, elles ont un identificateur représentant la valeur sémantique associée. Les types de données associées peuvent être simples ou complexes (des structures). (Les différents types de valeurs sont représentés pas des sous-classes de InterpretedAttribute? dans le schéma, mais c'est un détail d'implantation.)

Liste des champs ayant une sémantique comprise par Comete

Ces champs sont sélectionnés parce que leur signification contextuelle est extrêmement utile, voire essentielle, dans un contexte d'éducation.

  • title: LangString
  • classification
    • purpose: VocabularyTermOrString (optional)
    • value: VocabularyTerm
  • description: LangString
  • creationDate: DateTime
  • modificationDate: DateTime
  • type: VocabularyTermOrString
  • format: VocabularyTermOrString
  • relationship
    • qualifier: VocabularyTermOrString
    • target: Identifier
  • language
  • rights
  • location
  • originalRespository: #Repository
  • resourceContribution: ResourceContribution

Il est à noter que cette liste s'allongera avec le temps.

BaseValueType

Ici, c'est plutôt le type de donnée du champ que l'on veut traiter de façon riche, même si on n'en connaît pas la sémantique. Le meilleur exemple est un terme de vocabulaire.

Les types suivants sont compris par Comète dans le sens où leur nature et structure est comprise, mais pas nécessairement la sémantique contextuelle qui y est associée.

  • LangString
  • DateTime
  • Duration
  • VocabularyTerm
  • VocabularyTermOrString
  • Identifier
  • Identity

InterpretedValueType

Similaires aux BaseBalueTypes?, à l'exception que ce sont des structures propres à comete, et non des types génériques.

Contribution

Contribution à une ressource ou à une fiche (méta-métadonnée).

  • date: DateTime
  • role: VocabularyTerm
  • identity: Identity

Relationship

Relation entre deux ressources.

  • qualifier: VocabularyTermOrString
  • target: Identifier

Curriculum

À développer: Abstraction et composition du curriculum dans des programmes, etc. Le Curriculum est une sorte de contexte d'utilisation.

UsageContext

  • technicalRequirement
  • educationalMethod
  • audienceLevel
  • ageRange
  • userLanguage

Note: Les prérequis techniques sont considérés comme des entités rattachées à la fiche dans MLR, mais sont en pratique difficiles à identifier pour beaucoup d'autres formats. Á développer.

Les éléments d'audience sont également définis comme des entités, et en effet il y a plusieurs audiences possibles. Mais je doute qu'un usager recherche sur l'audience comme entité plutôt que sur les attributs de l'audience. Par contre, ça soulève la possibilité d'un contexte d'utilisation comme entité distincte, pour mieux marquer la multiplicité. Ce serait certainement utile dans les Evaluations.

Implantation interne (metadata record graph)

MetadataRecord

Une fiche de métadonnée interprétée (par un module d'import/export); peut aussi être un fragment de fiche, comme par exemple dans le cas d'ILOX, ou pour une évaluation extérieure. Pourrait être renommé en MetadataCluster, Bag... Ne pas confondre avec les #MetadataView; Les MetadataRecord ne sont pas généralement visibles à l'usager, sinon au travers une #MetadataView. Ils ne sont pas non plus visible au niveau de l'API.

Les Harvesters envoient des #NativeRecord; les modules d'import-export transforment ceux-ci en MetadataRecord, mais c'est à l'intérieur du module de stockage; la recherche ne voit que des #MetadataView. L'éditeur des fiches originales traitera principalement les #NativeRecords, alors que l'éditeur de fiches moissonnées traitera des MetadataRecord pour produire des fiches de correction.

Toutes les fiches sont rattachées à une origine, qui peut être un dépôt ou un simple URL. Dans tous les cas, l'origine donne une identité unique. Une fiche peut être composée de plusieurs fiches, par un ensemble de #Relation. Certaines fiches peuvent être le résultat de calculs.

  • langue de la fiche
  • identifiant de la fiche (URI)
  • contributions à la fiche
  • date de dernière modification
  • concret (bool): Si correspond à une ressource (termes vs abstractions dans ilox.)

Voir aussi le modèle de #Relation.

Note: Il n'est pas clair si la structure d'abstraction d'ILOX doit être exposée à ce niveau, qui doit en faire abstraction. La question revient à savoir si ces niveaux d'abstractions sont exposés à l'utilisateur; j'aurais tendance à dire que oui. (Je pense pareil. - FB)

Note 2: Certaines fiches sont des corrections pour d'autres fiches; elles invalident la fiche cible (si acceptées.) Elles ont néanmoins une origine identifiable. Il peut y avoir plusieurs fiches de correction; le plus simple est probablement de créer une fiche de correction composite dans ce cas.

Note 3: Certaines fiches sont des fragments, c'est-à-dire n'ont de sens que par rapport à une fiche aggrégatrice. Par exemple, les évaluations numériques des usagers, des commentaires, ou des rapports d'utilisation, sont périphériques par rapport à la description de la fiche. Il n'est pas clair si le statut de fragment correspond à une sous-classe ou à un attribut d'une fiche. Par contre, un fragment est nécessairement en relation de composition avec une fiche aggrégatrice: voire encore le modèle de #Relation.

ComputedMetadataRecord

Une fiche dont certains attributs sont le résultat d'un calcul; par exemple, une moyenne des évaluations numériques sur plusieurs fiches (fragments) d'évaluation. Elle aura alors une relation vers les multiples fragments en question.

Relation

Relations entre les fiches

Distinguons les ressources des fiches (MLR Record, par exemple). Les fiches contiennent un ensemble d'attributs-valeurs relatives à une ressource; parfois, ces valeurs sont elles-mêmes complexes (p.e. un FOAF ou une VCard.)

La distinction est importante; l'utilisateur veut trouver des ressources, mais en fait il effectue une recherche sur des fiches. Or, l'identité des ressources n'obéit pas à la même logique que celle des fiches. Les ressources sont concrètes; c'est-à-dire qu'elles correspondent à des items en langage ilox. Nous n'avons pas besoin de représenter les ressources abstraites, seulement les fiches plus abstraites.

Nous avons des relations entre les fiches; l'information de certaines fiches dérive de l'information d'autres fiches; à l'inverse, l'information de certaines fiches est remplacée par l'information d'une autre fiche.

Voici une première taxinomie des liens entre fiches:

  • Spécialise (S, C) -> données héritées de la cible, sauf si changées par la source. La cible reste valide. (pour ilox)
  • Remplace (S > C)
    • Corrige (S > C) -> invalide données de la cible, employer seulement source
    • Préférence (S > C) -> Les données de la source ont précédence sur celles de la cible, mais ces dernières demeurent accessibles.
  • Complémente (S, C) -> ajoute données supplémentaires. (par exemple usage, évaluation...) Multi-source.
  • Composition (S, C) -> ajoute données agrégées (moyenne, etc.) Multi-cible.
  • Variantes (S > C) -> ajoute données d'une variante (remix). Ce qui varie remplace l'original.
GraphViz image

Dans tous les cas, les données applicables sont celles du plus court chemin de la source à la cible. (Y compris un chemin de longueur 0.) Une recherche pourra aisément refuser de ramener les fiches corrigées par d'autres fiches; ainsi, la fiche de correction sera choisie, et supplantera les données corrigées, et seulement celles-ci. Certaines données, par contre, sont cumulatives: par exemple, les auteurs sont donnés pour chaque fiche, y compris la correction, et il faudrait ramener plusieurs auteurs.

On peut aussi limiter la recherche à un niveau d'abstraction donné; l'interaction avec les corrections est toutefois complexe. Une fiche de correction peut corriger des valeurs sur plusieurs niveaux d'abstraction différents; Tant qu'on cherche des fiches concrètes (items), elle peut être mise en avant de la hiérarchie d'abstraction et supplanter les valeurs. Mais si on cherche des fiches abstraites, la fiche de correction doit se placer au-devant de chaque niveau d'abstraction, ce qui est plus difficile à représenter. Il sera probablement nécessaire de placer la fiche de correction au-devant de chacun des quatre niveaux d'abstraction. Il est également possible d'intercaler dynamiquement la fiche de correction au niveau approprié à la recherche, par inférence, mais le coût en performance pourrait être important.

En effet, si nous arrivons à un modèle linéaire, les données des fiches connectées sont reliées à la fiche cible par une recherche transitive sur les liens. Or, beaucoup de bases de données permettent maintenant des requêtes traversant des relations transitives. Dans le cas de virtuoso, par exemple, on peut définir la transitivité soit au niveau RDF ou relationnel:

Virtuoso permet explicitement d'exiger le chemin le plus court entre deux relations.

Même pour une base de données classique, les relations entre fiches devraient être assez peu nombreuses pour qu'il soit raisonnable de précalculer la clôture de la relation transitive, avec mesure de distance, si la base de données ne la supporte pas. Ainsi, la recherche des valeurs de priorités ne suivrait que deux relations; d'une fiche source à une fiche cible à une donnée. L'algorithme de clôture pourra faire les ajustements pour les fiches de corrections.

Modèle de données et modèle de recherche

Comparer Architecture/MetaModel/IsoMlrModel La question du modèle de données peut être considérée de deux points de vue: modèle interne et modèle usager.

Le point de vue interne me semble bien couvert par une combinaison des niveaux d'abstractions comme dans ilox, avec la notion de fiche de correction ou d'agrégation comme décrit plus haut. Il faut également ajouter des notions de personnes et organisations: Les contributeurs à une ressource, les contributeurs à une fiche, les organisations auxquelles sont liés ces contributeurs. Les dépôts de ressources sont également des organisations pertinentes, bien que distinctes. Ajoutons enfin les taxinomies thématiques d'une part, et d'autre part les modèles pédagogiques. MLR relève l'audience (âge, langue et niveau) et le curriculum (niveau et sujet.) La plupart des aspects pédagogiques sont encore hors-cadre dans MLR, mais seront probablement ajoutés au fur et à mesure: syllabus (lié au curriculum mais plus micro); compétences, à la fois comme résultante et comme prérequis; activités pédagogiques. MLR mentionne les effets pédagogiques (outcomes) et activités d'évaluation, mais elles ne sont pas vraiment modélisées. LOM avait un modèle très primitif des activités pédagogiques.

La question principale est: Dans la mesure où certains de ces objets (contributeurs, curriculum, audience...) ont leur propre structure, doit-on considérer les propriétés comme reliées à la ressource, ou comme des entités distinctes?

Les acteurs (personnes et organisations) sont clairement des entités, et des requêtes peuvent découler de leur identité. Il faut donc les traiter comme telles.

Dans le cas des taxinomies, thématiques ou autres: Elles ont leur propre ontologie et structure, et il faudra prévoir de considérer chaque taxon comme une entité, et une série de convertisseurs. Il faut également prévoir différentes formes d'équivalence entre des catégories taxinomiques, ainsi qu'une façon de naviguer rapidement entre les taxinomies. Idéalement, une requête pour une branche d'une taxinomie devrait se traduire en un ensemble d'intervalles dans des taxinomies connexes. (Nous supposons pour l'instant des taxinomies en arbre; l'emploi des graphes est heureusement quasi-inconnu.)

Quant aux modèles pédagogiques: Le cas des curriculums et syllabus et clair: ce sont des entités définies par une identité propre. Le cas de l'audience est beaucoup plus flou; il s'agit d'une spécification et non d'une entité, et j'imagine que les recherches se feront sur chaque caractéristique individuellement plutôt que sur le groupe de caractéristiques définies. Enfin, le cas des activités pédagogiques est un champ de modélisation complexe... que nous ne réglerons probablement pas dans le cadre de ce projet. LOM donnait une taxinomie simple, et chaque profil pouvait définir la sienne; MLR donne une simple chaîne; etc. Dans un avenir éloigné, il sera possible de connecter les taxinomies entre elles et d'associer les chaînes aux taxinomies. Mais en attendant, nous devrons nous contenter de recherche plein-texte.

Du point de vue usager, quelles sont les requêtes plausibles qui ne se réduisent pas à une recherche plein texte? J'ai posé, lors d'une précédente rencontre, que la hiérarchie d'abstraction de ILOX était en partie étrangère aux usagers. En se basant sur les recherches de bibliothèques, les usagers recherchent une pièce répondant à certains critères, et s'attendent ensuite à voir une liste des différents exemplaires (items). Il faudrait aussi donner accès à des fiches connexes, autres réalisations, éventuellement versions et remix. Mais tout cela est en aval de la recherche, dans la représentation des résultats.

Les aspects de la recherche qui vont au-delà du plein-texte sont ceux relatifs à :

  1. la classification thématique
  2. Droits (à la fois comme filtre et comme objet de recherche)
  3. Le type de ressource
  4. Le type d'activité (qui dépend d'une taxinomie non-spécifiée dans la norme)
  5. Le niveau et la langue visée
  6. les compétences requises (idem)
  7. Les contributeurs à la ressource (personnes et organisations)
  8. Les contributeurs à la fiche (personnes et organisations)
  9. Les prérequis techniques
  10. L'évaluation moyenne

Notons que l'aspects le plus délicat au plan technique est celui des contributeurs à la fiche; il agit comme filtre personnel sur la structure de ce qui est recherché, plutôt que comme filtre sur un contenu fixe.

Dans la recherche plein-texte, incluons: titre et description, commentaires et annotations... couverture?

Graphiques des autres modèles conceptuels:

LOM

MLR et son impact sur le Metamodèle

La notion MLR d'EducationalOutcome est rattachée à la notion de compétence, hors champ pour MLR et probablement aussi pour COMETE. MLR y rattache les Assessments, qui devraient être des ressources de plein droit.

DublinCore

QUESTION/COMMENTAIRES

  • Donc si apres la moisson d'une fiche, on detecte une erreur dans un de ses elements VCard, selon ce modele si je comprends bien, au lieu de corriger la fiche directement, on devrait plutot generer une fiche de correction puis creer une relation liant la fiche moissonnee a la fiche de correction. C'est bien ca? Faudrait faire des tests de performance pour evaluer la faisabilite de ca. Faire une recherche SPARQL sur des fiches dynamique
  • On devrait illustrer ce modele avec un exemple concret comportant 2-5 fiches avec les formats de metadonnees qui nous interesse. Ca clarifierait, je crois, et ca permettrait peut-etre d'identifier des lacunes ou autres problemes.
  • Comment pense-t-on calculer la fiche MetadataView?? Quelles technologies imagine-t-on utiliser? XSLT pour appliquer des corrections et des aggregations (calculees avec des requetes SPARQL via le RDF), ou peut-etre plutot JDOM pour construire la fiche progressivement au fur et a mesure qu'on traverse le graphe des sous-fiches (pratique aussi peut-etre pour resoudre les valeurs heritees)? etc...
  • MA: Rendre plus explicite la notion de fiche composite. Également montrer que les Records de base sont des aggrégats fragmentaires. Enfin, monter que la composition se fait au niveau d'attributs-valeurs, généralement par simple remplacement. Expliciter les règles de composition. Relier à des cas d'utilisation.

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