OWL 2: la lógica del capítulo 3, ya estandarizada

OWL 2 no aporta semántica nueva: es SROIQ(D) con una sintaxis estándar y un comité detrás. Todo lo que hace, por qué lo hace y qué cuesta está en el capítulo 3. Lo que este capítulo añade es la parte de ingeniería — qué se puede serializar, qué fragmento elegir, y qué restricciones globales impone el estándar por encima de la lógica.

De OWL 1 a OWL 2 (§4.1)

OWL 1 tenía tres especies: OWL Lite, OWL DL (SHOIN(D), NExpTime-completo) y OWL Full (indecidible, porque permite tratar clases como individuos sin restricciones). OWL 2 mantiene la pareja OWL 2 DL / OWL 2 Full y añade tres perfiles.

OWL 2 DL se basa en SROIQ(D): más expresivo que OWL DL, y 2NExpTime-completo en complejidad taxonómica. Las novedades que de verdad se usan (§4.2.1):

Novedad	En DL	Para qué
Cardinalidades cualificadas	≥3 hasPart.Door	la Q de SROIQ; en OWL 1 solo se podía contar sin decir de qué
Cadenas de propiedades	R ∘ S ⊑ R	propagar por la mereología: el caso de estudio de esta página
Propiedades reflexivas, irreflexivas, asimétricas, disjuntas		cerrar la semántica de relaciones parte-todo
Self	∃R.Self	«se lava a sí mismo»
Claves (HasKey)		identificación al estilo base de datos, sin salir de OWL
Punning		usar el mismo nombre como clase y como individuo, controladamente
Tipos de dato enriquecidos	SROIQ(D)	rangos, facetas

La diferencia entre cardinalidad sin cualificar y cualificada es exactamente Bicycle ⊑ ≥2 hasComponent.⊤ frente a Bicycle ⊑ ≥2 hasComponent.Wheel (§4.2.1). La primera dice «tiene al menos dos piezas»; la segunda, «al menos dos ruedas». Solo la segunda es OWL 2.

Los tres perfiles (§4.2.2)

No son «versiones reducidas» genéricas: cada uno recorta por un lado distinto, según qué operación se quiere que sea barata.

Perfil	Basado en	Pensado para	Complejidad taxonómica
OWL 2 EL	EL++	ontologías grandes de tipo terminológico (SNOMED CT)	PTime-completo
OWL 2 QL	DL-Lite_R	responder consultas sobre muchos datos, reescribiendo a SQL	NLogSpace-completo
OWL 2 RL	Description Logic Programs, pD*	implementarse con motores de reglas	PTime-completo

¿Y esto qué quiere decir? Sin jerga

Piensa en tres formas de organizar una biblioteca enorme.

EL es el catálogo por materias: puedes tener millones de fichas y encontrar la jerarquía completa rápido, pero solo sabes decir «esto es un tipo de aquello» y «esto trata de aquello». No puedes decir «esto no es un tipo de aquello», ni «todo lo que hay aquí es de tal clase». Renuncias a la negación y al «todo» a cambio de que ordenar el catálogo entero sea rápido.

QL es el mostrador de consultas: hay pocas reglas, pero las que hay se pueden traducir a una búsqueda directa en el fichero. Sirve cuando lo grande no es el catálogo, sino el número de libros.

RL es el manual de procedimientos: reglas del tipo «si pasa esto, apunta aquello». Se puede ejecutar con un motor de reglas normal, sin razonador de ontologías.

La pregunta que hay que hacerse no es «¿cuál es más potente?» sino «¿qué operación tiene que ser barata en mi caso?». Y una vez contestada, el perfil está elegido.

La ventaja de los perfiles frente a OWL 2 DL es exactamente esa: garantías de complejidad, no elegancia. Se sabe de antemano que el razonamiento termina en tiempo polinómico, y para SNOMED CT eso es la diferencia entre viable e inviable.

Complejidad, cuatro parámetros (§4.2.4, copiados del estándar de perfiles): data complexity (respecto al tamaño de las aserciones), taxonomic complexity (respecto al de los axiomas), query complexity (respecto al de la consulta) y combined complexity (todo junto). Que un problema sea PTime-completo en un parámetro y no en otro es lo que explica por qué QL puede ser malísimo para clasificar y buenísimo para consultar.

Y la advertencia que Keet deja escrita: estos resultados son de peor caso, y no dicen nada sobre lo que tarda una ontología concreta.

Sintaxis (§4.2.3)

Existen varias —funcional, Manchester, Turtle, OWL/XML— y las herramientas convierten entre ellas. Pero solo una es obligatoria para que una ontología se considere intercambiable: RDF/XML. Es la única que toda implementación conforme debe saber leer; el resto son comodidad.

---

Caso de estudio: la lesión que sube por la mereología

Reproducible con:

cd capitulos/04-owl-2/artefactos
python3 -m venv .venv && ./.venv/bin/pip install -r requirements.txt
./.venv/bin/python verificar.py     # necesita Java en el PATH

Es el Exercise 4.2 del libro, literal: «an injury (a cut, a fracture) to a bone in your hand is also an injury to your hand. How can you model this […] such that it infers this not only for injuries to hands, but for any injury to any anatomical body part to an injury to its (direct/indirect) whole?»

La ontología mínima:

partOf   transitiva,  BodyPart × BodyPart
injuryOf              Injury   × BodyPart

partOf(hueso_escafoides, mano_derecha)
partOf(mano_derecha, brazo_derecho)
injuryOf(fractura_del_escafoides, hueso_escafoides)

Sin la característica de OWL 2, no pasa nada

[ok] injuryOf(fractura, mano_derecha) NO se infiere
[ok] y se prueba por refutación: T ∪ {¬α} sigue CONSISTENTE

Que partOf sea transitiva no ayuda: la transitividad propaga partOf entre partes, pero no dice nada sobre injuryOf. Son dos propiedades distintas y nada las conecta.

Con la cadena, un solo axioma lo cubre todo

injuryOf ∘ partOf ⊑ injuryOf

[ok] injuryOf(fractura, mano_derecha)  se infiere
[ok] injuryOf(fractura, brazo_derecho) también — el todo indirecto
[ok] T ∪ {¬α} INCONSISTENTE, luego T ⊨ injuryOf(fractura, mano_derecha)
[ok] la fractura queda relacionada con 3 partes anatómicas, sin una sola regla por caso

T ⊨ injuryOf(fractura_del_escafoides, brazo_derecho)

Esta es la respuesta al ejercicio: la característica que hace falta son las cadenas de propiedades, nuevas en OWL 2 (R de SROIQ). Un axioma, y vale para cualquier lesión sobre cualquier parte de cualquier todo, directo o indirecto. En OWL 1 esto no se podía escribir: había que enumerar los casos.

El precio, que el ejercicio no menciona

[ok] Injury ⊑ =1 injuryOf.BodyPart es legal mientras injuryOf sea simple
[ok] con la cadena declarada, la MISMA restricción rechaza la ontología entera

con la cadena: Injury ⊑ =1 injuryOf.BodyPart sale de OWL 2 DL

Aquí está lo que importa del capítulo. Al declarar la cadena, injuryOf deja de ser una propiedad simple, y OWL 2 DL prohíbe usar propiedades no simples en: restricciones de cardinalidad, Self, y las declaraciones de funcional, inversa funcional, irreflexiva y asimétrica. Es una restricción global de sintaxis, no un resultado lógico: la ontología no es inconsistente — es que no es una ontología OWL 2 DL, y el razonador no la acepta siquiera.

Por qué esto se detecta tarde y duele

El fallo no se parece a un fallo lógico. No hay clase insatisfacible ni inconsistencia: hay un rechazo del razonador que se lee como un error de herramienta.

Y la causa está en otro archivo, escrito otro día. La cardinalidad puede llevar meses funcionando; el que rompe la ontología es quien añade la cadena, y lo que peta no es su axioma, sino el ajeno. En un proyecto con varios modeladores esto es lo que convierte una restricción global en una tarde perdida.

La lectura práctica: decidir pronto qué propiedades van a llevar cadena, porque esa decisión les prohíbe para siempre las cardinalidades. Y si de verdad hacen falta las dos cosas, hay que partir la propiedad en dos —una simple para contar, otra con cadena para propagar— y relacionarlas con una inclusión.

Qué deja el caso

1. Las cadenas son la característica de OWL 2 que más cambia el modelado parte-todo. Sustituyen familias enteras de axiomas por uno.
2. La transitividad no propaga entre propiedades distintas. Es el error de partida más común en mereología.
3. OWL 2 DL impone restricciones globales, ajenas a la lógica, para seguir siendo decidible. Violarlas no produce una inferencia rara: produce una ontología que no es del lenguaje.
4. Simple o no simple es una propiedad de la propiedad, no del axioma. Se decide una vez y afecta a todo lo demás.

---

Los ejercicios (§4.4)

Review question 4.1. «How does OWL/OWL 2 differ from a DL language?» — OWL es un estándar del W3C: una sintaxis de intercambio, con serializaciones, IRIs, importaciones y versionado, sobre una DL. La lógica es SROIQ(D); lo demás es infraestructura. Además impone restricciones globales que la DL no tiene, como la de las propiedades simples del caso de estudio.

Review question 4.2. «What were the motivations to develop OWL 2?» — Limitaciones prácticas detectadas al usar OWL 1: falta de cardinalidades cualificadas, imposibilidad de propagar por cadenas, metamodelado inviable sin caer en OWL Full, y ausencia de fragmentos con garantías de complejidad para ontologías muy grandes o con muchos datos.

Review question 4.3. «What are the new features in OWL 2 DL compared to OWL-DL?» — La tabla de §4.2.1 de más arriba: cardinalidades cualificadas, cadenas de propiedades, propiedades reflexivas/irreflexivas/asimétricas/disjuntas, Self, claves, punning y tipos de dato enriquecidos.

Review question 4.4. «Which is the required format one has to serialise an OWL ontology in?» — RDF/XML. Es la única obligatoria.

Review question 4.5. «List all the species of OWL (both standards).» — OWL 1: Lite, DL, Full. OWL 2: DL, Full, más los perfiles EL, QL y RL.

Review question 4.6. «Which language features can be used on simple object properties only?» — Cardinalidades (cualificadas o no), Self, y las declaraciones de funcional, inversa funcional, irreflexiva, asimétrica y disjunta. Una propiedad deja de ser simple si es transitiva o si aparece como cabeza de una cadena. Está verificado en el caso de estudio de esta página.

Review question 4.7. «What are OWL 2 QL, RL and EL tailored toward?» — QL, consultas sobre grandes volúmenes de datos (reescritura a SQL); RL, implementación con motores de reglas; EL, ontologías terminológicas muy grandes. La tabla de §4.2.2 de más arriba.

Review question 4.8. «What is the major advantage of the OWL 2 Profiles over OWL 2 DL and OWL 2 Full?» — Garantías de complejidad: razonamiento en tiempo polinómico (o mejor) frente a 2NExpTime en DL e indecidibilidad en Full.

Review question 4.9. «Which four ‘parameters’ are considered for complexity?» — Data, taxonomic, query y combined complexity (§4.2.4). Y son cotas de peor caso.

Review question 4.10. «Describe in one sentence the purpose of DOL.» — El Distributed Ontology, Model and Specification Language es un metalenguaje estándar para relacionar y combinar ontologías escritas en lenguajes distintos, con sus alineamientos y traducciones, sin obligar a que todas estén en el mismo formalismo.

Exercise 4.1. «Complete Table 4.4.» — Ejercicio de tabla sobre qué construcción admite cada perfil; el propio enunciado sugiere repartirlo. Criterio propio: la tabla no se reproduce aquí porque copiarla no aporta nada — lo que sí es reutilizable es el criterio de por qué falta cada casilla: EL no tiene ni negación ni ∀, QL no tiene cardinalidades ni ⊔ en el lado derecho, y RL restringe qué puede aparecer a cada lado de un ⊑ para que la regla sea ejecutable.

Exercise 4.2. «…an injury to a bone in your hand is also an injury to your hand… Which OWL 2 DL feature do you need for this?» — Es el caso de estudio de esta página. La respuesta: cadenas de propiedades, injuryOf ∘ partOf ⊑ injuryOf, con partOf transitiva. Verificado, con la salvedad sobre propiedades simples que el enunciado no pide y que es la mitad de la respuesta.

Exercise 4.5. «Add Bicycle ⊑ ≥2 hasComponent.⊤, inspect the least expressive OWL species; update to Bicycle ⊑ ≥2 hasComponent.Wheel, inspect again. What is the main difference?» — La primera es una cardinalidad sin cualificar: N, y cabe en OWL 1 DL (SHOIN). La segunda es cualificada: Q, y exige OWL 2 DL (SROIQ). La diferencia que busca el ejercicio es que la especie mínima sube: el mismo axioma, aparentemente más preciso, deja fuera a toda herramienta que solo soporte OWL 1.

Exercise 4.6. «Create a new ontology, add the vegan and vegetarian from Exercise 3.2, and check both O ⊢ Vegan ⊑ Vegetarian and O ⊢ Vegetarian ⊑ Vegan.» — Hecho y verificado en el capítulo 3: la primera se deduce, la segunda no. No se repite aquí.

Exercises 4.3, 4.4, 4.7, 4.8. Ejercicios de herramienta (Protégé, el DL axiom renderer, comparar entornos). Criterio propio: el equivalente en este trabajo es la cadena owlready2 + HermiT, que da lo mismo de forma reproducible y ejecutable en CI; los artefactos guardan anatomia.owl en RDF/XML precisamente para poder abrirlo en Protégé y ver la cadena declarada.

---

Lo que hay que llevarse

1. OWL 2 DL = SROIQ(D) + estándar. La semántica está en el capítulo 3; aquí están las reglas del comité.
2. Los perfiles no se eligen por potencia, sino por qué operación debe ser barata.
3. Las cadenas de propiedades son lo más útil y lo más caro de OWL 2: resuelven la propagación parte-todo y a cambio inutilizan la propiedad para contar.
4. RDF/XML es el único formato obligatorio, por incómodo que sea leerlo.

Salvo los enunciados citados, el análisis y las resoluciones de esta página son criterio propio, verificados con HermiT. Numeración y enunciados tomados del PDF en /libro, no de ediciones web que renumeran las secciones.

Para la defensa — lo que te van a preguntar de aquí

«¿Por qué OWL 2 y no OWL 2 EL, o directamente RDFS?»

Por lo que hay que poder decir. El caso de estudio de este capítulo necesita cadenas de propiedades y el del capítulo 3 necesita negación y clases definidas; ninguna de las dos cosas está en RDFS, y la negación tampoco en EL. La decisión no es «el más potente» sino el fragmento mínimo que soporta los axiomas que el dominio exige — y cuando esos axiomas se conocen, el perfil está determinado.

«¿Qué diferencia hay entre OWL 2 DL y OWL 2 Full?»

Full permite tratar clases como individuos sin restricción y es indecidible: no hay razonador completo posible. DL impone restricciones globales —entre ellas la de las propiedades simples— para mantenerse dentro de SROIQ(D), que es decidible. En un trabajo que se apoya en lo que el razonador confirma, salirse de DL es quedarse sin la única evidencia disponible.

«¿Qué es una propiedad simple y por qué importa?»

Una propiedad que no es transitiva ni cabeza de una cadena. Importa porque OWL 2 DL prohíbe usar las no simples en cardinalidades, Self, funcionalidad, irreflexividad y asimetría.

Por qué es una respuesta fuerte: está medido. En el caso de estudio, Injury ⊑ =1 injuryOf.BodyPart es válida hasta que se declara injuryOf ∘ partOf ⊑ injuryOf; a partir de ahí el razonador rechaza la ontología entera, sin que nada sea lógicamente inconsistente. Es la clase de fallo que no se detecta razonando, solo ejecutando.

«¿Las cotas de complejidad significan que tu ontología será lenta?»

No. Son cotas de peor caso, y Keet lo dice explícitamente en §4.2.4: no dicen nada sobre lo que tarda una ontología concreta. Sirven para descartar —si el peor caso es indecidible, no hay herramienta que valga— pero el rendimiento real se mide, no se deduce.

«¿Por qué serializas en RDF/XML si es el formato más incómodo?»

Porque es el único obligatorio en el estándar (§4.2.3) y por tanto el único que garantiza que cualquier herramienta conforme lea el archivo. Para leerlo o escribirlo a mano se usa Manchester o funcional; para publicarlo e intercambiarlo, RDF/XML.