> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Composición de Meta-Modelos **Especificación del Meta-Universo** **ID del documento:** MU-V2-ARCH-016 **Título:** Estándar de arquitectura de meta-modelos - composición, anidamiento y conectores **Clase de documento:** normativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** Constitución del Meta-Universo (MUC), MMAS-Core, [Extension-Model](Extension-Model.md), [Semantic-Mapping](../03-federation/Semantic-Mapping.md) **Referencias informativas:** [Relationship](../04-core-concepts/Relationship.md), [Object](../04-core-concepts/Object.md), [Projection](../04-core-concepts/Projection.md), [Connector-Catalogue](../06-ecosystem/Connector-Catalogue.md), [External-Models-Registry](../06-ecosystem/External-Models-Registry.md) **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito [Extension-Model](Extension-Model.md) define cómo un Meta-Modelo **importa y extiende** un estándar externo. [Semantic-Mapping](../03-federation/Semantic-Mapping.md) define cómo dos Meta-Modelos soberanos **alinean significado** sin fusionarse. Este documento cubre la capa intermedia: la **composición estructural**, es decir, cómo se relacionan las *Propiedades* de un Meta-Modelo con *otros Meta-Modelos*, y la regla para decidir, ante cualquier concepto, si debe ser: - una **Propiedad literal** (un campo) que posee el propio Meta-Modelo; o - un Meta-Modelo anidado **embebido** (el tipo de la Propiedad *es* otro modelo); o - una **referencia** a una entidad o lista de códigos gobernada por separado. Sin esta capa, los modelos registrados son islas semánticas: un mismo concepto (una dirección, un país, un importe monetario, un registro de procedencia) se vuelve a modelar de forma independiente en decenas de Meta-Modelos con formas divergentes, de modo que duplican campos y no pueden componerse, unirse ni validarse juntos. Este documento define los principios, mecanismos y conectores que convierten el catálogo de [modelos externos](../06-ecosystem/External-Models-Registry.md) en un tejido conectado. --- # 2. El problema de la composición Quien redacta un Meta-Modelo se topa una y otra vez con un concepto que *podría* ser un campo simple pero que en realidad es una cosa que el ecosistema ya modela. Tratar todo concepto así como campo local produce tres fallos: - **Bifurcación** - `street`, `city`, `postcode`, `country` modelados improvisadamente en un Meta-Modelo y de otro modo en el siguiente: el concepto de Dirección queda bifurcado y ambos no pueden interoperar. - **Deriva** - una lista de países o divisas copiada en una enumeración local se aparta en silencio de la autoridad que la mantiene. - **Obsolescencia** - los atributos de un empleador incrustados dentro de una Persona en lugar de referenciados: cada Persona lleva una copia privada y envejecida de la misma Organización. El Meta-Universo DEBERÁ preferir la **composición frente a la duplicación**, la contrapartida estructural del principio de **extensión frente a duplicación** de [Extension-Model](Extension-Model.md) §3. El resto de este documento hace operativa esa preferencia. --- # 3. Clases de concepto Todo concepto que aparezca en un Meta-Modelo DEBERÁ clasificarse, a efectos de representación, como exactamente una de las clases siguientes. La clase determina el mecanismo de composición permitido (§4) mediante la guía de decisión (§5). | Clase | Definición | Prueba | Representación por defecto | |------|------------|------|------------------------| | **Atributo** | Un valor literal sin identidad propia, sin estructura interna y sin autoridad externa sobre sus valores. | «¿Es solo un valor que posee el anfitrión?» | Propiedad (campo) | | **Objeto de valor** | Un paquete estructurado de subvalores que viajan juntos y son iguales cuando lo son sus partes; carece de identidad propia. | «¿Tiene ≥2 partes que solo tienen sentido como unidad?» | EMBED | | **Entidad** | Una cosa con identidad y ciclo de vida propios, referenciable y compartible con independencia de cualquier anfitrión. | «¿Pueden otros Objetos apuntarle; puede crearse, versionarse y poseerse por sí sola?» | REFERENCE | | **Código / clasificador** | Un miembro de un conjunto de valores, clasificación o esquema de identificadores gobernado por una autoridad externa. | «¿El conjunto de valores permitidos lo mantiene otro?» | REFERENCE (al esquema) | | **Faceta** | Una preocupación transversal asociada a muchos Objetos con independencia del dominio: procedencia, tiempo de validez, política, marca de seguridad, etiquetas multilingües. | «¿Es esto *sobre* los datos y no *parte* de la carga del dominio?» | MIX-IN | La clase de un concepto es una decisión de modelado, no una verdad intrínseca: la misma palabra («dirección», «organización») puede ser una Entidad en un Meta-Modelo y una instantánea de Objeto de valor en otro. El autor DEBERÁ registrar la clase elegida para que validadores y consumidores puedan razonar sobre ella. --- # 4. Mecanismos de composición Seis mecanismos conectan Meta-Modelos. Cada uno tiene un perfil distinto de acoplamiento y soberanía. Dos de ellos, **EXTEND** y **MAP**, se especifican en otros documentos y se enumeran aquí solo por completitud; este documento especifica **EMBED**, **REFERENCE** y **MIX-IN**. | # | Mecanismo | Qué hace | Acoplamiento | Soberanía | Especificado en | |---|-----------|--------------|----------|-------------|--------------| | 1 | **EMBED** (composición) | El tipo de una Propiedad *es* otro Meta-Modelo; el valor viaja dentro del anfitrión como Objeto anidado sin identidad propia. | Fuerte: el compuesto lo posee el anfitrión | Se reutiliza la *forma* del modelo anidado; su autoridad se preserva | **este documento** | | 2 | **REFERENCE** (asociación) | Una Propiedad guarda un identificador que se resuelve contra una entidad o esquema de códigos externo; el referente vive y se gobierna en otra parte. | Débil | Plenamente preservada: el referente sigue siendo soberano | **este documento** | | 3 | **MIX-IN** (faceta / rasgo) | Las Propiedades de un Paquete transversal se aplican uniformemente a muchos Objetos anfitriones bajo su propio espacio de nombres. | Ortogonal | El modelo de la faceta sigue siendo autoritativo | **este documento** | | 4 | **EXTEND** (especialización) | El Meta-Modelo anfitrión es-un / refina un modelo importado, añadiendo restricciones o Propiedades. | Fuerte (subtipo) | Según las reglas de importación | [Extension-Model](Extension-Model.md) §8 | | 5 | **MAP** (alineación) | Dos modelos soberanos declaran equivalencias de campos sin cambio estructural. | Ninguno (estructural) | Máxima | [Semantic-Mapping](../03-federation/Semantic-Mapping.md) | | 6 | **ANNOTATE** (etiquetado) | Un concepto de vocabulario controlado se asocia a una Propiedad por significado, no por estructura. | Ninguno | Máxima | este documento (§4.3) | ## 4.1 EMBED EMBED se usa para **Objetos de valor**. La Propiedad del anfitrión se tipa con otro Meta-Modelo (preferiblemente uno importado como [paquete semántico](Extension-Model.md §4)), y el valor embebido: - DEBERÁ preservar el espacio de nombres, la versión y la [huella semántica](Versioning.md) del modelo embebido; - NO DEBERÁ aplanarse en Propiedades improvisadas del anfitrión; - **no tiene identidad propia** dentro del anfitrión: es un valor, igual a cualquier otro valor embebido con las mismas partes; - aporta su forma a la propia huella semántica del anfitrión, de modo que dos anfitriones que «tienen una dirección» puedan demostrarse de acuerdo sobre qué es una dirección. EMBED es el mecanismo correcto precisamente cuando un concepto tiene estructura interna que se repite por todo el ecosistema (Dirección, Dinero, Cantidad, Punto geográfico, Nombre personal, Intervalo temporal). ## 4.2 REFERENCE REFERENCE se usa para **Entidades** y **Códigos**. La Propiedad del anfitrión guarda un identificador, no una copia del contenido del referente. - **Referencia a entidad** - se modela como una [Relación](../04-core-concepts/Relationship.md) con un Meta-Objeto identificado por su identificador canónico, o como una Propiedad identificadora tipada por un esquema de identificadores. Los atributos del referente NO DEBERÁN incrustarse; se obtienen resolviendo la referencia (sujeto a [Contrato](../04-core-concepts/Contract.md) y [Proyección](../04-core-concepts/Projection.md) cuando el referente está en otro Universo). - **Referencia a código** - se modela como una Propiedad cuyo valor es «un término tomado del esquema *S*», que lleva la URI y la versión del esquema. Los miembros de *S* NO DEBERÁN copiarse en una enumeración local; llevar esquema y versión hace detectable la deriva. Una referencia PUEDE **instantanearse**, es decir, embeberse como copia de valor inmutable, cuando la auditoría o la inmutabilidad exigen una vista congelada (por ejemplo, una Proyección que captura una dirección tal como estaba en un momento dado). Una instantánea DEBERÁ marcarse como tal y DEBERÁ registrar el identificador de origen y el Evento de captura, para que nunca se confunda con el referente vivo. Esta es la cara legítima de la «duplicación» (§6). ## 4.3 MIX-IN y ANNOTATE Una **Faceta** DEBERÁ aplicarse como MIX-IN: un Paquete de faceta declarado cuyas Propiedades se funden en el anfitrión bajo su propio espacio de nombres y se aplican uniformemente a muchos Objetos (por ejemplo, procedencia `prov:*` en todo Objeto, tiempo de validez en todo Objeto versionado, política `odrl:*` en un Contrato). Una Faceta NO DEBERÁ reinventarse como campos de dominio a medida, ni DEBERÁ enterrarse en la carga del dominio: es algo *sobre* los datos. ANNOTATE asocia un concepto de vocabulario controlado (un concepto SKOS, un tipo de schema.org) a una Propiedad para fijar su significado sin cambiar su estructura. Es el mecanismo más ligero y preserva la soberanía por completo. --- # 5. La guía de decisión Para cualquier concepto *C* que aparezca en el Meta-Modelo *M*, aplique las pruebas siguientes **en orden**; la primera que encaje fija la representación. 1. **Prueba de faceta (ortogonal, se aplica primero).** ¿Es *C* una preocupación transversal (procedencia, tiempo de validez, política de acceso, marca de seguridad, etiqueta multilingüe) en lugar de carga del dominio? → **MIX-IN** del modelo de faceta correspondiente. Fin. 2. **Prueba de identidad.** ¿Denota *C* una cosa con identidad y ciclo de vida propios, a la que se puede referir y que puede crearse, versionarse o poseerse con independencia de *M*? → *C* es una **Entidad**: **REFERENCE** por identificador. Embeba solo como **instantánea** marcada cuando la inmutabilidad o la auditoría lo exijan. Fin. 3. **Prueba de autoridad.** ¿Están ya gobernados por un estándar externo el conjunto de valores permitidos de *C* o su estructura interna? - Una **lista de códigos / clasificación / esquema de identificadores** → **REFERENCE** a ese esquema (término + URI del esquema + versión). Nunca copie sus miembros. Fin. - Un **estándar de objeto de valor estructurado** (Dirección, Dinero, …) → prefiera ese modelo canónico y continúe con la prueba de estructura. 4. **Prueba de estructura.** ¿Tiene *C* estructura interna, dos o más subvalores que viajan juntos y carecerían de sentido repartidos por el anfitrión? → *C* es un **Objeto de valor**: **EMBED** como Meta-Modelo anidado (preferiblemente uno canónico importado). No aplane sus partes. Fin. 5. **Prueba de reutilización.** Aunque *C* sea hoy atómico, ¿necesitan dos o más Meta-Modelos del ámbito la misma forma (ahora o de manera previsible)? → extraiga *C* como Objeto de valor compartido y hágale EMBED/REFERENCE, de modo que la forma se defina una sola vez. Fin. 6. **Por defecto.** *C* es un **Atributo**: un literal sin identidad propia, sin autoridad externa, sin estructura interna y sin reutilización entre modelos. Represéntelo como **Propiedad (campo)**. Duplicar ese campo entre Meta-Modelos es aceptable (§6). ```text ┌───────────────────────────────────────────────┐ concept C │ 1. cross-cutting concern? ── yes ─▶ MIX-IN │ │ 2. own identity/lifecycle? ── yes ─▶ REFERENCE │ │ 3. governed value set? ── yes ─▶ REFERENCE │ │ 4. internal structure? ── yes ─▶ EMBED │ │ 5. reused across models? ── yes ─▶ EMBED │ │ 6. otherwise ─────────▶ FIELD │ └───────────────────────────────────────────────┘ ``` Un Meta-Modelo conforme DEBERÍA poder justificar cada Propiedad nombrando la prueba que produjo su representación. --- # 6. Cuándo la duplicación es aceptable Composición frente a duplicación es un valor por defecto, no un absoluto. Duplicar un valor, o mantener el «mismo» concepto como campo llano en varios Meta-Modelos, es **correcto** en estos casos: - **Atributos atómicos.** Un `title`, una `quantity`, una `note` de texto libre: un literal sin autoridad compartida. Dos Meta-Modelos que tengan cada uno ese campo no están bifurcando un concepto; tienen dos propiedades independientes que casualmente comparten nombre. - **Instantáneas inmutables.** Una Proyección, un registro de auditoría o una entrada de [preservación de conflictos](../03-federation/Conflict-Resolution.md) que congela deliberadamente una copia de valor por inmutabilidad o localidad. Aquí *la copia es el objetivo*; DEBERÁ marcarse como instantánea con su identificador de origen y su Evento de captura (§4.2). - **Soberanía mediante correspondencia.** Cuando dos modelos se gobiernan de forma independiente y una pasarela ([Semantic-Mapping](../03-federation/Semantic-Mapping.md)) es preferible al acoplamiento estructural, cada uno conserva sus campos y el enlace es un MAP, no un EMBED. - **Evitar la sobrenormalización.** Cuando extraer un modelo compartido añadiría más acoplamiento del que el concepto merece (un valor atómico puntual y genuinamente local), conservar un campo es la elección proporcionada. La duplicación es un **defecto** solo cuando bifurca un Objeto de valor *estructurado*, *copia* una lista de códigos gobernada, *incrusta* una Entidad o *reinventa* una Faceta: los cuatro casos que la guía está diseñada para atrapar. --- # 7. Roles composicionales de los modelos externos Para que la composición sea predecible a escala de ecosistema, a todo modelo externo del [Registro](../06-ecosystem/External-Models-Registry.md) puede asignársele un **rol composicional** que predice cómo deberían enlazarse otros modelos con él. El [Connector-Catalogue](../06-ecosystem/Connector-Catalogue.md) aplica estos roles a los conectores fundacionales, y los 1180 estándares catalogados llevan un rol y un tipo de enlace por defecto en [`external-models.csv`](../06-ecosystem/external-models.csv) (distribución en [External-Models-Registry §3a](../06-ecosystem/External-Models-Registry.md)). | Rol | Descripción | Enlace por defecto | Ejemplos | |------|-------------|--------------|----------| | **R1 Objeto de valor fundacional** | Estructurado, sin identidad, se repite por todas partes | EMBED | Dirección (CIQ xAL), Dinero, Cantidad (QUDT), Punto geográfico, Nombre personal, Intervalo temporal | | **R2 Datos de referencia / lista de códigos** | Conjunto de valores o clasificación curados | REFERENCE | ISO 3166, ISO 4217, ISO 639, UCUM, GPC, NACE, ESCO, SNOMED CT | | **R3 Esquema de identificadores** | Claves para entidades | REFERENCE | LEI, ISIN, GTIN, GLN, DOI, ORCID/ISNI, IBAN/BIC, DID | | **R4 Modelo de entidad** | Cosas con identidad y ciclo de vida | REFERENCE; EMBED de instantánea | schema:Organization, FHIR Patient, W3C ORG, schema:Place | | **R5 Faceta transversal** | Preocupaciones aplicadas a muchos Objetos | MIX-IN | PROV-O, OWL-Time, ODRL, etiquetas SKOS-XL | | **R6 Agregado / documento** | Compone R1-R5 en un documento | compone (rara vez embebido) | UBL Invoice, C-CDA, EPCIS Event, Order | | **R7 Ontología superior / fundamento** | Anclaje ontológico | ALIGN / ANNOTATE | BFO, DOLCE, nivel superior de ISO 15926, Common Logic | | **R8 Herramientas de correspondencia** | Implementan MAP / transformación | n/a (herramientas) | R2RML, RML, SAWSDL | Los roles son orientación, no ley: un modelo PUEDE embeberse en un contexto y referenciarse en otro. El rol nombra el enlace *típico* y *recomendado*. --- # 8. Expresar la composición en MMAS Cada mecanismo tiene una expresión concreta en MMAS. Todo enlace, sea cual sea el mecanismo, DEBERÁ preservar el **espacio de nombres, la versión, la procedencia y la huella semántica** del modelo enlazado, y NO DEBERÁ vulnerar los invariantes de importación de [Extension-Model](Extension-Model.md) §18. - **EMBED** - una Propiedad tipada con un tipo de Meta-Objeto de otro Espacio de nombres; el modelo embebido se declara como dependencia de paquete semántico; la huella del anfitrión incorpora la forma embebida. - **REFERENCE (entidad)** - una [Relación](../04-core-concepts/Relationship.md) con un Meta-Objeto, o una Propiedad tipada por identificador; las referencias entre Universos se gobiernan por Contrato y se intercambian como Proyecciones. - **REFERENCE (código)** - una Propiedad tipada `término ∈ esquema`, que lleva URI y versión del esquema; los validadores PUEDEN comprobar la pertenencia y detectar la deriva. - **MIX-IN** - un Paquete de faceta fundido bajo su propio espacio de nombres; aplicado uniformemente; declarado en la lista de facetas del Meta-Modelo. - **EXTEND** / **MAP** / **ANNOTATE** - según lo especificado en los documentos a los que pertenecen. Un Meta-Modelo DEBERÍA declarar, para cada Propiedad, su **clase de composición** (attribute / embed / reference / mixin) y, en los casos de embed y reference, el identificador y la versión del conector. Esa declaración es lo que hace comprobable por máquina la composición de un modelo. --- # 9. Ejemplo resuelto - `employee.person` Un único concepto de Persona ejercita todos los mecanismos: | Concepto | Clase | Mecanismo | Conector | |---------|------|-----------|-----------| | name | Objeto de valor | EMBED | Nombre personal (CIQ xNL / partes de nombre de schema) | | address | Objeto de valor | EMBED | Dirección postal (CIQ xAL / vCard ADR) | | nationality | Código | REFERENCE | ISO 3166-1 | | primaryLanguage | Código | REFERENCE | ISO 639 (+ escritura ISO 15924) | | salary | Objeto de valor | EMBED | Importe monetario (importe + divisa ISO 4217) | | height | Atributo (+unidad) | FIELD + REFERENCE | valor literal; unidad ∈ UCUM | | employer | Entidad | REFERENCE | Organización por LEI ISO 17442 | | orcid | Identificador | REFERENCE | ORCID / ISNI ISO 27729 | | provenance | Faceta | MIX-IN | PROV-O | | validFrom/validTo | Faceta | MIX-IN | OWL-Time / tiempo de validez del ciclo de vida | | accessPolicy | Faceta | MIX-IN | ODRL | Para la federación, esa misma `person` se **MAPea** después a `fhir:Patient` y `foaf:Person` mediante [Semantic-Mapping](../03-federation/Semantic-Mapping.md): ningún campo de la Persona se duplica para lograr interoperabilidad; solo se declaran correspondencias. --- # 10. Antipatrones - **Objeto de valor aplanado** - `addr_line1`, `addr_city`, `addr_zip` como campos del anfitrión en lugar de una Dirección embebida. Bifurca el concepto; impide unir y validar. - **Lista de códigos copiada** - un enum local `country` en lugar de una referencia a ISO 3166. Se aparta de la autoridad. - **Entidad incrustada** - el nombre, la dirección y el registro de un empleador copiados en cada Persona en lugar de una referencia. Produce duplicados obsoletos; vulnera la soberanía del referente. - **Faceta reinventada** - campos a medida `created_by` / `created_at` / `source` en lugar de un mix-in PROV. Fragmenta la procedencia por todo el ecosistema. - **Sobreembebido** - envolver un atributo genuinamente atómico en un modelo anidado. Acoplamiento innecesario; el error inverso. - **Embeber una entidad por valor** - copiar una cosa que tiene identidad, perdiendo su identidad, su ciclo de vida y su soberanía. Se corresponden uno a uno con los fallos que la guía (§5) está diseñada para evitar y amplían [Errores de diseño comunes](../05-reference-architecture/Anti-Patterns.md). --- # 11. Validación y conformidad Una implementación conforme DEBERÍA validar que: - toda Propiedad declara una clase de composición; - las Propiedades embed y reference nombran un conector y una versión; - las Propiedades tipadas por código llevan URI y versión de esquema (deriva detectable); - ningún grupo de Propiedades reproduce como campos llanos la forma de un conector de Objeto de valor conocido (comprobación de bifurcación); - las instantáneas están marcadas y llevan identificador de origen y Evento de captura. Estas comprobaciones son adiciones recomendadas a los niveles de [Validation](Validation.md) y al [kit de pruebas semánticas](../tests/). Las declaraciones de composición forman parte del propio Meta-Modelo y, por tanto, quedan cubiertas por su huella semántica. --- # 12. Invariantes arquitectónicos La composición NUNCA DEBERÁ vulnerar: - la **Constitución del Meta-Universo** y la soberanía semántica: los modelos referenciados y embebidos conservan su propia autoridad, identidad y gobernanza; - la **procedencia y la trazabilidad**: todo enlace registra origen, espacio de nombres y versión; - la **integridad de versiones**: los enlaces tienen en cuenta la versión; un cambio en un conector desencadena una evaluación de compatibilidad, no una migración silenciosa; - los **invariantes de importación** de [Extension-Model](Extension-Model.md) §18. --- # Declaración final Un campo es la respuesta correcta más veces que no, pero no cuando el «campo» es en secreto una dirección, un país, una organización o un registro de procedencia que el resto del mundo ya modela. La composición de Meta-Modelos da a los autores una única regla para distinguirlos, tres mecanismos (embeber, referenciar, mezclar) para conectarlos entre sí y un catálogo de conectores al que conectarlos. Es la capa que convierte un registro de mil estándares aislados en un tejido componible, donde un concepto se modela una vez y se reutiliza en todas partes, sin que ningún modelo entregue su soberanía.