Volume 17, 2010
Rubrique

Métadonnées pour ressources d’apprentissage (MLR) -
Nouvelle norme ISO de description de
ressources pédagogiques

Yolaine Bourda (Supélec, Gif-sur-Yvette), Gilles Gauthier (UQAM, Montréal), Rosa-Maria Gomez de Regil (CNDP, Poitiers), Olivier Catteau (IRIT, Toulouse)

RÉSUMÉ : Cet article présente la nouvelle norme ISO de description de ressources pédagogiques et plus particulièrement sa partie 1 qui décrit la façon de spécifier les éléments de données ainsi que les profils d’application.

MOTS CLÉS : métadonnées, ressource pédagogique, standard, norme.

ABSTRACT : This paper presents the new ISO Standard for the description of learning resources and more particularly it’s part 1 that describes how to specify data elements and application profiles.

KEYWORDS : metadata, learning resource, standard.

• Introduction
• 1. Présentation générale du MLR
• 2. La partie 1 du MLR : la charpente ou cadre général
• 3. Conclusion
• 4. Remerciements
• 5. Bibliographie

Introduction

Le 15 janvier 2011, une nouvelle norme ISO vient de sortir : la norme « ISO/CEI 19788-1 Technologies de l'information – Apprentissage, éducation et formation – Métadonnées pour ressources d'apprentissage – Partie 1: Charpente ».¹ C’est la première de la série 19788 de normes de description de ressources pédagogiques, série connue sous le nom de MLR (Metadata for Learning Resources). Cette norme a été élaborée au sein de la commission de normalisation internationale « ISO/CEI JTC1 SC36 Technologies pour l’apprentissage, l’éducation et la formation» et plus particulièrement de son groupe de travail « WG4 Management and delivery of learning, education and training »².

Les utilisateurs du LOM (Learning Object Metadata), le standard de l’IEEE (IEEE-LTSC, 2002) actuellement largement utilisé, rencontrent de nombreuses difficultés. Parmi celles-ci, on peut citer (de façon non-exhaustive) :

- l’incompatibilité entre eux des nombreux profils d’application basés sur le LOM (Bourda et Delestre, 2005) ;

- une structure figée, sous forme d’arbre (le célèbre tableau du LOM contenant tous les éléments), bien adaptée à une implémentation en XML ou dans une base de données centralisée mais difficilement exprimable dans les langages du Web sémantique, tels que RDF (W3C, 2010a) ou OWL (W3C, 2010b) ;

- une structure plus adaptée à des entrepôts centralisés qu’au monde décentralisé qui est le nôtre aujourd’hui, bien que les ressources pédagogiques soient librement réparties sur le Web, leurs descriptions restent centralisées ;

- le mélange des descriptions :

• de la ressource elle-même et des personnes ayant contribué à celle-ci ; ainsi si une personne contribue à 2 ressources, on aura duplication de la description de cette personne avec tous les problèmes posés par la redondance des informations ; ce problème se rencontre aussi si une même personne a contribué plusieurs fois à la même ressource avec des « casquettes » différentes ;

• de la ressource elle-même et de la description de cette description (catégorie meta-metadata du LOM) ;

- la gestion des vocabulaires ;

- l’ambigüité de certains éléments (dont l’élément 5.2 Learning Resource Type qui mélange les types pédagogiques et documentaires) ;

- une prise en charge incomplète du cycle de vie de la ressource pédagogique et de ses métadonnées (Catteau et al., 2007) ;

- la difficulté de prendre en compte différents formats (pdf, html, epub, word...) pour le « même contenu pédagogique » ;

- ...

Le MLR a comme objectifs, en plus de pallier les difficultés présentées ci-dessus, de pouvoir :

- prendre en compte le multilinguisme et le multiculturalisme ;

- permettre des extensions selon les besoins des utilisateurs (faciliter la construction de profils d’application et la gestion des vocabulaires) ;

- être indépendant de toute mise-en-œuvre informatique et donc permettre des « implémentations » utilisant des technologies différentes : bases de données relationnelles, fichiers XML, langages du Web sémantique (RDF(S), OWL)...

- être compatible avec le IEEE-LOM (standard IEEE 1484.12.1-2002, IEEE-LTSC, 2002) et le Dublin Core (en tant que norme ISO 15836:2009, ISO, 2009), c’est-à-dire pouvoir récupérer des descriptions reposant sur ces deux schémas et les transformer en descriptions conformes au MLR.

De notre point de vue, les objectifs précédents sont soit atteints soit pourront l’être dans les différentes parties du MLR non encore finalisées. Nous donnons dans le texte des indications sur les problèmes résolus.

La suite de l’article est organisée de la façon suivante : la section 2 est une présentation générale du MLR et de ses différentes parties, puis la section 3 présente de façon détaillée la partie 1 du MLR.

1. Présentation générale du MLR

Avant de détailler les différentes parties du MLR, nous décrivons brièvement le processus de normalisation suivi par l’ISO.

1.1. Processus de normalisation

La norme ISO MLR est le fruit de plusieurs courants d’influence provenant de groupes d’utilisateurs, d’organismes de standardisation et de normalisation. Historiquement, il faut citer le Dublin Core qui s’attache à la description de ressources numériques ou physiques. Le projet européen ARIADNE a permis de compléter la description en s’attachant particulièrement aux ressources pédagogiques dans le but d’en favoriser le partage et la réutilisation. En 2002, ces travaux aboutissent au standard IEEE LOM. Pour répondre aux besoins spécifiques des utilisateurs, des profils d’applications voient le jour comme par exemple le LOM-FR en France ou Normetic au Québec. Les personnes désirant en savoir plus sur les différents standards, ainsi que sur leur historique, concernant les ressources pédagogiques pourront se reporter à (Pernin, 2006).

Le processus d’adoption d’une nouvelle norme se fait par consensus de ses 163 membres nationaux. Etablir une nouvelle norme ISO prend du temps. En effet, le comité technique ISO JTC1/SC36 a été créé en 1999. Pas moins de 6 étapes sont nécessaires avant d’arriver à la version finale:

- Proposition d’étude nouvelle (NP ou New Project);

- Projet(s) de travail (WD ou Working Document) : brouillon(s) préliminaire(s) pour discussion au sein du groupe de travail ;

- Projet(s) de comité (CD ou Committee Draft) : brouillons complets soumis au vote et aux commentaires techniques des comités nationaux participant au comité technique impliqué dans l’élaboration de la norme ;

- Projet de norme internationale (DIS ou Draft International Standard) : le texte final soumis au vote et aux commentaires à l’ensemble des comités nationaux de l’ISO ;

- Projet final de norme internationale (FDIS ou Final Draft International Standard) : adoption finale du texte prévu pour la publication par l’ensemble des comités nationaux de l’ISO ;

- Norme internationale (IS ou International Standard) : la norme publiée.

1.2. Les différentes parties du MLR

Le MLR est une norme en plusieurs parties, certaines spécifient des éléments de données, d’autres des profils d’application, d’autres encore des bindings... Toutes les parties sont rédigées en anglais mais, par conception, les aspects nécessaires à l’implémentation de la norme ne dépendent pas de l’anglais (ni d’aucune autre langue).

Les parties actuellement terminées ou en cours de développement du MLR, mais dont le niveau de maturité est variable, sont les suivantes :

- Partie 1³ : Charpente (Framework)

Cette partie, publiée en tant que norme ISO depuis le 15 Janvier 2011, définit la philosophie générale du MLR, ce qu’est un élément de données et comment le spécifier, comment définir des classes de ressources, des profils d’application... Elle ne spécifie aucun élément de données. Elle est une fondation, non seulement pour les autres parties du MLR mais aussi pour les communautés souhaitant disposer d’un cadre bien défini pour spécifier leurs profils d’application.

- Partie 2 : Éléments « Dublin Core » (Dublin Core elements)

Cette partie spécifie chacun des éléments de données du Dublin Core (norme ISO 15836:2009, ISO, 2009) sous forme de spécifications d’éléments de données conformément à ce qui est défini dans la partie 1 du MLR. Elle en est à un stade quasi final (étape FDIS) et devrait être publiée à l’automne 2011.

- Partie 3 : Profil d’application de base (Basic application profile)

Cette partie définit un profil d’application basé sur la partie 2. Elle ajoute quelques contraintes aux éléments de la partie 2, elle reflète les pratiques actuelles des communautés « Dublin Core » (ISO, 2009) et « IEEE-LOM » (IEEE-LTSC, 2002) et elle prend en compte l’étude effectuée sur les éléments de données fréquemment utilisés (ISO, 2005). Elle pourra aussi servir d’exemple aux personnes désirant définir leur propre profil d’application. Elle va passer très prochainement au stade FDIS. Les parties 2 et 3 permettent de faire le lien entre le MLR et le Dublin Core. De la même façon, une partie, non encore votée, portera sur l’expression du LOM en tant que profil d’application du MLR.

- Partie 4 : Éléments techniques (Technical elements)

Cette partie contient les spécifications des éléments de données permettant de décrire des informations de type technique. Actuellement au stade WD elle devrait être publiée en 2012.

- Partie 5 : Éléments pédagogiques (Educational elements)

Cette partie est la plus importante en termes d’attente de description d’une ressource d’apprentissage car elle contient les spécifications des éléments de données permettant de décrire des informations de type pédagogique. Actuellement au stade CD, elle devrait être publiée début 2012.

- Partie 6 : Éléments de disponibilité, distribution, et de propriété intellectuelle
(Availability, distribution, and intellectual property elements)

Cette partie contient les spécifications des éléments de données permettant de décrire des informations de type propriété intellectuelle. Elle en est au stade CD et devrait être publiée en 2012.

2. La partie 1 du MLR : la charpente ou cadre général

Cette section de l’article qui présente la partie 1 du MLR n’est en aucun cas une traduction officielle de la norme anglaise mais une explication de son contenu en français rédigée par des francophones ayant participé à son élaboration. Pour mettre en évidence le fait que les spécifications d’éléments de données et de profils d’applications sont avant tout destinées à des utilisations par des êtres humains (l’utilisation par des ordinateurs sera précisée dans les bindings), nous avons choisi de les exprimer en privilégiant la langue de l’utilisateur donc, en ce qui nous concerne, le français.

Dans le cadre du MLR, un élément de métadonnées est défini comme un élément de données utilisé pour décrire une ressource pédagogique. L’élément de données quant à lui est défini comme étant une unité d’information décrite à l’aide d’une spécification d’élément de données.

Il n’existe pas d’éléments de données structurés ni de catégories dans le MLR, chaque élément de données est donc un élément « simple ». Ceci entraîne que la traduction dans les langages du Web sémantique sera quasi immédiate et que la répartition des descriptions des ressources pédagogiques pourra se faire naturellement dans ce cadre.

2.1. Spécification d’un élément de données

Tout élément de données qui sera utilisé doit être spécifié soit dans une partie du MLR spécifiant des éléments de données (comme les parties 4 ou 5 qui traiteront des descriptions techniques et pédagogiques) soit dans une partie du MLR décrivant des profils d’application⁴ (comme la partie 3). Pour cela, un ensemble d’attributs, communs à toutes les spécifications des éléments de données⁵, doivent être renseignés. La partie 1 du MLR prévoit une présentation sous forme de tableau (cf. tableau 1) de l’ensemble de ces attributs. La spécification précise de chaque élément de données permet d’éviter l’ambigüité d’éléments comme le 5.2 Learning Resource Type du LOM.

Les personnes familières avec le LOM, noteront la présence d’attributs supplémentaires tels que « Domaine » ou « Image» mais aussi quelques attributs manquants comme un indicateur de présence ou de répétition. Ces derniers seront précisés au moment de la définition des profils d’application.

Tableau 1 • Spécification d’un élément de données

2.1.1. Identifiant

Cet attribut est obligatoire et il contient l’identifiant de l’élément de données. Cet identifiant est unique, linguistiquement neutre et construit en suivant des règles strictes proposées dans la partie 1 du MLR. Quelques exemples de valeurs possibles : ISO_IEC_19788-2:2010::DES0100 (spécification de l’élément de données 100 de la partie 2 du MLR édition 2010), ISO_IEC_19788-5:2011::DES0800 (spécification de l’élément de données 800 de la partie 5 du MLR édition 2011). Il sera possible de construire canoniquement une URI à partir de chacun de ces identifiants.

2.1.2. Nom de la propriété

Cet attribut est obligatoire. Il peut être exprimé en plusieurs langues. Ainsi, au sein du MLR, les noms de propriétés devraient être donnés, au moins, en anglais, français et russe (les 3 langues officielles de l’ISO). D’autres langues pourront aussi être utilisées si les organismes nationaux fournissent la traduction correspondante.

2.1.3. Définition

Cet attribut est obligatoire, sa valeur contient un énoncé descriptif qui permet de différencier l’élément de données spécifié des autres éléments de données.

2.1.4. Indicateur linguistique

Cet attribut est obligatoire, ses valeurs possibles sont « linguistique » ou « non-linguistique ». La valeur « linguistique » indique que l’élément de données contiendra des valeurs qui, par nature, dépendent d’une langue. Des éléments de données comme un titre, une indication d’utilisation sont exprimées dans une langue et sont donc linguistiques. La valeur « non-linguistique » indique que l’élément de données contiendra des valeurs indépendantes de toute langue. Des éléments de données comme une taille, une date ou un format sont non-linguistiques.

2.1.5. Domaine

Cet attribut est obligatoire et il contient l’identifiant d’une classe de ressources, celle à laquelle peut s’appliquer l’élément de données. L’existence de cet attribut permet de prendre en compte différentes classes de ressources (ex : Ressource pédagogique, Contributeur, Audience...) chacune ayant ses propres propriétés.

2.1.6. Image

Cet attribut est obligatoire et contient les valeurs possibles que peut prendre cet élément de données. Les valeurs possibles pour cet attribut sont soit l’identifiant d’une classe de ressources, soit la valeur « littéral » pour un ensemble de littéraux (c’est-à-dire de valeurs telles que des chaînes de caractères, des dates, des nombres...). Par exemple, un élément de données dont le nom est « a comme contributeur » pourra avoir pour domaine la classe « Ressource pédagogique » et pour image la classe « Contributeur », cette classe pouvant elle-même être le domaine d’autres spécifications d’éléments de données tels que le rôle, le nom et l’organisation du contributeur. Comme autre exemple, nous pouvons citer la spécification de l’élément de données « Titre » dont l’attribut image pourra prendre la valeur littéral. L’existence de cet attribut permet d’éviter le mélange des descriptions et la duplication de celles-ci (cas, par exemple, d’un auteur ayant participé plusieurs fois à une même ressource).

2.1.7. Règles de contenu

Cet attribut est conditionné à la valeur de l’élément « Image». Si celle-ci est « littéral » alors cette valeur devient obligatoire et est fournie sous forme d’un ensemble de règles décrivant les valeurs que peut prendre l’élément de données. On peut avoir, par exemple, comme valeurs: « une date au format ISO 8601:2004 », « un type MIME »... Quelques ensembles prédéfinis de règles, ceux qui ont été identifiés comme devant servir fréquemment (comme une date, une durée...) sont fournis dans la partie 1.

2.1.8. Raffine

Cet attribut est conditionnel. Dans le cas ou un élément de données raffine un autre élément de données, cet attribut contient l’identifiant de l’élément raffiné. Ainsi, si un élément de données « créateur » raffine un élément de données « contributeur », dans l’attribut raffine de l’élément de données « créateur » on aura l’identifiant de l’élément de données « contributeur ».

2.1.9. Exemples(s)

Cet attribut est optionnel et sert à fournir des exemples. Il peut être exprimé en plusieurs langues.

2.1.10. Note(s)

Cet attribut est optionnel et peut contenir des informations complémentaires relatives à l’élément de données. Il peut être exprimé en plusieurs langues.

2.2. Classes de ressources

Une classe de ressources est un ensemble de ressources dont la structure et le comportement suivent les mêmes règles. La partie 1 du MLR fournit un ensemble limité de classes de ressources  prédéfinies : les classes « Ressource », « Ressource d’apprentissage » (français du Québec pour Learning Resource) ou « Ressource pédagogique » (français de France pour Learning Resource), « Personne » et précise comment définir de nouvelles classes de ressources. Cela se fait en remplissant un tableau, comme l’exemple suivant qui définit la classe « Ressource d’apprentissage» (cf. tableau 2).

Tableau 2 • Définition de la classe de ressource « Ressource d’apprentissage »

2.3. Exemple

L’exemple ci-dessous présente l’élément de données « format» tel qu’il est défini dans la partie 3 du MLR accompagné de son ensemble de règles de contenu (RS_DES0004) qui fait partie intégrante de la spécification de cet élément de données. En effet, son image ayant comme valeur littéral, il faut expliciter par un ensemble de règles les valeurs possibles que pourra prendre l’élément de données. L’élément de données spécifié dans le tableau 3 raffine un autre élément de données format défini dans la partie 2 du MLR. Le raffinement consiste, dans ce cas, à imposer que le contenu de cet élément de données ait comme valeur un type « MIME».

Tableau 3 • Spécification de l’élément de données « format »

2.4. Elément de données MLR

Un élément de données est une entité constituée de 3 ou 4 parties, elle a l’une ou l’autre des formes suivantes : <DES, sujet, contenu> ou <DES, sujet, contenu, langue> dans lesquelles :

- DES : identifiant d’une spécification d’élément de données (celle de l’élément) ;

- sujet : l’identifiant de la ressource décrite qui doit appartenir au domaine précisé dans la spécification de l’élément de données ;

- contenu : l’information enregistrée comme le contenu de l’élément (sa valeur) qui doit appartenir à l’image précisée dans la spécification de l’élément de données ;

- langue : code de la langue (issu de la norme ISO 639-3) si la valeur de l’élément est linguistique.

Exemple : <ISO_IEC_19788-3:2010::DES0300, http://www.sticef.org, text/html>
L’élément ISO_IEC_19788-3:2010::DES0300 a été spécifié dans la partie 3 du MLR comme étant la description du format de la ressource pédagogique. Cet élément a pour sujet la ressource pédagogique dont l’identifiant est http://www.sticef.org/ et pour contenu la valeur text/html.

2.5. Spécification d’un profil d’application

Dans la philosophie du MLR, le passage par les profils d’application permet de répondre aux besoins d’une communauté. C’est dans la spécification d’un profil d’application que l’on décrit les éléments de données utilisés, leur regroupement, leur ordre ainsi que leur présence, leur répétition... Avant de définir ce qu’est un profil d’application, nous allons définir ce que sont des groupes d’éléments.

2.5.1. Groupes d’éléments de données

Un groupe d’éléments de données est un ensemble identifié d’éléments de données ou de groupes d’éléments de données, il est décrit dans une spécification d’un groupe d’éléments de données⁶ (cf tableau 4) ;

Tableau 4 • Spécification d’un groupe d’éléments de données

L’identifiant du groupe d’éléments de données est obligatoire et peut-être soit une URI, soit un identifiant construit selon les règles de construction des identifiants du MLR. Le nom ainsi que la description sont obligatoires.

La spécification d’un groupe d’éléments de données est un regroupement constitué de spécifications d’éléments de données et de spécifications de groupes d’éléments de données. Pour chacun d’eux, il faut préciser les éléments suivants :

- « position » : un nombre indiquant la position de cet élément (ou groupe d’éléments) dans le groupe ;

- « identifiant » : soit un identifiant de la spécification d’un élément de données (Identifiant_DES) soit un identifiant de la spécification d’un groupe d’éléments de données (Identifiant_DEGS) ;

- « nom » : le nom de l’élément de données ou du groupe d’éléments de données ;

- « indicateur du type de présence » : un indicateur de présence qui peut prendre les valeurs suivantes : « obligatoire », « conditionnel » ou « facultatif » ; quand la valeur est « conditionnel », l’identifiant d’une règle exprimant les conditions doit être fourni ;

- « indicateur de répétition » : un indicateur de répétition qui peut prendre les valeurs suivantes « répétable », « non répétable » ; on peut aussi, si nécessaire, préciser le nombre minimum ou maximum d’occurrences possibles ;

- « indicateur d’ordre » : un indicateur d’ordre qui doit être renseigné quand l’élément (ou le groupe d’éléments) est répétable ; les valeurs suivantes sont possibles : « ordonné » et « non ordonné » ;

- « sémantique de la relation d’ordre » : la sémantique de la relation d’ordre qui doit être renseignée quand l’élément (ou le groupe d’éléments) est ordonné, l’expression de cette sémantique se fait alors d’une façon quelconque : phrase, expression mathématique...

Tableau 5 • Exemple de spécification d’un groupe d’éléments de données

Le tableau 5 présente le début de la spécification d’un groupe d’éléments de données devant constituer un profil d’application de base suggéré pour le MLR (parties 2 et 3 du MLR) accompagné de ses règles explicitant les conditions.

2.5.2. Profil d’application

Un profil d’application est une collection structurée de spécifications d’éléments de données issues de différentes parties du MLR ou d’autres sources et choisies pour répondre aux besoins d’une communauté. Un profil d’application peut aussi spécifier des éléments de données mais ils seront alors considérés comme locaux à ce profil d’application et ne pourront pas être utilisés à l’extérieur de celui-ci.

Il est possible, dans un profil d’application, pour un élément de données dont les valeurs permises sont celles issues d’un « vocabulaire », de restreindre celui-ci ou, au contraire, de l’étendre.

Un profil d’application est constitué d’un groupe d’éléments de données sous-jacent. La spécification d’un profil d’application se fait en renseignant les informations du tableau 6 que nous illustrons en prenant pour exemple le profil d’application québécois Normetic v2.0 en cours de développement.

Tableau 6 • Spécification d’un profil d’application

3. Conclusion

Fruit d’un long processus d’adoption par consensus, la nouvelle norme de description des ressources pédagogiques MLR repose sur deux standards largement adoptés que sont le « Dublin Core » et le LOM. Cette norme a pour objectifs de pallier les difficultés rencontrées jusqu’à maintenant en termes de description de ressources pédagogiques mais également de prendre en compte le multilinguisme et le multiculturalisme, de mieux répondre aux besoins des utilisateurs et d’être indépendante de toute mise-en-œuvre informatique. La norme se décompose en plusieurs parties. La partie 1, récemment adoptée, définit la charpente du MLR et a largement été décrite dans cet article. Elle montre en outre que le MLR fait la différence entre la spécification d’éléments de données, spécification qui peut-être partagée par de nombreuses communautés, et leur utilisation pour une communauté particulière par la définition d’un profil d’application. Les parties 2 et 3 du MLR, reprenant les éléments du « Dublin Core » devraient être adoptées au cours de cette année 2011. Il faudra toutefois patienter (probablement jusqu’en 2012) pour voir l’adoption des parties suivantes avec ce qui sera certainement la partie plus attendue : celle concernant les éléments pédagogiques.

La majorité des objectifs que s’est assigné le MLR sont soit atteints soit le seront dans les différentes parties en cours de préparation, qu’elles soient votées ou non, comme la partie sur les bindings qui permettra la mise-en-œuvre du MLR dans le cadre du Web sémantique, ou les compléments explicitant la description de vocabulaires (éventuellement sous forme de taxonomies).

Le MLR est une norme dont la première partie a été publiée le 15 janvier 2011 et dont les autres sont en cours d’élaboration. Les québécois sont les premiers à mettre en œuvre la partie 1 du MLR, en définissant actuellement la version 2 de Normetic⁷ comme un profil d’application du MLR. Il est impossible, à l’heure actuelle, d’avoir un véritable recul et de pouvoir faire une analyse critique du MLR, mais nous sommes persuadés que son usage mettra en évidence les progrès accomplis.

4. Remerciements

Nous tenons à remercier chaleureusement tous nos collègues des groupes de travail « nationaux » (canadiens et français) qui ont participé à ces travaux ainsi qu’à tous les participants du groupe de travail WG4 de la commission SC36 au sein de laquelle ces normes sont élaborées.

5. Bibliographie

BOURDA Y., DELESTRE N. (2005) Améliorer l'interopérabilité des profils d'application du LOM. Revue STICEF, Vol.12, 15 pages, ISSN : 1764-7223, mis en ligne le 20/10/2005, http://sticef.org

CATTEAU O., VIDAL P., BROISIN J., « Gestion du cycle de vie au sein du LOM et de ses profils d’application », Actes de la conférence TICE 2006, ISBN : 978-2-9527275-0-1

Dublin Core Metadata Initiative, “Memorandum of Understanding between the Dublin Core Metadata Initiative and the IEEE Learning Technology Standards Committee”, 2000, disponible sur Internet : http://dublincore.org/documents/2000/12/06/dcmi-ieee-mou/ (consulté le 8 mars 2011).

IEEE-LTSC, “1484.12.1-2002 IEEE Standard for Learning Object Metadata”, 2002, 40p., ISBN: 0-7381-3297-7

International LOM Survey: Report document ISO/IEC JTC1/SC36 N0871 Use Cases for Metadata for Learning Resources

ISO, “ISO 15836:2009, Information et documentation – L’ensemble des éléments de métadonnées Dublin Core”, 2009.

PERNIN J.-Ph (2006). « Normes et standards pour la conception, la production et l'exploitation des EIAH ». Environnements informatiques pour l'apprentissage humain (Traité IC2, série Cognition et traitement de l'information), sous la direction de GRANDBASTIEN M., LABAT J-M. Hermès/lavoisier. ISBN : 2-7462-1171-8.

W3C, “Resource Description Framework (RDF)”, 2010, disponible sur Internet: http://www.w3.org/RDF/ (consulté le 10 Mars 2011).

W3C, “Web Ontology Language (OWL)”, 2010, disponible sur Internet: http://www.w3.org/2001/sw/wiki/OWL (consulté le 10 Mars 2011).

¹ Cette norme est en anglais, et son titre anglais est « ISO/IEC 19788-1 Information technology – Learning, education and training – Metadata for learning resources – Part 1: Framework ». Charpente est le terme français, choisi par l’ISO, pour Framework.

² Gilles Gauthier est l’animateur de ce groupe de travail.

³ Yolaine Bourda est co-éditrice de la partie 1 du MLR.

⁴ Ces dernières spécifications ne sont alors pas réutilisables dans d’autres parties du MLR.

⁵ En anglais, une spécification d’éléments de données est désignée par le terme Data Element Specification ou DES (nous avons choisi de garder l’acronyme).

⁶ En anglais, une spécification d’un groupe d’éléments de données est désignée par le terme Data element group specification ou DEGS (nous avons choisi de garder l’acronyme).

⁷ Profil québécois du LOM développé par le groupe de travail sur les normes (GTN) du Québec. Pour plus d’informations, voir soit www.normetic.org soit www.gtn-quebec.org.