> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Convenciones de nomenclatura **Especificación del Meta-Universo** **ID del documento:** MU-V2-ARCH-003 **Título:** Estándar de arquitectura de meta-modelos - convenciones de nomenclatura **Clase de documento:** normativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** Constitución del Meta-Universo (MUC), MMAS-Core **Referencias informativas:** Versioning, Protocolo de Federación del Meta-Universo (MUFP) **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Este documento define las reglas de nomenclatura empleadas en todo el ecosistema del Meta-Universo. Una nomenclatura coherente mejora la localizabilidad, la interoperabilidad semántica, la federación, la automatización y el mantenimiento a largo plazo. --- # 2. Alcance Estas reglas se aplican a: - los estándares del Meta-Universo; - los meta-modelos; - los paquetes (bundles); - las capas; - los objetos; - las propiedades; - las relaciones; - los eventos; - los contratos; - los perfiles de proyección; - los espacios de nombres. Las implementaciones PUEDEN definir convenciones locales adicionales siempre que sigan siendo compatibles con esta especificación. --- # 3. Principios de nomenclatura Los nombres DEBERÁN ser: - inequívocos; - estables; - legibles por humanos; - legibles por máquinas; - independientes de la tecnología; - semánticamente significativos. Los nombres DEBERÁN describir conceptos, no detalles de implementación. --- # 4. Idioma canónico El inglés DEBERÁ ser el idioma canónico de todos los nombres normativos. Las etiquetas localizadas PUEDEN proporcionarse como metadatos. Los identificadores canónicos DEBERÁN permanecer independientes del idioma. --- # 5. Identificador frente a nombre visible Todo artefacto significativo DEBERÍA distinguir entre: - Identificador (estable) - Nombre visible (cómodo para humanos) Ejemplo: Identificador: employee.performance-review Nombre visible: Employee Performance Review Los nombres visibles PUEDEN cambiar. Los identificadores DEBERÍAN permanecer estables. --- # 6. Nombre semántico canónico (CSN) La distinción entre identificador y nombre visible se generaliza, para todo concepto público, en un **nombre semántico canónico (Canonical Semantic Name, CSN)**. Cada concepto público DEBERÁ tener ambos: - un **nombre humano / visible** - localizado, cómodo para las personas y libre de cambiar (por ejemplo, "Salary Agreement"); - un **nombre semántico canónico (CSN)** inmutable - un identificador de significado estable e independiente de la tecnología (por ejemplo, `employee.compensation.salaryAgreement`). Ejemplo: ```text Display Name : Salary Agreement CSN : employee.compensation.salaryAgreement ``` El CSN es análogo a un nombre de clase plenamente cualificado o a un URI de RDF, pero es deliberadamente **independiente de la tecnología**: no se compromete con ningún lenguaje de programación, serialización ni transporte. Expresa la posición de un concepto dentro de su jerarquía semántica y nada más. Reglas: - Cada concepto público DEBERÁ tener exactamente un CSN. - Un CSN DEBERÁ ser inmutable una vez publicado; renombrar un concepto DEBERÁ tratarse como un cambio semántico según [Versioning](Versioning.md) y DEBERÁ producir un CSN nuevo, nunca una reescritura silenciosa del existente. - Todas las **interacciones de federación DEBERÁN intercambiar CSN**. El Protocolo de Federación del Meta-Universo (MUFP) transmite CSN; NO DEBERÁ apoyarse en nombres visibles para la identidad. - Las interfaces de usuario DEBERÍAN presentar el nombre visible localizado resolviéndolo al CSN subyacente. - Los nombres visibles PUEDEN diferir entre idiomas, contextos y presentaciones; el CSN DEBERÁ permanecer igual. Para evitar colisiones de nombres en una federación, un CSN DEBERÍA ir acompañado de la [huella semántica](Versioning.md) de la versión que define el concepto. Juntos, el CSN identifica *qué concepto* y la huella identifica *qué significado*, de modo que dos universos que usan el mismo CSN pueden detectar si de verdad coinciden en su semántica antes de confiar en ella. --- # 6a. Gramática del CSN y esquema de identificadores Para que los CSN y los identificadores sean verificables por máquina, esta sección da su gramática formal. Un **nombre semántico canónico** DEBERÁ ajustarse a la siguiente ABNF (RFC 5234): ```abnf CSN = segment *("." segment) segment = lower *(ALPHA / DIGIT) lower = %x61-7A ; a-z (a segment SHALL start lowercase) ALPHA = %x41-5A / %x61-7A DIGIT = %x30-39 ``` El primer `segment` es el **espacio de nombres**; los segmentos restantes nombran el concepto dentro de él (por ejemplo, `employee.compensation.salaryAgreement` - espacio de nombres `employee`). Esta gramática es la fuente normativa del patrón `csn` en [`schemas/common.schema.json`](../schemas/common.schema.json) y la impone la comprobación `V2-03` de [Validation](Validation.md). Un **identificador** (el `id` de un objeto, relación, evento, contrato o proyección, y el valor de una identidad local) es opaco y DEBERÁ ser estable durante toda la vida de aquello que nombra. Una implementación DEBERÁ adoptar uno de los siguientes esquemas de identificador y declararlo para que los consumidores puedan resolverlo: | Esquema | Forma | Ejemplo | |--------|------|---------| | `uuid` | un UUID | `9d3f2c1a-...` | | `uri` | un URI absoluto | `https://acme.example/person/12345` | | `urn` | un URN | `urn:mu:person:9d3f2c1a` | | `qname` | `scheme:value` dentro de un Universo | `employee:12345` | Los identificadores DEBERÁN compararse como cadenas de bytes exactas; NO DEBERÁN plegarse por mayúsculas ni normalizarse. Una [identidad canónica](../04-core-concepts/Identity.md) empareja un esquema con un valor (`{ "scheme": "urn", "value": "urn:mu:person:9d3f2c1a" }`). PUEDEN registrarse esquemas nuevos sin romper los identificadores existentes. --- # 7. Convención de espacios de nombres Todo concepto público DEBERÁ pertenecer a un espacio de nombres. Formato recomendado: namespace:Concept Ejemplos: employee:Skill organization:Department product:Capability schema:Person fhir:Patient Los espacios de nombres DEBERÁN ser globalmente únicos dentro de su ámbito semántico. --- # 8. Nomenclatura de meta-modelos Los meta-modelos DEBERÍAN usar nombres descriptivos. Ejemplos recomendados: Employee Meta-Model Product Landscape Meta-Model Enterprise Landscape Meta-Model Evite nombres específicos de una implementación. --- # 9. Nomenclatura de paquetes Los nombres de paquete DEBERÍAN ser sustantivos que representen dominios semánticos. Ejemplos: Identity Knowledge Governance Runtime History Security --- # 10. Nomenclatura de capas Una capa DEBERÁ representar una única preocupación semántica coherente. Los nombres de capa DEBERÍAN: - usar sustantivos en singular; - evitar abreviaturas; - evitar nombres de tecnologías. Ejemplos: Employment History Projects Compensation Competencies --- # 11. Nomenclatura de objetos Los nombres de objeto DEBERÍAN: - usar sustantivos en singular; - representar entidades reales o conceptuales; - evitar terminología de implementación. Preferible: Employee Project Skill Evitar: EmployeeTable ProjectDTO SkillRecord --- # 12. Nomenclatura de propiedades Los nombres de propiedad DEBERÍAN: - describir hechos; - usar lowerCamelCase; - evitar prefijos; - evitar sufijos de implementación. Preferible: firstName createdAt currentPosition Evitar: emp_name fld1 col_employee --- # 13. Nomenclatura de relaciones Los nombres de relación DEBERÍAN describir el significado semántico. Ejemplos: worksFor reportsTo owns dependsOn assignedTo DEBERÍAN evitarse nombres genéricos como "link" o "relation". --- # 14. Nomenclatura de eventos Los eventos DEBERÍAN describir hechos consumados. Patrón recomendado: Ejemplos: EmployeeCreated ContractSigned ProjectArchived Evite nombres en imperativo. --- # 15. Nomenclatura de contratos Los contratos DEBERÍAN describir el propósito de negocio o semántico. Ejemplos: Employment Contract Knowledge Disclosure Contract Federation Agreement Evite nombres orientados a la implementación. --- # 16. Nomenclatura de ficheros Los documentos de especificación DEBERÍAN usar: Title-Case-With-Hyphens.md Ejemplos: Meta-Universe-Constitution.md Federation-Contracts.md Identity-Binding.md Los ficheros de ejemplo DEBERÍAN incluir el sufijo: .example.yaml --- # 17. Términos reservados Los siguientes términos están reservados por la familia de estándares del Meta-Universo: Universe Dimension Namespace Meta-Model Bundle Layer Object Projection Relationship Event Contract Context Identity Estos términos NO DEBERÁN redefinirse con significados incompatibles. --- # 18. Estándares importados Los conceptos importados DEBERÁN conservar sus nombres originales siempre que sea practicable. Las extensiones locales DEBERÍAN extender los conceptos importados en lugar de renombrarlos. Ejemplo: schema:Person ↓ employee:Employee --- # 19. Estabilidad de la nomenclatura Los identificadores DEBERÁN permanecer estables a lo largo de versiones compatibles. El renombrado DEBERÍA tratarse como un cambio semántico. DEBERÁ proporcionarse guía de migración siempre que cambien los identificadores. --- # 20. Direcciones futuras El nombre semántico canónico establece una capa de identidad estable e independiente de la tecnología que el trabajo futuro puede desarrollar en una **guía de estilo semántico**: un estándar complementario que defina la gramática de los segmentos del CSN, las reglas de mayúsculas y pluralización, la profundidad de jerarquía recomendada y el algoritmo de resolución por el cual un nombre visible localizado se corresponde con un CSN en distintos idiomas. Una guía así especificaría también un servicio de resolución de CSN para toda la federación, de modo que cualquier universo pueda desreferenciar un CSN hasta la versión que lo define y su [huella semántica](Versioning.md), cerrando el círculo entre nomenclatura y significado. --- # Declaración final Una nomenclatura coherente es requisito previo de la interoperabilidad semántica. El propósito de estas convenciones no es solo la coherencia estilística, sino la creación de modelos semánticos estables y comprensibles en todo el mundo, capaces de evolucionar, federarse e interpretarse de forma fiable tanto por personas como por sistemas de IA.