> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Modelo de extensión **Especificación del Meta-Universo** **ID del documento:** MU-V2-ARCH-005 **Título:** Estándar de arquitectura de meta-modelos - importar y extender modelos externos **Clase de documento:** normativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** Constitución del Meta-Universo (MUC), MMAS-Core, MMAS-Package **Referencias informativas:** Versioning, Naming-Conventions, [Meta-Model-Composition](Meta-Model-Composition.md) **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Este documento define cómo los Meta-Modelos del Meta-Universo DEBERÁN importar, referenciar y extender modelos semánticos externos preservando la interoperabilidad, la integridad semántica y la mantenibilidad a largo plazo. El objetivo es fomentar la reutilización de estándares existentes en lugar de redefinir conceptos que ya existen. --- # 2. Alcance Esta especificación se aplica a: - modelos semánticos importados; - espacios de nombres importados; - objetos importados; - relaciones importadas; - vocabularios importados; - extensiones locales; - correspondencias semánticas. --- # 3. Principio arquitectónico El Meta-Universo DEBERÁ preferir la **extensión frente a la duplicación**. Los estándares semánticos existentes DEBERÍAN importarse siempre que ya describan el concepto necesario con suficiente precisión. Mientras este documento gobierna *la importación y extensión* de un modelo externo, la cuestión estructural de si un concepto debe ser un campo literal, un Meta-Modelo anidado (embebido) o una referencia a un modelo gobernado por separado se especifica en [Meta-Model-Composition](Meta-Model-Composition.md). --- # 4. Paquete semántico Un estándar externo NO DEBERÁ importarse como una colección suelta de objetos. DEBERÁ importarse como **paquete semántico**: una unidad única, versionada y autodescriptiva que recoge la importación por completo y sobre la que se puede razonar como un todo. Es el análogo, en conocimiento semántico, de un gestor de paquetes de software, donde una dependencia se adquiere como artefacto con nombre y versión en lugar de copiarse a trozos. Un paquete semántico DEBERÁ declarar como mínimo: - **Declaración de origen** - el estándar de procedencia y su autoridad (por ejemplo Schema.org, O\*NET, HL7 FHIR); - **Espacios de nombres importados** - los espacios de nombres traídos desde el origen; - **Objetos seleccionados** - los conceptos concretos importados, en lugar de todo el origen; - **Extensiones locales** - las extensiones añadidas sobre los conceptos importados, identificables por separado; - **Correspondencias semánticas** - las correspondencias explícitas entre conceptos importados y locales (véase la Sección 10); - **Restricciones de compatibilidad** - las condiciones bajo las cuales el paquete sigue siendo válido; - **Rango de versiones compatible** - el rango de versiones del origen con las que se sabe que el paquete funciona; - **Huella semántica** - la propia [huella semántica](Versioning.md) del paquete, para que los consumidores puedan detectar si dos importaciones del «mismo» estándar coinciden realmente en significado. Tratar una importación como paquete semántico da a toda dependencia una identidad estable, un rango de versiones y una huella, exactamente como hace un gestor de paquetes con el código, pero aplicado al conocimiento semántico. El paquete semántico es la vista en el momento de la importación; su forma distribuible y publicable es el **Paquete de distribución semántica (SDP)** definido en [MMAS-Package](MMAS-Package.md), que lleva las mismas declaraciones más el empaquetado, la firma y los metadatos de conformidad. --- # 5. Modelo de importación Un modelo importado DEBERÁ seguir siendo una autoridad semántica independiente. Importar un modelo NO DEBERÁ transferir la propiedad de: - la semántica; - los identificadores; - las versiones; - la gobernanza. El estándar de origen sigue siendo autoritativo. --- # 6. Metadatos de la importación Todo modelo importado DEBERÁ declarar al menos: - el estándar de origen; - el espacio de nombres; - la versión importada; - la fecha de importación; - el propietario local; - una declaración de compatibilidad. --- # 7. Espacios de nombres importados Los conceptos importados DEBERÁN preservar su espacio de nombres original siempre que sea practicable. Ejemplos: schema:Person fhir:Patient odata:Entity bpmn:Process PUEDEN existir alias locales, pero NO DEBERÁN sustituir a las referencias canónicas. --- # 8. Modelo de extensión Los modelos locales PUEDEN extender conceptos importados. Las extensiones DEBERÁN: - preservar el significado original; - evitar modificar la semántica importada; - seguir siendo identificables por separado; - declarar propiedad. Enfoque preferente: Concepto importado + Extensión local = Concepto extendido --- # 9. Modificaciones prohibidas Una implementación NO DEBERÁ: - redefinir la semántica importada; - renombrar en silencio conceptos importados; - cambiar identificadores importados; - reclamar la propiedad de estándares importados. Si se requiere un comportamiento incompatible, DEBERÁ crearse un nuevo concepto local. --- # 10. Correspondencia semántica Las correspondencias DEBERÁN describir explícitamente la relación entre conceptos importados y locales. Los tipos de correspondencia admitidos PUEDEN incluir: - Equivalente - Extensión - Especialización - Generalización - Derivado de - Correspondencia parcial - Requiere transformación Las correspondencias DEBERÁN tener en cuenta la versión. --- # 11. Gestión de versiones Los modelos importados DEBERÁN preservar referencias a sus versiones originales. Las extensiones locales DEBERÁN declarar su compatibilidad con la versión importada. Los cambios en los estándares importados DEBERÍAN desencadenar una evaluación de compatibilidad y no una migración automática. --- # 12. Modelos de múltiples orígenes Un Meta-Modelo PUEDE importar varios estándares externos simultáneamente. Ejemplo: - schema.org - OData - FHIR - O*NET - BPMN Los conflictos DEBERÁN resolverse explícitamente mediante correspondencias semánticas. --- # 13. Propiedad La propiedad de los conceptos importados permanece en el estándar de origen. La propiedad de las extensiones locales pertenece al Meta-Modelo que extiende. Los límites de propiedad DEBERÁN permanecer explícitos. --- # 14. Trazabilidad Todo concepto importado DEBERÁ seguir siendo trazable hasta su origen. La trazabilidad DEBERÍA identificar: - el estándar de origen; - el espacio de nombres; - el identificador original; - la versión importada; - el historial de extensiones. --- # 15. Federación Los universos federados DEBERÍAN intercambiar referencias semánticas canónicas siempre que ambas partes admitan el mismo estándar importado. Cuando se usen estándares distintos, la federación DEBERÍA apoyarse en correspondencias semánticas explícitas y no en supuestos implícitos. --- # 16. Flujo de importación recomendado 1. Descubrir un estándar semántico existente. 2. Evaluar su idoneidad semántica. 3. Importar el concepto canónico. 4. Preservar espacio de nombres y versión. 5. Añadir extensiones locales solo donde sea necesario. 6. Publicar las correspondencias semánticas. 7. Mantener la compatibilidad durante la evolución. --- # 17. Ejemplos típicos Algunos estándares adecuados para importar: - Schema.org - OData CSDL - Vocabularios RDF / OWL - Esquemas OpenAPI - BPMN - DMN - HL7 FHIR - O*NET - ESCO - ArchiMate - IFC - OPC UA La lista es informativa y no exhaustiva. --- # 18. Invariantes arquitectónicos Importar modelos externos NUNCA DEBERÁ vulnerar: - la Constitución del Meta-Universo; - la identidad semántica; - la procedencia; - la propiedad; - la trazabilidad; - la integridad de versiones. --- # 19. Direcciones futuras El paquete semántico establece la unidad de dependencia en el momento de la importación. Una dirección futura es normalizar la gestión de estos paquetes en una federación: resolución de dependencias, importaciones transitivas, resolución de rangos de versiones y arbitraje de conflictos entre estándares solapados, al modo de un ecosistema de paquetes consolidado. Esto converge con el **Registro de paquetes semánticos** que anticipa [MMAS-Package](MMAS-Package.md), en el que los paquetes semánticos se publican, descubren y resuelven por su [huella semántica](Versioning.md) y su rango de versiones compatible en lugar de copiarse ad hoc. --- # Declaración final El Meta-Universo está diseñado para convertirse en una federación de estándares semánticos, no en su sustituto. El enfoque arquitectónico preferente es descubrir, importar, referenciar y extender modelos semánticos existentes preservando su identidad, gobernanza y significado. Esto habilita un ecosistema global de Meta-Modelos interoperables que evolucionan de forma colaborativa en lugar de fragmentarse en islas semánticas aisladas.