Preguntas frecuentes
Entender el protocolo empieza por entender sus principios.
El World Skills Protocol introduce conceptos que a menudo resultan poco familiares al principio: identificadores canónicos, definiciones lógicas, representaciones, Knowledge Graphs, resolución de identidad, reidentificación y más.
Esta página responde a las preguntas más frecuentes de lectores, desarrolladores, implementadores y organizaciones que descubren el protocolo.
Cada respuesta refleja el protocolo publicado.
Donde existe detalle adicional, los enlaces apuntan a los Records o a los recursos técnicos correspondientes.
Sección 1 — Sobre el protocolo
¿Qué es el World Skills Protocol?
El World Skills Protocol es un protocolo abierto para publicar, identificar, conectar y verificar información sobre competencias profesionales.
Define conceptos, identificadores y relaciones compartidos para que sistemas independientes puedan intercambiar información profesional sin perder significado ni trazabilidad.
No es un producto de software.
Es una especificación.
¿Para quién es el protocolo?
El protocolo está destinado a:
- —desarrolladores;
- —proveedores de software;
- —organismos de certificación;
- —organizaciones educativas;
- —empleadores;
- —sistemas de IA;
- —instituciones públicas;
- —y cualquier organización que necesite datos interoperables sobre competencias profesionales.
¿El protocolo reemplaza a las plataformas existentes?
No.
El protocolo está diseñado para conectar sistemas independientes.
Las aplicaciones existentes siguen siendo responsables de sus propios usuarios, interfaces y datos operativos.
El protocolo proporciona un lenguaje común entre ellas.
¿El protocolo es abierto?
Sí.
Sus conceptos publicados, sus Records y su gobernanza están destinados a documentarse abiertamente.
Cada implementación es libre de elegir sus propias licencias y modelos de negocio.
Sección 2 — Sobre los Records
¿Qué es un Record?
Un Record es un documento publicado que establece uno o más elementos normativos del protocolo.
Los Records definen conceptos, relaciones, reglas o decisiones de gobernanza.
Constituyen la fuente autorizada del significado del protocolo.
¿Los Records son especificaciones?
Sí.
Un Record es la especificación normativa de los conceptos que establece.
Todo lo demás deriva de esos Records.
¿Qué documento tiene autoridad?
Los Records.
El material de apoyo puede explicar el protocolo.
Solo los Records publicados lo establecen.
¿Puede el software discrepar de un Record?
El software puede comportarse de otra manera.
El protocolo no.
Cuando una implementación entra en conflicto con un Record publicado, el Record prevalece.
Sección 3 — Identidad
¿Por qué el protocolo no usa URLs como identificadores?
Porque las ubicaciones cambian.
La identidad debe permanecer estable aunque el almacenamiento, el alojamiento o los mecanismos de publicación evolucionen.
Los identificadores canónicos identifican el objeto publicado.
Los mecanismos de descubrimiento localizan su representación actual.
¿Qué es un identificador canónico?
Un identificador canónico es la identidad estable asignada a un objeto publicado del protocolo.
Permanece independiente de:
- —los nombres de archivo;
- —las URLs;
- —las bases de datos;
- —los formatos de publicación;
- —y las tecnologías de almacenamiento.
¿Qué es la resolución de identidad?
La resolución de identidad es el proceso de localizar la representación actual asociada a un identificador canónico.
Pertenece a la capa de lectura del protocolo.
No cambia la identidad en sí.
¿Puede cambiar un identificador?
El protocolo distingue entre identidad y representación.
Si la identidad en sí debe corregirse, el protocolo publica una reidentificación en lugar de cambiar en silencio las publicaciones históricas.
Sección 4 — Versionado
¿Por qué hay varios tipos de versión?
Porque cosas distintas evolucionan de forma independiente.
El protocolo distingue:
- —el versionado documental;
- —el versionado normativo;
- —el versionado de representación.
Cada uno responde a una pregunta diferente.
¿Cada nueva versión de documento cambia el protocolo?
No.
Muchas revisiones documentales mejoran la redacción, la estructura o la presentación sin cambiar el significado normativo.
¿Qué es una versión de representación?
Identifica una expresión publicada concreta de una definición lógica.
Cambiar una representación no cambia necesariamente el significado.
¿Pueden dos representaciones describir la misma definición?
Sí.
Distintas representaciones canónicas pueden preservar la misma definición lógica.
Sección 5 — Knowledge Graph
¿Qué es el Knowledge Graph?
El Knowledge Graph es la proyección canónica de los conceptos y relaciones publicados establecidos por el protocolo.
Ayuda a lectores y software a navegar por la arquitectura del protocolo.
¿El Knowledge Graph tiene autoridad?
No.
El grafo se genera a partir de los Records.
Los Records siguen siendo la fuente autorizada.
¿El grafo contiene datos de base de datos?
No.
El grafo proyecta conceptos.
No proyecta instancias operativas.
¿Puede el grafo inferir relaciones?
No.
Cada relación mostrada por el grafo debe haber sido publicada antes por el protocolo.
El grafo nunca inventa semántica.
¿Por qué no es visible una relación?
Porque aún no ha sido establecida por un Record publicado.
El grafo no puede proyectar conocimiento no publicado.
Sección 6 — Conceptos e instancias
¿Cuál es la diferencia entre un concepto y una instancia?
Un concepto pertenece al protocolo.
Una instancia pertenece a una implementación.
El protocolo publica definiciones.
Las aplicaciones almacenan ocurrencias de esas definiciones.
¿Por qué el grafo no muestra todos los hechos operativos?
Porque los hechos operativos pertenecen a las implementaciones.
El grafo representa intencionadamente solo el conocimiento publicado del protocolo.
¿Pueden las implementaciones extender el protocolo?
Sí.
Pueden introducir conceptos y comportamientos locales.
Esas extensiones siguen siendo propias de la implementación hasta que el protocolo las publique formalmente.
Sección 7 — Reidentificación
¿Qué es la reidentificación?
La reidentificación preserva la continuidad de una definición publicada cuando su identidad o su representación canónica debe corregirse.
El significado permanece sin cambios.
¿La reidentificación es lo mismo que la sucesión?
No.
La sucesión introduce un objeto normativo distinto.
La reidentificación preserva la misma definición lógica a través de una identidad o representación corregida.
¿Por qué son necesarias ambas relaciones?
Porque responden a preguntas diferentes.
La sucesión explica la evolución semántica.
La reidentificación explica la continuidad.
Sección 8 — Implementaciones
¿Debe cada implementación usar la misma base de datos?
No.
El protocolo especifica el significado.
Las implementaciones son libres de elegir su propia tecnología.
¿Deben las implementaciones exponer todos los conceptos del protocolo?
No.
Pueden implementar solo los conceptos relevantes para su propósito.
¿Puede una implementación añadir campos locales?
Sí.
Siempre que esos campos no se representen como si fueran conceptos del protocolo.
¿La conformidad con el protocolo trata sobre la arquitectura de software?
No.
La conformidad concierne a la preservación del significado publicado, no a la implementación interna.
Sección 9 — IA
¿Pueden los sistemas de IA usar el protocolo?
Sí.
Los conceptos y relaciones explícitos del protocolo lo hacen adecuado para la recuperación y el razonamiento estructurados.
¿El protocolo garantiza que las respuestas de una IA sean correctas?
No.
El protocolo garantiza el origen y la estructura de la información publicada.
La interpretación correcta sigue siendo responsabilidad del sistema que la consume.
¿Puede una IA inventar relaciones del protocolo?
No.
Las interpretaciones generadas deben seguir siendo distinguibles de los hechos publicados del protocolo.
Sección 10 — Gobernanza
¿Cómo evoluciona el protocolo?
Mediante procesos de gobernanza publicados y nuevos Records.
Los cambios pasan a formar parte del protocolo solo una vez que se han establecido formalmente.
¿Pueden reescribirse los hechos publicados?
No.
Las publicaciones históricas siguen formando parte del historial documental.
La evolución ocurre mediante nuevas publicaciones, no mediante modificación silenciosa.
¿Por qué preservar los estados históricos?
Porque la reproducibilidad, la trazabilidad y la auditabilidad requieren que el historial de publicación del protocolo permanezca observable.
Sección 11 — Interoperabilidad
¿Qué hace que dos implementaciones sean interoperables?
Preservan el mismo significado publicado.
No necesitan arquitecturas de software idénticas.
¿La interoperabilidad requiere APIs idénticas?
No.
Requiere una interpretación compatible de los conceptos del protocolo.
¿La interoperabilidad requiere bases de datos idénticas?
No.
El protocolo estandariza la semántica, no el almacenamiento.
¿Qué ocurre si las implementaciones discrepan?
El protocolo publicado proporciona la referencia común utilizada para resolver las diferencias semánticas.
Conclusion
Si estás descubriendo el protocolo, empieza por los Records publicados.
Si lo estás implementando, continúa con la documentación de Desarrolladores.
Si quieres entender cómo se conectan los conceptos, explora el Knowledge Graph.
Los conceptos presentados en esta guía están definidos por los Records publicados del World Skills Protocol. Habrá recursos terminológicos adicionales a medida que avance la gobernanza terminológica del protocolo.
Juntos, estos recursos explican el protocolo desde perspectivas complementarias, permaneciendo anclados en el mismo corpus canónico.
Seguir explorando el protocolo
Elige el recurso que mejor se ajuste a tu objetivo.