Annexe
Stratégies de sémantification des données JSON

Obtention des données

Dans sa démarche OPEN DATA, le Ministère de l’Éducation Nationale, de l’Enseignement Supérieur et de la Recherche (MENESR) met à disposition sous licence libre, des jeux de données ouvertes dont un de ressources pédagogiques numériques contenant 33817 ressources pédagogiques accessibles par un moteur de recherche . Leurs fiches descriptives sont indexées en respectant les standards SupLOMFR .

Ces ressources sont mises à disposition dans l’entrepôt que nous avons analysé.

La page Web d’accès à cet entrepôt propose une liste de filtres (sur la colonne de gauche) afin de de cibler les résultats en fonction de critères. Ces filtres sont associables entre eux, le nombre de ressources correspondantes est affiché à côté du filtre.

L’onglet "Informations" de la zone principale de la page nous expose (en bas de page) le modèle de données. Nous allons étudier ce modèle.

Nous avons une longue liste de propriétés présentées par un libellé suivi d’une description qui s’avère n’être jamais disponible.

À chaque libellé, correspond un nom (identifiant), un type et un exemple qui n’est pas toujours fourni. Nous pouvons constater que les noms des propriétés commencent tous (à l’exception du premier) par le préfixe "lom" et sont construits comme une suite de mots séparés par des "_".

Le deuxième mot du nom correspond à un élément du SupLOMFR.

Pour certaines propriétés, les exemples fournis contiennent du texte avec des virgules qui ne sont pas suivies d’un espace contrairement à la norme typographique française. Certaines propriétés du SupLOMFR ayant une cardinalité N, nous en avons déduit que la virgule était le symbole de séparation de données multiples (il s’avérera dans les faits que d’autres symboles « séparateur » sont utilisés, les UNT ou les établissements ayant probablement choisi d’autres symboles que la virgule en fonction de leurs contraintes ou de leurs logiciels).

Les ressources pédagogiques, une fois filtrées sont téléchargeables sous 3 formats fichiers plats : CSV, JSON et Excel. Nous avons travaillé avec un fichier source contenant l’ensemble des 33817 ressources au format JSON qui est le plus adapté à un traitement informatique.

Les problématiques principales ont été que le fait que des données structurées dans des éléments liés entre eux, sur plusieurs niveaux et avec des cardinalités simple ou multiples sont diffusés à plat, que les symboles séparateurs ne sont pas toujours les mêmes d’un enregistrement à un autre pour des mêmes données, que des normes ne sont pas toujours respectées (code pour une langue, entre autres).

Les LangString

Champs associés n’ayant pas le même nombre de données et obligation de créer des LangString mono-langues.

D'après le SupLOMFR :

Ensemble de chaînes de caractères chacune étant exprimée dans une langue différente. (NF Z76-040) Un LangString est constitué d'un ensemble de couples : (langue, chaîne de caractères). Le sens de chaque chaîne est le même et chaque langue doit être différente. (NF Z76-040)

Par exemple :

{ ("fr" : "code"), ("en" :"code"), ("de" : "kode"), ("es" : "código")}

Dans SupLOMFR, le titre d’une ressource est de cardinalité 1 et au format LangString, ex. : titre : ("fre", "Bases de données relationnelles" "eng", "Relational Databases")

Dans le fichier JSON source, la propriété titre est éclatée sur 2 propriétés : lom_general_title_text et lom_general_title_language.

Par exemple : "lom_general_title_text":"Conférence de Herta Müller,Prix Nobel de littérature 2009 - 1ère partie" et "lom_general_title_language":"fre", une seule langue est fournie et le texte contient une virgule. Le titre ne devant contenir qu’une donnée par langue, nous sommes face à deux possibilités : le séparateur n’est pas le bon ou la donnée "lom_general_title_text" est erronée.

Après analyse des LangString présents dans les ressources, nous avons retenu que le séparateur de texte des LangString le plus couramment utilisé était le point directement suivi d’une virgule elle-même directement suivie par la donnée suivante (ex. : "fin de chaîne de caractères.,Début de chaîne de caractères").

Nous traitons donc les textes des LangString avec ce séparateur dans un premier temps en le confrontant au nombre de langues fournies dans la propriété associée, avec par contre la virgule comme séparateur pour ces dernières. Si les nombres sont différents, une seconde tentative est faite en utilisant la virgule comme séparateur de texte, car c’est souvent le cas pour les propriétés correspondant à des mots clés (lom_general_keyword_text et lom_general_keyword_language). Au final, si ces tentatives se montrent infructueuses, nous considérons que les données fournies ne sont pas cohérentes et la propriété n’est pas retenue. Ce qui génère une erreur, qualifiée de bloquante pour certaines propriétés ou mineure pour d’autres (cela sera détaillé dans une autre section).

Quand une propriété de langue fournit plusieurs langues, nous n’avons pas de garantie qu’elles indiquent que les textes trouvés en face sont des traductions d’un même texte dans ces langues. Nous avons donc créé des LangString ne contenant qu’une seule langue, mais cela n’a pas d’incidence sur les triplets RDF générés, à part que la cohérence sémantique n’est pas assurée.

Exemple de données que notre programme a rejeté :

lom_general_title_text:"ACVBAT ? Démarche d'analyse du cycle de vie. Principes,méthodologie,exemples d'application aux matériaux et éléments de construction,Life Cycle Assessment  Approach. Principle,Methodology and Examples concerning Building Materials and Components"

Les propriétés basées sur des vocabulaires

D'après le SupLOMFR :

C’est un type structuré constitué de deux composants : une source (identifiant d’un référentiel) et une valeur (prise dans ce référentiel). Un référentiel peut-être une liste recommandée de valeurs appropriées, un thésaurus... Pour permettre l’interopérabilité, il est déconseillé de choisir des valeurs en dehors d’un référentiel connu et partagé par une communauté la plus large possible. (NF Z76-040)

Nous n’avons pas vérifié la cohérence entre la valeur de la propriété et le référentiel attendu (« LOMv1.0 », « LOMFRv1.0 » ou « SupLOMFRv1.0 ») car cela n’a pas d’incidence sur la propriété qui sera générée dans les triplets RDF. Les données injectées en RDF qui ne seraient pas cohérentes avec les référentiels attendus ne ressortiraient pas si les requêtes SPARQL, elles, seraient cohérente avec les référentiels.

Par contre dans une certaine mesure, en considérant les valeurs issues de vocabulaires des filtres proposées sur l’entrepôt ou lors de nos tests, lorsque nous avons pu relever des valeurs ne correspondant pas exactement à un terme du vocabulaire, nous avons enrichi notre vocabulaire pour admettre ces valeurs en les mettant en correspondance avec le terme exact du vocabulaire.

Les exemples suivant correspondront chacun à un même terme du vocabulaire :

• « accessibility restriction », « accessibility restrictions » (avec un « s » à la fin),
• « isformatof », « is format of »,
• « contributeur », « contributor »

Sinon, nous avons rejeté la propriété.

Les propriétés liées entre elles sur plusieurs niveaux avec des cardinalités multiples

L’élément Relation du SupLOMFR

Une ressource pédagogique peut avoir N relations avec d’autres ressources pédagogiques. Chacune des N relations est caractérisée par 1 type de relation avec 1 ressource, cette dernière pouvant avoir N’ identifiants, et N’’ descriptions.

Dans le fichier JSON source, les propriétés correspondantes sont :

• lom_relation_kind_source référentiel du vocabulaire
• lom_relation_kind_value nature de la relation, vocabulaire
• lom_relation_resource_identifier_catalog nom du catalogue où la ressource est stockée. (source : LOMFR NF Z76-040)
• lom_relation_resource_identifier_entry valeur de l’identifiant dans le catalogue
• lom_relation_description_language langue dans le LangString de la description de la ressource « destination »
• lom_relation_description_text texte dans le LangString de la description de la ressource « destination »

Ne pouvant pas déduire les valeurs de N’ et N’’, nous avons pris le parti de postuler que N = N’ = N’’, c’est-à-dire que pour la ressource donnée chaque ressource en relation avait un identifiant et une description.

Au final sur les 33817 ressources, 20163 ont un champ lom_relation_resource_identifier_entry, les différences avec le nombre de relations sont de 591 pour les types de relation et 1144 pour le nombre de descriptions.

L’élément Contribution (cycle de vie) du SupLOMFR.

Une ressource pédagogique peut avoir N contributions. Chaque contribution a un rôle (tiré d’un vocabulaire), N’ entités (Vcard) et une date.

S’il n’y a qu’un seul rôle et une seule date (c'est-à-dire une seule valeur pour lom_lifecycle_contribute_role_value et lom_lifecycle_contribute_date, le séparateur étant considéré être la virgule) et au moins une entité, nous ajoutons cette contribution avec ces entités.

Si les nombres de rôles, entités et dates sont identiques, nous considérons qu’il y ce nombre de contributions, chacune ayant une seule entité.

Sinon, nous ne pouvons pas savoir comment ventiler les entités sur les contributions. De même, même si les nombres de rôles et de dates sont égaux et supérieurs à un et que le nombre d’entités est supérieur à zéro mais différent des deux autres propriétés, comment ventiler les entités ?

L’élément Classification

D'après le SupLOMFR :

Cette catégorie est obligatoire : il doit y avoir pour la ressource au moins une occurrence correspondant à la classification décimale et internationale Dewey (Dewey Decimal Classification ou DDC).

Le fichier source JSON nous fournit en dur les données pour les chemins taxon dont les sources sont la CDD, Rameau et UNIT, par les champs lom_classification_CDD_xxx, lom_classification_Rameau_xxx et lom_classification_UNIT_xxx.

Pour chacune de ces trois sources de classification, il nous est donné dans les champs suffixés _value la donnée « Objectif » (purpose), D'après le SupLOMFR : « La classification Dewey correspond au terme "discipline" » D'autres référentiels comme Rameau, MeSH, TermSciences correspondent au terme "notion"

Donc, normalement nous devrions avoir systématiquement pour lom_classification_cdd_value la valeur « discipline » mais il a fallu gérer des valeurs comme celle-ci : "lom_classification_cdd_value":"security level,discipline,idea", nous avons donc juste vérifié que cette donnée contenait bien la valeur "discipline", vu que la cardinalité de cette donnée est 1.

Les données lom_classification_xxx_text correspondent à TaxonPath.Taxon.Entry de SupLOMFR qui sont des LangString. Pour la CDD, il y a deux champs notables qui sont lom_classification_cdd_text_fre et lom_classification_cdd_text_eng qui correspondent donc aux valeurs en français et en anglais du LangString, c’est la seule donnée où la structure du LangString a réellement pu être exploitée.

Pour les classification Rameau et Unit nous avons automatiquement ajouté l’attribut de langue @fr pour les TaxonPath.Taxon.Entry.