Dans le premier projet LOFAR l'offre de formation utilisée par le moteur de recherche était celle du département ASI de l'INSA Rouen Normandie. Dans ce second projet nous avons voulu étendre cette offre de formation à celle d'un établissement, en l'occurrence celle de l'INSA Rouen Normandie.
Nous allons voir dans cette partie comment nous avons sémantifié cette offre de formation afin qu'elle puisse être utilisée par le moteur de recherche.
L'organisation pédagogique des INSA
Les INSA sont des écoles publiques qui délivrent des diplômes d'ingénieurs. Un étudiant diplômé d'un INSA, par exemple l'INSA Rouen Normandie, est diplômé pour une spécialité donnée, par exemple la spécialité Architecture des Systèmes d'Information. Les départements de spécialité sont les entités administratives qui gèrent au moins une spécialité. Ces départements, pour l'obtention d'un diplôme, proposent au moins un parcours pédagogique. Un parcours est composé de six semestres consécutifs, que l'étudiant doit tous valider. La validation d'un semestre nécessite la validation des Unités d'Enseignement (UE) qui le compose. Chaque UE étant elle même composée d'Éléments Constitutifs (EC). Ces EC peuvent être des cours classiques, des cours en blended learning, en e-learning, des projets ou des stages. Enfin chaque EC est constitué d'Actes Pédagogiques (AP) qui peuvent être des cours magistraux, des travaux tutorés, des travaux pratiques, du tutorat, etc.
Il est à noter que cette organisation pédagogique est sensiblement la même dans tout établissement de l'enseignement supérieur, puisqu'elle a été en partie définie par le traité de Bologne sur l'enseignement supérieur européen avec le système LMD. Ainsi les systèmes d'information de gestion des établissements de l'enseignement supérieur adoptent cette organisation. Mais qu'est-ce-qu'un Système d'Information dans ce contexte ?
Les Systèmes d'Information des établissements de l'enseignement supérieur
Un Système d'Information (SI) est un ou plusieurs logiciels qui servent à gérer un établissement ou une de ces composantes. Pour l'enseignement supérieur cette gestion comprend par exemple :
- la description de l'organisation pédagogique (diplôme, parcours, semestre, UE, EC, AP);
- la gestion des inscriptions des étudiants (au niveau de l'établissement, au niveau des départements, au niveau des EC);
- la gestion des notes des étudiants;
- la gestion des services des enseignants;
- la gestion des emplois du temps (des enseignants, des étudiants, des salles);
- etc.
Dans le cadre de notre projet, il faut donc extraire les informations qui décrivent l'offre de formation, mais cette action induit deux problèmes majeurs qui rendent cette tâche difficile :
- Comme nous venons de le voir, les établissements de l'enseignement supérieur français bien qu'adoptant tous peu ou prou cette organisation ont chacun leurs particularités. Les SI qu'ils utilisent, bien que paramétrables, ne sont pas exactement adaptés à tous les établissements. Ainsi, alors qu'une grande partie des informations renseignées sont structurées, certaines le sont moins, les utilisateurs détournant le rôle de certaines zones de saisie pour signifier une information non prévue.
- Dans la plupart des cas l'accès à ces informations par
une application externe n'est pas prévu. Deux cas sont
envisageables :
- exporter ces informations dans un format reconnu. Dans le cadre des offres de formation, il s'agit du CDM-fr. Mais comme nous l'avions montré dans le premier projet (dans l'article Une ontologie OWL pour le CDM-fr), les données générées par les SI sont déstructurées, et il est pratiquement impossible de les restructurer;
- accéder directement à la base de données qui stocke ces informations. Cela permet d'accéder à des informations natives et à jour. Pour des questions de sécurité, le périmètre des informations accessibles doit être déterminé et l'accès doit être en lecture seule. Ces deux contraintes peuvent être réalisées par le développement de vues.
Ainsi la sémantification des offres de formations d'un établissement d'enseignement supérieur nécessite un développement ad hoc d'un logiciel qui d'une part accède aux données et d'autres part les interprète en les adaptant si nécessaire.
Le logiciel ontop
Dans ce projet plutôt que de développer un logiciel à partir de rien, nous avons utilisé la plateforme open source Ontop pour générer nos triplets RDF.
Comme l'indique la vidéo de Mariano Rodriguez Muro, la plateforme permet de créer un mapping entre une base de données relationnelle (à partir des tables ou de vues) vers une représentation sous forme de triplets RDF, qui sont interrogeables à l'aide d'une entrée SPARQL. Ontop a deux caractéristiques très intéressantes :
- le mapping, que l'on peut créer facilement à l'aide d'un plug-in pour le logiciel protégé, est réalisé en exprimant les triplets RDF à l'aide de requête SQL.
- l'ensemble est dynamique, toutes nouvelles données insérées dans la base de données relationnelle est récupérable à l'aide des requêtes SPARQL.
Les vues SQL
Le premier travail réalisé a donc été la création des vues SQL sur les données du SI. La difficulté ici est que ces vues, bien qu'étant un modèle physique, doivent être proches d'un modèle conceptuel afin d'être indépendantes du modèle physique sous-jacent, et donc du SI. Nous avons utilisé les vues proposées par la figure suivante :

On retrouve dans ce schéma l'organisation décrite dans la première section. À cette organisation s'ajoute la gestion des chaînes de caractères linguistiquement étiquetées telles que les titres ou les descriptions.
Le mapping
À partir des précédentes vues, il est possible de définir des triplets RDF. Plus exactement à des catégories de triplets RDF correspond une requête SQL. Par exemple, le code suivant décrit les triplets décrivant une personne :
mappingId Person target :Person#{ID} a sch:Person, foaf:Person ; sch:familyName {NOM}^^xsd:string ; sch:givenName {PRENOM}^^xsd:string ; sch:name "{PRENOM} {NOM}"^^xsd:string ; sch:email {COURRIEL}^^xsd:string ; foaf:name "{PRENOM} {NOM}"^^xsd:string ; foaf:mbox <mailto:{COURRIEL}> . source select distinct PERS_ID as ID, PRENOM, NOM, COURRIEL from PERSONNE
Pour chaque personne de la
vue PERSONNE
correspond sept triplets RDF
dont la source a pour URI :Person
suivi de
l'identifiant de la personne :
a sch:Person
qui indique que l'URI est une instance de la classesch:Person
;sch:familyName
qui indique le nom de famile;sch:givenName
qui indique le prénom;sch:name
etfoaf:name
qui indiquent le nom (pour nous français le prénom suivi du nom de famille);sch:email
etfoaf:mbox
qui indiquent l'adresse email.
Des données interrogeables
Une entrée SPARQL, dont l'URL est
http://linkeddata.insa-rouen.fr/OffreFormationINSARouen/sparql/,
permet d'interroger ces données. Nous proposons aussi un
formulaire Web permettant de tester des
requêtes http://linkeddata.insa-rouen.fr/OffreFormationINSARouen/query/. Voici
un exemple de requête, le titre des cours qui possèdent la
chaîne de caractères "programmation"
:
SELECT distinct ?name WHERE { ?uri rdf:type ei:EducationalItem. ?uri ei:name ?name. filter(regex(?name,".*programmation.*","i")) }