Los símbolos, antes de empezar
página propia — no es del libro
Dos notaciones para lo mismo: la descriptiva es primer orden recortado para que el razonamiento siempre termine.
- juegos de símbolos
- 2
- ideas base
- 4
- capítulos del libro
- 0
Un recorrido capítulo a capítulo por An Introduction to Ontology Engineering, de C. Maria Keet. Cada capítulo cierra con un caso de estudio donde lo aprendido se aplica a algo que un razonador puede confirmar o desmentir — y todo lo que se afirma aquí está comprobado por un script.
Keet, C.M. An Introduction to Ontology Engineering, v1.5 (2020). Libro abierto, CC BY 4.0, con material suplementario y ejercicios: página de la autora · copia en el repo.
Es un libro de texto de universidad, no una introducción divulgativa: da la lógica formal detrás de OWL en vez de recetas de Protégé. Por eso sirve de base — las decisiones quedan citables.
página propia — no es del libro
Dos notaciones para lo mismo: la descriptiva es primer orden recortado para que el razonamiento siempre termine.
Keet, cap. 1 (Introduction), §1.1–1.5
La ontología de ejemplo del propio libro pasa el razonador en verde y se cae al afirmar un individuo que no come nada.
Keet, cap. 2 (First order logic and automated reasoning in a nutshell), §2.1–2.3
Aquella inferencia sobre el impala nunca fue una deducción: es una abducción, y hay otra hipótesis más débil que explica lo mismo.
Keet, cap. 3 (Description Logics), §3.1–3.4
Degradar dos clases definidas a primitivas no «pierde precisión»: destruye por completo la subsunción que el propio ejercicio del libro pide demostrar.
Keet, cap. 4 (The Web Ontology Language OWL 2), §4.1–4.4
La cadena de propiedades que resuelve el ejercicio 4.2 vuelve ilegal una restricción de cardinalidad que antes era válida: el razonador rechaza la ontología entera, sin que nada sea lógicamente inconsistente.
Keet, cap. 5 (Methods and Methodologies), §5.1–5.3
De las once preguntas de competencia que el propio libro propone, la ontología de ejemplo contesta cuatro; tres devuelven vacío —que no es un «no»— y una parece contestada solo porque la ontología está rota.
Keet, cap. 6 (Top-down Ontology Development), §6.1–6.3
Meter la pertenencia a un grupo dentro de la misma propiedad transitiva que la parte estructural produce una deducción falsa que nadie escribió: la hoja pasa a ser parte del bosque.
Keet, cap. 7 (Bottom-up Ontology Development), §7.1–7.7
Un NOT NULL de base de datos no sobrevive a la traducción: ni como domain, ni como ∃. La fila que la base de datos rechazaría, la ontología la acepta sin decir nada.
Keet, cap. 8 (Ontology-Based Data Access), §8.1–8.5
La misma consulta sobre los mismos datos devuelve {} o {Mkhize, Naidoo} según se reescriba o no con la TBox; y ni siquiera razonando aparece en una fila el departamento cuya existencia la ontología garantiza.
Keet, cap. 9 (Ontologies and natural languages), §9.1–9.3
Traducir bien no basta: alinear fleuve y rivière con river como equivalentes vuelve la ontología inconsistente, porque las dos lenguas no cortan el mundo por el mismo sitio.
Keet, cap. 10 (Advanced Modelling with Additional Language Features), §10.1–10.3, 1ª ed. v1.5
Alinear como equivalentes dos ontologías que ponen el umbral de «joven» en 30 y en 35 vuelve la ontología inconsistente en cuanto aparece alguien de 31.
Keet, cap. 11 (Ontology modularisation), §11.1–11.4, 1ª ed. v1.5
Un módulo que contiene los tres nombres pedidos y ningún axioma inventado deja de deducir que un león no puede ser un impala. Correcto y a la vez incompleto.
El destilado: de cada capítulo, la idea que cambia cómo se modela y el hallazgo que un razonador confirmó. Si algo hay que llevarse del libro entero, es esto.
Lo esencial: Hay dos notaciones para lo mismo —lógica de primer orden y lógica descriptiva— y el libro salta de una a otra sin avisar. ⊑ es «está contenido en», no «implica».
Comprobado: Página propia, no del libro: la tabla de símbolos que los demás capítulos enlazan en vez de repetir.
Lo esencial: Una ontología no es una base de datos: es una teoría lógica bajo mundo abierto. Lo que no está escrito no es falso, es desconocido.
Comprobado: La ontología de ejemplo del propio libro pasa el razonador en verde y se cae al afirmar un individuo que no come nada.
Lo esencial: T ⊨ α cuantifica sobre todos los modelos, no sobre el que tienes en la cabeza. Un razonador solo deduce: ni abduce ni induce.
Comprobado: La inferencia sobre el impala del capítulo 1 nunca fue una deducción: es una abducción, y hay una hipótesis más débil que explica lo mismo.
Lo esencial: Es el motor de OWL. ∀R.C se cumple por vacuidad si no hay ningún R, y ≡ frente a ⊑ decide qué puede deducirse.
Comprobado: Degradar dos clases definidas a primitivas no «pierde precisión»: destruye la subsunción que el propio ejercicio del libro pide demostrar.
Lo esencial: Es SROIQ(D) con un estándar detrás. Los perfiles no se eligen por potencia sino por qué operación debe ser barata.
Comprobado: La cadena de propiedades que resuelve el ejercicio vuelve ilegal una restricción de cardinalidad que antes era válida: el razonador rechaza la ontología entera.
Lo esencial: Las preguntas de competencia son las pruebas unitarias: consulta más respuesta esperada. Consistente no significa bien modelado.
Comprobado: De las once preguntas de competencia que el libro propone, su ontología de ejemplo contesta cuatro; y una parece contestada solo porque está rota.
Lo esencial: Elegir ontología fundacional es elegir qué existe. Y «parte de» son varias relaciones distintas que el idioma confunde.
Comprobado: Meter la pertenencia a un grupo en la misma propiedad transitiva que la parte estructural deduce que la hoja es parte del bosque.
Lo esencial: Reutilizar lo que ya hay —bases de datos, modelos, tesauros— sabiendo que casi nada significa lo mismo después de convertirlo.
Comprobado: Un NOT NULL no sobrevive a la traducción: ni como domain, ni como ∃. La fila que la base de datos rechazaría, OWL la acepta.
Lo esencial: La ontología se pone encima de la base de datos y reescribe la pregunta en vez de mover los datos. Por eso la TBox va en OWL 2 QL.
Comprobado: La misma consulta sobre los mismos datos devuelve {} o {Mkhize, Naidoo} según se reescriba o no con la TBox.
Lo esencial: El nombre no es el concepto: los identificadores no razonan. Y una frase natural no determina un axioma.
Comprobado: Alinear fleuve y rivière con river como equivalentes —lo que dice el diccionario— vuelve la ontología inconsistente.
Lo esencial: OWL es nítido y atemporal. Vaguedad y tiempo solo entran deformándolo, y todo umbral es una decisión de modelado.
Comprobado: Alinear dos ontologías que ponen el umbral de «joven» en 30 y en 35 revienta en cuanto aparece alguien de 31 años.
Lo esencial: Correcto (no inventa axiomas) y completo (conserva las consecuencias) son independientes, y solo se comprueba el primero.
Comprobado: Un módulo con los tres nombres pedidos y ningún axioma inventado deja de deducir que un león no puede ser un impala.
Los mismos fallos reaparecen en capítulos que no tienen nada que ver entre sí. Cada uno está verificado en más de una página.
∀ admite a todo el que no participa en la relación. La forma correcta es ∀ + ∃: el ∀ clasifica, el ∃ impide la vacuidad. cap. 1 · cap. 3 · cap. 5 · cap. 6 · cap. 9 domain y range no rechazan nada: clasifican en silencio. Sus errores aparecen lejos de donde se cometieron, como una clase insatisfacible que no tiene la culpa. cap. 5 · cap. 7 broader y subclase, fleuve y river, dos umbrales de «joven». Igualar por el nombre produce deducciones falsas o inconsistencias, nunca un aviso claro. cap. 6 · cap. 7 · cap. 9 · cap. 10 Los doce pasos en el orden en que el libro manda darlos, cada uno con el capítulo que lo respalda y el error caro que evita. Es lo mismo de arriba, puesto en procedimiento: los pasos 1 y 2 son los que deciden si el resto sirve, y son los que todo el mundo se salta.
El ejemplo que se sigue de principio a fin. Un taller de bicicletas con una base de datos de inventario que ya funciona y una pregunta que la base de datos no sabe contestar: «¿qué piezas de las que tengo son compatibles con esta bici?». Es el caso típico —hay datos, falta significado— y toca casi todos los capítulos. Es un ejemplo ilustrativo: lo verificado con razonador vive en cada capítulo enlazado, no aquí.
Antes que ninguna clase, un párrafo de dominio y alcance. El alcance se define mejor por exclusión: lo que queda fuera es lo que impide que la ontología crezca sin fin.
En el taller: Entra: piezas, montaje, compatibilidad. No entra: precio, cliente, stock, proveedor. El stock cambia cada hora; una ontología no es el sitio donde vive lo que cambia cada hora.
La trampa: Empezar enumerando conceptos «del dominio». Produce ontologías con todos los sustantivos y ninguna relación — el síntoma exacto de la CQ11 del capítulo 5: las clases están y la pregunta sigue siendo incontestable.
Entre 8 y 15 preguntas que la ontología deberá contestar, cada una con la respuesta que se espera. Son la especificación y son las pruebas. Todo lo que no aparezca en ninguna CQ es vocabulario que no hace falta.
En el taller: CQ1 ¿qué frenos valen para un cuadro de ruta? → los de llanta y los de disco con anclaje flat mount. CQ2 ¿es esta bici eléctrica? → sí, si tiene motor. CQ3 ¿qué piezas hay que quitar para sacar el eje? → las que son parte del conjunto de transmisión.
La trampa: Dar por buena una CQ que «funciona». Hay tres formas de fallar y dos parecen éxitos: contestar vacío —que bajo mundo abierto es «no consta», no «no»— y contestar por accidente. En el capítulo 5, la ontología del libro contesta una CQ solo porque está rota.
Casi nada se construye desde cero: hay tesauros, esquemas de base de datos, modelos UML, vocabularios del sector. Reutilizar es un paso, no un atajo — es lo que separa NeOn de Methontology.
En el taller: La tabla piezas del taller ya tiene los tipos, los diámetros y las claves ajenas. De ahí sale el vocabulario inicial en una tarde; lo que no sale de ahí es el significado.
La trampa: Traducir el esquema tal cual y creer que las restricciones viajan con él. Verificado en el capítulo 7: un NOT NULL no sobrevive a la conversión ni como domain ni como ∃. La fila que la base de datos rechazaría, OWL la acepta sin decir nada.
No se elige el perfil más expresivo, se elige el que hace barata la operación que vas a repetir un millón de veces. EL si lo que importa es clasificar una jerarquía enorme; QL si vas a consultar sobre una base de datos; DL completo solo cuando algo lo exija de verdad.
En el taller: El taller consulta contra su inventario: la TBox se escribe en OWL 2 QL, para que la pregunta se pueda reescribir a SQL en vez de mover los datos a la ontología.
La trampa: Escribir en SROIQ «por si acaso» y descubrir tarde que cierra la puerta al acceso a datos. Y ojo al orden inverso: en el capítulo 4, añadir una cadena de propiedades vuelve ilegal una restricción de cardinalidad que ya estaba escrita, y el razonador rechaza la ontología entera.
Decide —y escribe— qué tipos de cosa hay: objetos, procesos, cualidades, roles. Se puede adoptar una ontología fundacional (DOLCE, BFO, GFO) o declarar las cuatro o cinco categorías propias, pero no se puede no decidirlo: elegir el nivel de arriba es elegir qué existe.
En el taller: Pieza es un objeto y Montaje es un proceso. Son categorías distintas, así que Montaje no cuelga de Pieza por muy natural que suene decir «el montaje del freno».
La trampa: Colgar un proceso de un objeto, o un rol de una clase rígida. Nada de eso produce contradicción: el razonador no protesta jamás. Se caza con OntoClean —Persona bajo Estudiante es el caso canónico— y por eso el capítulo 5 insiste en que consistente no es lo mismo que bien modelado.
La taxonomía es la parte fácil y la que menos deduce. El trabajo está en las propiedades: cuáles son transitivas, cuáles funcionales, cuál es subpropiedad de cuál, y sobre todo cuántas relaciones distintas esconde la palabra «parte de».
En el taller: Tres relaciones separadas: parteEstructuralDe (el radio es parte de la rueda, transitiva), montadoEn (la rueda va montada en el cuadro, desmontable) y miembroDe (la bici pertenece a la flota de alquiler).
La trampa: Meterlas todas en una propiedad transitiva. Verificado en el capítulo 6: juntar pertenencia a un grupo con parte estructural hace que el razonador deduzca que la hoja es parte del bosque. La deducción es impecable; la ontología, falsa.
Usa ≡ solo cuando las condiciones sean necesarias y suficientes; en cualquier otro caso, ⊑. Esa elección decide qué puede clasificar el razonador solo: con ⊑ tienes que decir a mano a qué clase pertenece cada cosa.
En el taller: Bicicleta es primitiva: no hay lista cerrada de condiciones que baste. BiciEléctrica ≡ Bicicleta ⊓ ∃tieneParte.Motor es definida — y por eso el razonador etiqueta solo cualquier bici a la que se le añada un motor.
La trampa: Definir con ∀ a secas. ∀tieneParte.Motor lo cumple también la bici que no tiene ninguna parte: se satisface por vacuidad. La forma correcta es ∀ + ∃, y está verificado en los capítulos 1, 3 y 5. Degradar una definida a primitiva tampoco «pierde precisión»: destruye la subsunción, según el capítulo 3.
Clasificar después de cada tanda de axiomas, no cuando esté «terminada». Y cuando algo salga insatisfacible, pedir la justificación: el conjunto mínimo de axiomas culpable. Sin eso, la reparación es a ciegas.
En el taller: Declarar domain(montadoEn) = Cuadro y ver qué se clasifica solo. Si aparece algo raro, mirar la justificación antes de tocar nada.
La trampa: Reparar donde señala el error. Verificado en el capítulo 5: una clase resulta insatisfacible sin que nadie escribiera una contradicción, y la causa está en un domain lejano. Peor: quitar la disyunción hace desaparecer el síntoma y deja el error de modelado intacto y ya invisible. domain y range no validan, clasifican en silencio.
Si los datos están en una base de datos que funciona, no los copies a una ABox: pon la ontología encima y declara los mapeos. La pregunta se reescribe con la TBox y baja a SQL; los datos no se mueven ni se duplican.
En el taller: La tabla piezas se queda donde está. La consulta «¿qué frenos valen para este cuadro?» se reescribe usando la jerarquía de tipos de freno y devuelve filas que ninguna consulta SQL directa habría encontrado.
La trampa: Consultar sin reescribir y creer que el resultado es el mismo. Verificado en el capítulo 8: la misma consulta sobre los mismos datos devuelve {} o dos resultados según se use la TBox o no.
Cada CQ, una comprobación ejecutable: consulta más respuesta esperada, y salida con código 1 si deja de reproducirse. Es lo más parecido a CI que admite una ontología, y es lo que convierte «buena ontología» en algo que se puede fallar.
En el taller: Un verificar.py que afirma lo que debe deducirse (la bici con motor se clasifica como eléctrica) y también lo que no debe deducirse (el radio no es parte de la flota).
La trampa: Comprobar solo lo que debe salir. La mitad del valor está en las afirmaciones negativas: son las que detectan que una propiedad se volvió transitiva de más. Y para distinguir «no» de «no consta», la prueba es afirmar lo contrario: si la ontología sigue consistente, era ignorancia —capítulo 1, capítulo 5—.
Cuatro fuentes de evidencia independientes, y ninguna basta sola: razonador (sin insatisfacibles), CQ ejecutadas, OOPS! (pitfalls frecuentes), y OntoClean más RBox Compatibility (errores ontológicos que la lógica tolera sin inmutarse).
En el taller: Comprobar que montadoEn ⊑ parteEstructuralDe tiene dominios contenidos en los del padre, no al revés — es justo lo que detecta RBox Compatibility.
La trampa: Leer «0 clases insatisfacibles» como aprobado. La ontología del propio libro está consistente y contesta 4 de 11 requisitos: capítulo 5.
IRI estable, versionado, y si la ontología se reparte en módulos, decidir explícitamente qué garantiza cada uno. Las etiquetas en varios idiomas van como anotaciones: no razonan y no deben razonar.
En el taller: Un módulo de piezas y compatibilidad para publicar al proveedor, sin el módulo de montaje. Y rdfs:label en español e inglés sobre los mismos IRI.
La trampa: Dar por hecho que un módulo correcto conserva las deducciones. Verificado en el capítulo 11: correcto (no inventa axiomas) y completo (conserva las consecuencias) son independientes, y solo se comprueba el primero. Y alinear términos por el diccionario rompe: en el capítulo 9, igualar fleuve y rivière con river deja la ontología inconsistente.