Skill oficial · IA en la práctica
Borrador de ontología de un dominio
Redacta una ontología de dominio: preguntas de competencia, clases con definiciones sencillas, propiedades con cardinalidad, instancias de ejemplo y reglas de nombres.
Funciona en Claude, ChatGPT y agentes de programación. En Team y Business, la skill oficial de tu pod se actualiza sola cuando la mejoramos.
Cuándo usarla
- Los equipos usan la misma palabra para cosas distintas y necesitas definiciones compartidas
- Vas a construir un grafo de conocimiento, la estructura de un CRM o un sistema RAG
Qué le das
- El dominio y su límite
- Quién la usa y para qué
- Documentos o campos de sistemas de ejemplo
Qué obtienes
Tablas de clases, propiedades e instancias de ejemplo, vinculadas a las preguntas que la ontología debe responder.
Cómo funciona
- Escribe de 5 a 10 preguntas de competencia Preguntas reales que la ontología debe responder: “¿Qué cuentas renuevan en los próximos 90 días y quién es responsable de cada una?”. Delimitan el trabajo y lo ponen a prueba al final.
- Lista los términos Todos los sustantivos y verbos de las preguntas y del material de origen, todavía sin estructura.
- Elige las clases y define cada una en una frase Una clase es un tipo de cosa que tiene instancias. Forma de la definición: “Un/a [clase] es un/a [clase padre] que [rasgo distintivo]”. Junta los sinónimos en una sola clase y anótalos. Si algo entra y sale de un estado (“cliente activo”), hazlo valor de una propiedad, no una clase.
- Construye la jerarquía Cada subclase debe ser “un tipo de” su clase padre. Evita una clase con una sola subclase y evita más de una docena aproximada de subclases directas. Marca como disjuntas las clases que no pueden compartir instancias.
- Añade propiedades y relaciones Asigna cada una a la clase más general que la tiene. Para cada una: nombre, tipo de valor (texto, número, fecha, otra clase) y cardinalidad (exactamente 1, 0 o 1, 1 o más, 0 o más). Añade la inversa en las relaciones clave (owns / owned_by).
- Crea de 2 a 3 instancias de ejemplo por clase principal Realistas pero ficticias. Si un ejemplo no encaja, la clase o la propiedad está mal.
- Pruébala con las preguntas de competencia Para cada pregunta, muestra qué clases y propiedades la responden. Una pregunta sin respuesta significa que falta algo; una clase que ninguna pregunta usa es candidata a eliminarse. Reglas de nombres por defecto de esta skill: clases en singular y UpperCamelCase (SalesOpportunity), propiedades en lower_snake_case que empiezan por un verbo o por “has” (has_owner, renews_on), sin abreviaturas y sin palabras como “class” o “type” en los nombres.
El SKILL.md
El archivo completo, tal como lo lee tu IA. Descargarlo
---
name: ontology-draft
description: Redacta un borrador de ontología para un área del negocio - las preguntas de competencia que debe responder, las clases principales con definiciones sencillas, las propiedades y relaciones con su cardinalidad, instancias de ejemplo y reglas de nombres - con el método Ontology Development 101, en tablas que alguien que no es ingeniero puede revisar. Úsala cuando un equipo pide definir los conceptos clave del negocio, diseñar un modelo de datos en palabras sencillas, crear una ontología, una taxonomía, un esquema para un grafo de conocimiento o “qué cosas registramos y cómo se relacionan”.
---
# Borrador de ontología
Una ontología es una lista acordada de las cosas de las que habla un negocio (clases), lo que registramos de ellas (propiedades) y cómo se relacionan, con definiciones tan precisas que dos personas clasificarían lo mismo de la misma forma. Ontology Development 101, de Noy y McGuinness, empieza por fijar el dominio y el alcance con preguntas de competencia, las preguntas que la ontología debe responder; esta skill hace lo mismo, porque a una ontología que no responde sus preguntas le falta algo, y una que responde preguntas que nadie hace es demasiado grande.
## Cuándo usarla
- Antes de construir un grafo de conocimiento, la estructura de un CRM, un data warehouse o un sistema RAG para un dominio.
- Cuando los equipos usan la misma palabra para cosas distintas (“cliente”, “cuenta”, “usuario”).
- Cuando una hoja de cálculo acumula columnas que nadie sabe definir.
- No para extraer hechos de documentos existentes: usa knowledge-graph-extraction cuando las clases ya existan.
## Qué necesitas
- El dominio y su límite (“suscripciones B2B desde la cotización hasta la renovación”, no “el negocio”).
- Quién usará la ontología y para qué.
- Documentos, hojas de cálculo o campos de sistemas de ejemplo. Si no hay, trabaja con la descripción del dominio y marca las clases con “[propuesta]”.
- Los estándares que el equipo ya usa (un esquema del sector, schema.org, los objetos de un CRM). Reutiliza sus nombres donde encajen.
## Pasos
1. **Escribe de 5 a 10 preguntas de competencia.** Preguntas reales que la ontología debe responder: “¿Qué cuentas renuevan en los próximos 90 días y quién es responsable de cada una?”. Delimitan el trabajo y lo ponen a prueba al final.
2. **Lista los términos.** Todos los sustantivos y verbos de las preguntas y del material de origen, todavía sin estructura.
3. **Elige las clases y define cada una en una frase.** Una clase es un tipo de cosa que tiene instancias. Forma de la definición: “Un/a [clase] es un/a [clase padre] que [rasgo distintivo]”. Junta los sinónimos en una sola clase y anótalos. Si algo entra y sale de un estado (“cliente activo”), hazlo valor de una propiedad, no una clase.
4. **Construye la jerarquía.** Cada subclase debe ser “un tipo de” su clase padre. Evita una clase con una sola subclase y evita más de una docena aproximada de subclases directas. Marca como disjuntas las clases que no pueden compartir instancias.
5. **Añade propiedades y relaciones.** Asigna cada una a la clase más general que la tiene. Para cada una: nombre, tipo de valor (texto, número, fecha, otra clase) y cardinalidad (exactamente 1, 0 o 1, 1 o más, 0 o más). Añade la inversa en las relaciones clave (owns / owned_by).
6. **Crea de 2 a 3 instancias de ejemplo por clase principal.** Realistas pero ficticias. Si un ejemplo no encaja, la clase o la propiedad está mal.
7. **Pruébala con las preguntas de competencia.** Para cada pregunta, muestra qué clases y propiedades la responden. Una pregunta sin respuesta significa que falta algo; una clase que ninguna pregunta usa es candidata a eliminarse.
Reglas de nombres por defecto de esta skill: clases en singular y UpperCamelCase (SalesOpportunity), propiedades en lower_snake_case que empiezan por un verbo o por “has” (has_owner, renews_on), sin abreviaturas y sin palabras como “class” o “type” en los nombres.
## Formato de salida
```markdown
# Borrador de ontología — [dominio]
**Alcance:** [límite] · **Usuarios:** [quién, para qué] · **Estado:** borrador
## Preguntas de competencia
1. [Pregunta]
## Clases
| Clase | Padre | Definición | Sinónimos (no se usan) |
|---|---|---|---|
## Propiedades y relaciones
| Propiedad | De la clase | Tipo de valor | Cardinalidad | Inversa | Definición |
|---|---|---|---|---|---|
## Instancias de ejemplo
| Instancia | Clase | Valores de propiedades |
|---|---|---|
## Cobertura de preguntas
| Pregunta | Se responde con |
|---|---|
## Reglas de nombres
- [Reglas]
## Decisiones pendientes
- [Decisión necesaria, opciones]
```
## Ejemplo
**Entrada:** “Dominio: nuestras suscripciones SaaS. Vendemos a empresas; cada empresa puede tener varios espacios de trabajo; cada espacio de trabajo tiene un plan y licencias. La gente llama a las empresas «cuentas» o «clientes». Necesitamos saber quién renueva cuándo, quién es responsable de cada renovación y qué espacios de trabajo superan su límite de licencias”.
**Salida:**
```markdown
# Borrador de ontología — Suscripciones SaaS
**Alcance:** empresas, espacios de trabajo, suscripciones, renovaciones · **Usuarios:** Customer Success y finanzas, para seguir las renovaciones · **Estado:** borrador
## Preguntas de competencia
1. ¿Qué suscripciones renuevan en los próximos 90 días y quién es responsable de cada renovación?
2. ¿Qué espacios de trabajo usan más licencias de las que permite su plan?
3. ¿Cuántos espacios de trabajo tiene cada empresa?
## Clases
| Clase | Padre | Definición | Sinónimos (no se usan) |
|---|---|---|---|
| Company | — | Una entidad jurídica que compra o puede comprar nuestro producto | cuenta, cliente, organización |
| Workspace | — | Un área separada de nuestro producto en la que inician sesión los usuarios de una empresa | instancia, tenant |
| Subscription | — | Un acuerdo de pago de un espacio de trabajo en un plan durante un periodo | contrato, licencia |
| Plan | — | Un paquete con nombre, precio y límite de licencias | nivel |
| Person | — | Una persona que registramos | contacto, usuario |
## Propiedades y relaciones
| Propiedad | De la clase | Tipo de valor | Cardinalidad | Inversa | Definición |
|---|---|---|---|---|---|
| has_workspace | Company | Workspace | 1 o más | belongs_to | Espacios de trabajo que paga la empresa |
| has_subscription | Workspace | Subscription | exactamente 1 (la vigente) | covers | El acuerdo de pago vigente |
| on_plan | Subscription | Plan | exactamente 1 | — | El plan contratado |
| renews_on | Subscription | fecha | exactamente 1 | — | Fecha en que termina el periodo vigente |
| has_renewal_owner | Subscription | Person | 0 o 1 | owns_renewal | La persona de nuestro equipo responsable de la renovación |
| seat_limit | Plan | número | exactamente 1 | — | Máximo de licencias del plan |
| seats_used | Workspace | número | exactamente 1 | — | Licencias en uso hoy |
## Instancias de ejemplo
| Instancia | Clase | Valores de propiedades |
|---|---|---|
| Cumbre Norte S.A. | Company | has_workspace: CumbreNorte-EU, CumbreNorte-US |
| CumbreNorte-EU | Workspace | seats_used: 48; has_subscription: SUB-1042 |
| SUB-1042 | Subscription | on_plan: Team; renews_on: 2026-03-31; has_renewal_owner: Lena Ortiz |
| Team | Plan | seat_limit: 40 |
## Cobertura de preguntas
| Pregunta | Se responde con |
|---|---|
| 1 | Subscription.renews_on, has_renewal_owner |
| 2 | Workspace.seats_used frente a Plan.seat_limit vía Subscription.on_plan |
| 3 | Company.has_workspace (recuento) |
## Reglas de nombres
- Clases: singular, UpperCamelCase. Propiedades: lower_snake_case, con un verbo o “has” al principio. Sin abreviaturas.
## Decisiones pendientes
- ¿Una prueba gratuita es una Subscription con precio 0 o una clase propia? Afecta a la pregunta 1.
```
## Comprobaciones antes de enviar
- [ ] Cada pregunta de competencia se corresponde con clases y propiedades concretas.
- [ ] Cada clase tiene una definición de una frase que nombra su clase padre y lo que la distingue.
- [ ] Los sinónimos están unidos en una sola clase y anotados, no modelados como clases separadas.
- [ ] Cada propiedad tiene tipo de valor y cardinalidad.
- [ ] Cada relación “es un tipo de” se cumple para todas las instancias de la subclase.
## Errores comunes
- Convertir estados en clases (“ChurnedCustomer”). Usa una propiedad de estado; las cosas entran y salen de los estados.
- Modelar todo lo que el negocio ha mencionado alguna vez. Detente en lo que necesitan las preguntas de competencia.
- Dejar definiciones que solo repiten el nombre de la clase (“Un cliente es un cliente”). Di qué lo hace distinto.
Compártela con tu equipo
Agrégala a un AI Skill Pod y todo el equipo, colaboradores externos incluidos, usa la misma versión desde su propia IA. Lee las mejores formas de compartir skills de IA con un equipo
Historial de cambios
- v1.0.0 · · First release.
Fuentes
- Ontology Development 101: A Guide to Creating Your First Ontology (leída el 2026-11-04)
- RDF 1.1 Concepts and Abstract Syntax (leída el 2026-11-04)