Besoin de ne voir que mes données personnelles​

┌────────────────────────┐
│    MY-competences      |
│------------------------│
│ ┌────────────────────┐ │
│ │ Mes postes         │ │
│ │ Mes contributions  │ │
│ │ Mes formations     │ │
│ └────────────────────┘ │
└────────────────────────┘

Sur l'interface de My-compétences, il est possible de relier les compétences aux postes, aux contributions et aux formations.

L'objectif de My-compétence est que l'utilisateur ne voit que ses données personnelles et pas celles remplies par les autres comme dans le Back-office.

Donc nous avons filtré les listes de choix afin que chacun.e ne puisse créer des liens que vers les postes, contributions ou formations qu'ielle a créé.

Pour plus d'information, voir le manuel utilisateur de My-compétences

Utilisation d'un seul prédicat​

┌───────────────────────┐       ┌────────────┐
│ Competences           │       │ Discipline │
│-----------------------│       │------------│
│ id                    │   ┌──>│ uri        │
│ titre                 │   │   │ titre      │
│ description           │   │   │ description│
│ heco:hasDiscipline    │───┘   └────────────┘
│ xxxxxx                │       ┌────────────┐
│ xxxxxx                │       │ Poste      │
│ xxxxxx                │       │------------│
│ xxxxxx                │   ┌──>│ uri        │
│ xxxxxx                │   │   │ titre      │
│ xxxxxx                │   │   │ description│
│ heco:isCompAcquiredIn │───┘?  └────────────┘
└───────────────────────┘   │   ┌──────────────┐
                            │   │ Contribution │
                            │   │--------------│
                            └──>│ uri          │
                                │ titre        │
                                │ description  │
                                └──────────────┘       

Au niveau ontologie HeCo, nous avons souhaité n'utiliser qu'un seul prédicat (relation) entre une compétence et un poste / contribution / formation. Ainsi, le jour où nous ajouterons un nouvel objet, nous n'aurons pas à changer l'ontologie.

Pour permettre cela, nous avons dû ajouter une customisation côté serveur, afin qu'il fasse croire au client qu'il utilise un prédicat différent pour chaque objet, tout en conservant un seul prédicat en base.

Pour plus d'information sur HeCo, voir Ontologie HeCo

┌──────────────────────────┐      ┌───────────────────────────┐
│ Création                 |      │ Création                  | 
│--------------------------│      │---------------------------│
│             ┌─────────┐  │      │             ┌──────────┐  │
│ Titre       │         │  │      │ Titre       │          │  │
│             └─────────┘  |      │             └──────────┘  |
│  ┌────────────────┐      │ ---> │             ┌──────────┐  │
│  | Valider ../..  │      │      │ Description |          │  │
│  └────────────────┘      │      │             └──────────┘  │
|                          │      |  ┌────────────────┐       │
| Attention : 2 étapes !   |      │  | Enregistrer    │       │
└──────────────────────────┘      │  └────────────────┘       │
                                  └───────────────────────────┘

Avant​

Jusqu'à présent, la création d'une ressource dans les formulaires du démontrateur (dans l'interface BO ou MY), se faisait en deux temps. D'abord, le titre et une première validation (qui créait la ressource en base), puis un formulaire complémentaire, où on retrouvait la suite des champs qui composent la ressource.

Problématique : La plupart du temps, l'utilisat.eur.rice ne savait pas quoi entrer dans le champ "titre", car il ne voyait pas encore le contenu global du formulaire.

A présent​

Nous l'avons donc simplifié en fusionnant tout dans le même formulaire.

La majorité des formulaires du démontrateur ont été revus pour simplifier leur saisie.

Suppression du titre pour les compétences

┌──────────────────────────┐      ┌───────────────────────────┐
│ Création compétence      |      │ Création compétence       | 
│--------------------------│      │---------------------------│
│             ┌─────────┐  │      │             ┌──────────┐  │
│ Titre       │         │  │      │ Description │          │  │
│             └─────────┘  |      │             └──────────┘  |
│             ┌─────────┐  │ ---> │  ┌────────────────┐       │
│ Description |         │  │      │  | Enregistrer    │       │
│             └─────────┘  │      │  └────────────────┘       │
|  ┌────────────────┐      │      └───────────────────────────┘
|  | Enregistrer    │      |                                           
│  └────────────────┘      │                                           
└──────────────────────────┘                                                

Dans le même ordre d'idée, les utilisateurs ne savaient pas quoi entrer dans le champ "titre" des compétences.

Nous l'avons donc retiré, et nous avons généré un titre automatique en fonction de l'identifiant de l'utilisateur et d'un numéro incrémental.

Pour plus d'informations sur les interfaces du démonstrateur, consultez les manuels utilisateurs :

• My-competences
• Back-office

┌────────────────────────┐      ┌────────────────────────┐
│         PAIR           |      │       HECO v1.0        |
│------------------------│      │------------------------│
│ ┌────────────────────┐ │----->│ ┌────────────────────┐ │
│ │   pair:hasSkill    │ │      │ │ heco:hasCompetence │ │
│ └────────────────────┘ │      │ └────────────────────┘ │
└────────────────────────┘      └────────────────────────┘

Qu'est-ce l'ontologie PAIR ?​

L'objectif premier de l'Assemblée virtuelle est de cartographier des communautés. Elle a donc créé, en plus de la boite à outils SemApps, une ontologie PAIR, permettant de cartographier des Projets, des Acteurs, des Idées et des Ressources. Plus tard, se sont ajoutés des événements et encore d'autres concepts...

Une migration progressive...​

Au début, les premières versions du démonstrateur Carto4CH cartographiaient des personnes (acteurs), des organisations et des compétences (skills). Il y avait donc dans PAIR tout ce qu'il nous fallait pour faire une preuve de concept.

En avançant dans le projet, nous avons souhaité nous éloigner de PAIR, car sa raison d'être n'était pas la même que celle d'HeCo. Nous avons donc ajouté des classes et des relations venant de HeCo en plus de PAIR.

Pendant la première année, les deux ontologies ont très bien cohabitées, et c'est là toute la force du web sémantique de pouvoir utiliser et mélanger plusieurs ontologies ! Mais au bout d'un moment, et pour la maintenance de l'application, il est prudent de faire des choix pérennes.

Libérons les ontologies !​

Il est important de voir le démonstrateur Carto4CH comme "une solution technique qui peut s'interfacer avec l'ontolgie HeCo". Autrement dit, HeCo ne doit être spécifique à aucune implémentation. Elle doit pouvoir vivre sa vie d'ontologie sans se préocuper de la manière dont les développeurs vont l'utiliser.

Fin juin 2023, l'ontologie HeCo est passée en V1.0, ce qui signifie pour nous qu'elle peut entrer dans un cycle de "production" et de "maintenance", et nous avons pu commencer à envisager de nous séparer de l'ontologie PAIR.

En juillet-aout 2023, un travail d'alignement entre l'ontologie HeCo et toutes les classes / relations présentes dans le code et dans la base du démonstrateur a été réalisé pour devenir le moins possible dépendant de PAIR.

On peut dire qu'à présent, le démonstrateur utilise l'ontologie HeCo à 95%.

En effet, certaines spécificités de fonctionnement de SemApps nous ont contraint à conserver des références à PAIR à certains endroits. Mais si nous avons fait cela, c'est plus pour le confort ou par simplicité, cela ne signifie pas qu'il manque des choses à l'ontologie HeCo.

Nouvelle version de l'ontologie HeCo 1.0 !​

Nous avons mis à jour l'ontologie HeCO en version 1.0, vous pouvez consulter cette nouvelle version, en ligne ou via un schéma, un fichier OWL, ainsi qu'un document de présentation : Ontologie HeCo

┌────────────────────────┐
│ Démonstrateur Carto4CH |
│------------------------│
│ ┌────────────────────┐ │
│ │      SemApps       │ │
│ │--------------------│ │
│ │ ┌────────────────┐ │ │
│ │ │  React-Admin   │ │ │
│ │ └────────────────┘ │ │
│ └────────────────────┘ │
└────────────────────────┘

Qu'est-ce que React-Admin ?​

L'interface utilisatrice du démonstrateur Carto4CH est basée sur la boite à outil SemApps, qui elle même est dépendante d'un socle technique (framework) appelé React-Admin. Ce socle technique est maintenu par la société (française) Marmelabs. Il utilise la bibliothèque JavaScript React.

En résumé, les composants SemApps utilisés pour l'interface utilisatrice, sont en fait un assemblage de composants issus du framework React-Admin. Ces composants ont été adapté (écriture de "sur-couches") afin qu'ils puissent s'interfacer avec un (ou plusieurs) serveurs SemApps (qui eux sont codés en Node JS, une autre bibliothèque Javascript).

Pourquoi migrer ?​

Cette nouveauté concerne une étape importante de réusinage de code, qui permettra à notre démonstrateur :

• d'être à jour par rapport aux composants de base dont il dépend,
• d'être plus stable, en bénéficiant des corrections de bugs
• d'accéder à de nouvelles fonctionalités présentes ou futures

Nous allons donc profiter de cette migration pour vous donner des détails techniques sur son fonctionnement, en vulgarisant au maximum.

Explication​

Depuis le début du projet Carto4CH, nous utilisions la version 3 de React-Admin. Or, depuis quelques mois, Marmelab a sorti une version majeure, la version 4, et il nous fallait donc "migrer" le code des composants SemApps dans cette version, ainsi que toute les interfaces qui utilisent ces composants. Pour l'Assemblée virtuelle, cette opération est loin d'être neutre, et a nécessité plusieurs semaines à nos équipes pour mettre à jour les composants SemApps, pour qu'ils fonctionnent avec la nouvelle version de React-Admin. Cela a été terminé début juillet, ce qui nous a permis de mettre à jour le code de l'interface du démonstrateur Carto4CH à notre tour.

Ces adaptations ont d'abord été faites sur le back-office, puis sur My-compétences.

Une fois que nous sommes arrivé à iso-fonctionalité, nous nous sommes rendu compte que cette nouvelle version 4.0 permettait de simplifier certaines interfaces, ou de simplifier l'écriture du code, car en version 3, nous avions rajouté des "pansements" à cause de bugs qui ont été corrigés en version 4. Nous avons donc repassé en revue une deuxième fois le code du démonstrateur, pour qu'il soit plus facile à maintenir à l'avenir.

Pour plus d'informations sur le fonctionnement interne de SemApps, consultez la rubrique Documentation technique > Doc. technique SemApps

Le début de la phase de production commence.

Nous avons mis à disposition des partenaires un "paquet" technique leur permettant d'installer et de paramétrer leur propre serveur de production.

C'est un paquet reprenant le code du démonstrateur, mais pour un seul serveur.

Pour plus d'informations, consultez la rubrique Documentation technique > Déploiement d'un serveur

Depuis le début du projet, nous avions utilisé des noms d'organisations pour appeler les deux serveurs du démonstrateur. Par soucis de neutralité, nous les appelons à présent Server A et Server B.

Nous avons donc renommé tous les éléments faisant référence aux organisations :

• dans ce portail
• dans les URL d'accès au démonstrateur
• dans les schémas
• dans les fichiers du serveur

Nous avons ajouté des documentations permettant aux utilisateurs d'ajouter plus simplement leurs compétences et de comprendre les différentes interfaces proposés par le démonstrateur.

Pour le moment, il existe 3 interfaces développées dans le démonstrateur :

• My-competences
• Back-office
• Carto

Publication d'une nouvelle version de l'ontologie HeCo.

• Page de l'ontologie
• Schéma correspondant

Pour faciliter le renseignement des compétences et simplifier l'expérience utilisat.eur.rice, nous avons ajouté au démonstrateur une nouvelle application appelée My-competence.

Dans cette application, l'utilisat.eur.rice se loge, et ensuite, ne voit que ses données personnelles. Ielle peut alors remplir son CV dans une interface épurée.

Elle pourra être déclinée en fonction de l'instance, comme par exemple dans le démonstrateur, nous l'avons appelé My-ServerA (pour l'instance A).

Vous retrouverez la documentation utilisat.eur.rice de cette application dans Doc. projet > doc. démonstrateur > My-competences.

Techniquement, c'est une deuxième interface utilisant la boite à outils SemApps. Elle pointe sur les mêmes données que l'application de back-office.

Abandon des relations réifiées​

Pour des raisons techniques et de délai d'avancement, nous avons décidé d'abandonner le mécanisme des relations réifiées pour mettre à disposition une première version fonctionnelle contenant la gestion :

• des formations
• des postes
• des contributions
• des compétences (avec 4 qualités fixes)

En effet, après quelques mois d'implémentation complexe et de difficulté à expliquer l'interface lors des ateliers de compétences, nous nous sommes orienté vers une solution plus simple, consistant à figer 4 qualités, reliées chacunes à un référentiel :

• Discipline
• Secteur
• Objet d'étude
• Outil

Avantage : L'utilisat.eur.rice sera ainsi plus guidé dans sa saisie des compétences

Inconvénient : Si nous souhaitons à l'avenir ajouter une nouvelle qualité, nous devrons repasser par le code.

Remise à plus tard des référentiels automatiques​

Nous avons aussi décidé d'utiliser pour le moment des référentiels internes, renseignés par les saisies de chac.un.e dans chaque serveur.

PS : Nous continuons d'utiliser les référentiels ESCO et Wikidata pour l'aide à la saisie.

Avantage : Gain de temps et simplicité d'architecture. Nous souhaitons commencer petit, mais que cela fonctionne, car cela reste un démonstrateur. Cela permettra d'avoir un début de référentiel pour le jour où nous aurons besoin d'en créer un automatique.

Inconvénient : Cela signifie qu'au début, les listes de choix ne seront pas beaucoup remplies, mais qu'au fil des saisies, ces listes se complèteront avec les qualités créées par chacun.e dans chaque instance.