| name | create-ontology |
| description | Crear, ampliar o borrar clases de una ontología en Stratio Governance, con planificación interactiva a partir de ficheros de referencia (.owl/.ttl, CSVs, documentos de negocio) antes de crear. Usar cuando el usuario quiera modelar la ontología de un dominio, añadir clases a una ya existente, sembrar clases desde documentos de referencia, o eliminar clases obsoletas. Para generar las vistas de negocio a partir de la ontología, preferir create-business-views. |
| argument-hint | [dominio técnico (opcional)] |
Skill: Crear, Ampliar o Borrar Clases de Ontología
Crea, amplia o borra clases de una ontología en Stratio Governance mediante planificación interactiva con el usuario. Fase 2 del pipeline de capa semántica.
Tools MCP utilizadas
| Tool | Servidor | Propósito |
|---|
search_domains(search_text, domain_type='technical') | sql | Preferir. Buscar dominios técnicos por texto libre. Resultados por relevancia |
list_domains(domain_type='technical', refresh?) | sql | Listar todos los dominios técnicos. refresh=true para bypass de cache |
list_domain_tables(domain) | sql | Conocer tablas del dominio |
get_tables_details(domain, tables) | sql | Detalle de tablas: reglas de negocio, contexto |
get_table_columns_details(domain, table) | sql | Columnas de una tabla (para planificar data properties) |
search_domain_knowledge(question, domain) | sql | Buscar conocimiento existente |
search_ontologies(search_text) | gov | Buscar ontologías por texto libre. Resultados por relevancia |
list_ontologies() | gov | Listar todas las ontologías existentes |
get_ontology_info(name) | gov | Estructura de clases, data properties y relaciones |
create_ontology(domain, name, ontology_plan, best_effort?) | gov | Crear ontología nueva con plan en Markdown. Argumento opcional best_effort (bool, off por defecto): entregar el último resultado intentado con warnings si los supervisores siguen rechazando tras todos los reintentos + reconstrucciones del plan. Ver guides/stratio-semantic-layer-tools.md §2 y §7.2 |
update_ontology(domain, name, update_plan, best_effort?) | gov | Añadir clases nuevas a ontología existente. Argumento opcional best_effort (bool, off por defecto): misma semántica que create_ontology. ADD-only — las clases añadidas en modo best-effort solo se pueden eliminar con delete_ontology_classes |
delete_ontology(ontology_name) | gov | DESTRUCTIVO: borrar la ontología entera con todas sus clases (protegido por Published). Útil en el flujo de recuperación tras best-effort (ver workflow §4.b) o para deshacerse de ontologías obsoletas |
delete_ontology_classes(ontology_name, class_names) | gov | DESTRUCTIVO: borrar clases específicas (protegido por Published). Preferido cuando solo unas pocas clases —añadidas en best-effort u otras— necesitan ser eliminadas sin tocar el resto de la ontología |
Reglas clave: domain_name inmutable. Ontologías son ADD+DELETE: update_ontology añade clases; delete_ontology_classes borra clases específicas; delete_ontology borra la ontología entera (protegido: clases con vistas Published dependientes se saltan; las ontologías publicadas no se pueden eliminar). No se pueden modificar clases existentes. Nomenclatura: sin espacios (→ guiones bajos), sin caracteres especiales. Construir el contexto de planificación mediante el Workflow de Enriquecimiento con Instrucciones del Glosario (guides/stratio-semantic-layer-tools.md §11) antes de proponer el plan de ontología. La entrega best-effort mediante el argumento opcional best_effort es opt-in y solo afecta a cómo se gestionan los rechazos de calidad durante la generación de clases/vistas; no anula los fallos previos a la generación (plan no alcanzable con las tablas disponibles, se exceden los topes de tablas/tamaño, servicios de governance no disponibles) — esos siguen provocando el fallo de la llamada.
Workflow
1. Determinar dominio
Si $ARGUMENTS contiene un nombre de dominio, buscar con search_domains($ARGUMENTS, domain_type='technical'). Si no coincide, reintentar con search_domains($ARGUMENTS, domain_type='technical', refresh=true) por si es una colección recién creada. Si ahora coincide, continuar. Si sigue sin coincidir o no hay argumento, listar dominios con list_domains(domain_type='technical') y preguntar al usuario siguiendo la convención de preguntas al usuario.
2. Evaluar ontologías existentes
Ejecutar en paralelo:
search_ontologies(dominio_o_contexto) o list_ontologies() → ontologías existentes. Preferir search_ontologies si el usuario menciona una ontología concreta; usar list_ontologies() si se necesita el listado completolist_domain_tables(domain) → tablas disponibles para la ontología
Si hay ontologías, mostrar al usuario:
- "No hay ontología → crearemos una nueva"
- "Ya existe [nombre] con N clases → podemos ampliar, borrar clases o crear una nueva"
Si aplica, ejecutar get_ontology_info(name) para mostrar estructura existente.
3. Planificación interactiva
Este es el nucleo de la skill. Preguntar al usuario agrupando para minimizar interacciones:
Bloque de preguntas (una sola interacción):
- ¿Tiene una ontología existente para tomar como referencia? (si sí →
get_ontology_info o leer fichero local)
- ¿Qué clases o entidades considera indispensables?
- ¿Aspectos importantes sobre formato y nomenclaturas?
Enriquecimiento con instrucciones del glosario:
Antes de proponer el plan, aplicar el Workflow de Enriquecimiento con Instrucciones del Glosario descrito en guides/stratio-semantic-layer-tools.md §11, acotado a ontology (al llamar a get_glossary_instructions, pedir solo la fase de ontology). Aquí es donde el usuario puede traerse las instrucciones GenAI de ontología desde el diccionario de datos, aportar un fichero externo (.owl/.ttl, documento de negocio, CSV) como su fuente, superponer comentarios libres, o saltar el enriquecimiento por completo.
Si el orquestador ya pre-cargó instrucciones enriquecidas para esta fase durante el flujo de build-semantic-layer, reutilizarlas — opcionalmente preguntar si el usuario quiere añadir algo específico para esta fase.
El texto enriquecido pasa a formar parte del contexto de planificación que alimenta el plan en Markdown propuesto más abajo. Cuando el MCP subyacente acepte user_instructions para create_ontology / update_ontology, ese mismo texto se pasará también a la llamada.
Exploración del dominio (en paralelo con la interacción si es posible):
list_domain_tables(domain) + get_tables_details(domain, tables) → entender tablas y su contextoget_table_columns_details(domain, table) para tablas clave → datos disponibles para data propertiessearch_domain_knowledge(question, domain) → terminología existente
Proponer plan:
- Proponer nombre de ontología (sin espacios → guiones bajos, sin caracteres especiales)
- Proponer plan en Markdown con:
- Clases propuestas con descripción
- Data properties por clase
- Relaciones entre clases
- Tablas fuente de cada clase
- Presentar plan al usuario para revisión
- Iterar hasta aprobación (max 3 iteraciones de refinamiento)
4. Ejecución
4.a Invocación nominal
Según decisión del paso 2:
- Nueva ontología:
create_ontology(domain, name, ontology_plan) con el plan aprobado en Markdown
- Ampliar existente:
update_ontology(domain, name, update_plan) — solo clases nuevas
- Borrar clases específicas: Operación DESTRUCTIVA — confirmar con el usuario listando las clases a borrar y advirtiendo que las vistas de negocio dependientes se refrescarán. Ejecutar
delete_ontology_classes(ontology_name, class_names). Informar del resultado: clases borradas (deleted) y clases saltadas por tener vistas Published (skipped_locked)
- Borrar la ontología entera: Operación DESTRUCTIVA — confirmar con el usuario que la ontología nombrada y todas sus clases serán eliminadas. Ejecutar
delete_ontology(ontology_name). Informar de si el borrado tuvo éxito o si fue bloqueado porque la ontología está en un estado no-borrable
4.b Flujo de recuperación si create_ontology / update_ontology devuelve error
Distinción importante: si la respuesta de fallo indica que la chain se detuvo antes de generar ninguna clase, la ontología no se persistió — NO entrar en el flujo A-F siguiente (que aplica solo cuando la chain produjo o produjo parcialmente clases y la validación de calidad las siguió rechazando). Dos causas pre-generación distintas, con acciones opuestas (reconoce la causa por el significado del mensaje — bilingüe, no por un string literal):
- Plan no viable — el plan no es alcanzable con las tablas disponibles, los nombres de tabla son incorrectos, o la petición excede los límites de tablas/tamaño. → volver a llamar a
create_ontology con un plan ajustado (acotar alcance, corregir nombres, simplificar).
- Precondición de datos no cumplida — la colección no tiene tablas, sus tablas no tienen columnas, o ninguna tiene términos técnicos todavía. NO volver a llamar con un plan retocado (
guides/stratio-semantic-layer-tools.md §7.3):
- Sin términos técnicos → ofrecer generarlos primero con
/create-technical-terms para este dominio, y luego reintentar la ontología.
- Sin columnas / sin tablas → el agente no tiene tool para refrescar el esquema; transmitir los próximos pasos del mensaje (refrescar/verificar la vista técnica de la colección en Stratio Governance) y parar.
En ese caso, presentar al usuario las seis opciones siguientes y dejar que elija. Confirmar explícitamente con el usuario antes de cualquier llamada a delete_ontology (opciones A, D, E) — la anotación destructive-hint del MCP es informativa, no enforcement.
| Opción | Pasos | Cuándo elegirla |
|---|
| A — Limpia y reintenta con best-effort | delete_ontology(name) → create_ontology(name, plan, best_effort=True) | El plan parece correcto; el usuario acepta una ontología subóptima con warnings en vez de más reintentos |
| B — Completa lo que falta vía update con best-effort | update_ontology(name, update_plan_para_lo_que_falla, best_effort=True) | La base se creó; faltan clases/vistas; el usuario acepta clases nuevas subóptimas |
| C — Completa lo que falta vía update en modo estricto | update_ontology(name, update_plan_corregido) (sin best_effort) | La base está bien; el usuario ajusta el plan de update para pasar la validación |
| D — Limpia y reintenta con un plan corregido | delete_ontology(name) → create_ontology(name, plan_corregido) (sin best_effort) | Problemas estructurales en el plan original; reseteo y reintento en modo estricto |
| E — Solo limpia | delete_ontology(name) (sin recrear) | El usuario quiere borrar el intento fallido y detenerse aquí |
| F — Dejarlo como está y revisar/corregir manualmente en la UI de Governance | (sin llamada a tool) | El usuario acepta la ontología parcial y la refinará manualmente |
Heurística de sugerencia (la decisión final siempre es del usuario):
- Solo unas clases concretas fallaron y el resto está sano → sugerir C (más barato, no destructivo).
- Problemas transversales o de estructura base → sugerir D.
- El plan parece bien pero la validación insistente impide terminar → sugerir A.
Tras ejecutar la opción elegida, volver al paso 5 (Verificación) para confirmar el estado resultante.
5. Verificación
Ejecutar get_ontology_info(name) para confirmar la estructura creada. Presentar al usuario:
- Clases generadas con sus data properties
- Relaciones establecidas
- Diferencias respecto al plan (si las hay)
Ofrecer proactivamente: "Si tras revisarla quieres eliminar alguna clase, puedo hacerlo (las clases con vistas Published no se pueden borrar)." No bloqueante — el usuario decide si continuar o borrar algo.
6. Resumen
- Ontología creada/ampliada con nombre y número de clases
- Clases generadas vs planificadas
- Advertencias o problemas encontrados
- Siguiente paso sugerido: "Puedes crear las vistas de negocio con
/create-business-views"
