Saltar al contenido

Cuaderno de trabajo · 12 de 12 páginas

Ingeniería de ontologías

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.


El libro

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.


Capítulos

00

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
01

Introduction

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.

clases en la AWO
31
axiomas de disyunción
7
comprobaciones
12
02

First-Order Logic and Automated Reasoning in a Nutshell

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.

formas de inferir
3
que hace el razonador
1
comprobaciones
8
03

Description Logics

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.

cajas: TBox, ABox, RBox
3
servicios de razonamiento
5
comprobaciones
9
04

The Web Ontology Language OWL 2

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.

perfiles de OWL 2
3
parámetros de complejidad
4
comprobaciones
8
05

Methods and Methodologies

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.

CQ que la AWO contesta
4/11
familias de método
4
comprobaciones
17
06

Top-down Ontology Development

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.

axiomas para clasificar el rockdassie
2
mereologías completas que caben en OWL 2 DL
0
comprobaciones
9
07

Bottom-up Ontology Development

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.

clase insatisfacible en el modelo UML
1
subsunciones no dibujadas
2
comprobaciones
12
08

Ontology-Based Data Access

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.

respuestas a la misma consulta
3
perfil de la TBox
QL
comprobaciones
8
09

Ontologies and Natural Languages

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.

formalizaciones de una misma frase
2
inferencias que cambian al traducir los IRI
0
comprobaciones
9
10

Advanced Modelling with Additional Language Features

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.

formas de meter tiempo en OWL
2
grados de pertenencia en OWL 2
0
comprobaciones
8
11

Ontology modularisation

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.

dimensiones de un módulo
5
clases frente a 7 en el módulo bueno
3
comprobaciones
12

Lo esencial de cada capítulo

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.

0 Los símbolos

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.

1 Qué es una ontología

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.

2 Lógica y razonamiento

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.

3 Description Logics

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.

4 OWL 2

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.

5 Métodos y metodologías

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.

6 Desarrollo top-down

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.

7 Desarrollo bottom-up

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.

8 Acceso a datos (OBDA)

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.

9 Ontologías y lenguas

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.

10 Modelado avanzado

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.

11 Modularización

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 cuatro errores que se repiten

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.

  1. El universal vacío. Una definición hecha solo con ∀ 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
  2. Vacío no es «no». Bajo mundo abierto, una respuesta vacía significa «no consta», no «no existe». Y se puede probar cuál de las dos es: si al afirmar lo contrario la ontología sigue consistente, era ignorancia. cap. 1 · cap. 2 · cap. 5 · cap. 8
  3. El dominio no valida, infiere. 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
  4. La misma palabra, dos relaciones. Parte y miembro, 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

Cómo se hace una, de cero

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í.

  1. 01 Escribe qué NO entra

    cap. 5

    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.

  2. 02 Escribe las preguntas de competencia, con su respuesta esperada

    cap. 5

    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.

  3. 03 Busca lo que ya existe antes de escribir un axioma

    cap. 7 · cap. 5

    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.

  4. 04 Elige el perfil por la operación que debe ser barata

    cap. 4 · cap. 8

    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.

  5. 05 Fija las categorías de arriba antes de tocar el dominio

    cap. 6

    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.

  6. 06 Modela las relaciones, no solo la taxonomía

    cap. 6

    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.

  7. 07 Distingue clase primitiva de clase definida

    cap. 3 · cap. 4

    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.

  8. 08 Corre el razonador desde el tercer axioma, no al final

    cap. 2 · cap. 5

    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.

  9. 09 Conecta los datos donde ya viven

    cap. 8

    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.

  10. 10 Convierte las CQ en un script que falle

    cap. 5

    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—.

  11. 11 Pásale los métodos que el razonador no sustituye

    cap. 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.

  12. 12 Publica en módulos, y con las etiquetas fuera del razonamiento

    cap. 11 · cap. 9

    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.