Construir sobre un significado publicado
Un protocolo diseñado para sistemas que deben intercambiar datos de competencias sin perder identidad, contexto ni trazabilidad.
El World Skills Protocol proporciona una arquitectura común para publicar, identificar, resolver y conectar información sobre competencias profesionales.
Los desarrolladores pueden usarlo para crear aplicaciones que entiendan los mismos conceptos, sigan las mismas relaciones y preserven el origen de cada definición publicada.
El protocolo no impone ningún lenguaje de programación, base de datos, framework ni proveedor de infraestructura.
Define el significado que las implementaciones deben preservar.
Sección 1 — Qué pueden construir los desarrolladores
El World Skills Protocol está destinado a sistemas que necesitan intercambiar o interpretar información sobre competencias profesionales más allá de las fronteras organizativas y técnicas.
Puede sustentar aplicaciones como:
- —professional passports;
- —registros de competencias;
- —sistemas de certificación;
- —plataformas de formación y evaluación;
- —herramientas de reclutamiento;
- —sistemas de gestión de plantilla;
- —servicios de evidencia de confianza;
- —capas de interoperabilidad;
- —agentes de IA que consumen información profesional estructurada.
Estos sistemas no necesitan compartir la misma arquitectura interna.
Necesitan preservar el mismo significado publicado.
El protocolo proporciona los conceptos, identificadores y relaciones comunes que lo hacen posible.
Sección 2 — Empezar por el corpus canónico
El protocolo comienza por sus Records.
Los Records definen los conceptos, las reglas y las relaciones que constituyen el World Skills Protocol.
Son la fuente normativa frente a la cual se interpretan las implementaciones.
Por tanto, un desarrollador nunca debería deducir el significado del protocolo únicamente a partir de:
- —una interfaz de usuario;
- —un ejemplo de carga útil;
- —un esquema de base de datos;
- —un SDK;
- —una proyección de grafo;
- —o el comportamiento de otra implementación.
Esos recursos pueden facilitar el uso del protocolo, pero no reemplazan a los Records que establecen su significado.
Cuando una implementación y un Record parecen discrepar, el Record prevalece.
Sección 3 — Usar identificadores canónicos
Los nombres son útiles para las personas.
Los identificadores son necesarios para los sistemas.
El World Skills Protocol distingue el significado de un objeto publicado de la dirección utilizada para descubrir una de sus representaciones.
Un título legible por humanos puede cambiar.
Una ubicación de almacenamiento puede cambiar.
Un nombre de dominio puede cambiar.
Una representación puede ser reemplazada.
La identidad de la definición publicada debe permanecer estable.
Por tanto, los desarrolladores deberían usar los identificadores canónicos establecidos por el protocolo al almacenar, referenciar o intercambiar objetos del protocolo.
Las etiquetas de visualización pueden ayudar a los lectores humanos, pero no deben sustituir a la identidad canónica.
Sección 4 — Resolver la identidad mediante la capa de lectura
Los identificadores canónicos no exigen que las implementaciones sepan dónde está almacenado actualmente un objeto.
La resolución de identidad pertenece a la capa de lectura.
Cuando un sistema recibe un identificador canónico, debería usar los mecanismos de resolución y descubrimiento publicados por el protocolo para localizar la representación actual asociada a esa identidad.
Esta separación protege a las implementaciones de los cambios en:
- —infraestructura;
- —ubicación de publicación;
- —organización de archivos;
- —alojamiento;
- —o representación canónica.
Así, las aplicaciones pueden seguir referenciando la misma identidad publicada aunque evolucione la forma en que se lee.
El identificador permanece estable.
El mecanismo de lectura resuelve la representación actual.
Sección 5 — Distinguir la identidad de la representación
Una representación canónica es la expresión aprobada por el protocolo de una definición publicada, en un estado documental determinado.
No es la identidad de la definición.
Pueden existir varias representaciones a lo largo del tiempo preservando la misma definición lógica.
Por tanto, los desarrolladores deben evitar tratar una ruta de archivo, una URL de documento, una fila de base de datos o una carga útil serializada como si fueran la identidad del objeto en sí.
Esta distinción permite que el protocolo evolucione sin romper todas las implementaciones que lo referencian.
La definición lógica responde a:
¿Qué es este objeto publicado?
La representación canónica responde a:
¿Cómo se expresa ese objeto en este estado de publicación?
La dirección de descubrimiento responde a:
¿Dónde puede leerse la representación actual?
Estas tres preguntas deben permanecer separadas.
Sección 6 — Tratar los hechos publicados como inmutables
Un hecho publicado no se reescribe en silencio.
Cuando el protocolo necesita expresar una nueva relación, estado o representación, procede por adición.
Esto significa que las implementaciones deberían preservar los hechos históricos que han consumido, en lugar de reemplazarlos como si la publicación anterior nunca hubiera existido.
La información nueva puede:
- —superseder una representación anterior;
- —identificar un sucesor;
- —establecer una reidentificación;
- —publicar una nueva versión;
- —o cambiar la lectura derivada de un objeto.
No debe borrar el hecho de que la publicación anterior ocurrió.
Esto habilita la auditabilidad y la reconstrucción histórica en todo el protocolo.
Sección 7 — Entender la sucesión y la reidentificación
El protocolo distingue dos formas de continuidad.
La sucesión
La sucesión se aplica cuando la semántica ha cambiado lo suficiente como para que la nueva definición constituya un objeto normativo distinto.
El nuevo objeto sigue al anterior, pero no pretende ser la misma definición.
La reidentificación
La reidentificación se aplica cuando la semántica permanece sin cambios, pero la identidad publicada o la representación canónica debe corregirse o reemplazarse.
La nueva publicación preserva las propiedades normativas de la definición reidentificada.
Estas relaciones no deben tratarse como intercambiables.
La sucesión expresa una evolución semántica.
La reidentificación expresa una continuidad de significado a través de una identidad o representación corregida.
Las aplicaciones que exponen el historial deberían preservar esta distinción.
Sección 8 — Separar los conceptos de las instancias
El protocolo publica conceptos.
Las implementaciones almacenan ocurrencias de esos conceptos.
Por ejemplo, el protocolo puede publicar que un Framework puede reidentificarse.
Una implementación puede almacenar el hecho concreto de que un Framework fue reidentificado como otro.
Lo primero es una regla del protocolo.
Lo segundo es una ocurrencia operativa.
Los desarrolladores no deberían insertar ocurrencias propias de su implementación en el corpus normativo ni en su proyección conceptual.
A la inversa, no deberían tratar el Knowledge Graph como si fuera una base de datos operativa.
Esta separación mantiene el protocolo universal, permitiendo a la vez que las implementaciones almacenen los hechos relevantes para sus propios usuarios y sistemas.
Sección 9 — Usar el registro canónico
El Canonical Registry expone los predicados, los identificadores y las relaciones controladas reconocidos por el protocolo.
Los desarrolladores deberían usar los identificadores de predicados canónicos exactamente como se publican.
Un sinónimo cómodo a nivel local no es un identificador de protocolo equivalente.
Cambiar:
reidentified_as
por una ortografía, mayúsculas o forma verbal distinta puede crear una relación que parezca comprensible para una persona, pero que el software conforme no reconozca.
Por tanto, los identificadores canónicos deben reutilizarse sin traducción dentro de los datos de protocolo legibles por máquina.
Las interfaces dirigidas a humanos pueden acompañarlos de etiquetas explicativas.
Sección 10 — Leer correctamente el Knowledge Graph
El Knowledge Graph es una proyección generada de los conceptos y relaciones publicados por el corpus.
Puede ayudar a los desarrolladores a:
- —descubrir conceptos relacionados;
- —entender dependencias;
- —navegar entre los Records;
- —inspeccionar las relaciones publicadas;
- —y proporcionar contexto estructurado a agentes de software.
No debe usarse como una fuente normativa independiente.
El grafo no contiene instancias de base de datos.
No infiere relaciones a partir de datos de implementación.
No publica hechos ausentes de los Records.
Cada proyección del grafo corresponde a un estado documental concreto del corpus.
Por tanto, los desarrolladores deberían conservar la identidad o la huella de la proyección en la que se apoyan cuando la reproducibilidad importa.
Sección 11 — Respetar las tres capas de versionado
El protocolo distingue tres formas independientes de versionado.
El versionado documental
El versionado documental sigue los cambios de un Record como documento publicado.
Identifica el estado de ese Record dentro del corpus.
El versionado normativo
El versionado normativo sigue los cambios de significado, obligaciones o definición lógica establecidos por el protocolo.
Una revisión documental no cambia necesariamente el significado normativo.
El versionado de representación
El versionado de representación sigue los cambios de la forma en que se expresa o se entrega un objeto publicado.
Una nueva serialización, estructura de archivo o formato de publicación no crea necesariamente un nuevo objeto normativo.
Los desarrolladores no deberían fusionar estas capas en un único número de versión.
Hacerlo hace imposible distinguir una corrección textual, una enmienda semántica y un cambio de representación.
Sección 12 — Derivar el estado; no persistirlo como verdad
El estado del protocolo se deriva de hechos publicados.
No debería tratarse como un campo mutable aislado cuyo valor pueda cambiarse sin preservar los hechos que lo justifican.
Una implementación puede almacenar en caché un estado derivado por rendimiento o presentación.
Ese valor en caché debe permanecer reproducible a partir de los hechos publicados subyacentes.
La derivación debería ser determinista.
Los hechos deberían permanecer trazables.
Una etiqueta almacenada que no pueda justificarse a partir del historial de publicación no debe tratarse como verdad del protocolo.
Sección 13 — Preservar la procedencia
Cada objeto del protocolo consumido por una implementación debería permanecer trazable hasta su origen publicado.
Según el caso de uso, esto puede incluir:
- —el identificador canónico;
- —el Record que establece el objeto;
- —la versión documental;
- —la huella de la representación;
- —la proyección del grafo;
- —la fecha o el estado de resolución;
- —y las relaciones utilizadas en la interpretación.
La procedencia es lo que permite a un sistema explicar por qué interpretó un objeto de una manera determinada.
Sin procedencia, dos sistemas pueden mostrar la misma etiqueta apoyándose en estados documentales distintos.
Con procedencia, la interpretación puede reconstruirse y auditarse.
Sección 14 — Diseñar para un comportamiento determinista
Donde el protocolo proporciona una regla canónica, los sistemas conformes deberían producir el mismo resultado a partir de los mismos hechos publicados.
La resolución no debe depender de suposiciones no documentadas.
La derivación del estado no debe depender de elecciones manuales ocultas.
Los identificadores canónicos no deben depender de las etiquetas de visualización.
Las relaciones del grafo no deben depender de contenido de base de datos privado.
El comportamiento determinista permite que implementaciones independientes lleguen a conclusiones compatibles sin compartir el mismo código.
Es una de las condiciones fundamentales de la interoperabilidad.
Sección 15 — No inventar una semántica ausente
Un desarrollador puede encontrarse con una relación que parece obvia pero que no está publicada.
La implementación no debe promover en silencio esa interpretación al rango de significado del protocolo.
La respuesta correcta es distinguir entre:
- —lo que el protocolo establece;
- —lo que una implementación observa;
- —y lo que el desarrollador infiere.
Puede existir lógica específica de la implementación donde sea necesaria.
Debe permanecer identificable como lógica de implementación.
No debe representarse como si formara parte del World Skills Protocol hasta que la regla apropiada se haya publicado mediante el proceso de gobernanza del protocolo.
La ausencia en el protocolo no es permiso para fabricar una respuesta normativa.
Sección 16 — La conformidad trata del significado preservado
El World Skills Protocol no exige que cada implementación use la misma tecnología.
Un sistema puede usar almacenamiento relacional.
Otro puede usar un almacén de documentos.
Otro puede consumir artefactos publicados estáticos.
Otro puede funcionar como un agente de IA.
Sus diseños internos pueden diferir sustancialmente.
Siguen siendo interoperables cuando preservan:
- —la identidad canónica;
- —las definiciones publicadas;
- —las relaciones normativas;
- —las distinciones de versión;
- —la procedencia;
- —el comportamiento de resolución;
- —y la separación entre los conceptos del protocolo y las instancias de implementación.
Por tanto, la conformidad concierne al significado observable, no al parecido interno.
Sección 17 — Un camino práctico de implementación
Un desarrollador que inicia una integración debería proceder en el siguiente orden.
1. Identificar los conceptos en cuestión
Determinar qué conceptos del protocolo necesita consumir, publicar o referenciar la aplicación.
2. Leer los Records que los establecen
Localizar los Records que definen esos conceptos y sus relaciones normativas.
3. Recuperar los identificadores canónicos
Usar los identificadores y los nombres de predicados publicados por el Canonical Registry.
4. Implementar la resolución
Resolver los identificadores mediante los mecanismos de lectura y descubrimiento, en lugar de codificar de forma fija las ubicaciones de almacenamiento actuales.
5. Preservar la procedencia
Registrar el estado documental y la representación utilizados por la aplicación.
6. Separar los hechos del protocolo de los hechos locales
Mantener las definiciones normativas distintas de las instancias propias de la implementación y de los datos operativos.
7. Probar el comportamiento determinista
Verificar que los mismos hechos publicados producen la misma resolución, el mismo estado derivado y la misma interpretación de las relaciones.
8. Vigilar los cambios de publicación
Cuando el corpus evoluciona, evaluar de forma independiente los cambios documentales, normativos y de representación pertinentes.
Este camino permite que una implementación empiece pequeña sin dejar de ser compatible con la arquitectura más amplia del protocolo.
Sección 18 — Lo que el protocolo no prescribe
El World Skills Protocol no prescribe:
- —una interfaz de usuario;
- —un motor de base de datos;
- —un proveedor de alojamiento;
- —un sistema de autenticación;
- —un lenguaje de programación;
- —un framework de software;
- —un modelo comercial;
- —ni una arquitectura de aplicación única.
Tampoco exige que las implementaciones expongan todos los conceptos del protocolo.
Una implementación puede admitir solo los conceptos relevantes para su propósito.
Lo que no debe hacer es alterar el significado de los conceptos que dice admitir.
La libertad técnica está permitida.
La divergencia semántica no.
Sección 19 — Para agentes de IA
Los sistemas de IA pueden usar el protocolo para acceder a información profesional con una estructura explícita y un origen trazable.
Pueden usar:
- —los Records para recuperar el significado normativo;
- —el Knowledge Graph para navegar entre conceptos;
- —el Canonical Registry para reconocer predicados;
- —y los mecanismos de descubrimiento para resolver las representaciones actuales y los hechos operativos.
Un agente de IA debe seguir distinguiendo los hechos recuperados de las interpretaciones generadas.
La presencia de un concepto en el grafo no prueba que una persona u organización determinada lo posea.
La existencia de una relación en el protocolo no prueba que exista una ocurrencia operativa correspondiente.
El acceso estructurado mejora la fiabilidad.
No elimina la necesidad de procedencia y evidencia.
Sección 20 — Cuando el protocolo cambia
El protocolo evoluciona mediante sus mecanismos de gobernanza publicados.
Los desarrolladores no deberían suponer que cada actualización documental crea un cambio disruptivo.
Deberían determinar qué capa cambió.
Una publicación puede implicar:
- —una corrección editorial;
- —una nueva versión documental;
- —una enmienda normativa;
- —una nueva representación canónica;
- —una reidentificación;
- —una sucesión;
- —o una nueva proyección de grafo.
Cada una tiene consecuencias distintas.
Las aplicaciones deberían responder a la naturaleza del cambio, más que a la mera presencia de una nueva versión.
Conclusion
El World Skills Protocol ofrece a los desarrolladores una manera estable de construir con información sobre competencias profesionales, sin forzar a cada sistema al mismo diseño técnico.
Su requisito central no es la uniformidad tecnológica.
Es la fidelidad al significado publicado.
Usa los identificadores canónicos.
Resuelve la identidad mediante la capa de lectura.
Distingue las definiciones de las representaciones.
Separa los conceptos de las instancias.
Preserva la procedencia.
Deriva el estado a partir de los hechos.
Y nunca introduzcas una semántica de protocolo que el corpus no haya publicado.
Cuando se respetan estos principios, aplicaciones independientes pueden intercambiar, interpretar y verificar información profesional sin renunciar a la trazabilidad ni al control.
Empezar a construir con el protocolo
Explora los recursos canónicos que establecen los conceptos, los identificadores y las relaciones que tu implementación puede usar.