Bâtir sur un sens publié

Le World Skills Protocol s'adresse aux systèmes qui doivent échanger ou interpréter de l'information sur les compétences professionnelles au-delà des frontières organisationnelles et techniques.

Il peut soutenir des applications telles que :

• —des professional passports ;
• —des registres de compétences ;
• —des systèmes de certification ;
• —des plateformes de formation et d'évaluation ;
• —des outils de recrutement ;
• —des systèmes de gestion des effectifs ;
• —des services de preuve de confiance ;
• —des couches d'interopérabilité ;
• —des agents IA qui consomment de l'information professionnelle structurée.

Ces systèmes n'ont pas besoin de partager la même architecture interne.

Ils doivent préserver le même sens publié.

Le protocole fournit les concepts, identifiants et relations communs qui le rendent possible.

Le protocole commence par ses Records.

Les Records définissent les concepts, les règles et les relations qui constituent le World Skills Protocol.

Ils sont la source normative à l'aune de laquelle les implémentations sont interprétées.

Un développeur ne devrait donc jamais déduire le sens du protocole uniquement à partir :

• —d'une interface utilisateur ;
• —d'un exemple de charge utile ;
• —d'un schéma de base de données ;
• —d'un SDK ;
• —d'une projection de graphe ;
• —ou du comportement d'une autre implémentation.

Ces ressources peuvent faciliter l'usage du protocole, mais elles ne remplacent pas les Records qui en établissent le sens.

Lorsqu'une implémentation et un Record semblent en désaccord, le Record fait foi.

Les noms sont utiles aux humains.

Les identifiants sont nécessaires aux systèmes.

Le World Skills Protocol distingue le sens d'un objet publié de l'adresse utilisée pour découvrir l'une de ses représentations.

Un titre lisible par un humain peut changer.

Un emplacement de stockage peut changer.

Un nom de domaine peut changer.

Une représentation peut être remplacée.

L'identité de la définition publiée, elle, doit rester stable.

Les développeurs devraient donc utiliser les identifiants canoniques établis par le protocole pour stocker, référencer ou échanger des objets du protocole.

Des libellés d'affichage peuvent aider les lecteurs humains, mais ils ne doivent pas se substituer à l'identité canonique.

Les identifiants canoniques n'exigent pas des implémentations qu'elles sachent où un objet est actuellement stocké.

La résolution d'identité relève de la couche de lecture.

Lorsqu'un système reçoit un identifiant canonique, il devrait utiliser les mécanismes de résolution et de découverte publiés par le protocole pour localiser la représentation courante associée à cette identité.

Cette séparation protège les implémentations des changements de :

• —infrastructure ;
• —emplacement de publication ;
• —organisation des fichiers ;
• —hébergement ;
• —ou représentation canonique.

Les applications peuvent ainsi continuer à référencer la même identité publiée, même lorsque la manière dont elle est lue évolue.

L'identifiant reste stable.

Le mécanisme de lecture résout la représentation courante.

Une représentation canonique est l'expression approuvée par le protocole d'une définition publiée, à un état documentaire donné.

Ce n'est pas l'identité de la définition.

Plusieurs représentations peuvent exister au fil du temps tout en préservant la même définition logique.

Les développeurs doivent donc éviter de traiter un chemin de fichier, une URL de document, une ligne de base de données ou une charge utile sérialisée comme s'ils étaient l'identité de l'objet lui-même.

Cette distinction permet au protocole d'évoluer sans casser toutes les implémentations qui le référencent.

La définition logique répond à :

Qu'est cet objet publié ?

La représentation canonique répond à :

Comment cet objet est-il exprimé dans cet état de publication ?

L'adresse de découverte répond à :

Où la représentation courante peut-elle être lue ?

Ces trois questions doivent rester distinctes.

Un fait publié n'est pas réécrit en silence.

Lorsque le protocole doit exprimer une nouvelle relation, un nouveau statut ou une nouvelle représentation, il procède par ajout.

Cela signifie que les implémentations devraient préserver les faits historiques qu'elles ont consommés, plutôt que de les remplacer comme si la publication précédente n'avait jamais existé.

Une information nouvelle peut :

• —superséder une représentation antérieure ;
• —identifier un successeur ;
• —établir une réidentification ;
• —publier une nouvelle version ;
• —ou modifier la lecture dérivée d'un objet.

Elle ne doit pas effacer le fait que la publication antérieure a eu lieu.

C'est ce qui rend possibles l'auditabilité et la reconstruction historique au sein du protocole.

Le protocole distingue deux formes de continuité.

La succession

La succession s'applique lorsque la sémantique a suffisamment changé pour que la nouvelle définition constitue un objet normatif distinct.

Le nouvel objet suit le précédent, mais ne prétend pas être la même définition.

La réidentification

La réidentification s'applique lorsque la sémantique reste inchangée, mais que l'identité publiée ou la représentation canonique doit être corrigée ou remplacée.

La nouvelle publication préserve les propriétés normatives de la définition réidentifiée.

Ces relations ne doivent pas être traitées comme interchangeables.

La succession exprime une évolution sémantique.

La réidentification exprime une continuité de sens à travers une identité ou une représentation corrigée.

Les applications qui exposent l'historique devraient préserver cette distinction.

Le protocole publie des concepts.

Les implémentations stockent des occurrences de ces concepts.

Par exemple, le protocole peut publier qu'un Framework peut être réidentifié.

Une implémentation peut stocker le fait particulier qu'un Framework donné a été réidentifié en un autre.

Le premier est une règle du protocole.

Le second est une occurrence opérationnelle.

Les développeurs ne devraient pas insérer d'occurrences propres à leur implémentation dans le corpus normatif ni dans sa projection conceptuelle.

À l'inverse, ils ne devraient pas traiter le Knowledge Graph comme s'il s'agissait d'une base de données opérationnelle.

Cette séparation garde le protocole universel, tout en permettant aux implémentations de stocker les faits pertinents pour leurs propres utilisateurs et systèmes.

Le Canonical Registry expose les prédicats, les identifiants et les relations contrôlées reconnus par le protocole.

Les développeurs devraient utiliser les identifiants de prédicats canoniques exactement tels qu'ils sont publiés.

Un synonyme localement commode n'est pas un identifiant de protocole équivalent.

Transformer :

reidentified_as

en une orthographe, une casse ou une forme verbale différente peut créer une relation qui paraît compréhensible à un humain, mais que des logiciels conformes ne reconnaissent pas.

Les identifiants canoniques doivent donc être réutilisés sans traduction à l'intérieur des données de protocole lisibles par la machine.

Les interfaces destinées aux humains peuvent leur adjoindre des libellés explicatifs.

Le Knowledge Graph est une projection générée des concepts et des relations publiés par le corpus.

Il peut aider les développeurs à :

• —découvrir des concepts liés ;
• —comprendre des dépendances ;
• —naviguer entre les Records ;
• —inspecter les relations publiées ;
• —et fournir un contexte structuré à des agents logiciels.

Il ne doit pas être utilisé comme une source normative indépendante.

Le graphe ne contient pas d'instances de base de données.

Il n'infère pas de relations à partir des données d'implémentation.

Il ne publie pas de faits absents des Records.

Chaque projection de graphe correspond à un état documentaire particulier du corpus.

Les développeurs devraient donc conserver l'identité ou l'empreinte de la projection sur laquelle ils s'appuient lorsque la reproductibilité importe.

Le protocole distingue trois formes indépendantes de versioning.

Le versioning documentaire

Le versioning documentaire suit les changements d'un Record en tant que document publié.

Il identifie l'état de ce Record au sein du corpus.

Le versioning normatif

Le versioning normatif suit les changements de sens, d'obligations ou de définition logique établis par le protocole.

Une révision documentaire ne change pas nécessairement le sens normatif.

Le versioning de représentation

Le versioning de représentation suit les changements de la forme sous laquelle un objet publié est exprimé ou délivré.

Une nouvelle sérialisation, structure de fichier ou format de publication ne crée pas nécessairement un nouvel objet normatif.

Les développeurs ne devraient pas fondre ces couches en un seul numéro de version.

Le faire rend impossible de distinguer une correction textuelle, un amendement sémantique et un changement de représentation.

Le statut du protocole est dérivé de faits publiés.

Il ne devrait pas être traité comme un champ mutable isolé dont la valeur peut changer sans préserver les faits qui la justifient.

Une implémentation peut mettre en cache un statut dérivé pour la performance ou l'affichage.

Cette valeur en cache doit rester reproductible à partir des faits publiés sous-jacents.

La dérivation devrait être déterministe.

Les faits devraient rester traçables.

Un libellé stocké qui ne peut être justifié à partir de l'historique de publication ne doit pas être traité comme une vérité du protocole.

Chaque objet du protocole consommé par une implémentation devrait rester traçable jusqu'à son origine publiée.

Selon le cas d'usage, cela peut inclure :

• —l'identifiant canonique ;
• —le Record établissant l'objet ;
• —la version documentaire ;
• —l'empreinte de la représentation ;
• —la projection de graphe ;
• —la date ou l'état de résolution ;
• —et les relations utilisées dans l'interprétation.

La provenance est ce qui permet à un système d'expliquer pourquoi il a interprété un objet d'une manière donnée.

Sans provenance, deux systèmes peuvent afficher le même libellé tout en s'appuyant sur des états documentaires différents.

Avec la provenance, l'interprétation peut être reconstruite et auditée.

Là où le protocole fournit une règle canonique, les systèmes conformes devraient produire le même résultat à partir des mêmes faits publiés.

La résolution ne doit pas dépendre d'hypothèses non documentées.

La dérivation du statut ne doit pas dépendre de choix manuels cachés.

Les identifiants canoniques ne doivent pas dépendre des libellés d'affichage.

Les relations de graphe ne doivent pas dépendre d'un contenu de base de données privé.

Le comportement déterministe permet à des implémentations indépendantes de parvenir à des conclusions compatibles sans partager le même code.

C'est l'une des conditions fondamentales de l'interopérabilité.

Un développeur peut rencontrer une relation qui paraît évidente mais qui n'est pas publiée.

L'implémentation ne doit pas promouvoir cette interprétation en silence au rang de sens du protocole.

La bonne réponse est de distinguer :

• —ce que le protocole établit ;
• —ce qu'une implémentation observe ;
• —et ce que le développeur infère.

Une logique propre à l'implémentation peut exister là où c'est nécessaire.

Elle doit rester identifiable comme logique d'implémentation.

Elle ne doit pas être représentée comme faisant partie du World Skills Protocol tant que la règle appropriée n'a pas été publiée par le processus de gouvernance du protocole.

L'absence dans le protocole n'est pas une permission de fabriquer une réponse normative.

Le World Skills Protocol n'exige pas que chaque implémentation utilise la même technologie.

Un système peut utiliser un stockage relationnel.

Un autre peut utiliser une base documentaire.

Un autre peut consommer des artefacts publiés statiques.

Un autre peut fonctionner comme un agent IA.

Leurs conceptions internes peuvent différer substantiellement.

Ils restent interopérables tant qu'ils préservent :

• —l'identité canonique ;
• —les définitions publiées ;
• —les relations normatives ;
• —les distinctions de version ;
• —la provenance ;
• —le comportement de résolution ;
• —et la séparation entre les concepts du protocole et les instances d'implémentation.

La conformité concerne donc le sens observable, non la ressemblance interne.

Un développeur qui entame une intégration devrait procéder dans l'ordre suivant.

1. Identifier les concepts concernés

Déterminer quels concepts du protocole l'application doit consommer, publier ou référencer.

2. Lire les Records établissant ces concepts

Localiser les Records qui définissent ces concepts et leurs relations normatives.

3. Récupérer les identifiants canoniques

Utiliser les identifiants et les noms de prédicats publiés par le Canonical Registry.

4. Implémenter la résolution

Résoudre les identifiants via les mécanismes de lecture et de découverte, plutôt que de coder en dur les emplacements de stockage actuels.

5. Préserver la provenance

Enregistrer l'état documentaire et la représentation utilisés par l'application.

6. Séparer les faits du protocole des faits locaux

Garder les définitions normatives distinctes des instances propres à l'implémentation et des données opérationnelles.

7. Tester le comportement déterministe

Vérifier que les mêmes faits publiés produisent la même résolution, le même statut dérivé et la même interprétation des relations.

8. Surveiller les changements de publication

Lorsque le corpus évolue, évaluer indépendamment les changements documentaires, normatifs et de représentation pertinents.

Ce chemin permet à une implémentation de commencer petit tout en restant compatible avec l'architecture plus large du protocole.

Le World Skills Protocol ne prescrit pas :

• —d'interface utilisateur ;
• —de moteur de base de données ;
• —de fournisseur d'hébergement ;
• —de système d'authentification ;
• —de langage de programmation ;
• —de framework logiciel ;
• —de modèle commercial ;
• —ni d'architecture d'application unique.

Il n'exige pas non plus des implémentations qu'elles exposent tous les concepts du protocole.

Une implémentation peut ne prendre en charge que les concepts pertinents pour son objet.

Ce qu'elle ne doit pas faire, c'est altérer le sens des concepts qu'elle prétend prendre en charge.

La liberté technique est permise.

La divergence sémantique ne l'est pas.

Les systèmes d'IA peuvent utiliser le protocole pour accéder à de l'information professionnelle dotée d'une structure explicite et d'une origine traçable.

Ils peuvent utiliser :

• —les Records pour récupérer le sens normatif ;
• —le Knowledge Graph pour naviguer entre les concepts ;
• —le Canonical Registry pour reconnaître les prédicats ;
• —et les mécanismes de découverte pour résoudre les représentations courantes et les faits opérationnels.

Un agent IA doit toujours distinguer les faits récupérés des interprétations générées.

La présence d'un concept dans le graphe ne prouve pas qu'une personne ou une organisation donnée le possède.

L'existence d'une relation dans le protocole ne prouve pas qu'une occurrence opérationnelle correspondante existe.

L'accès structuré améliore la fiabilité.

Il ne supprime pas le besoin de provenance et de preuve.

Le protocole évolue par ses mécanismes de gouvernance publiés.

Les développeurs ne devraient pas supposer que chaque mise à jour documentaire crée un changement cassant.

Ils devraient déterminer quelle couche a changé.

Une publication peut impliquer :

• —une correction éditoriale ;
• —une nouvelle version documentaire ;
• —un amendement normatif ;
• —une nouvelle représentation canonique ;
• —une réidentification ;
• —une succession ;
• —ou une nouvelle projection de graphe.

Chacune a des conséquences différentes.

Les applications devraient réagir à la nature du changement, plutôt qu'à la simple présence d'une nouvelle version.

Le World Skills Protocol offre aux développeurs une manière stable de construire avec l'information sur les compétences professionnelles, sans forcer chaque système dans la même conception technique.

Son exigence centrale n'est pas l'uniformité technologique.

C'est la fidélité au sens publié.

Utilisez les identifiants canoniques.

Résolvez l'identité par la couche de lecture.

Distinguez les définitions des représentations.

Séparez les concepts des instances.

Préservez la provenance.

Dérivez le statut à partir des faits.

Et n'introduisez jamais une sémantique de protocole que le corpus n'a pas publiée.

Lorsque ces principes sont respectés, des applications indépendantes peuvent échanger, interpréter et vérifier de l'information professionnelle sans renoncer à la traçabilité ni au contrôle.